You Have an ADA Plan. Now What?

A transition plan is a genuine starting point. Writing one means an organization has acknowledged the gap between where its digital content currently stands and where it needs to be under Title II of the Americans with Disabilities Act. That acknowledgment matters. What many organizations discover next is that a plan describes intent — it doesn't constitute evidence of action. When it comes to WCAG 2.1 Level AA compliance under the DOJ Final Rule (28 CFR Part 35), proof requires documentation of what was found, what was fixed, and how the fix was confirmed to work for people who use assistive technology.

This article walks through what that documentation looks like in practice, which WCAG success criteria are most relevant to digital documents, and how organizations can build a compliance process that holds up — even when starting small.

What the DOJ Final Rule actually requires

The DOJ's April 2024 rulemaking under 28 CFR Part 35 establishes WCAG 2.1 Level AA as the technical standard for web content and digital documents published by state and local government entities. The rule covers websites, web applications, and "documents and other types of digital content" that entities make available to the public. That last phrase does significant work — it includes PDFs, Word documents, Excel spreadsheets, presentations, and any other file format linked from a public-facing website.

WCAG 2.1 Level AA is organized into four principles: Perceivable, Operable, Understandable, and Robust. Within those principles, 50 numbered success criteria define specific, testable requirements. For digital documents, the most commonly implicated success criteria are:

• SC 1.1.1 — Non-text Content: Every image, chart, figure, and non-text element must have a text alternative that conveys equivalent information. A photograph of a city council member without alt text fails this criterion for users of screen readers and braille displays.
• SC 1.3.1 — Info and Relationships: Structure conveyed visually — headings, lists, tables, form labels — must also be encoded in the document's tag structure so it can be programmatically determined. A document that uses large bold text to simulate headings without proper H-tags fails SC 1.3.1, regardless of how it looks on screen.
• SC 1.3.2 — Meaningful Sequence: The reading order of content must be logical and consistent. PDFs draw content to the page in the order it was placed during authoring, which often differs from the order a human reads it. A two-column layout where columns interleave when read aloud by a screen reader fails SC 1.3.2.
• SC 2.4.1 — Bypass Blocks: Documents should provide a way to skip repetitive content and navigate directly to sections of interest. In practice, this means proper heading structure and bookmarks in longer documents.
• SC 2.4.2 — Page Titled: The document must have a descriptive title set in its metadata — not just a filename like march-meeting-2024.pdf, but a title that identifies its purpose.
• SC 4.1.2 — Name, Role, Value: All user interface components, including form fields in interactive PDFs, must have programmatically accessible names, roles, and current values. An unlabeled dropdown in a permit application fails this criterion for keyboard and switch-access users.

This list is not exhaustive. Contrast requirements (SC 1.4.3 at 4.5:1 for normal text), language identification (SC 3.1.1), and consistent navigation all apply. But these six criteria account for the majority of failures found in typical government document audits.

From intent to evidence: what documentation looks like

An ADA transition plan says "we will remediate our digital documents." Documentation of compliance says "we remediated these specific documents, here is what was found in each, here is what was corrected, and here is the result of the post-remediation verification." The difference is auditable specificity.

In practice, compliance documentation for a document typically includes four pieces:

• An audit report identifying which WCAG success criteria failed, where in the document the failure occurs, and what category of user is affected. A useful audit report doesn't just say "missing alt text" — it identifies which images lack alt text, on which pages, and whether those images are decorative or carry information.
• A remediation log recording what changes were made to address each finding. For tag structure issues under SC 1.3.1, this means documenting which elements were re-tagged and how the tag tree was repaired. For contrast failures, it records the original and corrected color values and the resulting contrast ratio.
• A conformance report showing the post-remediation state of the document against the same set of checkpoints. The conformance report is what demonstrates that remediation actually worked — not just that it was attempted.
• A VPAT or accessibility statement for documents where one is warranted — particularly high-traffic public forms and reports. The Voluntary Product Accessibility Template is a standardized format for reporting how well a document conforms to WCAG 2.1 AA criteria.

None of this needs to be perfect or exhaustive on day one. What matters is that it's systematic and traceable — that each document's compliance status can be looked up and supported by evidence.

The three components of a working process

Talking to compliance officers, IT directors, and accessibility leads at government agencies, I've found that most organizations have a handle on "we need to fix our documents" but are less certain about the mechanics of doing it in a way that holds up. Three components tend to matter most:

1. Discovery

Before you can remediate, you need an inventory of what you have. Most government websites accumulate documents across years of staff turnover, department migrations, and CMS updates. A crawl of a mid-sized city website commonly surfaces hundreds to thousands of linked PDFs — many of which were never intentionally published as public resources.

Discovery doesn't require perfecting the inventory before starting remediation. It means having enough visibility to prioritize. Which documents are linked from the homepage? Which are required for people to access services — permit applications, public notices, meeting agendas? Those are the ones to start with.

2. Remediation

Remediation is the process of actually correcting accessibility failures in a document. This is more involved than running a checker and clicking "fix." Genuine remediation addresses the underlying document structure: repairing tag trees, correcting reading order, adding proper alt text to images, labeling form fields, setting the document title in metadata.

A key distinction: verification that a document looks correct in Adobe Acrobat is not the same as verification that it works correctly for people using assistive technology. Screen readers, braille displays, magnification software, text-to-speech tools, and keyboard-only navigation each interact with document structure differently. A fix that addresses one failure mode may not address another.

3. Verification

Verification means confirming that remediation produced a document that actually conforms to the relevant WCAG success criteria — not just that the original audit findings were marked as addressed. The most useful verification involves both automated re-auditing (which can rapidly check hundreds of criteria) and, where feasible, testing with real assistive technology.

Automated re-auditing catches structural failures reliably. Things like missing tags, incorrect reading order, unlabeled form fields, and absent document titles are detectable by inspection. Some issues — the quality of alt text descriptions, the logical clarity of table headers — benefit from human review. Both matter.

Process over perfection: starting where it counts

One of the most common points of paralysis I see is organizations feeling they need to remediate everything before they've demonstrably remediated anything. The better frame is that a systematic process applied to 10 or 15 of the most-used public documents is more meaningful — legally and practically — than a plan that promises everything and delivers nothing while the inventory is still being scoped.

The DOJ has been clear that it evaluates good faith efforts. Good faith means a documented, systematic approach. It doesn't mean an impossible standard of retroactive perfection for a 20-year document backlog. Starting with the forms people actually use to interact with government services — the permit application, the public comment form, the meeting agenda — and working outward from there is a defensible, practical approach.

Budget-constrained organizations should think about where accessibility failures have the most human impact. A grant application that can't be completed by someone using a switch-access device is not just a compliance gap; it's a barrier to participation. Starting there is both the right priority and the most justifiable use of limited resources.

What Foresera produces

Foresera runs documents through the full pipeline described above. For each document, the platform generates an audit report identifying WCAG failures by criterion and location, applies remediation to the document structure, runs a verification re-audit, and generates a conformance report. For documents that warrant it, VPAT generation is part of the output.

The audit and conformance reports are designed to serve as the documentation described earlier in this article — the kind of artifact that shows what was found, what was changed, and what the verified state of the document is. The goal is that an organization can point to that documentation as evidence of a systematic remediation process, not just a plan to have one.

If you're working through the "now what" stage of your ADA compliance effort — you have a plan, you have intent, and you need to start producing evidence — the most useful next step is usually a focused inventory of your highest-impact documents and a clear process for moving them through audit, remediation, and verification. The plan got you here. The process is what takes you the rest of the way.