# Accessibility Audit Tests an interface against the conformance level it is meant to meet, and reports who each failure excludes and how. ## Deliverable One Markdown document, `accessibility-audit.md`, in the structure set out under **Output** below. It is read beside **Design System Audit**, because most repeated failures are defined once in a shared component. ## Required inputs - **An interface that can be operated** — a running build, or the source and design material if nothing can be run, stated as which of the two it is. - **The conformance level being targeted**, and who set it. A finding is a failure only against a stated criterion. - **What is in scope** — which screens, flows and states are to be examined. If the level was not set, stop and report it. Auditing against an unstated bar produces a list of opinions nobody has to act on. ## Optional inputs - The browser, platform and assistive-technology combinations the product commits to supporting - Design material showing the intended focus order and the intended styling of each state - Component source, so a fault can be traced to where it is defined rather than where it appears - The longest and the shortest content the interface has to carry - Earlier findings and what was done about them - Any accessibility statement the organisation has already published Absent optional inputs limit coverage, not rigour. Anything not examined is reported as not examined; it is never reported as passing. ## Execution **1 — Fix the scope, the level and the method.** Record the screens, flows and states in scope, the level being targeted, the environment the audit ran in, and what will not be covered. Write the exclusions before the findings, so they cannot be quietly dropped later. **2 — Operate the interface by keyboard alone.** Reach every control, in an order that matches the meaning of the page. Check that focus is visible wherever it lands, that nothing traps it, that what opens can be closed, and that a mechanism exists to skip repeated blocks. Record each failure at the control where it occurs. **3 — Check structure and naming.** Headings in a nesting that describes the content, landmarks that let a user jump, every control with a name that says what it does, every field with a label, and every error message associated with the field that caused it. **4 — Check what carries meaning without text.** Text alternatives for images, icons and media; the contrast of text and of interface components against what sits behind them; and anything whose meaning is carried by colour, position or shape alone. **5 — Check what changes under the user's own settings.** Reduced motion, increased text size, page zoom, changed orientation and forced colours. Record what reflows, what truncates, what overlaps and what disappears. **6 — Write each finding against a criterion.** Where it is, which criterion at the targeted level it fails, what the interface does, which user it excludes and how, the specific remediation, and whether the fault sits in a shared component or in one place. **7 — Separate what was verified from what was not.** State which checks were run by inspection, which by tooling, and which need assistive-technology testing that was not performed here. A check that was not run is listed as not run, under its own heading, never inside a passing result. ## Output `accessibility-audit.md`, in this order: - **1. Scope, level and date** — what was audited, against which level, in what environment, and what was excluded - **2. Method** — what was checked by inspection, what by tooling, and what neither covered - **3. Findings** — per finding: location, criterion, what fails, who it excludes and how, remediation, and whether it is shared or local - **4. Coverage by area** — keyboard and focus, structure and naming, non-text and contrast, forms and errors, user settings: what was examined in each, and what was not - **5. Passing with conditions** — checks that hold only in the environment tested, each with the condition named - **6. Not verified** — the checks that require assistive-technology testing that was not performed, and what each would settle - **7. Order of work** — findings ordered by who is excluded and by whether the exclusion blocks the task or obstructs it - **8. Missing information** — what blocked a check, and who can unblock it ## Validation The report is ready when all of these hold: - Every finding names a location, a criterion at the targeted level, and a remediation - Every finding names the user it excludes and how, not only the rule it breaks - Section 2 distinguishes what was inspected from what was tooled from what was not covered - No check is reported as passing that section 2 does not show as run - Every check needing assistive technology appears in section 6, whatever it looked like - Section 7 orders the findings by exclusion rather than by ease of fixing Fail the run if a finding cites no criterion, or if an assistive-technology result is reported when that testing was not performed. ## Failure handling - **No conformance level supplied** — stop. Report that findings need a stated bar, and name who sets it. - **No operable build** — audit the source and the design material, mark every finding `unverified in use`, and list in section 6 what operating the interface would settle. - **Assistive technology not available** — run what inspection and tooling can settle, list the rest by name in section 6, and never present an inspection result as a screen-reader result. - **Contradictory accounts of intended behaviour** — record both with their sources, audit the built behaviour because that is what the user meets, and raise the contradiction in section 8. - **Partial access** — audit what was reachable, mark the rest `NOT AUDITED — `, and state plainly that an unaudited screen is not a passing screen.