This post is a follow-up to my previous post urging readers to ask the OMB and DOJ not to delay or modify the DOJ Title II web accessibility rule. As explained here, the new rule won’t cause a flood of problems for state and local governments and is actually quite simple to comply with.
The Bottom Line
Creating a plan and processes, then showing the diligence to follow through with them, is what compliance truly involves under the new ADA Title II web accessibility regulation. That is the key message of everything that follows. Whether you are a small town in rural America or a state agency with thousands of employees, the path to compliance remains the same: build a credible, documented strategy on day one and follow it consistently.
The Fear Is Real, But the Deadline Is Manageable
Over the past year, I have written about the growing chorus of organizations calling for the new ADA Title II web accessibility regulation to be suspended, delayed, or withdrawn. From the American Council on Education's letter asking OMB to pause the rule to the League of Minnesota Cities' more recent effort to have it weakened to credible rumors that it could be pulled entirely through an interim final rule, the skepticism has been loud and persistent.
I understand the impulse. When I first read the draft regulation in 2023, I called it a disaster. My concern was that requiring full WCAG 2.1 Level AA compliance for every public-facing web page was both impractical and counterproductive. The final rule is an improvement, but the language still feels unsettling if taken at face value. The idea that a government must make its entire digital footprint conform to a detailed technical standard seems, on its face, overwhelming. That concern is understandable but exaggerated — it overlooks a key aspect of the rule that most commentary has missed.
The DOJ released the final rule in April 2024 and gave state and local governments a full two years to get ready. Larger entities (i.e., those serving populations of 50,000 or more) have until April 24, 2026. Smaller entities and “special district governments” have until April 26, 2027. That lead time was intentional. DOJ was not requiring governments to drop everything and start fixing their websites immediately after the rule was published. Instead, it was sending state and local governments a straightforward message: here is what’s coming, here is your timeline, get prepared. The rule does not require anything before those effective dates.
This means that a government beginning its compliance efforts on its effective date is not falling behind; it is actually meeting the schedule. If that government starts with a well-planned, documented strategy, few would say it is out of compliance with the ADA; instead (and as explained in more detail below), a deliberate, good-faith effort is exactly what the regulation expects because it would be an undue burden to make all web and mobile apps accessible immediately.
Working with Colorado governments to comply with HB21-1110 (which essentially strengthens the DOJ rule with stricter enforcement, broader scope, and harsher penalties) over the past two years has confirmed this. Colorado governments adapted and met their deadlines. The expected wave of litigation never appeared. Once governments understand what the DOJ rule truly requires and what the defenses of undue burden, fundamental alteration, and minimal impact actually allow, the regulation becomes much easier to handle than it initially appears.
What follows is the practical guide I wish DOJ had created. It aims to demonstrate that a government can achieve solid ADA compliance from the start.
Step 1: Document a Public-Facing Roadmap
The most important step a government can take now is to create and publish a clear, high-level accessibility plan. This isn’t the final version; consider it a work in progress. It acts as a public statement of intent and strategy, showing that the organization has considered its digital environment and developed a concrete plan to improve accessibility over time. Releasing this on day one is a sign of compliance.
Most Colorado governments developed this type of roadmap as part of their HB21-1110 compliance efforts. The roadmaps published by Arapahoe County, the City of Centennial, and El Paso County are worth reading. None of them promises to fix everything immediately. Each document recognizes the scope of the challenge, outlines the main categories of digital content that need attention, and details the organization's general approach for each. That is exactly the right model.
A good roadmap addresses four broad categories of work:
- Existing web applications and mobile apps. State and local governments typically rely on dozens, sometimes hundreds, of third-party web applications and multiple mobile apps to deliver public services, including permit portals, payment systems, parks registration tools, and transit apps. These applications present a unique compliance challenge because the government often lacks direct control over their code. When an application has accessibility barriers, the government's primary influence is through its vendor relationships, not its own development team. The roadmap should acknowledge this reality and commit to a systematic process of inventorying these applications, engaging vendors on their accessibility plans, and prioritizing remediation based on the importance of the services they offer.
- Existing PDFs and other electronic documents. Most government websites host hundreds or thousands of PDF files accumulated over the years. The DOJ rule adopts a practical approach: on the government's April effective date, only documents that are actively used by the public to access government programs, services, or activities need to be accessible. The roadmap should outline a triage process that identifies active, program-relevant documents from historical materials, presents a high-level plan to manage the active ones over time, and explains how users can access information in inaccessible documents that have not yet been made accessible.
- New web applications and mobile apps acquired going forward. Every new application the government acquires after its effective date should be evaluated for accessibility as part of procurement. The standard is not perfection; the goal is taking reasonable steps to find the most accessible option available and documenting how you made that choice. The roadmap should commit to building accessibility evaluation into the procurement process as a standard requirement.
- New documents will be published moving forward. Not every document created by a government needs to be fully accessible; however, documents that support current public programs and services and that are published online or shared publicly should be accessible. The roadmap should commit to a workflow that ensures accessibility is integrated into document creation for the people and teams responsible for public-facing content.
The roadmap should identify the departments responsible for each category and include the organization's staff training plan. It should avoid making specific remediation timeline commitments that may be unrealistic (keep any timeframes general) and avoid naming particular technology products or vendors. Including excessive specific details in a public roadmap can create legal risks without providing real transparency.
The strategic value of the roadmap is both legal and practical. The defenses of undue burden and fundamental alteration under Title II regulation depend on documented, good-faith efforts and practical decision-making. A government that publicly commits to a thoughtful accessibility strategy and actively works to implement it is in a much stronger legal position than one with no plan at all. The roadmap shows regulators, plaintiffs' attorneys, and the public that the organization understands its obligations and takes them seriously. This initial signal is extremely important.
Step 2: Implement the Roadmap
Before diving into the details, it's important to clarify one key point. The regulation adopts WCAG 2.1 Level AA as its technical standard. However, the legal requirement is compliance with Title II ADA. These are not the same because of the defenses built into the ADA and the practical reality that perfect WCAG compliance is usually impossible. This distinction affects everything that follows.
Everything in the implementation phase centers on three legal protections found in the new Title II web accessibility rule: the undue burden defense, the fundamental alteration defense, and the minimal impact exception under Section 35.205. Understanding how each works in practice is what makes the regulation manageable rather than overwhelming.
A. Existing Web Applications
Here’s your step-by-step guide for existing applications:
- Start with an inventory. Identify all public-facing web applications and mobile apps used by the organization. For most government IT and procurement teams, this isn’t a tough task because applications are typically tracked by contract and renewal dates. Procurement staff are often the best starting point since recurring agreements are usually well-documented.
- Reach out to vendors. Right after finishing the inventory, reach out to each vendor. Ask them to explain their current accessibility status and their plans to improve product accessibility. The responses will be insightful. As we have observed in working with Colorado governments, many vendors have already scheduled significant accessibility updates in the upcoming months. Some major software providers hired entire accessibility teams after the DOJ rule was finalized. Others are in the midst of testing and remediation. The market is progressing.
This vendor outreach step offers more value than it might initially seem. It provides extra planning time and helps governments organize their efforts more efficiently. Conducting a thorough accessibility audit on an application that is only three months away from a major accessibility update is a poor use of government resources; any regulator would view it as a waste. This reasoning also supports the built-in ADA defenses. Taking down the application in the meantime would fundamentally change the government service. Expecting an agency to modify its application during this period would likely be seen as an undue burden. In fact, DOJ’s regulation quietly anticipated this scenario when it issued the final rule. In the preamble, the Department stated:
"While the Department understands the concerns raised by commenters that current market options make it challenging for public entities to procure accessible services, the Department expects that options for accessible third-party services will grow in response to subpart H of this part. The Department believes that more accessible options will be readily available by the time public entities are required to comply with subpart H, which will make it less difficult for public entities to procure accessible services from contractors. The Department also notes that public entities will be able to rely on the fundamental alteration and undue burdens limitations in this part in § 35.204 where they can satisfy the requirements of that provision."
89 Fed. Reg. 31,345–46 (Apr. 24, 2024) (emphasis added). DOJ knew that not every application would be accessible on day one. That is precisely why it preserved the undue burden and fundamental alteration defenses — and why a government that engages its vendors early and documents the process is doing exactly what DOJ envisioned.
- Prioritize based on risk and timing of vendor updates. While vendor responses come in, prioritize applications based on risk and the timing of vendor updates. This does not need to be a precise exercise. Applications that deliver core public services, handle high volumes of user interactions, or are only a click or two from the organization's main homepage may rank higher than niche or infrequently used tools. Whatever prioritization metric the organization uses, the goal is simply to be able to explain the logic if anyone asks.
- Start lightweight app testing. Once vendor timelines are known and prioritization is complete, begin lightweight manual testing of the highest-priority applications. The testing goal is not WCAG perfection. The real question is whether a person with a disability can easily use the application to access the services it provides. Test results should be documented and returned to the vendor for remediation. Replacing an application should be considered only when two conditions are both true: there are significant barriers to access and the vendor has been slow or unwilling to address them.
How can a state or local government get away with light accessibility testing instead of conducting a full, detailed accessibility audit? The first reason is simply practical—even the smallest local government uses dozens of applications and cannot afford to spend $8-$15,000 per application on testing. These costs should be covered by the vendor trying to make the sale, not the thousands of jurisdictions that use their product. Second, the regulation's minimal impact exception at Section 35.205 recognizes that very minor WCAG deviations do not constitute a violation. DOJ offered the example of a contrast ratio of 4.45:1 instead of the required 4.5:1 as the kind of slight inconsistency this exception covers. 89 Fed. Reg. 31,388. I believe that time will show this still provides enough of a margin to drive a truck through in many real-world cases; ultimately, no regulator will argue about small barriers that don't actually hinder users across dozens of applications. Third, even if a regulator claimed that the minimal impact exception was unavailable, it would be more difficult to ignore another simple truth—most applications will probably never fully meet WCAG standards, and replacing every application with minor WCAG inconsistencies would be an undue burden.
Documented vendor outreach, thoughtful prioritization, and a phased testing schedule demonstrate exactly the kind of systematic, resource-conscious approach that DOJ envisioned. It would have been better if they had expressed it more clearly.
B. The Main Website and Content Management System
The main government website and its content management system need a different approach compared to third-party applications. Since website content constantly changes, a thorough manual audit followed by regular automated testing offers the most effective solution.
Automated testing tools are frequently criticized for their limitations and that critique is valid. As my colleague Jeff Singleton has written, there are many types of accessibility issues that automated tools cannot reliably detect, including complex keyboard navigation problems, screen reader compatibility for dynamic content, and meaningful image descriptions.
However, automated testing excels at what matters most for managing website content: identifying basic errors like color contrast failures, improper list structures, incorrect heading hierarchies, missing image alternative texts, and inaccessible tables—exactly the kinds of issues that content creators introduce. Other accessibility issues (such as problems with interactive components, navigation patterns, JavaScript behavior, and page templates) occur within the CMS itself and are the vendor's responsibility to fix, not the content author's. This means that automated testing systems effectively cover the range of what content staff can influence, and when combined with an accessibility expert who can filter out false positives and ignore low-impact warnings, they provide a government with a strong, practical quality control system for its content management processes.
One key principle: keep the ruleset simple. More capable automated testing tools can generate more noise than useful signals by flagging potentially inaccessible JavaScript event handlers, edge-case ARIA attribute concerns, and other highly technical issues. For content management purposes, limiting automated testing to the core WCAG success criteria that can be actually violated by content creators yields more actionable results and is easier for content staff to implement. Many content management systems also have built-in integrations with accessibility scanning tools that highlight issues during the publishing process, providing accessibility feedback while content is being created rather than afterward.
C. Existing PDFs and Electronic Documents
The DOJ rule takes a practical view of existing documents. Only documents currently used by the public to access government programs, services, or activities as of the effective date need to be accessible. Documents not actively used to deliver government services on the effective date are not an immediate compliance requirement. I have written about this exception and quoted the rule directly. A deliberate, phased approach that the exception contemplates is precisely what DOJ had in mind.
This makes the challenge mainly about triage. Tools are available to scrape a government website and identify all PDFs and electronic documents it hosts. Running that kind of audit creates a complete inventory from which the organization can distinguish active, program-relevant documents from historical or archival material, then prioritize and work through the active ones.
For documents that need to be accessible, services like DocAccess provide a temporary solution while the organization works through its remediation backlog. DocAccess combines AI-assisted document processing with integration with AIRA, a service that connects people who are blind or have low vision with trained human agents. The real genius isn't in the AI—it’s in the integration of quick access to a human assistant. Additionally, maps, blueprints, diagrams, engineering drawings, and other complex visual documents can never be fully made accessible through automated fixes. A human agent who can describe a zoning map or explain a building plan in real time fills a gap that no amount of PDF tagging can bridge. This matters both legally and practically. The ADA's Title II obligations have always gone beyond mere technical compliance. When technology alone cannot make a program or service accessible, the regulation requires governments to provide reasonable modifications to their policies and to offer auxiliary aids and services. A service like DocAccess with AIRA integration exemplifies an auxiliary aid — one that guarantees a person with a disability access to information in a document from day one, even before the document itself has been officially remediated.*Disclosure: we do not have a business relationship with the products mentioned. Full disclosure note appears at the end of this page.
When the cost of compliance for a given body of documents becomes genuinely disproportionate, that is exactly what the undue burden defense is for. What matters is that the analysis is documented.
D. New Web Applications and Mobile Apps
Every new web or mobile app acquired after the effective date should be assessed for accessibility as a key factor in procurement. I discussed how to approach this in a way that conforms with the new DOJ rule.
The key idea is procuring applications that "best meets" WCAG standards. When no product on the market fully offers WCAG 2.1 Level AA conformance—something still true for many specialized government applications—the obligation is to acquire the product that best meets the standard and to document the basis for that decision. This is, in practical terms, the undue burden defense expressed as a procurement rule. Why? Because a government cannot be expected to build its own perfectly WCAG-compliant software from scratch (or force its vendors to do so) simply because no fully accessible commercial option exists. What it can be expected to do is purchase the most accessible available option from the products that meet its business needs and maintain documentation to demonstrate it has done so.
The challenge here is smaller than it appears. Most states already require Section 508 compliance through their laws or policies. However, Section 508 already mandates this “best meets” analysis. Therefore, state and local governments should know how to perform it and vendors who work with government clients should already understand how to document their accessibility compliance to make the process easier.
E. New Documents
Not every document a government creates needs to be fully accessible. The obligation applies to documents published on the organization's website or distributed through public-facing digital services that support a current program, service, or activity.
Before asking how to make a document accessible, the better question is whether it needs to be published at all. Many organizations over-publish and then burden themselves with compliance requirements that better content management could have avoided. If a document is not relevant to an active program or service, the government should ask whether it belongs on the public website in the first place.
For documents that need to be published accessibly, the goal is to establish a sustainable workflow rather than forcing a heroic global effort. A small group of designated staff, equipped with the right tools, should be responsible for making key decisions about how and when documents are made accessible. These individuals should receive the more advanced accessibility training described below and be provided with document remediation tools. Office applications like Microsoft Word, Excel, and PowerPoint have built-in accessibility checkers that make it reasonably easy to create accessible documents from the start. For documents that require more extensive remediation, using external services tends to be faster and more cost-effective than building internal capacity, and the organization should only expand internal capacity and expertise when volume genuinely overwhelms the current process.
Step 3: Train the Right People
Training should be practical, proportionate, and role-specific.
For all employees, a brief foundational module on digital accessibility is beneficial. Many people are unaware that web accessibility is a practical necessity and some still think accessibility only involves curb cuts and ramps. A basic overview of what digital accessibility includes, why it matters to people with disabilities, and what the law requires helps increase organizational awareness, making implementation easier overall.
For employees who create or manage digital content—such as communications staff, department coordinators posting forms and documents, or anyone updating website content—a second training module is essential. This module should not aim to cover all of WCAG but should concentrate on common mistakes content creators make. This usually includes elements like color contrast, list structure, heading hierarchy, image alternative text, table formatting, and captions and transcripts for audio and video. It should also guide staff through the accessibility features already built into the tools they regularly use. All core Microsoft 365 applications, including Word, Excel, and PowerPoint, have basic accessibility checkers built in. Teaching staff to use these tools as part of their normal workflow is one of the most effective accessibility investments a government can make.
A Practical Timeline
To illustrate how this plays out, consider a government whose compliance date arrives in April 2026. Here is a reasonable timeline for year one.
- Months 1 through 2: Quickly publish an interim accessibility roadmap and update it once the organization is fully aligned. Inventory all public-facing web applications and mobile apps. Send initial outreach to all vendors requesting their accessibility status and update timelines. Ensure that all services and information are available through traditional channels (e.g., telephone) and that this information is widely known (e.g., in the organization’s accessibility statement).
- Months 3 through 6: Compile vendor responses and incorporate them into the application prioritization. Set up automated testing for the main website and content management system. Conduct the PDF and document triage audit, separating active program-relevant documents from archival material. Establish the new document creation workflow and complete role-specific staff training.
- Months 4 through 12: Begin lightweight accessibility reviews of the highest-priority applications, sequenced around vendor update timelines. Start PDF remediation for the highest-priority active documents. Review and refine the document workflow as the team gains experience. Continue follow-up on applications awaiting updates.
Simply publishing the roadmap and beginning vendor outreach on the compliance date already constitutes meaningful progress toward accessibility. The regulation asked for nothing before that date. A government doing these things on day one may feel like it is vulnerable and scrambling to catch up; in reality, it’s right on schedule.
Conclusion
The ADA Title II web accessibility regulation isn’t easy. No regulation that asks governments to make all of their public-facing web applications and mobile apps ever will be. But it is manageable from day one.
A government that documents its strategy publicly, engages its vendors, builds sensible processes for new content, and trains its staff is doing exactly what the regulation asks. The undue burden, fundamental alteration, and minimal impact defenses exist to protect precisely this kind of thoughtful, resource-constrained effort. The goal was never technical perfection but legal compliance.
People with disabilities have waited decades for the accessibility this regulation offers. They deserve a public sector that takes its responsibility seriously. This guide aims to dispel the fear, uncertainty, and doubt surrounding this seemingly unfamiliar challenge. Compliance is actually straightforward, so let’s get started!
*Converge Accessibility LLC has no business relationship with DocAccess or AIRA.
For a plain-language overview of the ADA Title II web accessibility rule, deadlines, and a practical compliance roadmap, see our companion resource site at adatitleii.us.
Disclaimer: Nothing in this post should be interpreted as legal advice or as forming an attorney-client relationship. It is offered for educational purposes only. You should always contact a qualified attorney in your area to discuss your legal rights and responsibilities.
Want to See More Content Like This?
Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!
We're Here to Help When You're Ready
Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.
0 comments on “Getting Past the FUD: A Day-One Compliance Strategy for the New ADA Title II Web Accessibility RuleFear. Uncertainty. Doubt. Just because digital accessibility is new doesn’t mean that it has to be difficult”