How to Prioritize Accessibility Issues

A first scan of a typical website returns more findings than a team can fix at once. Prioritizing is not optional; it is how the work starts. The question is what to rank by, because the order a scanner produces and the order that helps users most are rarely the same list.

Start with blocked tasks, not issue counts

The most important question about any finding is what it prevents. A barrier that stops someone from completing a core task matters more than a dozen cosmetic issues on rarely visited pages.

An unlabeled "Submit payment" button is a checkout blocker. Ten missing alt attributes on decorative blog thumbnails are not a journey blocker, even though the count is higher. If an issue can stop a person from finishing the thing they came to do, it goes near the top of the list regardless of how it ranks elsewhere.

Consider who is affected and how

Two findings with the same technical severity can affect people very differently. Ask who encounters the barrier and what it costs them:

• An issue that makes a control unusable for keyboard users may be a total blocker for some people.
• An issue that makes content confusing or slower to use may still leave the task completable.
• Barriers facing people who rely on assistive technology tend to be more blocking than issues that are merely nonstandard.

Severity ratings from scanners are a useful shorthand for this judgment, but they are estimates of rule importance, not measurements of impact on your users in your context. Treat them as one input.

Weigh page importance and shared components

Two further factors change where a finding belongs in the queue:

• Where it lives. A navigation barrier appears on every page. A defect on the checkout page outweighs the same defect in an archived press release. High-traffic pages and core journeys concentrate impact.
• Where it comes from. Issues generated by shared templates and components repeat across the site. One fix to a shared form component may clear the same barrier on forty pages, which makes it more valuable than forty individual fixes.

This is also why raw occurrence counts mislead: a component bug repeated on every page inflates the count without proportionally increasing the work. Fixing the component once retires all of them.

A realistic example

A scan of a library website returns 60 findings. A reasonable ordering, based on the factors above rather than scan order:

1. The "renew books" button cannot be reached by keyboard. One finding, but it blocks a core task for every keyboard user on the site.
2. The site header search field has no label. A shared component, so the fix clears it everywhere.
3. Event listings use low-contrast date text. Common and easy to fix in one stylesheet change.
4. Forty news photos lack alt text. Real work and worth doing, scheduled after the blockers unless editorial time is already planned.

Notice what did not drive the order: the count per issue type, and the scanner's own severity sort. Both informed it without dictating it.

Make priorities defensible

Whatever order you choose, record it: which findings were ranked first, why, and who owns them. A prioritized list with named owners turns a scan report into a work plan, and the reasoning written down now is what explains the order later. Deadlines belong to your organization's own commitments and obligations, not to a generic urgency invented by a report.

The remediation checklist fits prioritization into the full find-fix-verify loop, and How to Document Accessibility Improvements covers what to record. In SiteRecord, every finding carries an assignee, a priority, and its history, so the ranking and the reasoning stay attached to the work.