Accessibility Monitoring
Accessibility Remediation Priorities: Which Issues to Fix First
A first assessment of a mid-sized government website routinely returns hundreds of findings, and the instinct is to start at the top of the list. The better order is by what currently blocks somebody from finishing a task, because a barrier on an application form matters more than a hundred cosmetic defects in an archive.
Sources
Key takeaways
- Blockers before volume: anything that stops a task being completed outranks anything that merely makes it unpleasant.
- Templates before pages: one header or component fix can clear a defect from every page at once.
- Transactions before brochures: forms, portals and payments carry the real risk; a photo gallery does not.
- Count findings per template, not per URL: a raw URL count makes a small problem look enormous.
What makes a finding a blocker?
That somebody cannot complete the task at all. A form field with no programmatic label, a control that cannot be reached or operated with a keyboard, a focus trap inside a modal, an image-only PDF of the application somebody has to submit, a video with no captions where the instructions are only spoken. Each of those ends the task rather than slowing it down.
In detail
Contrast my earlier example with a decorative image missing alternative text in a 2019 news post. Both are findings. Only one stops a resident applying for a permit this week. Severity in our reports is ordered on that basis, and it is the order we recommend to the people doing the work.
Why fix templates before individual pages?
Because the arithmetic is on your side. A skip link missing from the site header is one defect in the theme and a finding on every URL in the inventory. A form component with an unlabelled input is one component and a finding everywhere that form appears. Fix the template once and the finding count falls in a straight line.
In detail
This is why a report that lists findings by URL alone is close to useless for planning. Ours groups them by the template or component that produced them, so the team can see that eleven hundred findings are really thirty defects repeated, and can sequence the thirty.
How should documents be sequenced against the website?
Run them in parallel, with different rules. Website defects are mostly template work for a developer. Documents are mostly a content and process problem, and the volume is usually larger. Start with the documents people currently use to access or take part in your services, and leave genuinely dormant material where the rule's preexisting-documents exception is likely to apply. The accessible documents guide covers the distinction.
How do you keep a fixed defect from coming back?
By testing again after the next change, not by filing the first report. Themes get updated, vendors push releases, a new plugin reintroduces an old pattern, staff upload a scanned PDF. A remediation programme without a repeat measurement is a snapshot of a day that has passed.
That is the whole argument for monthly monitoring: a scheduled scan, a regression check on everything that changed, a person verifying each finding, and a timestamped record showing when an issue was found and when a later scan verified it resolved. We do not make the fixes ourselves, which is exactly why our verification of them means something.