Auditing Accessibility

An audit investigates a defined application and set of tasks. Record what was examined, what failed, and how someone else can reproduce the observation; a tool score alone does not describe those conditions.

The worked audit follows the date-range form from Chapter 6.5. Imagine an earlier, faulty revision that clears both dates after an invalid submission and leaves focus on Check dates. The component shown in Chapter 6.5 already includes the repair. The record below illustrates how to connect that earlier failure to its conditions, effect and repair; it is not a report of a test run against the shown component.

Choose a task and record test conditions

Name the application revision, page, browser, viewport and task. Concrete conditions make the observation repeatable. For example:

Revision: the hypothetical faulty date-range form revision
Page: /date-range
Task: submit an invalid date range, correct the end date and submit again
Conditions: named browser and version; 1280px window; keyboard only
Additional condition: repeat at 200% browser zoom

In your own audit, record the actual source revision, browser name and version from the run. One browser, workflow and set of conditions do not cover every assistive technology or the whole site.

Use automated checks to find concrete problems

Browser audit tools and accessibility engines can identify many mechanical problems, such as missing names or particular contrast and structure issues. They do not establish that a person can complete the form’s error-and-correction sequence.

Begin with the browser’s available accessibility inspector and audit interface. Inspect names and roles as well as the visual page.

When a tool reports a problem, find the element and understand the rule. Do not add an arbitrary aria-label merely to remove a warning if it gives the control the wrong name.

Perform the task manually

Follow a small, repeatable sequence:

1. Navigate from the top of the page with a keyboard.
2. Enter start date 2030-06-12 and end date 2030-06-10.
3. Activate Check dates and record the retained values, focused element and error feedback.
4. Try to reach the affected field, correct the end to 2030-06-13 and submit again. Record any obstacle to completing that recovery.
5. Repeat at 200% browser zoom and inspect whether the fields, feedback and controls remain available.

Identify the focused control throughout the sequence. Review headings, page regions such as navigation and main content, labels, and status feedback too.

Where available, also try an assistive technology and record what was actually tested. Do not report a screen-reader test that was not performed. The WAI evaluation resources provide further methods and explain the limits of quick checks.

Record and retest a finding

A finding connects the observation to its effect and a repeatable repair check:

Observation: an invalid submission clears both dates and leaves focus on Check dates.
Reproduction: enter start 2030-06-12 and end 2030-06-10; activate Check dates with Enter.
Impact: the user must reconstruct the proposal and find the error and correction path.
Change: retain both dates, focus the rendered error summary and link it to the affected field.
Retest: repeat the invalid submission; confirm retained dates and summary focus.
        Tab to the recovery link and press Enter; confirm End date receives focus.
        Correct the end to 2030-06-13 and submit again; confirm the summary disappears,
        the ready status appears and focus stays on Check dates.
Limit: screen-reader announcements were not examined.

Prioritize barriers to completing a task before cosmetic consistency. A missing submit-button name is more consequential than a minor spacing preference. Preserve the distinction between a measured failure, a design concern, and an untested hypothesis.

After a change, repeat the original reproduction against the repaired revision and record that revision too. Then inspect nearby behavior: the corrected submission should preserve the new dates and leave focus on the initiating button. A fix may improve one case and break another.

The next chapter turns this finding’s checks for retained values and keyboard recovery into a regression test. Some observations remain manual because they depend on perception, judgment, or an interaction environment the test does not model.

Check Your Understanding

1. Why should an audit name its revision, task, and conditions?
2. What should happen after an automated tool reports an issue?
3. Why should an audit distinguish an observed barrier from an untested concern?
4. What makes an audit finding reproducible?
5. Why should a repaired interaction be checked in both success and failure cases?