Can keyboard users see which customer page control is active?

Find the point where keyboard users lose their place

A customer tabs from a search box to a filter, then presses Enter and nothing expected happens. The problem may not be the key itself: the page may have moved focus to a control whose focused state is invisible. A sighted keyboard user needs to know which link, button or field will receive the next action. WCAG 2.2 Focus Visible, at Level AA, calls for a mode in which the keyboard focus indicator is visible. Start with the customer journey rather than one screenshot: visit the page using Tab and Shift+Tab, and mark each point where the focused item cannot be identified without guessing.

A focus indicator is a state cue, not decoration around every control. It might be a browser outline, a deliberate border or another clear visual change, provided the user can reliably identify the active element. A hover style alone does not help a person navigating without a pointer. Nor does changing only a subtle shade that disappears on a product photo or dark panel. Before specifying a new brand treatment, see whether the browser default has already been suppressed by a sitewide CSS reset. Restoring an effective default is often the fastest repair, then custom styling can follow only where it improves clarity.

Keep this decision separate from the order of keyboard focus. A page can have a visible outline but a confusing tab sequence; it can also have a sensible sequence with no visible cue. Both deserve testing, but this guide concentrates on how the current target is shown. Likewise, a modal may require deliberate focus placement and containment, yet the visual indicator on its close button is still a separate styling requirement. Write an inventory of interactive components used across templates: links, menus, cards with actions, filters, form fields, disclosure buttons and checkout controls. Shared components let one fix reach many pages.

Choose a style that remains visible in context

W3C explains that a focus indicator needed to identify a component is visual information subject to the Non-text Contrast criterion. Its meaningful pixels need at least 3:1 contrast against adjacent colours at Level AA, subject to the criterion’s exceptions. This is a different measure from the contrast of ordinary body text. Test the actual indicator against the pixels beside it: a ring that contrasts with a white page may vanish when a button sits on a light photograph. A two-colour outline or solid offset can help across mixed backgrounds, but check the rendered result rather than assuming a colour token guarantees it.

WCAG 2.2 also defines Focus Appearance at Level AAA. It describes a stronger size and change-of-contrast test for the focus indicator; it is not the same as the Level AA Focus Visible requirement. A team can use its guidance to design a more robust indicator, especially for small icons, without incorrectly telling customers that every AAA detail is required for AA. Record which standard the project is checking and which test method was used. That distinction prevents a review from passing a nearly invisible one-pixel change as good practice or failing a valid default browser outline under the wrong criterion.

The CSS :focus-visible selector can show an indicator in situations where the browser judges a visible cue useful, often during keyboard navigation, while reducing unwanted rings after some pointer interactions. It is a styling tool, not proof that every custom widget works with a keyboard. Use a clear fallback for older or unusual environments and test programmatic focus, text inputs and controls after a mouse-to-keyboard switch. Never remove outlines globally and then depend on a single selector that misses elements in a component library. The user must still have a mode in which the current keyboard target remains visible.

Check that the focused control is actually on screen

A bright outline cannot help when a sticky header covers the focused button. WCAG 2.2 Focus Not Obscured (Minimum), also Level AA, addresses author-created content that entirely hides the focused component. Check pages with fixed navigation, cookie notices, floating chat launchers and expanding filters. Tab slowly near the top and bottom of the viewport; do not assume that scrolling automatically places every item clear of overlays. A partially visible control may meet the stated minimum but still be awkward, so use the customer task to judge whether more space or scroll offset is needed.

Zoom and narrow screens change where focus rings are clipped. A custom outline may be cut off by an ancestor with overflow hidden, by a card boundary, or by a carousel viewport. A ring that worked on the desktop may be lost on a mobile layout when buttons wrap. Test the component at common responsive widths and high browser zoom, including when validation messages or translated Chinese labels make a control taller. Keep the indicator aligned with the element that will activate; a ring around the whole card while focus is on a tiny nested link can mislead the user about the clickable target.

Do not rely on focus colour alone to imply what Enter or Space will do. Labels and control semantics still matter. A visible outline around a decorative container is confusing if the actual interactive child has no focus. Native buttons and links often give predictable keyboard behaviour; custom clickable divs require extra semantics and event handling before styling is meaningful. In an audit, note separately whether the element receives keyboard focus, whether its focus is visible, whether its name explains the action, and whether the expected key activates it. A pass on one dimension does not repair failure on another.

Test a retailer journey, not only a component sheet

Imagine a shopper using a keyboard to search for a replacement part. They enter a query, move to a filter, open a product, choose a variant and reach the order review. The design team has a blue ring on white input fields, but the product cards sit on pale blue and the variant controls sit over a photograph. On those backgrounds the same ring is hard to spot. The team tests each rendered state, keeps a high-contrast focus treatment across backgrounds, and checks that disabled variants do not appear to be available choices. The exercise measures the ability to follow a task, not the beauty of one isolated component.

Have a tester begin with the keyboard alone and speak aloud which control they think has focus before pressing a key. Record the first uncertain point, the background, zoom level and whether an overlay is open. Then compare the same path in English and Traditional Chinese; longer labels may wrap and alter the focus shape or position. Repeat after a validation error, because new messages can shift controls under a fixed header. Include at least one user who is unfamiliar with the page if possible. A developer who knows the DOM order may unconsciously fill in missing visual information.

When a defect is found, fix the shared component and rerun the journey. If the issue is only on one promotional card, repair that card too, but check whether its style pattern recurs elsewhere. Document a small visual acceptance set: a text link, an icon button, a form field, a filter chip and a control near a sticky element, on both light and dark surfaces. Manual keyboard testing remains necessary because an automated checker cannot know whether a customer can comfortably track a faint ring across a busy image. Capture screenshots as evidence of the tested states, with no claim that an untested page is covered.

Keep focus visible as the site changes

Assign the focus style to design-system components and add it to the acceptance criteria for new controls. Ask reviewers to inspect hover, focus, disabled and error states together, because a later colour change can break only one of them. A new sticky promotion or chat panel can hide an otherwise excellent indicator, so revisit complete journeys after layout changes. The ongoing rule is concrete: a keyboard user can name the current target, see enough of it on screen, and predict the action before activation. If any of those observations fails, the page needs repair regardless of how polished the pointer experience looks.