Which findings to fix first, and when to rebuild instead

How to order an audit's findings by what each does to a task, whom it reaches, where it sits and what the fix costs, when to fix and when to rebuild, and how to write a finding a developer can act on.

In short: Fix first what stops people finishing a key task, and what one change to a shared template or component clears everywhere; then what makes tasks harder; then what only annoys. When the whole interface has to change, fix the blockers now, give people another way through, and plan the rebuild.

When you need this

Riverside Leisure runs 4 swimming pools and sells lessons and lane bookings on its website. An audit of 15 pages came back with 40 findings. The development team has 2 sprints, 4 weeks, before the summer timetable opens, and a new booking platform is planned for next year.

The product owner asks the question every audit leads to: "Where do we start?" The report lists the findings by WCAG criterion, 1.1.1 first. That order says where each finding sits in the standard, not what it does to the people trying to book a lesson.

How to do it

Sort by what each finding does to people, then by how much one fix clears and what it costs. The W3C's implementation advice puts it in one line: high-impact, easy-to-resolve issues first.

Rate the effect on the task. For each finding, ask what happens to the person who meets it:
- It blocks: they can't finish, and the page offers no other way. A sign-in that only a puzzle unlocks, as in CAPTCHAs with no way past them except solving the puzzle, or an editor that Tab can't leave, as in keyboard traps in editors and form fields, is a blocker.
- It makes the task harder: they finish, with extra effort, guessing or help. A dialog that drops focus back at the top of the page when it closes, as in modals that leave keyboard focus behind them, sends a keyboard user Tabbing back through the navigation, but they get there.
- It annoys: they finish, through noise, such as an icon's text read twice beside the link it repeats.
Name who it reaches. Write down which groups of people meet it, using the groups in who is affected. EN 301 549 Annex B maps each requirement to the functional performance criteria it supports, so the row of the failed requirement shows which groups it serves. A finding that reaches several groups, or reaches one group with nothing else to fall back on, moves up.
Weight by where it is. A finding on a key task outranks the same finding on an archive page. The W3C's first-aid page names key tasks (registration, search, submit, checkout, every step of each), frequently used pages such as the home page, content relevant to people with disabilities, and content people have reported. Use the site's analytics for "frequently used", not a guess.
Trace it to its source. Ask where the broken code lives. 30 unlabelled fields may be 1 field component, as in form fields with missing or mismatched labels, and 1 change to the component clears all 30 and every form built later. Group the findings by their source before you count them, and count what each fix clears.
Size the fix. Sort each fix by what it changes:
- Style: CSS only, such as a focus ring or a colour. Usually the cheapest to make and to retest.
- Markup: HTML or ARIA, such as a label tied to its field. Often invisible on screen, so no design sign-off.
- Behaviour: script or server, such as focus management or replacing a CAPTCHA with rate limiting. Needs more testing, sometimes a second team.
Then ask whether the fix changes the interface people see: a new visible label, a moved button, a step taken out of a flow. Those need design and content sign-off, and sometimes a word to users, so they take longer than their code suggests.
Add outside pressure. Note anything outside the audit that makes a finding urgent: a complaint or support email about it, a date in a contract, a letter that names it, a statement the organisation has to publish. Record the fact and its date. What it means in law is a question for a lawyer, not for the ranking.
Set the order and the dates. Put each blocker on a key task first, with the cheap site-wide fixes beside them, since both clear the most harm per day of work. Then the findings that make key tasks harder, then the rest of the harder ones, then the annoyances in one batch. A finding that waits for the rebuild gets an interim repair and a date. Rank again after each release: a fix changes what is left.

Fix now or rebuild

Sometimes the honest answer to a finding is that the part should be rebuilt. The choice is part by part, not for the whole site.

Factor	Points to fixing now	Points to rebuilding
How far it spreads	A few components or pages	The same failure in most templates, or in the platform itself
The code	Clear, owned, and changed often	Generated, vendor-locked, or nobody can change it safely
People meanwhile	A blocker on a key task, which can't wait	An inconvenience people can get round until the rebuild
Resources	A small fix the team can make this sprint	Each fix costs nearly as much as building it again
The future	The part stays for years	A replacement is already funded and dated

The usual answer is both: fix the blockers now, plan the rebuild, and give people another way through in the meantime. The W3C's implementation advice suggests putting less into tools or systems, such as a CMS, that are about to be replaced, and its first-aid page puts areas being redesigned in scope so they don't create new barriers. A rebuild without a date is not a plan: until it ships, the barriers in the old part are still there, so name each one and its other way through in the site's statement, as in accessibility statements that are missing or say nothing.

A finding a developer can act on

The order only helps if each finding can be picked up and fixed without a meeting. A finding a developer can act on answers 3 questions:

Where: the page address, the component, and the state it fails in ("Booking page, step 2, the Notes editor, after typing"), with the steps to get there. Say whether it repeats on every page that uses the component.
What: what happens, to whom, and the criterion it fails ("Tab indents the line instead of leaving the editor, so keyboard users can't reach Confirm booking; WCAG 2.1.2 No Keyboard Trap"). Add a screenshot or a short recording when the failure takes steps to show.
How: the fix in code terms, with a link to a worked fix, and how to check it ("Stop intercepting Tab, or release it on Escape and say so on screen; then Tab and Shift + Tab leave the editor").

"Not accessible to screen readers" answers none of the 3. EaseWeb's sample report writes each finding this way: its location, what the tester saw, the remediation, the evidence, and whether it is a global issue.

Worked example

The team groups the 40 findings by source first. They come down to 15 fixes. These are the 8 that decide the order:

