In the digital landscape, we often design for the mouse. We obsess over hover states, smooth cursor transitions, and the “joy of use” for pointer users. Yet, for users relying on keyboards, screen readers, or alternative input devices, the mouse stays invisible.
Session 3 of our Trusted Tester study group tapped into Topic 4: Keyboard Access and Focus. As you already know, the Trusted Tester Process is based on WCAG 2.0, but lucky us, the relevant success criteria on this topic stay the same in WCAG 2.2.
4.A Keyboard Access: The Foundation
The rule is simple but non-negotiable: All functionality must be operable through a keyboard interface.
This isn’t just about links and buttons, it covers dropdown menus, form fields, and even tooltips containing essential information. For example, during the session, we tested a shipping information form. While most fields were accessible, the “City” and “Area Code” input fields were completely unreachable via the Tab key. Even though they were visible on the screen, the lack of keyboard access meant the form was unusable for keyboard users.
If a user can’t click it with a mouse, they must be able to reach it with Tab, Enter, Space, or arrow keys. Setting custom key combinations for specific interactions is also acceptable, as long as you tell users what the combination is and it doesn’t include timing requirements because… that’s a spoiler for the next one:
4.B Keystroke Timing: No Race Conditions
Users should never have to race against the clock to activate a feature. This is not the great ticket master war, it’s WCAG 2.1.1 which explicitly states that functionality must not require specific timings for individual keystrokes.
In the session, our example was a survey tool where the only way to drag and drop a question type via keyboard was to hold Ctrl + Right Arrow for three full seconds. While the feature was technically keyboard accessible, the timing requirement excludes users with motor impairments or slower reaction times.
If a function requires a long-press or a timed sequence, there must be an alternative method that doesn’t rely on timing e.g. a simple Ctrl + C / Ctrl + V shortcut (which you also tell users about!).
4.C Keyboard Traps: Escaping the Loop
A keyboard trap occurs when a user moves focus into a component (like a modal dialog or a custom menu) and cannot move focus out using standard navigation keys (Tab, Shift+Tab, Escape).
In our passing example, we tested a file upload dialog. The focus cycled logically through the inputs, and pressing Esc or the “X” button returned the user to the main page. In this case, the loop within the dialog is intended behavior, not a trap.
However, in our failing example, a similar dialog box had an “X” button that was visually present but not focusable. The focus looped endlessly between two links inside the dialog. The user was stuck. Without a documented custom shortcut to escape, this was a hard fail.
Rule of Thumb is: If you can’t get out of a component with Tab or Escape, you likely have a trap on your fingers.
4.D Focus Visibility: Seeing Where You Are
For mouse users, hovering reveals the target. For keyboard users, the focus indicator is their only map.
WCAG 2.4.7 requires a visible mode of operation where the keyboard focus indicator is visible. We saw a login page where the focus indicator was a subtle, light-gray dotted line that blended perfectly into the background. Technically, it existed, but it was invisible to anyone with low vision or poor eyesight.
Another example was a test page where links had tooltips on hover, but no focus when tabbed to. A tooltip is not a focus indicator. If you can’t see where the focus is, you can’t navigate.
Tooltips are not Focus Indicators
Design Note: I know custom focus states are tempting, but don’t remove the default browser outline unless you replace it with something highly visible and high-contrast.
4.E Focus Change of Context: Don’t Surprise Me
When a user tabs to an element, nothing should happen automatically. No new windows should open, no pages should redirect, and no content should change unless the user explicitly activates the element (e.g., presses Enter).
We tested a “Peanuts” link that, upon receiving focus, immediately opened a new window and redirected the user. This is a Change of Context triggered solely by focus. It disorients users, especially those using screen readers who might be exploring a page and suddenly find themselves in a completely different context.
Similarly, a registration form that auto-submitted and showed a “Success” dialog just because the user tabbed to the submit button (without even pressing Enter) was a failure. Repeat after me: Focus is not activation.
4.F Focus Order: The Logical Flow
Finally, the sequence in which focus moves must preserve the meaning and operability of the page. In a well-implemented form, the tab order follows the visual flow: Name -> Address -> City -> State.
And then you have things like our failing example: A newsletter subscription page had a chaotic tab order that jumped from the “Name” field to the “Business Digest” newsletter, then back to “Street Name,” then back to another newsletter choice (probably also why subscribing to A11y News was not an option here).
This remixed order destroys the logical narrative of the form. While the user could eventually fill it out, the jumping focus makes it unnecessarily harder to. Alas, the Dark Souls of Accessibility strikes again!
Note: The focus order doesn’t have to be strictly top-to-bottom, but it needs to be logical for the target demographic. It must make sense for the content’s structure and the language setting, e.g., right-to-left could be appropriate for Arabic, Hebrew, or traditional-style Japanese formatting. This is a cultural question to consider in the design process.
SOCIAL SHARE CARD GENERATOR