1. Start with the interaction structure
Treat the quiz as a multi-step form with a result, not as a sequence of decorative cards. Use native buttons, radio inputs, checkboxes, text fields, headings, and progress elements where they match the interaction. Native controls expose expected names, roles, values, and keyboard behavior more reliably than clickable containers rebuilt with scripts.
Keep one clear page purpose and heading. When a step contains one question, the question still needs an associated control label or group name. Visual proximity alone does not tell assistive technology which answers belong together.
2. Label and group every answer control
Give every input a persistent label that describes its purpose. Group related radio buttons and checkboxes with a fieldset and legend, or an equivalent accessible group pattern when native markup is unavailable. The group name should contain the question, while each option has its own concise label.
State formats, units, required status, and constraints before the person enters data. Do not rely on color, position, placeholder text, or an icon alone. If an option says “Other,” explain whether entering text is optional and how that response affects the result.
- Question text is programmatically associated with its answer group
- Every visible option has a unique accessible name
- Required status is communicated in text and code
- Instructions remain available after a field receives input
- Score or range labels describe meaning, not only numbers
3. Complete the whole quiz with a keyboard
Starting from the browser address bar, complete every route using Tab, Shift plus Tab, arrow keys, Space, and Enter as appropriate. Focus order should follow the visual and logical order, and the visible focus indicator must not disappear against any background.
When the quiz advances automatically, confirm that focus moves to a meaningful location without skipping instructions. Sticky headers, cookie controls, chat widgets, and embedded frames must not completely cover the focused control. A person should be able to go back without losing previously entered answers unless the quiz clearly warns otherwise.
4. Explain progress and remove unnecessary timing pressure
For a known sequence, state the current step and total, such as “Question 3 of 7.” If branching changes the total, use language that remains true, such as the current section or an approximate remaining path. Progress information must be available in text, not only through a colored bar.
Avoid time limits unless timing is essential to the result. If a limit is required for security or another valid reason, warn the person and provide a way to extend or disable it where applicable. Do not auto-advance text questions before assistive technology can announce their state.
5. Make errors and status changes understandable
Identify an error in text, name the affected field, and explain how to fix it. Move focus to an error summary or the first invalid field when submission fails, while keeping each inline message associated with its control. Do not clear correct answers because one field is invalid.
Announce important changes such as a saved answer, a new conditional question, a loading result, and a successful submission when those changes are not otherwise apparent. Confirmation should state what happened and what the person can expect next.
6. Check mobile targets, zoom, and reflow
WCAG 2.2 defines a 24 by 24 CSS pixel minimum target size at Level AA, with specific exceptions including sufficient spacing. For a quiz, making the full answer label clickable and providing generous separation is usually more usable than relying on an exception.
Test portrait and landscape layouts at 200 percent zoom. Question text, answer labels, validation messages, navigation buttons, and result content should reflow without horizontal scrolling for ordinary text. Do not place the next button so close to an answer that an imprecise touch can submit the wrong choice.
7. Record a manual accessibility test matrix
Test at least one complete path for every result, plus an error path and a return-to-previous-step path. Record the browser, viewport, input method, assistive technology where used, expected behavior, actual behavior, and evidence.
| Test | Expected result | Evidence to retain |
|---|---|---|
| Keyboard-only completion | Every action works in logical order with visible focus | Path, step, and observed focus sequence |
| Screen reader labels | Question groups and options have understandable names | Announced question and option text |
| Validation failure | Error is identified, described, and associated | Submitted state and correction path |
| Mobile zoom and reflow | Content remains readable and operable | Viewport, zoom level, and affected step |
| Conditional branch | New content is announced and reachable | Trigger answer and focus destination |
| Result delivery | Result and next step are understandable | Result route and confirmation state |
Related: Audit whether every qualification question is necessary
Evidence
How to reproduce the method
The checklist produces a route inventory and a manual test matrix. A reviewer can repeat each keyboard, label, validation, reflow, branch, and result test using the recorded conditions, then compare the observed state with the expected behavior and linked W3C guidance.
Limitation
Where this conclusion stops
This checklist is a focused first review, not a WCAG conformance audit, legal opinion, or substitute for testing with people who use assistive technologies. Conformance depends on the complete page, embedded context, content, code, third-party widgets, and every reachable state.
Sources and verification
What this guide relies on
- The Lead Quiz Review editorial methodology
- W3C, Forms accessibility tutorial
- W3C, Multi-page forms
- W3C, Validating input
- W3C, Understanding target size minimum
- W3C, Understanding focus not obscured
Sources and method checked August 11, 2026. External standards are linked to their primary publishers.