Evidence Studio field notes

Accessibility audit field note

Seven fields that make an accessibility finding retestable

A retestable accessibility finding identifies the exact page or product state tested, the effect on a disabled user’s task, the shortest reliable reproduction, the evidence captured and protected, where the issue repeats, what was and was not evaluated, and a dated retest record. Another evaluator can then rerun the check without guessing.

6 minute read published vendor-neutral method

  1. Tested page state

    Record the URL or app path, page or view title, build and date, authenticated role, and the state that exposed the barrier. Name the open dialog, validation error, selected tab, process step or dynamic content variation. A URL alone rarely identifies an interactive state.

    Add the conditions that could change the result: browser and assistive-technology versions, viewport, zoom, language, colour preferences, input method and any test data. WCAG-EM recommends recording settings, inputs, actions and software versions so a sample can be found and replicated later.

  2. User impact

    Describe the task, the barrier and the consequence in plain language: who encounters the problem, what they are trying to do, what actually happens, and what should happen instead. Keep a scanner message or criterion reference as supporting context, not as the explanation of the human effect.

    Be precise about the evidence you have. One observed experience can reveal a real barrier, but it does not represent every person with the same disability. W3C advises reporting the study scope, methods and participant characteristics rather than generalising from a limited evaluation.

  3. Shortest reliable reproduction

    Start from a named state and list the fewest steps that reliably expose the issue. Include the input method, exact control labels, necessary values, expected result and actual result. Add a reset condition when prior actions, cached data or focus placement can change the outcome.

    Short does not mean incomplete. For a multi-step process, record the actions needed to move between views. WCAG-EM notes that the URL alone is often insufficient to identify a sample within a process.

  4. Protected evidence

    Attach only the evidence needed to understand the finding: a focused screenshot, DOM excerpt, short recording or tool result. Connect it to the tested state and build. Add a text explanation so the evidence remains understandable without relying on an image, colour or annotation alone.

    Inspect captures before sharing them. Screenshots, source, credentials and copied data may expose personal or confidential information. Redact the shareable copy under the project’s data policy, and retain any controlled original only when there is a defined reason, location and retention period.

  5. Repeated occurrences

    Record every known location while keeping the shared issue easy to fix once. Group occurrences only when the component, behavior and corrective action are genuinely the same. If one instance has a different state, implementation or user effect, keep it separate.

    WCAG-EM says repeated components do not normally need a full re-evaluation on every occurrence unless they appear or behave differently. It also calls it good practice to indicate issues that recur. Preserve both facts: the shared cause and the places where it was observed.

  6. Scope and limitations

    State what the finding supports and what it does not. Include the standard and level in scope, the evaluated sample, relevant test conditions, exclusions, untested paths and known tool or method limits. Distinguish a finding from a statement about the whole product.

    A sampled evaluation does not by itself prove that an entire website conforms. WCAG-EM requires an unambiguous scope and warns that evaluating a selected subset generally cannot support a site-wide WCAG conformance claim.

  7. Retest history

    Append a retest entry instead of replacing the original finding. Record the date, build, evaluator, test conditions, result, remaining occurrences and any changed reproduction step. Use clear outcomes such as fixed, still present, partly fixed or not retested, then explain the evidence behind the status.

    Reusing relevant samples makes results easier to compare over time. WCAG-EM explicitly supports rerunning an evaluation after repairs or for periodic monitoring, while replacing some samples when broader coverage is needed.

Copy the seven-field record

Tested page state
Where, when, build, state and test conditions
User impact
Task, barrier, actual result and expected result
Reproduction
Starting state and shortest reliable steps
Protected evidence
Relevant capture or excerpt, with sensitive data handled
Occurrences
Known locations and evidence for any shared cause
Scope and limitations
What was evaluated, excluded and not established
Retest history
Dated result, conditions and remaining instances

Primary W3C sources