Focus order checklist
Put the mouse aside and walk one page of your site with the Tab key, one step at a time. Each step says what to press, what a pass looks like and which WCAG criterion it tests; you mark it Pass or Fail, add a note, write down the order the focus took, and print or copy the record for whoever fixes the site.
Walk a page with the keyboard
Focus order checklist — altstamp.com
Open your own page in another tab and do one step at a time, then mark it here. Nothing is sent anywhere: the walk stays in this browser on this device until you reset it.
Steps checked
Step 1 of 9: Start from the address bar
- 2.4.3Focus OrderA
- 2.4.7Focus VisibleAA
- Do this
- Open the page, click once in the browser's address bar, put the mouse aside and press Tab once. On a Mac in Safari, first turn on Safari > Settings > Advanced > "Press Tab to highlight each item on a webpage".
- A pass looks like
- The first press lands on something at the top of the page and you can see exactly what it is.
- A fail usually looks like
- Nothing seems to happen, or the first visible stop is halfway down the page.
Step 2 of 9: Find the skip link
- 2.4.1Bypass BlocksA
- Do this
- Look at that first stop. If it reads "Skip to content" (or similar), press Enter, then press Tab once more.
- A pass looks like
- A skip link is the first or second stop, and after Enter the next Tab lands inside the main content, past the menu.
- A fail usually looks like
- There is no skip link, or it scrolls the page but the next Tab goes back to the menu.
Step 3 of 9: Reach every control
- 2.1.1KeyboardA
- Do this
- Keep pressing Tab down the whole page. Use Enter on links and buttons, Space on checkboxes and buttons, and the arrow keys inside radio groups and select boxes.
- A pass looks like
- Every link, button, field, menu and pop-up you could use with a mouse can be reached and used from the keyboard.
- A fail usually looks like
- A "Book now" or "Add to cart" that the ring skips, a menu that opens only on mouse hover, a fake button that ignores Enter.
Step 4 of 9: Check the order
- 2.4.3Focus OrderA
- Do this
- Watch where the ring goes as you Tab. Write each stop in the list below the steps, in the order you meet it.
- A pass looks like
- The ring moves the way the page reads: header, then content top to bottom, then the footer.
- A fail usually looks like
- The ring jumps from the header to the footer and back, or skips around a form so fields come out of order (often a tabindex above 0).
Step 5 of 9: Keep the ring in sight
- 2.4.7Focus VisibleAA
- Do this
- On every stop, ask: can I see which item has focus without hunting for it?
- A pass looks like
- Every stop shows a ring, underline, colour change or other mark you can see from a normal distance.
- A fail usually looks like
- Stops where focus disappears, usually from an outline: none in the theme, or a faint ring that blends into the background.
Step 6 of 9: Nothing covers the focus
- 2.4.11Focus Not Obscured (Minimum)AA
- Do this
- Tab down a long page and Shift+Tab back up, with any cookie banner or chat bubble still open. Try it at the window size you use most and on a narrow window.
- A pass looks like
- The item with focus is never completely hidden behind a sticky header, sticky footer, cookie banner or chat button.
- A fail usually looks like
- Focus goes behind a sticky header or a cookie bar and you lose track of it for one or more stops.
Step 7 of 9: Tab out of everything
- 2.1.2No Keyboard TrapA
- Do this
- Tab into each embedded thing: a video player, a map, a booking or payment frame, a chat window. Then press Tab and Shift+Tab to leave it.
- A pass looks like
- You can always move on with Tab, Shift+Tab or Escape, or the page tells you which key gets you out.
- A fail usually looks like
- Focus goes into a widget and every Tab cycles inside it with no way out except the mouse.
Step 8 of 9: Open menus and dialogs
- 2.4.3Focus OrderA
- 2.1.1KeyboardA
- 2.1.2No Keyboard TrapA
- Do this
- Open the main menu with Enter or Space, and open any pop-up: a newsletter box, a cart drawer, a cookie settings panel. Close it with its close button and with Escape.
- A pass looks like
- Focus goes into what opened, the next Tab stays in it, and on closing focus returns to the button that opened it.
- A fail usually looks like
- The pop-up opens but focus stays behind it on the page, or closing it drops you back at the top of the page.
Step 9 of 9: Walk back with Shift+Tab
- 2.4.3Focus OrderA
- 2.1.1KeyboardA
- Do this
- From the footer, hold Shift and press Tab all the way back to the top.
- A pass looks like
- You meet the same stops in reverse, with nothing skipped and nothing new.
- A fail usually looks like
- Shift+Tab gets stuck in a section, skips a control, or jumps somewhere unexpected.
Record your tab order
One line per stop, as you meet it in step 4: "Skip to content", "Logo", "Menu", "Book a table". A stop that should come earlier is the one to note.
What WCAG asks
- 2.1.1KeyboardA
- 2.1.2No Keyboard TrapA
- 2.4.1Bypass BlocksA
- 2.4.3Focus OrderA
- 2.4.7Focus VisibleAA
- 2.4.11Focus Not Obscured (Minimum)AA
What it checks
This is a manual test, done by you, with the keyboard you already own. It checks the things a keyboard user meets first: where the first Tab lands, whether there is a way past the menu, whether every control can be reached, whether the order makes sense, whether you can always see where you are, and whether anything holds focus prisoner. It does not scan your site and it sends nothing anywhere.
An automated checker is good at things in the code, such as a link with no text. Whether the order of stops makes sense, and whether you can see the ring on a busy photo, are questions a person answers by looking. That is why a walk like this sits beside a scan, never under it; our comparison of accessibility testing tools covers the scanning half.
Try it on this page first
Click the address bar and press Tab. The first stop is the "Skip to content" chip at the top left, which is always on show, wearing a thick orange ring. Press Enter and the next Tab skips the menu and lands on the breadcrumb above the title. The bar at the top stays put as you scroll on a wide screen, so the page keeps a strip of space under it to stop a focused item sliding out of sight. That is what a pass looks like for steps 1, 2, 5 and 6.
What WCAG asks
What WCAG asks: 2.4.3 Focus Order, Level A
If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
What WCAG asks: 2.4.7 Focus Visible, Level AA
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
| Criterion | What it asks |
|---|---|
| 2.1.1 KeyboardA | Everything on the page works from a keyboard. |
| 2.1.2 No Keyboard TrapA | If focus can get into a part of the page, it can get out again by keyboard. |
| 2.4.1 Bypass BlocksA | There is a way to skip blocks repeated on every page, such as the menu. |
| 2.4.3 Focus OrderA | Focus moves in an order that keeps the meaning and lets you operate the page. |
| 2.4.7 Focus VisibleAA | You can see which item has keyboard focus. |
| 2.4.11 Focus Not Obscured (Minimum)AA | The focused item is never entirely hidden by the page's own content. New in WCAG 2.2. |
One nuance on 2.4.1. W3C lists a skip link as one way to meet it, but also headings at the start of each section and page landmarks (header, nav, main). A page with good landmarks and no skip link can still meet 2.4.1. Those help screen reader users, though; a sighted person on a keyboard cannot use them without extra software, which is why the walk asks for a skip link and our guide to skip links explains how to add one.
Two related criteria are left out on purpose because they are Level AAA, beyond what a site meeting WCAG 2.2 Level AA has to do: 2.4.12 Focus Not Obscured (Enhanced), where no part of the focused item may be hidden, and 2.4.13 Focus Appearance, which sets a minimum size and contrast for the ring. How big and how strong a ring should be is covered in focus indicators and what WCAG asks of them.
What a fail usually looks like
W3C keeps a list of known failures for each criterion. Five of them account for most of what an owner finds on a keyboard walk, and each has a short name a developer will recognise.
F78 fails 2.4.7
The ring was switched off
A theme or reset stylesheet sets
outline: noneon links and buttons and draws nothing in its place. The most common fail of all, and one line of CSS to undo.F44 fails 2.4.3
Tabindex numbers above zero
Someone gave a field
tabindex="1"to make it come first. Every positive number is visited before the rest of the page, so focus leaps out of the reading order.F85 fails 2.4.3
A pop-up far from its button
The cart drawer or dialog lives at the end of the page's code. It opens on screen, but Tab walks the whole page behind it before reaching it.
F110 fails 2.4.11
A sticky bar over the focus
A fixed header, footer or cookie bar is tall enough to cover a focused link entirely as you Tab past it.
F55 fails 2.4.7
Focus pushed away by script
A script moves focus off an element the moment it gets it (often to stop a mouse click leaving a ring), so the keyboard can never rest there.
Forms are where a broken order hurts most, because a skipped field is a lost enquiry; our guide to accessible forms covers labels and errors as well as order.
A worked example: a bakery's home page
Here is what a first walk of a small bakery site typically records in the tab-order list. The page has a logo, a three-link menu, a hero photo with an "Order a cake" button, opening hours, a short order form and a footer, with a cookie banner pinned to the bottom of the screen.
| Stop | What took focus | Note |
|---|---|---|
| 1 | Logo (link to home) | No skip link before it. |
| 2 | Menu: Cakes, Bread, Visit us | Fine. |
| 3 | Order a cake (hero button) | Ring is a faint grey line on a photo. |
| 4 | Footer: Instagram, Facebook | Jumped past the opening hours and the order form. |
| 5 | Order form: Name | Reached only after the footer. |
| 6 | Cookie banner: Accept | Sat over the form's Send button the whole time. |
Read as results, that walk gives Fail on step 2 (no skip link), Fail on step 4 (the footer before the form, which the developer traced to a tabindex="1" on the footer's first link), Fail on step 5 (the faint ring on the hero) and Fail on step 6 (the banner over the Send button). Steps 3, 7, 8 and 9 passed. Four fails, and every one is a theme-level fix: a skip link in the header template, one stray attribute removed, one focus style, and a little bottom padding while the banner is open.
The takeaway
Most keyboard fails on a small site are in the theme, not in each page. Walk the home page, one inner page and the contact or checkout page; if the same fail shows on all three, it is one fix, not three.
After the walk
Print the record or copy it as text and hand it to whoever looks after the site. Each step names its criterion, so a developer or theme support desk knows the rule being asked about. On a hosted shop or a WordPress theme, check first whether the theme itself is the problem: the Shopify themes comparison and the WordPress plugins and themes comparison look at exactly these keyboard points.
A keyboard walk covers six criteria out of the 55 a site meeting WCAG 2.2 Level AA has to meet. For the rest, work through the WCAG 2.2 AA checklist, and add a screen reader test for what the keyboard alone cannot tell you. If a demand letter or a contract deadline is behind the question, the record is useful evidence of where you stand, but it is not legal advice: ask a lawyer about your own case, and see how to make a website meet WCAG 2.1 AA for the order of fixes.