How to Build an Accessibility Remediation Plan From a Scan
An accessibility remediation plan counts defects, not scan errors. Most of the thousands of errors a scan reports come from a few template bugs, repeated on every page.
To build the plan, prune pages you don’t need. Sort the rest into templates, content, and documents, fix templates first, and target Web Content Accessibility Guidelines (WCAG) 2.1 Level AA.
This guide is for technology and digital leads at public agencies, universities, nonprofits, and enterprises. It summarizes public sources and isn’t legal advice.
Key Takeaways
- A scan counts copies, not defects. One bug in a shared header or form repeats on every page.
- Findings sort into three buckets: templates for engineers, content for editors, and documents to fix or retire.
- Prune first. US and EU rules both exclude archived content that meets their tests.
- Report open template defects, new content issues, and documents left to fix, not the scan total.
- Target WCAG 2.1 AA, the level US rules name, not AAA across the whole site.
Why Does an Accessibility Scan Report Thousands of Errors?
An accessibility scan reports thousands of errors because it counts every copy of a failure on every page. One bug in a shared header, footer, or form repeats on each page that uses it.
So the useful count is unique defects. A unique defect is one root cause counted once, no matter how many pages show it.
Picture a hypothetical 3,000-page site. Its search box has no label, its footer text fails contrast, and its three social icons are links with no text. Those three bugs produce 15,000 reported failures, and each needs just one fix.
At web scale, the WebAIM Million 2026 report found six error types behind 96% of the errors on the top one million home pages.
The count is also incomplete, since automated tools can’t catch every failure. So the total is too large as a measure of work and too small as a measure of risk.
What Changed in 2026 About Accessibility Deadlines?
Two US agencies pushed their web accessibility deadlines back one year in spring 2026. The standard is still WCAG 2.1 Level AA.
In April, the US Department of Justice (DOJ) moved its Americans with Disabilities Act (ADA) Title II dates. Governments serving 50,000 or more people now have until April 26, 2027. Smaller governments and special districts have until April 26, 2028.
The DOJ’s interim final rule changed only the dates, though the DOJ said it may propose other changes later. In May, the US Department of Health and Human Services (HHS) extended its Section 504 deadline to May 11, 2027, for funded groups with 15 or more employees.
The DOJ also found that generative AI can’t yet fix inaccessible content reliably at scale. So more of the work stays manual, and every extra page costs staff time. Spend the extra year on root-cause fixes and pruning.
Which Accessibility Failures Belong to Templates, Content, or Documents?
Accessibility failures sort into three buckets, each with its own owner and fix. Templates are the shared parts many pages reuse, such as headers, menus, and forms. Engineers own them, editors own page content, and documents need a choice first: fix or retire.
Table: Accessibility findings by bucket, owner, and fix
Bucket | Typical findings | Owner | How it gets fixed | How it stays fixed |
|---|---|---|---|---|
Templates and components | Low-contrast theme text, unlabeled form fields, empty icon links and buttons, missing page language | Engineers | One fix in the shared component | Accessibility tests in every release |
Page content | Skipped heading levels, missing or vague alt text, link text such as “read more” | Editors | Page edits, most-used pages first | Required fields, training, and checks at publish time |
PDFs and documents | Untagged PDFs, scanned images of text, broken reading order | Document owners | Fix the file, rebuild it as a web page, or retire it | Publish new information as web pages |
Read the table by its last column. Template fixes last once releases test them, but content and documents keep breaking until publishing changes.
How Do You Fix Template and Component Failures?
Fix each template failure once, in the shared component, and every page gets the fix. Add accessibility tests to each release so the bug can’t return, and test key templates with a keyboard and a screen reader. Our WCAG 2.2 AA checklist for Drupal covers the setup.
How Do You Fix Page Content Issues Like Alt Text and Headings?
Page content issues, such as skipped headings, missing alternative text (alt text), and vague link text, return with every new page. Start with the pages people use most, not those with the highest counts.
The content management system (CMS) can help. In Drupal core’s CKEditor 5 editor, an image without alt text shows a warning. The warning stays until the editor adds alt text or marks the image as decorative, per the Drupal core issue that added it.
Varbase, Vardot’s open-source Drupal distribution, can add an on-page accessibility checker for editors and AI-suggested alt text that editors review before saving.
What Should You Do With PDFs and Documents?
Fix a PDF, rebuild it as a web page, or retire it. Fixing a long PDF by hand is slow, so first ask whether anyone still needs it.
The ADA Title II rule generally exempts PDF, Word, slide, and spreadsheet files posted before the compliance date, per the DOJ’s fact sheet. The exemption ends if people still use the file to apply for or access a service. The European Accessibility Act (EAA) excludes office files published before June 28, 2025.
Should You Prune Pages Before You Fix Them?
Yes. Every old page you delete or archive drops its errors from all three buckets and from future upkeep.
Archiving has rules, so moving a page into an archive folder isn’t enough. Under ADA Title II, archived content must predate the compliance date, be kept only for reference or records, sit in a marked archive area, and stay unchanged. The European Accessibility Act excludes archive content not updated or edited after June 28, 2025.
Prune from a site inventory that names an owner for each section.
Should You Aim for WCAG AA or AAA?
Aim for WCAG AA. WCAG has three levels: A is the floor, AA the usual target, and AAA the strictest. US rules name WCAG 2.1 Level AA.
The World Wide Web Consortium (W3C), which writes WCAG, advises against requiring AAA site-wide. Its guidance on conformance says some content can’t meet every AAA criterion.
The AAA criteria show why. They include 7:1 text contrast (1.4.6), sign language for recorded audio (1.2.6), and a simpler version of any text above a lower secondary reading level (3.1.5).
Apply all of AAA to every page of a content-rich site, and very little would pass. Use single AAA criteria where they help, such as plain language on key service pages.
What Should You Report Instead of the Scan Total?
Our view: the scan total is the wrong number to manage and to report. One template fix can cut it by thousands, and a scan of a new section can raise it overnight.
Manage unique defects, each with an owner. Then report the three numbers that predict whether the site stays compliant:
Open template defects
New content issues per publishing cycle
Documents left to fix or retire
From a quality assurance (QA) seat, accessibility bugs act like any regression, a bug that returns after a fix. A fixed component breaks again when a release ships without an accessibility test. A fixed page breaks again when an editor publishes without a check.
That’s why enforcement is part of the fix, not a later phase. This matters most on the multilingual sites Vardot builds for nonprofits, intergovernmental groups, and the public sector, where one template bug repeats in every language.
How Do You Turn an Accessibility Scan Into a Remediation Plan?
An accessibility remediation plan turns a scan total into a short list of defects, each with an owner and a place in line. Run these six steps in order:
Prune. Delete or archive pages that no longer serve anyone.
Group by root cause. Sort findings by rule and by the component or page that caused them. Count unique defects, not copies.
Assign owners. Engineers take templates, editors take content, and document owners take files.
Fix in order of reach. Templates first, then the most-used pages, then documents people still use.
Enforce. Add accessibility tests to each release, require alt text at publish time, and publish new information as web pages. Skip this, and you pay for fixes twice.
Monitor. Rescan on a schedule, test by hand what scans miss, and track new issues per release as part of ongoing Drupal support.
Are You Still Fixing, or Staying Compliant?
Fixing means root-cause fixes plus enforcement. Staying compliant means good templates plus monitoring. Check where your site stands:
Still fixing: your scan total has never been grouped by template, template bugs still drive most of it, or some defect types have no owner.
Staying compliant: template bugs are closed, new issues come mostly from new pages, and checks run in each release and at publish time.
If you’re still fixing, spend the next quarter on pruning, root-cause fixes, and enforcement. If you’re staying compliant, budget for monitoring, editor training, and release tests. That cost never drops to zero.
Where Should You Start With Accessibility Remediation?
Vardot audits, fixes, and builds accessible Drupal sites, so pruning and template-first fixes cut work we could bill. We recommend them anyway, because they shrink later work and keep fixes from breaking again.
If your scan total hasn’t been grouped by root cause, start with an audit. A Vardot Drupal audit reviews accessibility alongside security and performance, rates every finding by risk, and typically takes one to two weeks.