You handed someone a WordPress site for an accessibility audit. The report came back with 437 findings. The number is paralyzing — nobody fixes 437 things in a sprint, or even a quarter. The question is where to start, and most audit reports don't help: they prioritize by tool severity, not by user impact. Here's how I sequence the work when the queue is too long for the budget.
The accessibility audit deliverable is a spreadsheet. 400+ rows. Every row has a severity label assigned by the scanner, a WCAG criterion reference, a code snippet, and a recommended fix. The number is overwhelming, and the severity column — usually some flavor of critical/serious/moderate/minor — is misleading. The scanner is calling severity based on which WCAG criterion is violated, not based on how badly the site actually fails real users. Those are very different questions.
The job at this point is to ignore the spreadsheet’s prioritization and re-sequence the work based on what actually affects whether a person with a disability can use the site.
The criteria the scanner can’t see.
Three things determine real-world impact that don’t show up in the audit report:
- How many users see this. A bug on the homepage hero is encountered by every visitor. A bug on a long-tail blog post from 2019 is encountered by a handful. Both might have the same WCAG severity. The first one matters more.
- What the bug actually blocks. A missing alt tag on a decorative inline image and a missing alt on the “Contact us” CTA button are both “missing alt text.” The first one is a minor nuisance for screen-reader users. The second one is a failure: the user can’t tell what the button does.
- Whether the bug cascades. A broken focus state on a component used 200 times across the site is one problem pretending to be 200. A standalone bug on one page is one problem.
How I re-sequence the queue.
Five buckets, in the order I work them:
- Bugs on global elements (nav, header, footer, CTAs). These show up on every page. Fix one, fix many. Anything in the global chrome that’s broken should be the first morning’s work, regardless of the scanner’s severity rating.
- Bugs on the highest-traffic templates. Pull the top 20 pages from analytics. For most marketing sites, that’s homepage, top three solution pages, top three blog posts, contact, pricing, and a handful of landing pages. Bugs on those templates affect almost everyone who comes through the site. Fix them before fixing bugs on the archive of 2019 blog posts that get six visits a month.
- Bugs that block primary actions. Anything that makes a user unable to complete the thing the page is designed for — submit the form, navigate the menu, read the article, use the search. Even if the scanner rates these as “moderate,” they’re functional blockers.
- Bugs that the scanner missed but a screen-reader user would hit. Run NVDA or VoiceOver against the top 10 templates yourself. The bugs you find — focus traps, ambiguous announcements, broken landmark structure — are usually invisible to automated tools and absolutely block actual use.
- Long-tail and edge cases. Decorative-image alt text on the 2019 archive, contrast on a footer link that’s rarely clicked, headings out of order on an old landing page. These get done eventually. They’re last.
What to flag for the client.
Some accessibility issues aren’t a developer’s decision. They’re product, content, or design decisions that someone else has to make. Surface those separately:
- Auto-playing media without controls. Maybe a marketing choice, maybe an oversight. Flag it.
- Image-only text (logos, infographics) without text alternatives. The design team needs to provide accessible alternatives or accept that some users can’t access the content.
- Color choices that fail contrast on brand colors. Sometimes brand identity is set; sometimes it’s negotiable. Either way, the brand owner has to decide.
- Form fields that ask for data in inaccessible ways. A datepicker without a text-input fallback, a CAPTCHA that only works visually. Product decisions, not code-level fixes.
These should go on a separate page of the deliverable: “Decisions for the client.” Don’t bury them in a 400-row spreadsheet hoping someone will sort them out. Surface them as questions that need answers.
The first week.
A realistic first week of work on a 400-finding audit looks like this:
- Day 1-2: Fix the global chrome — nav, header, footer, CTA buttons. Verify across all templates.
- Day 3-4: Fix the top 10 templates. Run a screen reader against each one and add findings the audit missed.
- Day 5: Document what’s been done, what’s left, and what’s blocked on client decisions. Send a status update.
At the end of week one, the spreadsheet count might only have dropped from 437 to 280. But the site is meaningfully more accessible to most users than it was on Monday, because the fixes you made were on the surfaces they actually touch. That’s the goal — user experience moves, not just the dashboard. See accessibility that holds up for the ongoing process side.