Accessible Crossword Publishing Checklist
A practical manual-test checklist for crossword grids, clue announcements, keyboard controls, error feedback, zoom, reduced motion, and print layouts.
An online crossword is not accessible merely because its page passes an automated scan. The grid, clue list, controls, feedback, print view, and completion flow form one interaction. This checklist turns that interaction into repeatable manual tests for publishers and developers. It is implementation guidance, not a certification or a substitute for testing with disabled users and assistive technologies.
Start with the keyboard interaction model
A crossword grid behaves like an editable two-dimensional widget. A practical model places one grid cell in the page Tab sequence, uses arrow keys to move inside the grid, and lets Tab continue to the next component. The W3C ARIA Authoring Practices grid pattern also documents Home, End, Control+Home, and Control+End behavior that may be useful for larger grids.
Do not add grid roles without implementing the matching focus management and keyboard behavior. Native inputs can provide valuable semantics, but a screen reader user still needs the row, column, clue number, current value, selected direction, and error or reveal state announced at the right time.
- Reach the grid with Tab and confirm that focus is visible.
- Move in all four directions without trapping focus or scrolling the page unexpectedly.
- Use Tab and Shift+Tab to leave the grid in a predictable order.
- Verify that blocked cells are skipped and edge cells do not move focus outside the grid.
Give every control an unambiguous name
Check, Reveal, Pencil, Pause, Print, previous clue, next clue, and direction controls need programmatic names that describe their action. Icon-only buttons should expose the same meaning to assistive technology that sighted users get from the icon and tooltip.
Stateful controls should also expose their state. For example, Pencil mode can use an accessible pressed state, while a Pause button should change its name to Resume when the timer is paused.
Announce clue and cell context without noise
Selecting a cell should make the active clue and direction available without forcing the user to hunt through the clue list. Announcements should be concise enough to remain useful during rapid arrow-key movement. Repeating the entire clue for every keystroke can be as disruptive as announcing too little.
Test the exact spoken sequence with more than one screen reader and browser combination. The ARIA Authoring Practices examples are informative patterns, not a promise that every assistive-technology combination behaves identically.
Make mistakes and reveals perceivable in more than colour
A red cell alone does not tell a blind user or a user with colour-vision deficiency what went wrong. Add text or an accessible state that identifies the incorrect cell or entry. Confirmation dialogs for Reveal actions should explain the scope before the answer is exposed.
W3C guidance for error identification requires detected input errors to be identified and described in text. For a crossword, that principle applies to pattern errors, invalid form filters, and any Check feedback that the interface presents as an error.
Check contrast, focus, zoom, and target size
WCAG 2.2 Level AA sets a 4.5:1 minimum contrast ratio for normal text, with specific exceptions. It also requires a visible keyboard-focus mode. The 24 by 24 CSS pixel target-size criterion includes exceptions, but larger controls are usually easier to operate on a puzzle toolbar and touch keyboard.
At 200% and 400% zoom, confirm that the active clue, grid, controls, and feedback remain available without overlapping or becoming clipped. On narrow screens, a horizontally scrolling grid must not hide the clue context or strand the user away from controls.
Keep print and reduced-motion paths usable
The print view needs a legible blank grid, separated Across and Down clues, adequate writing space, and no controls or decorative backgrounds that waste ink. Print preview should be checked at common paper sizes because browser and printer defaults vary.
Respect reduced-motion preferences for onboarding, completion effects, animated gradients, and transitions. Turning off motion should not remove status changes or other information.
Record evidence instead of a blanket pass
For each release, record the route, puzzle size, browser, operating system, input method, assistive technology, test result, defect, and retest date. A broad statement such as “screen-reader friendly” is not defensible unless it is supported by named test combinations and known limitations.
Automated tools can find missing labels, invalid roles, and some contrast problems, but they cannot judge whether clue announcements are understandable or whether the solving flow is efficient. Pair automated checks with keyboard-only and assistive-technology testing.
Manual test checklist
Record a result and evidence for every row. A blank cell is unknown, not a pass.
| Area | Manual test | Evidence to record |
|---|---|---|
| Entry and exit | Tab to the grid, then Tab and Shift+Tab out of it. | Focus order, visible indicator, and any trap. |
| Cell navigation | Use all arrow keys at edges, open cells, and blocked cells. | Row/column reached and unexpected movement. |
| Context | Move between Across and Down entries with a screen reader. | Cell, direction, clue number, value, and clue announcement. |
| Text entry | Type, replace, and erase letters using keyboard and touch. | Value announcement and cursor position. |
| Check feedback | Check a deliberately wrong cell and word. | Non-colour error message and focus behavior. |
| Reveal safety | Reveal one cell, one word, and the whole puzzle. | Confirmation scope and revealed-state announcement. |
| Toolbar | Operate Pencil, Pause, Undo, Redo, Check, Reveal, and navigation controls. | Accessible name, state, and keyboard activation. |
| Zoom and reflow | Test 200% and 400% zoom plus a narrow mobile viewport. | Clipping, overlap, two-dimensional scrolling, and lost context. |
| Contrast and focus | Measure normal text and inspect focus in every theme. | Ratios, theme, and screenshots of focused controls. |
| Open print preview on common portrait and landscape paper sizes. | Grid size, clue legibility, page breaks, and hidden controls. | |
| Reduced motion | Enable the operating-system reduced-motion preference and replay key flows. | Animations removed and information preserved. |
| Compatibility | Repeat core flows in at least two screen-reader/browser combinations. | Exact versions, defects, workarounds, and retest date. |
Standards and source notes
These primary sources define or explain the referenced patterns and success criteria. The checklist applies them to crossword interactions; that application is the site's editorial interpretation.
Key Takeaway
Treat accessibility as a recorded test matrix for the complete solving flow. Semantics, keyboard support, announcements, visual presentation, and print behavior all need evidence; none of them alone proves that a crossword is accessible.