Skip to main content
    Foresera
    ← Resources
    March 2026 · 12 min read

    ADA Title II 2026: What Cities Actually Need to Do

    M

    Matt

    Founder, Foresera

    In April 2024, the Department of Justice finalized a rule under Title II of the Americans with Disabilities Act (28 CFR Part 35) establishing WCAG 2.1 Level AA as the technical standard for web content and digital documents published by state and local government entities. The deadline for cities, counties, and other entities serving 50,000 or more people is April 24, 2026. Smaller entities — those with populations under 50,000 — have until April 26, 2027.

    Most of the compliance conversation has focused on websites: do pages have proper heading structure, are navigation menus keyboard-operable, do images have alt text in the HTML. The document side — the hundreds or thousands of PDFs, spreadsheets, and forms that most government websites link to — has received considerably less attention. This article focuses on both, with particular attention to what the document requirements actually mean in practice.

    What "web content" covers under the rule

    The DOJ rule defines web content to include not just web pages but "documents and other types of digital content" that entities make available through their websites. The rule specifically names PDFs, Word documents, presentation files, and spreadsheets as examples of covered content. It also addresses the question of existing content: documents published before the compliance deadline still count. The backlog is not exempt.

    There are limited exceptions. Content posted before June 24, 2024, that has been archived and is not actively used may be excluded. But "archived" has a specific meaning — it means content that is no longer updated, stored for reference or record purposes only, and clearly identified as such on the website. A meeting agenda from 2018 that's still linked from a department page without an archival label is not archived under the rule — it's just old.

    Password-protected content and content posted solely by members of the public (like public comments submitted to a portal) are also excluded from the main requirements, though entities should review the full rule text for specifics.

    The WCAG success criteria that matter most for documents

    WCAG 2.1 Level AA contains 50 numbered success criteria organized under four principles. For digital documents, the following criteria are the most commonly relevant — and the most commonly failing:

    • SC 1.1.1 — Non-text Content: Every image, chart, diagram, figure, and decorative graphic must have an appropriate text alternative. Informational images need descriptive alt text that conveys equivalent information. Decorative images should be marked as such so assistive technology can skip them. A photograph of a city council meeting without alt text fails this criterion for screen reader users and people using braille displays.
    • SC 1.3.1 — Info and Relationships: Structure that is conveyed visually — headings, lists, tables, form labels — must also be encoded in the document's tag tree so it can be programmatically determined by assistive technology. A document where large bold text simulates headings without proper heading tags fails SC 1.3.1. A table where column relationships exist visually but not structurally fails SC 1.3.1. This criterion affects screen readers, braille displays, and text-to-speech tools.
    • SC 1.3.2 — Meaningful Sequence: The reading order of a document must be logical when consumed sequentially. PDFs store content in the order it was drawn to the page during authoring, which frequently diverges from the visual reading order. A two-column layout that interleaves content between columns when read linearly fails SC 1.3.2. Sidebars, headers that repeat across pages, and complex multi-column layouts are common sources of reading order failure.
    • SC 1.4.3 — Contrast (Minimum): Normal text must achieve a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) requires at least 3:1. Light gray text on white backgrounds, watermarks, and decorative text overlaid on photographs commonly fail this criterion. Contrast failures affect people with low vision and those reading in high-glare environments.
    • SC 2.1.1 — Keyboard Accessible: All document functionality must be operable via keyboard alone. For most static documents this is addressed by proper tag structure. For interactive PDFs with form fields, this means form fields must be navigable by Tab key and operable without a mouse. People who use keyboard-only navigation, switch access devices, and some voice input software depend on this criterion.
    • SC 2.4.1 — Bypass Blocks: Documents should provide a mechanism for users to skip repetitive navigational content and jump to sections of interest. In practice, this means meaningful heading structure that allows screen reader users to navigate by heading, and bookmarks in longer documents.
    • SC 2.4.2 — Page Titled: Every document must have a descriptive title set in its metadata — not a filename, not "Untitled," not whatever the authoring software populated by default. The title should identify what the document is.
    • 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 text field in a permit application that a screen reader announces only as "text field" fails this criterion. It prevents people using screen readers, braille displays, and voice input software from accurately completing the form.

    A typical government PDF audit surfaces failures across most of these criteria. It's unusual to find a document published through a standard workflow — Word export, print-to-PDF, or auto-generated report — that passes all of them without remediation.

    What "good faith" looks like in practice

    The DOJ's rulemaking history and technical assistance materials make clear that compliance is evaluated in terms of systematic, documented effort — not instantaneous perfection. A city that has been aware of the requirement, has made a documented effort to inventory and remediate documents, and can show an ongoing process is in a substantively different position than one that has taken no action.

    Good faith, in this context, means:

    • A documented inventory of what content the organization publishes
    • A prioritization process — not arbitrary, but based on public impact and traffic
    • Remediation activity with associated records: what was done to which document, by whom, when, with what result
    • A verification step confirming that remediation produced a conformant document
    • An ongoing process for new content published after the baseline remediation

    None of this requires completing the entire backlog before the deadline. An organization that has fully remediated and documented its hundred most-accessed documents, has a plan for the remainder, and has established a process for new content is demonstrating systematic effort. That's meaningfully different from having written a plan that says "we intend to do this."

    Common patterns that leave organizations exposed

    Talking with IT directors and compliance officers at cities and counties across Texas and the broader Southwest, a few patterns come up consistently:

    Certified template, unaudited documents

    The city's CMS — often a major government-focused platform — has been certified as accessible. The IT department has done the work, has the report, and considers the website compliant. What wasn't addressed: the several hundred PDFs linked from those pages. The CMS certification covers the HTML template. It doesn't extend to binary files uploaded through the file manager. These are different things, and the difference matters under the rule.

    One-time project, no ongoing process

    An organization hired a contractor to remediate documents — perhaps in advance of a specific review or in response to a complaint — but didn't establish a process for documents published afterward. New meeting agendas, new budget documents, and new forms are published through the same workflow that produced the inaccessible backlog. The one-time project created a historical baseline but left the ongoing situation unchanged.

    Treating the backlog as optional

    The interpretation that existing documents are exempt — that only new content published after the deadline needs to meet WCAG 2.1 AA — is not supported by the rule's text. The DOJ has been explicit that the rule covers content posted before June 24, 2024, with specific and narrow exceptions. A city website's meeting minutes archive, planning documents, and public notices all fall within scope unless they meet the archival exception criteria.

    Relying on website scanners as the primary compliance check

    Automated website accessibility scanners are valuable tools for identifying HTML-level failures — missing alt text in page content, missing form labels in HTML forms, color contrast issues in rendered CSS. They are not designed to evaluate the accessibility of linked binary files. A scan that returns a high accessibility score is reporting on the HTML of your pages. It is not reporting on the accessibility of your PDFs. Organizations that rely solely on scanner scores to assess their document compliance are measuring the wrong thing.

    A practical starting framework

    Given the scale of most government document inventories and the reality of limited staff and budget, a staged approach tends to be more productive than attempting to scope the full problem before starting remediation. Here's a framework that has worked well in practice:

    Step 1: Inventory

    Crawl your public website to identify every linked document. A proper crawl captures the URL of each document, the page it was linked from, the anchor text used, and when it was last modified. The output is a manifest of your document inventory. For most mid-sized city websites, this takes hours to days depending on scope — not weeks.

    The inventory doesn't need to be perfect before you start remediating. You need it to be good enough to prioritize.

    Step 2: Prioritize by public impact

    Not all documents carry equal weight. Prioritize documents that are required for people to access government services, that are linked from high-traffic pages, or that represent current-year information people are likely to be seeking. In most cities, this points toward:

    • Active permit and license application forms
    • Public notice documents (variance notices, environmental reviews, bid announcements)
    • Current and recent budget documents and financial summaries
    • City council meeting agendas and minutes from the past one to two years
    • Documents required for program enrollment or benefit applications

    For organizations with constrained budgets, starting with ten to fifteen documents in this category is a meaningful beginning. It creates documented evidence of a systematic process and addresses the content most likely to matter to people who depend on it.

    Step 3: Audit and remediate

    Run each prioritized document through an accessibility audit that checks against the WCAG criteria listed above. The audit should produce a report identifying specific failures by criterion and location — not just a pass/fail score. Then remediate: correct the tag structure, repair reading order, add alt text, label form fields, set the document title.

    Remediation is not the same as running a checker and marking issues as addressed. Genuine remediation modifies the underlying document structure to resolve each failure. The result is a structurally different file, not just a re-scored one.

    Step 4: Verify with assistive technology

    Post-remediation verification should confirm that the fixed document actually works correctly for people using assistive technology across the five disability categories. Automated re-auditing catches structural failures reliably. For high-priority documents — especially interactive forms — human testing with screen readers, keyboard-only navigation, and magnification software catches issues that automated tools may miss.

    Step 5: Establish an ongoing process for new content

    Once the initial backlog remediation is underway, the harder problem is preventing the backlog from growing. New documents published through the same authoring workflows will have the same accessibility gaps unless something in the process changes. This means either modifying the publishing workflow to include accessibility checks, using an authoring guide that addresses accessibility at source, or establishing a remediation step as part of the publication process for new documents.

    Neither approach is costless. Both are significantly less expensive than remediating years of accumulated documents after the fact.

    Where to put your energy now

    For cities and counties approaching the April 2026 deadline, the most productive use of the remaining time is not debating whether the rule applies or scoping a multi-year compliance program. It's starting: inventorying what you have, identifying the highest-impact documents, remediating them systematically, and documenting the work. Ten fully remediated and documented documents with conformance reports is more defensible than a transition plan that promises a thousand.

    The document side of Title II compliance has been underweighted in most organizations' planning. The website scanner score, the CMS certification, the accessibility statement — these are important, and they're not the whole picture. The PDFs, forms, and reports that people actually use to interact with local government carry the same legal requirements as every other piece of web content. Getting those documents right is what the rule is asking for.

    Are you an early adopter?

    We're looking for compliance teams, IT directors, and accessibility leads who want to shape the product.

    Get Early Access

    Do you use assistive technology?

    Your feedback directly improves how we remediate documents for people who rely on screen readers, magnifiers, and braille displays.

    Share Your Experience
    Compliance Analysis

    See what we find

    Run a full WCAG compliance audit on your documents. Upload a PDF and get results in minutes.

    112
    WCAG Issues
    118
    Auto Fixes
    15
    Doc Templates

    By submitting, you agree to receive email communications from Foresera regarding your results. Privacy Policy