Can your sign-up or checkout flow be finished with a keyboard alone? A test script and the focus rules behind it

Why one flow and a named list of criteria

"Make the site accessible" cannot be accepted, because nobody can say when it is finished. WCAG 2.2, the W3C Recommendation, is a set of testable success criteria at three levels, and a fair piece of work names the criteria and the pages. W3C's conformance rules add a catch for flows: where a page is one step of a process, all pages in the process must conform at the level claimed, so a sign-up or checkout flow is judged as a whole. That is a reason to choose one short flow, agree its screens and list the criteria, instead of testing a whole site.

Four criteria cover keyboard use, and they fail for different reasons.

• 2.1.1 Keyboard (A): all functionality is operable through a keyboard interface.
• 2.4.3 Focus Order (A): focus moves in an order that preserves meaning and operability.
• 2.4.7 Focus Visible (AA): there is a visible keyboard focus indicator.
• 2.4.11 Focus Not Obscured (Minimum) (AA, new in 2.2): a focused component is not entirely hidden by author-created content.

A five-minute keyboard test of one flow

Put the mouse aside. On the first screen of the flow, press Tab to move forward and Shift+Tab to move back, Enter or Space to activate buttons and links, and the arrow keys inside menus, radio groups and similar widgets. Complete the flow from first screen to last, then go back and repeat on a phone-sized window. Write down every screen and control where something fails. This does not replace a full evaluation, but it finds the faults that stop people altogether.

• A control that cannot be reached or operated is a 2.1.1 failure.
• Focus jumping to an unrelated place, or going to the footer before the form, is a 2.4.3 concern.
• No visible outline on the focused control is a 2.4.7 failure.
• A focused field completely hidden behind a sticky header or banner is a 2.4.11 failure.

The cause of most hidden-focus failures

W3C's guidance for 2.4.11 names the usual culprits: sticky headers and footers, cookie banners and non-modal dialogs that overlay the page. Only complete hiding fails at Level AA; partial overlap passes, though the stricter AAA criterion wants no overlap. The guidance suggests CSS scroll padding so focused items scroll clear of a fixed header, making a banner modal so it takes focus, or closing notifications when they lose focus. The fix belongs in the layout, not in telling people to scroll.

• Check each form field while tabbing with the cookie banner open and closed.
• Check at a narrow width, where fixed elements cover more of the screen.
• A custom dialog must take focus and return it when closed.

What a checker misses

Automated checkers help a first pass, but W3C states that no tool alone can determine whether a site meets accessibility standards and that knowledgeable human evaluation is required. A keyboard trap, a confusing focus order and a banner that hides a field are the kinds of fault a person finds by using the flow. Treat a clean checker result as a start. Also note what you cannot test yourself: screen reader announcements, voice control and use by people with disabilities need their own testing.

• Record both the tool used and the manual test for each criterion.
• Do not claim conformance for the site from one flow.

What the paid job covers and how it is accepted

Our accessibility job (posted test price from £595, untested, quoted after we see the flow) takes one page or up to five connected screens and a checklist of WCAG 2.2 criteria agreed in writing, tests by hand with a keyboard and one agreed screen reader and browser, fixes the failures and re-tests every criterion. It is accepted when each criterion is recorded as pass or not applicable for each screen, a keyboard-only run completes the flow with a visible focus indicator and nothing focused fully hidden, and you sign off. It is not a legal statement or a certificate. Send the flow and why it matters now in your first enquiry, not credentials.