Pages and UI Elements to Check When Changing Website Colors

TIPS

After changing a website’s primary color, is the job done once the homepage button looks right? Colors are reused across pages and interactive components, so a form error, mobile sticky button, or other less visible screen may still show the old color. This guide lists the pages and UI (user interface) elements to check before and after a color change, helping you catch unintended effects.

List the pages to inspect by type

First, identify where the component you’re recoloring appears. Even pages based on the same template (a shared page layout) may need separate review if their backgrounds and surrounding elements differ. Use the following list for the page types your website actually includes.

Homepage and shared areas: header, navigation, footer, announcements, main buttons, and mobile sticky buttons
Articles, products, and service details: headings, text links, text over photos, cards, comparison tables, and booking or purchase actions
Listings and search results: category controls, filters, selected items, and the screen shown when no results are found
Forms and checkout flows: field boundaries, required indicators, error messages, review steps, completion screens, and disabled buttons
Account areas: sign-in, account dashboard, cart, checkout, and notifications, where applicable
Overlaid and expandable UI: modals (small windows in front of the page), tabs, collapsible menus, and tooltips (brief explanatory labels)
Exception pages: 404 pages (not found), maintenance notices, and older campaign pages

Instead of looking at every URL in the same way, choose representative pages that share components and additional pages where backgrounds or states differ. There is no need to create or test features that the website does not have.

Example: changing a booking button from blue to teal

Imagine a booking service changing the background of its booking button. HEX color codes specify web colors using a “#” followed by six hexadecimal digits. Previously, the button used blue #1D4ED8 with white #FFFFFF text, a contrast ratio of approximately 6.70:1. After the change, it uses teal #0F766E with white #FFFFFF text, a ratio of approximately 5.47:1. Both exceed the 4.5:1 minimum for normal-sized text.

Check not only the homepage’s “Book Now” button but also the same action in plan listings, plan details, booking forms, and review screens. Where the surrounding background isn’t white, separately check whether the button is identifiable and its text remains clear against the button background. Also make sure the color change has not unexpectedly altered button labels or destinations.

Keep ordinary body text dark gray #1F2937 on white #FFFFFF, which has a contrast ratio of approximately 14.68:1. For a form with a white #FFFFFF background, an input boundary in #64748B has approximately 4.76:1 contrast against that background. Compare the before-and-after screens to make sure body text and field borders did not change unintentionally along with the booking button.

Record your checks with columns for “Page / Component / Before-and-after colors / Normal or selected state / Desktop or mobile / Result.” The same button might pass on the homepage but need additional adjustment in a form because the surrounding background differs.

Check interaction states and the published result

Test buttons not only in their default state but also on hover (when a pointer is placed over them), while pressed, when showing keyboard focus, and when disabled. For forms, check empty, editing, error, and completed states, and make sure meaning is never conveyed through color alone. Disabled controls have exceptions to some contrast requirements, but their unavailable state should still be understandable.

Under WCAG (Web Content Accessibility Guidelines) Level AA, normal-sized text generally needs a contrast ratio of at least 4.5:1 against its background, and large text needs at least 3:1. Visual information required to identify controls or meaningful status icons generally needs at least 3:1 against adjacent colors. Measure the actual colors used together; a result calculated against one background cannot simply be reused for another.

Compare desktop and mobile views before publishing. After deployment, review representative pages again once the updated styles are being served rather than an older cached version. Record each changed color role, the relevant URLs, states tested, and any outstanding issues. The same checklist can then be reused for future color changes.