Accessibility
The exam-taking flow — access gate, runner and result — was remediated against WCAG 2.1 level AA. This page describes what that work actually produced, so you can judge it rather than take a badge on trust.
The remediation targets the flow an examinee uses. It is the part that matters most: an inaccessible authoring screen inconveniences a colleague, while an inaccessible exam can prevent someone demonstrating what they know.
Structure and navigation
| Feature | Detail |
|---|---|
| Skip link | The first focusable element on the runner jumps straight to the questions, which take focus when the link is activated. |
| Landmarks | The question navigator is a labelled navigation region, in every one of its three forms. |
| Headings | The result page runs a correct heading outline, with each reviewed question a heading under the review section, so a screen reader user can jump between them. |
| Focus visibility | A visible focus indicator is applied throughout, rather than relying on the browser default being adequate over the theme colours. |
Announcements
The runner carries two screen-reader live regions — one polite, one assertive. Both are outside the region that gets hidden when an attempt is paused, so they can still announce while the exam is paused.
What is announced:
| Event | Announcement |
|---|---|
| Moving between questions | "Question 3 of 6" |
| Answering | The navigator cell's name gains ", answered" |
| Autosave failure | Announced assertively, so it interrupts |
| Five minutes remaining | Announced once, as the threshold is crossed |
| One minute remaining | Announced once |
| Time up | Announced once |
The countdown itself is hidden from assistive technology. Reading a per-second timer aloud would make the exam unusable; the three threshold announcements carry the moments that matter. Thresholds are pre-marked when the attempt starts, so a short exam beginning inside a threshold does not announce it incorrectly.
Focus management
Focus is moved deliberately, and only when the examinee caused the movement:
- Paging to a question moves focus to that question's fieldset and marks it as the current item.
- Clicking a navigator cell on a single-page exam moves focus to the target as well as scrolling to it.
- Opening the navigator as a bottom panel moves focus to its close button and traps focus inside it; closing returns focus to the button that opened it. It is announced as a modal dialog only in that form — as a permanently visible rail it is not one, so the dialog role is added when it opens and removed when it closes rather than left in place.
- A paused page that is reloaded puts focus on the Resume button.
- The image lightbox traps focus while open and restores it to the image on close.
Loading the page does not steal focus. The runner shows the first question on load without moving focus there, because an unrequested focus jump disorients a screen reader user who has just arrived.
Accessible names
Every control in the runner has a unique, meaningful accessible name — which is harder than it sounds for question types that repeat the same widget.
| Control | How it is named |
|---|---|
| Choice options | Associated with the question stem, which each fieldset references |
| Bare inputs — dropdown, short answer, essay | Explicitly labelled by the stem, since they have no visible label of their own |
| Cloze blanks | Labelled "Blank 1", "Blank 2", and so on |
| Matching selects | "Match for item" — named per item, not a shared "Match" |
| Ordering selects | "Position for item" — likewise |
| Navigator cells | Composed from the question number plus its answered and flagged state |
| Review-step cells | The same, using the review step's own wording — "Question 3, not answered, flagged" |
| Question cards | The card title carries the question type, so the type reaches assistive technology even though it is shown only as a tooltip |
| The flag button | Named "Flag for review" with a pressed state, rather than renaming itself — the state belongs in the pressed state, not in the name |
The matching and ordering names are worth calling out: before remediation, every select in a matching question shared the name "Match", which is exactly the failure mode that makes a question unanswerable by screen reader.
State is never colour alone
Every state that is shown with colour is also shown another way:
- Answered and flagged navigator cells carry the state in their accessible name, and flagged cells also show a badge.
- The review step spells every cell's state out in words as well, prints the three counts above the grid, and shows a key.
- The current question has a non-colour cue.
- Correct and incorrect markers on the review page are not distinguished by colour alone.
Motion
The runner honours the operating system's reduced-motion preference. Smooth scrolling becomes an instant jump, and the lightbox fade is neutralised, for users who have asked for less animation.
Forms and errors
- The access gate's code and guest fields are properly associated with their labels.
- Gate errors are announced as alerts, so a screen reader user hears a rejected access code rather than having to go looking for it.
- The autosave indicator is a persistent region rather than one that appears and disappears, because a region that is added to the page after an event is unreliably announced.
Working without JavaScript
The accessibility work sits on top of a server-rendered HTML form. The page has real named inputs and a working submit button before any script runs. This is a genuine fallback, not a theoretical one — an examinee whose assistive setup or corporate policy blocks scripting can still complete and submit the paper.
Known limits
Two things are stated plainly rather than claimed:
- The remediation covers the examinee flow. The authoring application is a conventional admin interface and has not been through the same audit.
- No formal third-party audit or VPAT has been commissioned. The conformance claim is based on our own testing, including screen-reader passes over the runner in both layouts.