An accessibility issue register connects a person’s blocked task with the work required to restore access. It should tell a new team member what failed, who is repairing it, and how success will be checked. You can begin with an existing issue tracker or a shared record. The quality of the entries and decisions matters more than the shape of the dashboard.
Record one reproducible problem
Give each finding a stable identifier. Record the affected URL or component, account role, page state, environment, steps, observed behavior and expected outcome. Add the user impact in ordinary language: “A keyboard user cannot reach the confirmation button after the dialog opens.” Keep screenshots or recordings only when they clarify the issue, and remove private information.
A criterion reference can help specialists connect the finding to a standard, but it should accompany the explanation. Record the standard and version actually being evaluated. Label an automated result as awaiting validation until a reviewer has established what it means in context.
The accessibility issue record supplies a reusable entry and a fictional worked example. Copy it into your team’s existing system and retain the fields needed for reproduction and retesting.
Make each status mean something observable
- Reported: an observation is captured and awaits review.
- Validated: the problem is reproduced, its impact described and the affected scope understood.
- Assigned: a named owner has agreed the next action and target date.
- Ready for retest: a specific change is available in a stated environment.
- Verified: the agreed steps succeed and evidence identifies the build and test conditions.
- Reopened: the problem persists or returns; the new observation is attached.
Keep blocked and deferred work visible, with the dependency, decision-maker and next review date. A temporary access route belongs in a separate field so its adequacy can be reviewed while the underlying repair remains open. Avoid using “done” for both a code change and a verified user outcome.
Prioritize impact and shared causes
During triage, consider whether an essential journey is blocked, how widely the component appears, the availability and quality of an alternative route, and the effort or dependencies involved. Include reports from people using assistive technology. Agree the next action before leaving the item in a backlog.
Group repeated occurrences under a shared cause when appropriate, while retaining examples from the affected pages and states. One missing label in a reusable component may appear on many URLs. Fixing the component is efficient, but the team still needs to verify that the correction reaches the relevant instances.
W3C’s implementation guidance connects assigned responsibilities, prioritization and progress reporting. Translate those responsibilities into named owners who can act on this service, including suppliers where needed.
Follow an issue through a real decision
Report progress with its boundaries
Report essential journeys tested, unresolved blockers, findings awaiting validation, repairs awaiting retest and recurring causes. Include the sample, date and test environments. Explain changes in scope: discovering more pages or enabling new rules may increase findings even as the service improves.
For a simple fictional example, a team begins with 20 validated findings, verifies 8 repairs and adds 5 newly validated findings. The open total is 20 − 8 + 5 = 17. That count describes the register, not a percentage of site accessibility. Keep duplicate handling and reopened items explicit so totals can be reproduced.
Review aging blockers with the people able to resolve them. Feed recurring problems into component fixes, author guidance and release checks. The purpose of tracking is to help work reach users, with a record that can explain what changed.