Accessible online assessment beyond the checklist: applying WCAG 2.2 to real candidate journeys

An online assessment can pass an automated accessibility scan and still be impossible to finish. The timer may disappear at high zoom. A screen reader may announce button without saying what the button does. Keyboard focus may move behind a modal. A candidate may complete forty minutes of work, lose connectivity and discover that nothing was saved. Each problem looks technical, but the result is an assessment validity problem: the experience has started measuring a barrier rather than the capability the organisation intended to assess.

WCAG 2.2 is the right baseline for web content and interfaces. W3C recommends using the current version, and its success criteria cover issues directly relevant to assessment, including labels, focus, status messages, target size and accessible authentication. Conformance is not the finish line. Assessment teams must also examine content, timing, adjustments, support and the construct itself.

Begin with the construct, not the interface

Write a plain sentence describing what each task is meant to measure. If the answer is analytical judgement, an inaccessible drag-and-drop interaction should not decide the outcome. If speed is not an essential part of the capability, a strict timer may add irrelevant difficulty. If visual interpretation is essential, the team still needs an equitable route for candidates who cannot perceive the visual presentation in the same way.

This construct review prevents a common mistake: creating an accessible alternative that measures something different. Replacing a complex simulation with a much easier multiple-choice question may remove a barrier but make results incomparable. Work with subject experts, accessibility specialists and people who use assistive technology to preserve the intended demand while changing the route used to demonstrate it.

Test the entire candidate journey

The assessment begins before question one. Test the invitation, account creation, authentication, adjustment request, system check and practice experience. Continue through instructions, navigation, response entry, review, submission, receipt and any later result or appeal route. A perfectly accessible question renderer cannot rescue an inaccessible identity check.

Use real journeys rather than isolated components. Increase browser zoom to 200 and 400 percent. Reflow to a narrow viewport. Navigate without a mouse. Use a screen reader to find the timer, question number, save state and error messages. Change an answer, move away and return. Let a session approach timeout. Disconnect the network. Attempt the route with reduced motion and high-contrast preferences. Record both failures and the impact on the persons ability to demonstrate the construct.

Automated tools are useful for repeatable checks, but they cannot judge whether instructions make sense, focus order reflects the task or an alternative is equivalent. Include disabled users in testing and compensate them for their expertise. One carefully observed journey often reveals more than a dashboard of isolated pass rates.

Make time visible, adjustable and recoverable

Timed assessment creates pressure even when everything works. The interface should state the duration before starting, show whether breaks are allowed, warn before expiry and let candidates understand the consequence of time running out. The timer must be available programmatically and should not steal focus every time it changes.

Ask why the limit exists. Where speed is part of the construct, document that reason and design appropriate adjustment rules. Where it merely controls scheduling, allow extension or a different arrangement. Extra time should be configured in the assessment record rather than handled through an improvised support intervention after the candidate starts.

Save continuously and show the last successful save. If a session expires or authentication must be repeated, preserve the persons activity so they can continue without loss where security permits. W3cs guidance explicitly recognises that re-authentication can disadvantage people who need more time and highlights preservation of prior activity. Recovery is not a luxury feature; it protects the integrity of the evidence.

Use native controls and announce state

Standard HTML buttons, inputs, headings and fieldsets bring useful accessibility behaviour when used correctly. Custom controls must expose their name, role, value and state to assistive technology and support expected keyboard interaction. A styled card that acts like a radio option should not require a mouse or announce itself as ordinary text.

Dynamic changes need accessible status messages. When an answer saves, a validation error appears, connectivity drops or a file finishes uploading, the update should be programmatically available without unexpectedly moving focus. Use concise messages. Repeated announcements of every autosave can overwhelm a screen-reader user, while silence leaves them unsure whether work is safe.

Focus must remain visible and predictable. Opening help should move focus into the help panel; closing it should return focus to the control that opened it. Sticky headers and cookie banners must not cover the focused element. Error summaries should link to the relevant field, and instructions should not rely on colour, position or shape alone.

Treat question content as a separate accessibility product

Authors can create barriers inside an accessible platform. Provide templates and checks for heading structure, link purpose, table headers, captions, reading order and plain instructions. Teach authors when alternative text should describe purpose rather than appearance. WCAG recognises that a text alternative can invalidate a test item; in those cases provide descriptive identification and design an appropriate equivalent route rather than revealing the answer.

Mathematical notation, code editors, diagrams, audio and video need deliberate testing. Confirm that keyboard users can operate editors, that notation is meaningful to screen readers, that captions and transcripts meet the assessment purpose, and that colour is not the only signal. Preview content through the same delivery interface candidates will use, not only in the authoring screen.

Make adjustments a dependable workflow

A candidate should know how to request an adjustment, what information is required, when to apply and how the decision will be communicated. Avoid demanding excessive health information when a functional description will do. Protect adjustment data through role-based access; a marker may need to know that extra time applies without seeing a diagnosis.

Approved adjustments should travel with the booking and be visible before the assessment begins. Test common configurations such as extra time, rest breaks, alternative formats, a reader or scribe, reduced-distraction delivery and assistive technology. Provide a practice route that matches the configured experience. Discovering on assessment day that an approved tool is blocked creates stress and weakens the result.

Offer support that does not require the channel causing the difficulty. A person locked out of the platform needs a phone or email route, not an inaccessible chatbot behind the same login. Publish support hours, likely response time and what happens to the timer during an incident.

Design for interruption without inviting ambiguity

Connectivity problems are normal, especially for candidates on shared or mobile networks. Store responses durably, retry safely and prevent duplicate submission. Show clear states such as saved, saving, and offline; changes are held on this device. On reconnection, reconcile changes and confirm the result.

At submission, provide a durable receipt with assessment, time and status. If an upload or final save fails, do not show a success message. Give the candidate a reference and a recovery route. Operational teams should see the same incident state so the person does not have to prove a technical failure from memory.

Measure accessibility as an assessment-quality signal

Track more than conformance defects. Review abandonment, repeated validation errors, support requests, adjustment failures, timeouts, lost-session recoveries and appeals linked to access. Look for patterns by device and assistive technology where it is lawful and proportionate to collect that information. Use qualitative feedback to understand what the numbers cannot show.

Keep accessibility issues connected to the affected assessment version and candidate record. A reviewer deciding whether evidence is sufficient needs to know about a material interruption or failed adjustment. At population level, repeated problems with one item or interaction should trigger redesign and, where necessary, review of earlier outcomes.

A practical release gate

• The construct has been reviewed for barriers unrelated to the intended capability.
• The whole journey works with keyboard, screen reader, zoom and reflow.
• Timing, breaks, warnings and expiry behaviour are clear and configurable.
• Responses survive navigation, disconnection and permitted re-authentication.
• Dynamic save, error and connection states are announced appropriately.
• Authors have tested media, tables, notation and complex interactions.
• Adjustment and support routes work before, during and after delivery.
• Submission creates a reliable receipt and an operationally visible record.

Accessibility protects the meaning of the result

The strongest reason to build an accessible assessment is not a badge or procurement answer. It is that the result should reflect the capability you intended to measure. When unrelated friction determines who finishes, what they can submit or how much attention remains for the task, the evidence becomes less trustworthy for everyone.

Use WCAG 2.2 as the technical baseline, then keep going. Design from the construct, test real journeys, make adjustments operational and preserve evidence about access conditions. That is how accessibility becomes part of assessment quality rather than a checklist performed just before launch.