Fix	What it does, and to whom	Order
The global CSS reset removes the focus ring	Harder for keyboard users on every page; 1 CSS rule	1, sprint 1: site-wide for one line
The sign-in shows a CAPTCHA after 2 wrong passwords, with no other way in	Blocks sign-in, so booking, for screen reader users and people who can't read distorted text	2, sprint 1: blocker on a key task; replace with rate limiting on the server
The shared field component's labels are loose text (18 fields on 5 forms)	Harder for screen reader and voice control users on every form, booking included	3, sprint 1: one markup change, no visible change
The booking Notes editor keeps Tab for indenting	Blocks the booking step for keyboard users	4, sprint 1: blocker on a key task
The shared dialog component leaves focus behind (4 pages)	Harder for keyboard users choosing a session	5, sprint 2: behaviour change, retest on all 4 pages
Low-contrast text on the news pages	Harder for people with low vision, on pages 2% of visits reach	6, sprint 2
Icon text read twice beside its link (6 places)	Annoys screen reader users	7, one batch after sprint 2
The timetables are PDFs exported by the old CMS with no structure	Harder for screen reader users; the new platform replaces the export	Rebuild, with the timetable as an HTML page in the meantime

The ranking puts the global focus ring first even though it only makes things harder: it is 1 line, it reaches every page, and keyboard users need it to use the other fixes. The CAPTCHA and the editor are the 2 blockers on the key task, booking, so both land in sprint 1. The timetable waits for the new platform because the old CMS writes the PDF, but people can't wait a year, so the interim repair is a plain HTML timetable page, listed with a date in the accessibility statement.

The result: sprint 1 clears both blockers and 2 of the 3 shared components, and the field component alone was 18 of the 40 findings. Every finding has an owner and a date.

Common mistakes

Fixing in the report's order. The criteria are numbered by principle and guideline, not by harm, so 1.1.1 first can mean every image's alt text before a keyboard trap on the booking step (2.1.2). Rate each finding by its effect on the task, as in the steps above.
Ranking by the number of instances. A scan that reports 300 instances of one missing label reports 1 cause; a single CAPTCHA blocks everyone who meets it and can't solve it. Group by source first; what automated checks miss covers what a scan can and can't establish.
Fixing each page instead of the component. Patching the 18 fields one by one leaves the component broken for the next form. Fix it where it is rendered, as form fields with missing or mismatched labels does.
Treating the level as the order. The W3C's first-aid page counts a Level A issue as one sign of high impact, beside where the issue appears and whether a process depends on it. A Level AA failure on checkout can matter more than a Level A one on an archive page.
Waiting for the rebuild with nothing in between. People meet the old site until the new one ships. Give each postponed barrier an interim repair, and say so in the statement, as in accessibility statements that are missing or say nothing.
Closing a fix untested. A ticket closed on the code review alone often comes back. Retest each fix the way it was found; testing a whole site against WCAG, and standing behind the result covers how.

What the standard says

No standard sets an order of repair. What they set is what counts as meeting them, and the groups of people each requirement serves.

WCAG 2.2 §5.2.1 (required): "One of the following levels of conformance is met in full." A page conforms at Level AA only when it meets every Level A and AA criterion, or a Level AA conforming alternate version is provided, so the order of fixing changes when a page conforms, not whether every failure has to go.
EN 301 549 V4.1.1 Annex B (informative): "Table B.2 illustrates the impact a specific accessibility issue might have on different users" (B.2.0), by showing which requirements in clauses 5 to 13 support each functional performance criterion of clause 4.2. "P = Primary relationship. The requirement supports the functional performance criterion." "S = Secondary relationship. The requirement provides partial support for the functional performance criterion because some users may use the feature in specific situations." V3.2.1 (2021-03) has the same annex, calling them functional performance statements. ETSI published V4.1.1 in September 2026; check which edition your law or contract cites.
Section 508 §302 (required, for US federal ICT): 9 functional performance criteria, from 302.1 Without Vision to 302.9 With Limited Language, Cognitive, and Learning Abilities. EN 301 549 clause 4.2 covers the same groups and adds 2: minimising photosensitive seizure triggers, and privacy.
W3C WAI (advice): "Use resources effectively by addressing high impact, easy-to-resolve issues first." The first-aid page counts as high impact the repairs that appear on many pages, on frequently used pages, in processes such as purchase forms, and Level A issues; as low effort, those that need less time, cost or skill, and less testing.
Japan (advice): the Ministry of Internal Affairs and Communications' guidelines for public websites (2024 edition, 6.2.5) sort repairs by scope, number of places and difficulty, and allow a problem that affects the whole site to wait for the next renewal, with an alternative provided in the meantime. WAIC's guideline for stating JIS X 8341-3:2016 conformance (3.2) allows "partial conformance" (一部準拠) only with a stated plan for what comes next.

Limits

This page orders findings; it doesn't decide whether each one is a failure, which is the tester's call, made as in testing a whole site against WCAG, and standing behind the result. The ranking is a judgement the client owns: the team knows its analytics, its code and its budget, and may weigh them differently. Legal and contract risk changes the order, but what a law or contract requires is for a lawyer to say. Keeping the same findings from coming back in the next project is in who does what, and when, so accessibility isn't left to the end.

Terms

blocker: A finding that stops a person finishing a task, with no other way through on the page.
key task: A task the site exists for, such as signing up, searching, booking or paying, with every step it takes.
shared component: A template, component or design-system part that many pages render, so one fix in it clears every page that uses it.
interim repair: A fix or another way through that removes a barrier now, while a larger rebuild is planned.

Sources and guides

Guides that show it

This page explains a practice, with recreated examples. It is not legal advice, and it is not a finding about a named client.