Measure the relevant rendered colour pairs in each real interaction state, keep meaningful focus/state cues and verify the actual journey rather than accepting a default screenshot or scanner score.
Review a website control in every state that readers can encounter. A readable default button can become unreadable on hover if the background changes but its label does not. Keyboard focus, selected options, errors and disabled controls raise different questions from the initial screenshot.
This guide uses official W3C WAI and browser documentation checked on 13 October 2026. It provides a focused contrast and interaction-state review, not a WCAG certificate or legal-compliance finding for a website. No colour combination or real interface was measured for this guide.
Make an inventory of controls and states
Choose representative text links, primary and secondary buttons, icon controls, fields, checkboxes and selected navigation items. Record the page background and any alternative surface on which each component appears. The same button can need different surrounding-colour checks in a white article and a tinted comparison panel.
| State | What to inspect | Common missed detail |
|---|---|---|
| Default | Label, meaningful icon and control identification | A low-contrast secondary action is still active |
| Hover | New text, background and surrounding colours | Only the background changed |
| Keyboard focus | Visible indication and unobscured focused control | A ring is clipped or covered |
| Selected or error | Meaningful state cue and accompanying wording | Colour is the only explanation |
| Disabled | Actual inactive behaviour and understandable reason | A pale control is visually disabled but still operable |
For a fictional booking form, test its initial state, the focused date field, an unavailable option and the correction after an error. This reveals different responsibilities from checking the submit button alone.
Measure text against its actual background
WAI’s Contrast Minimum explanation describes 4.5:1 for ordinary text and 3:1 for qualifying large text, with stated exceptions. Large text is based on the criterion’s size and weight definition; making a small label bold does not automatically qualify it.
Use the rendered foreground and background colours, including the effect of transparency or an image behind the text. A brand palette entry alone does not tell you the final pair. Test the weakest relevant background area when text crosses a gradient or variable photograph.
Record the ratio, text role, size/weight and state with the result. Do not round a value below a required threshold upward to call it a pass. If the text needs repair, adjust the relevant foreground/background treatment and recheck it rather than increasing all website type merely to seek a different threshold.
The typography guide covers reading size, zoom and spacing. A comfortable size and a sufficient contrast ratio are related design concerns with separate acceptance evidence.
Identify meaningful non-text information
WAI’s Non-text Contrast explanation applies a 3:1 comparison with adjacent colours to visual information needed to identify active controls and their states, and relevant graphical objects, with exceptions. It does not require every decorative border or shadow to meet that ratio.
Ask what makes a control identifiable. A field may depend on its boundary; a checkbox depends on a discernible selected indicator; an image-only control may depend on its icon. Check the meaningful information and its actual adjacent colours rather than measuring an unrelated flourish.
Do not confuse this with a universal 3:1 comparison between a button’s default colour and its hover colour. The criterion does not require those separate, non-adjacent states to contrast against each other. Each state must preserve the relevant information against its own surroundings.
Check hover without depending on it for access
Move the pointer over the control and inspect both text and background. A pale-blue button may use a blue label at rest, then acquire a darker blue background on hover. Leaving the same label colour can reduce readability; choose and measure a coherent pair for the hovered state.
Also inspect links and icons nested in the control. A broad button rule may change its background while a more specific link rule retains another foreground. Repair the responsible component style instead of adding a global override that affects unrelated links.
Mozilla’s hover media-feature reference distinguishes input mechanisms that can conveniently hover from those that cannot. Essential labels and actions should remain discoverable without a mouse-hover reveal. Verify the normal touch interaction as a separate route.
Keep keyboard focus visible and reachable
WAI’s Focus Visible explanation requires a visible indication when an operable component has keyboard focus within its scope. Use Tab and Shift+Tab through the actual page and identify where focus lands. A hover colour change is not a substitute for that keyboard feedback.
Mozilla’s focus-visible reference explains browser heuristics for showing a focus indication. Preserve a reliable indicator when customising it; removing the outline without a replacement can make the keyboard position disappear.
Inspect the indicator on every relevant surface and with hover and focus together. Clipping by a rounded container, an overflow rule or an overlay can make an otherwise strong ring invisible. Correct the boundary rather than merely making the ring thicker.
Focus Not Obscured Minimum addresses a focused component being entirely hidden by author-created content. Its Level AA requirement differs from the stronger preferred outcome of no obscuring. Review sticky headers and notices while tabbing and scrolling, not only a top-of-page screenshot.
Focus Appearance adds a separate Level AAA visibility criterion. Do not relabel its complete size/change requirements as the basic Focus Visible criterion or claim that passing one ring check establishes all focus-related requirements.
Communicate state with more than colour
WAI’s Use of Color explanation addresses information conveyed only through colour. An error can include clear text and a meaningful relationship to the field; a selected option can use a discernible mark as well as a different fill.
In the fictional form, “Choose an available date” explains the correction more usefully than a red outline alone. A link in ordinary article text benefits from a clear visual link treatment rather than depending solely on a subtle hue difference.
Keep the full error and recovery route in view. The accessible-form review covers associated instructions, error discovery and truthful confirmation. Changing the error colour cannot repair an unannounced or unreachable message.
Treat disabled controls as a real state
The contrast criteria contain exceptions for inactive controls. That does not turn every muted label, secondary button or read-only value into an exempt disabled element. Establish the actual interaction state before applying an exception.
Mozilla’s disabled-attribute documentation distinguishes supported disabled controls from read-only controls and ordinary styled elements. Native disabled controls are not focusable or submitted with the form. A grey link is not disabled merely because it looks inactive.
Explain why a necessary action is unavailable and how to proceed through visible, reachable guidance. Check that the control becomes understandable and usable when enabled. An exemption is not a reason to make a user’s next step impossible to discover.
Use inspection tools and real interaction together
Chrome’s CSS reference documents forcing pseudo-classes in the Styles panel. This helps hold hover, active or focus-visible styling while inspecting computed values. A forced state is useful styling evidence, not proof that keyboard focus actually reaches that element.
Run the real pointer, keyboard and touch routes after the style change. Check representative desktop and narrow layouts, long labels and relevant overlays. The mobile and keyboard navigation guide covers the wider menu journey.
Retain a component-level acceptance record
- Identify the component, surface and relevant interaction states.
- Measure applicable text and non-text contrast using the rendered colours.
- Check genuine keyboard focus, combined states and any obscuring content.
- Verify meaningful state cues and the actual disabled/enabled behaviour.
- Repair the responsible shared style and retest representative uses.
- Record the observations and anything outside the focused review.
Use the launch checklist for the broader release. A useful result here is a set of readable, identifiable and understandable states with recorded evidence. A single clean scan or an attractive default screenshot cannot establish that the whole interaction works.
Sources and verification
Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- W3C WAI: Contrast MinimumChecked Ordinary versus qualifying large-text thresholds, actual foreground/background comparison and stated exceptions.
Limits: No real pair is measured, no small bold label automatically qualifies as large text, and no whole-site conformance is claimed. - W3C WAI: Non-text ContrastChecked Required control/state/graphic information contrasts with adjacent colours; decorative boundaries and separate non-adjacent hover/default colours have different scope.
Limits: Not every border requires 3:1; the disabled and unmodified-user-agent exceptions remain distinct. A threshold is not rounded upward to create a pass. - Mozilla: hover media featureChecked Primary input mechanisms can differ in whether they conveniently support hover.
Limits: A hover simulation is not a touch-route result and essential access is not made dependent on hovering. - W3C WAI: Focus VisibleChecked A visible focus indication needs to remain available for keyboard operation within the criterion scope.
Limits: A colour ratio or hover effect alone does not prove keyboard reachability or all focus criteria. - Mozilla: focus-visibleChecked Browser heuristics govern focus-visible matching; custom styling should retain useful keyboard feedback.
Limits: No universal always-visible mouse ring or CSS outline-removal recipe is prescribed. - W3C WAI: Focus Not Obscured MinimumChecked Level AA prevents an author-created layer entirely hiding the focused component; stronger no-obscuring preference is distinct.
Limits: Partial obscuring is not misrepresented as automatic failure of this minimum criterion. No sticky-header or overlay test was performed. - W3C WAI: Focus AppearanceChecked The additional Level AAA focus-appearance criterion is distinct from basic Focus Visible.
Limits: Its full size/change conditions are not incorrectly relabelled as the Level AA Focus Visible criterion or represented as tested. - W3C WAI: Use of ColorChecked Meaningful information/state cues must not rely only on colour in the relevant scope.
Limits: No universal underline-only implementation is imposed; field relationship, message discovery and operation require their own checks. - Mozilla: disabled attributeChecked Supported native disabled controls differ from read-only or merely grey styled elements and have focus/submission consequences.
Limits: Visual muting is not treated as proof of inactivity or a universal contrast exemption. - Chrome DevTools: CSS referenceChecked Force pseudo-classes for focused style inspection, including hover and focus-visible.
Limits: Forced styling is not proof of real keyboard focus, touch behaviour or a performed contrast measurement.