Implementation worksheet · 7 min read
A Keyboard-Only Acceptance Test for a Generated Dashboard
Accept a generated dashboard for keyboard use only when one tester, with no mouse or trackpad, can complete every task the dashboard exists for: get past the sidebar to the main content, change the date range and filters, sort and page the table, open a row's actions, edit a record in its dialog, and read the numbers a chart shows. At every step the focus indicator must be visible and never entirely hidden behind a sticky header, focus must move in an order that matches the layout, and nothing may trap it. Those checks produce evidence for WCAG 2.2 success criteria 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.3 Focus Order, 2.4.7 Focus Visible and 2.4.11 Focus Not Obscured (Minimum). A pass is evidence for those rows on that build, not a conformance claim.
Scope: the actor is whoever accepts the build (a founder, a client, a contracted tester) checking a dashboard that an AI app builder generated from a prompt. The starting state is a deployed preview with synthetic data, a signed-in user with the most common role, and no pointing device. The boundary is the dashboard's own screens; the browser, the operating system and any embedded third-party widget are noted but not fixed here. The outcome is a pass, fail or blocked result per task, with the failing element named precisely enough that the fix can be requested as one change.
Put it into practice
1. List the tasks before touching the keyboard
Write down what the dashboard is for, in verbs: change the reporting period, filter by region, find an order, mark it shipped, export the view. The test is task completion, not a tour of every element. A list written after the session tends to contain only the tasks that worked.
2. Make the mouse unavailable
Unplug it, switch off the trackpad, or put it out of reach. A tester with a hand on the mouse reaches for it the moment focus gets lost, and that moment is the finding. Use Tab and Shift+Tab to move between controls, Enter and Space to activate, the arrow keys inside composite widgets, and Escape to dismiss.
3. Count the presses from page load to the main content
Press Tab from a fresh load. A sidebar with a dozen links costs a keyboard user a dozen presses on every screen unless there is a way past it. Success criterion 2.4.1 Bypass Blocks (Level A) asks for a mechanism to bypass blocks repeated across pages; a skip link as the first stop is the simplest one to test. Record the count.
4. Watch the focus indicator at every stop
At each press you should be able to point at the focused element straight away. Custom-styled controls are where it disappears: a global rule that removes outlines, or a card that looks identical focused and unfocused. 2.4.7 Focus Visible (AA) requires a visible indicator. 2.4.11 Focus Not Obscured (Minimum) (AA) fails when author content such as a sticky header, footer or cookie banner hides the focused element entirely, so Tab down the table until rows pass under the sticky header and check.
5. Operate every composite widget
Date pickers, filter dropdowns, tab sets and row-action menus are where to look for a clickable div standing in for a button: it looks right, responds to a click, and Tab skips it. For a widget that follows a WAI-ARIA Authoring Practices pattern, try the keys that pattern documents. In a tab list, for example, the arrow keys move between tabs and Tab moves on into the panel.
6. Read the chart without hovering
If a value only appears in a hover tooltip, a keyboard user cannot get it, which is a 2.1.1 Keyboard (A) failure. Acceptable routes include data points that take focus and show the same tooltip, or the same numbers in a table or summary beside the chart. A tooltip that appears on focus and covers other content must also be dismissible without moving focus, for example with Escape (1.4.13 Content on Hover or Focus, AA).
7. Check drag-to-rearrange and single-key shortcuts
If widgets can be rearranged by dragging, there needs to be a keyboard route to the same result, such as move up and move down options in a menu. The exception in 2.1.1 covers input that depends on the path of the movement; a widget's new position depends only on where it ends up. If the dashboard binds a single character such as / or n as a shortcut, 2.1.4 Character Key Shortcuts (A) requires a way to turn it off or remap it, or that it only works while its component has focus.
8. Worked example (illustrative, synthetic data)
A generated operations dashboard for a fictional three-person courier business: a sidebar with 9 links, a date-range picker, two filter dropdowns, four summary cards, a line chart of daily deliveries, a 25-row orders table with a sticky header and a row menu on each row, and an Edit order dialog. Expected: a skip link as the first stop, landing on the page heading; four more presses to the date picker; arrow keys change days inside the picker and Escape closes it without applying; rows 12 to 25 stay visible when focused; each row menu opens on Enter and closes on Escape; chart values reachable through a View as table toggle. Observed in this synthetic run: the row menu was a div with a click handler, so Tab never reached it. That one failure blocks the mark-shipped task, so the dashboard fails acceptance even though every other row passes.
Keyboard-only acceptance matrix
Copy this structure into your review document and record your observed result for each row.
| Task or component | Keys to try | Pass condition | WCAG 2.2 reference | Result |
|---|---|---|---|---|
| Get past the sidebar | Tab from page load, then Enter | First stop moves focus to the main content | 2.4.1 Bypass Blocks (A) | |
| Reach every control | Tab and Shift+Tab | Every interactive element takes focus; nothing clickable is skipped | 2.1.1 Keyboard (A) | |
| Focus order | Tab through one full screen | Order follows the layout: filters, cards, chart, table | 2.4.3 Focus Order (A) | |
| Focus visibility | Tab, watching each stop | An indicator is visible on every focused element | 2.4.7 Focus Visible (AA) | |
| Rows under a sticky header | Tab down the whole table | The focused row is never entirely hidden | 2.4.11 Focus Not Obscured (Minimum) (AA) | |
| Date-range picker | Enter, arrow keys, Escape | Opens, changes the range and closes from the keyboard alone | 2.1.1 Keyboard (A); 2.1.2 No Keyboard Trap (A) | |
| Filter dropdowns | Enter or Space, arrow keys, Escape | Every option can be reached and chosen | 2.1.1 Keyboard (A) | |
| Row action menu | Enter, arrow keys, Escape | Opens from the keyboard; Escape closes it | 2.1.1 Keyboard (A); 2.1.2 No Keyboard Trap (A) | |
| Edit dialog | Tab, Shift+Tab, Escape | Focus moves into the dialog and leaves it by closing it | 2.1.2 No Keyboard Trap (A); 2.4.3 Focus Order (A) | |
| Chart values | Tab to the chart or its table toggle | Every plotted value can be read without hovering | 2.1.1 Keyboard (A) | |
| Tooltips shown on focus | Tab, then Escape | Can be dismissed without moving focus when they cover content | 1.4.13 Content on Hover or Focus (AA) | |
| Single-key shortcuts | Press the bound key inside a text field | Shortcut can be turned off or remapped, or only works on focus | 2.1.4 Character Key Shortcuts (A) | |
| Rearranging widgets | The layout menu or move controls | Same result as dragging, with no pointer | 2.1.1 Keyboard (A) |
A failure worth checking
The dashboard that passes because the mouse was in reach. A tester Tabs into the orders table, loses sight of focus under the sticky header, reaches for the trackpad to get past it, clicks the row menu and carries on. The report says keyboard access passed, and the two real findings (focus hidden under the header, a menu Tab never reaches) are the exact moments the tester switched input. The limit of the method is just as important: a keyboard pass says nothing about what a screen reader announces, whether contrast is adequate, or how the dashboard works with voice control. Record the build it ran against as well, because a regenerated component can undo a pass.
Common questions
Does passing this test make the dashboard WCAG 2.2 compliant?
No. It produces evidence for a handful of success criteria, on the screens you tested, on the build you tested. Conformance is claimed against every criterion at a level, and several of them (contrast, text alternatives, status messages) need other tests. W3C's guidance on evaluation tools says tools can assist but cannot determine accessibility, and a manual pass like this one is also only part of an evaluation.
How long should the test take?
Long enough to finish every task on your list once per role. The first run is slow because every finding needs a note; later runs against the same matrix are regression checks and go faster. If a task is blocked, record it as blocked and move on rather than hunting for a workaround, because the workaround is what hides the finding.
How do I ask an AI builder to fix a failure?
One failure per request, named by element and expected behaviour: 'The row menu button in the orders table can't be reached with Tab. Make it a button that opens the same menu on Enter and closes on Escape, returning focus to the button. Don't change the table layout.' Then re-run the whole matrix, not just that row, because focus changes can ripple into other components.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.