2026-09-30 · 11 min read · Evidence asset # Accessible Online Assessment Checklist: 15 Tests for Multi-Step Flows An accessible online assessment must let a respondent understand, answer, review, correct, and submit every step using a keyboard, assistive technology, text enlargement, and common mobile layouts. Start with semantic questions and labels; preserve visible focus and logical order; announce validation and progress changes; avoid using color, timing, drag, or pointer precision as the only path; and make the result understandable without relying on one chart. ## Definition Assessment accessibility is the degree to which the complete respondent journey—including introduction, questions, instructions, validation, navigation, contact collection, result interpretation, and recovery—can be perceived, understood, and operated by people with diverse access needs. Automated scans cover only part of that journey. ## Method and evidence We rechecked the W3C Forms Tutorial and selected WCAG 2.2 understanding documents on September 30, 2026, then mapped them to a synthetic five-step scored consultancy assessment. The protocol runs fifteen manual acceptance tests at desktop and mobile sizes with keyboard-only input, 200% text enlargement, and deliberate error injection. It is an audit protocol, not a certification, legal opinion, or claim that one test environment proves conformance. Evidence type: Five-stage respondent journey, fifteen manual acceptance tests, worked repair, and platform-versus-publisher responsibility boundary. See the [publication methodology](https://best-assessment-tool.com/methodology) and [correction path](https://best-assessment-tool.com/corrections). ## Use a five-stage respondent journey Test the flow as one connected task. A question page can use good labels and still fail if a respondent cannot recover from an error, return to a prior page, or interpret the result. StageRespondent jobRequired evidenceStartUnderstand purpose, time, data use, and resultClear heading, instructions, and alternativesAnswerIdentify and operate each choiceAssociated label, group name, state, and keyboard pathNavigateMove forward, backward, and resume safelyLogical focus order and preserved answersCorrectFind and fix a missing or invalid answerError summary, field message, and focus recoveryInterpretUnderstand score, band, and next stepText explanation that does not depend on chart or color Sources: [W3C Forms Tutorial](https://www.w3.org/WAI/tutorials/forms/) · [W3C form instructions](https://www.w3.org/WAI/tutorials/forms/instructions/) · [W3C labels](https://www.w3.org/WAI/tutorials/forms/labels/) ## Run these fifteen acceptance tests Record the environment, input method, expected behavior, observed behavior, and pass or fail result. Repeat the set after changing page logic, validation, an embed, a sticky element, or the result layout. - Navigate from the first heading through every interactive element with the keyboard alone. - Confirm each radio or checkbox group announces its question and current choice. - Confirm required and optional status is available before submission. - Trigger every validation error and verify the message names the field and the correction. - Submit multiple errors and verify the summary links or moves focus to the affected controls. - Move backward and forward and verify prior answers remain intact. - Enlarge text to 200% and verify no answer, label, action, or result is clipped. - Test narrow reflow without two-dimensional page scrolling for ordinary text content. - Verify focus remains visible and is not entirely hidden by sticky navigation or banners. - Verify answer targets meet the applicable minimum size or have sufficient separation for touch use. - Ignore color as a cue: selection, error, progress, and result must still be clear. - Verify progress is announced as meaningful text rather than only a moving bar. - Verify any timer can be avoided, extended, or justified for the assessment purpose. - Verify charts have a text result, named values, and the same recommendation as the visual. - Test the embedded version and its host page, including focus entering and leaving the assessment. Sources: [W3C user notifications](https://www.w3.org/WAI/tutorials/forms/notifications/) · [WCAG 2.2 focus not obscured](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html) · [WCAG 2.2 target size](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum) · [WCAG 2.2 resize text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html) ## Repair the whole failure, not only the visible symptom A five-page readiness assessment contains four radio groups and a contact page. Keyboard testing reveals that moving to page three resets page two, an error appears only as a red border, and a sticky footer entirely hides the focused Back button at 200% text size. The result page shows a gauge marked 62 but no textual band. The repaired acceptance contract preserves answers between pages, adds an error summary and field-specific text, reserves space so focused controls remain visible, and states: “Prepare — 62 out of 100. Your main gap is evidence readiness.” The gauge remains as supporting context. The change improves operability without changing the score or promising conformance. ## Separate platform capability from publisher responsibility An assessment builder can provide semantic controls, page structure, validation behavior, and responsive layouts. The publisher still owns question wording, alternative text, contrast choices, result explanation, custom embed context, and end-to-end testing. A third-party accessibility score cannot cover an inaccessible host page, custom code that obscures focus, or a misleading interpretation. Test both the assessment and the page that contains it. Sources: [Embedding scored assessments](https://best-assessment-tool.com/blog/embed-scored-assessment) · [Choosing an assessment graph](https://best-assessment-tool.com/blog/assessment-graph-selection) ## Keep result meaning outside the chart Write the score, band, strongest evidence, priority gap, and next action as text. The visual may reinforce the comparison, but it should not be the only place where a value, threshold, or recommendation appears. This makes the result more resilient to low vision, color-vision differences, small screens, blocked images, and machine retrieval. It also prevents a decorative chart from becoming the sole explanation of a consequential decision. Sources: [Assessment result-page design](https://best-assessment-tool.com/blog/assessment-results-pages) · [Question-count method](https://best-assessment-tool.com/blog/assessment-question-count) ## Document the audit boundary A useful record names the tested URL and version, browser and assistive technology, viewport or zoom condition, input method, expected behavior, observed behavior, issue owner, and retest date. Keep the record with the scoring and content version so a later change does not inherit an obsolete pass. Use the correction path for a reproducible defect: include the exact stage, control, environment, observed behavior, expected behavior, and W3C source. Do not label a partial automated scan as a complete accessibility audit. Sources: [Publication methodology](https://best-assessment-tool.com/methodology) · [Report a correction](https://best-assessment-tool.com/corrections) ## Practical next step Copy the framework or checklist into a draft, run every stated test case, and record the observed result before publishing. Recheck changing product capabilities and plan limits against the linked vendor page. --- Canonical: https://best-assessment-tool.com/blog/accessible-online-assessment