State and local government entities with a total population of 50,000 or more now have until April 26, 2027 to meet the Department of Justice’s Title II web and mobile accessibility requirements. Public entities with fewer than 50,000 people, and special district governments, have until April 26, 2028.
The DOJ rule generally requires covered web content and mobile apps to meet WCAG 2.1 Level AA. For organizations facing the 2027 date, the most useful question now is not simply “What is the deadline?” It is “What should we complete before the deadline arrives?”
This checklist focuses on practical readiness work: inventory, testing, remediation, vendor review, document accessibility, and verification. For the rule background and deadline details, see our ADA Title II web accessibility rule guide.
1. Confirm Which Compliance Date Applies to Your Entity
Start by confirming the population category that applies to your public entity. According to the DOJ’s current guidance, entities with a total population of 50,000 or more have a compliance date of April 26, 2027. Entities with fewer than 50,000 people and special district governments have until April 26, 2028.
Do not assume an entity is a “special district government” simply because its name includes the word district. The rule contains specific definitions and methods for determining total population. If your organization is uncertain about its category, review the DOJ’s official Title II web rule guidance before building the project timeline.
2. Build an Inventory of Websites, Mobile Apps, and Digital Services
A readiness project should begin with scope. List the digital experiences your entity provides or makes available, including systems operated through contractual, licensing, or other arrangements.
- Primary public websites and subdomains
- Department and agency websites
- Public-facing web applications and portals
- iOS and Android mobile apps
- Online forms and application workflows
- Payment, reservation, scheduling, and registration systems
- Maps, calendars, meeting tools, and embedded widgets
- PDFs, spreadsheets, presentations, and other electronic documents
- Third-party platforms used to deliver government services
Do not limit the inventory to pages your internal web team built. DOJ guidance explains that content and apps made available through certain vendor or contractor arrangements can remain within the rule’s scope.
3. Prioritize High-Impact Public Services First
Not every digital asset has the same impact on public access. Prioritize services that people rely on to interact with government programs and complete important tasks.
Examples include paying bills, applying for permits or licenses, registering for programs, submitting forms, accessing benefits, reviewing public meeting information, making appointments, and using public transportation or parking services.
This prioritization does not replace the technical requirements. It helps teams allocate testing and remediation resources so that barriers in essential workflows are identified early rather than discovered near the deadline.
4. Evaluate Against WCAG 2.1 Level AA
The Title II rule uses WCAG 2.1 Level AA as its technical standard for covered web content and mobile apps. A useful readiness assessment should therefore evaluate the applicable WCAG 2.1 Level A and AA success criteria across representative pages, templates, components, and workflows.
Common areas that require review include:
- Keyboard navigation and visible focus
- Accessible names for controls and form fields
- Heading and page structure
- Image alternatives
- Color contrast and use of color
- Error identification and form instructions
- Dialogs, menus, tabs, and other interactive components
- Captions and other media accessibility requirements
- Zoom, reflow, and responsive behavior
- Status messages and dynamic content
For more detail on the standard, see our guide to WCAG 2.1 AA.
5. Combine Automated Scanning With Manual Accessibility Testing
Automated accessibility tools are useful for finding certain patterns across large websites, but they cannot determine whether every WCAG success criterion is satisfied or whether a person using assistive technology can complete a real workflow.
A stronger readiness process combines automated checks with manual evaluation. That can include keyboard testing, focus review, form interaction testing, and screen-reader testing where appropriate.
Our guide to automated vs. manual accessibility testing explains why a scanner alone should not be treated as a complete accessibility audit.
6. Review Third-Party Vendors and Embedded Services
Vendor technology deserves its own workstream. DOJ guidance states that a public entity cannot simply contract away its ADA responsibilities. For example, a payment system, reservation platform, or mobile app provided through a contractual or licensing arrangement may still need to meet the rule’s technical standard.
Create a vendor inventory and ask practical questions:
- Which vendor products are used to provide public services?
- What accessibility documentation can the vendor provide?
- Has the actual deployed product been tested, not just the vendor’s marketing site?
- Who is responsible for fixing accessibility findings?
- Does the contract address accessibility requirements and remediation timelines?
- Can the entity test updates before or after deployment?
Be careful with the rule’s third-party content exception. DOJ guidance distinguishes truly unaffiliated third-party posts from content, tools, and services a public entity provides through a contractor or other arrangement.
7. Audit PDFs and Other Electronic Documents
Government websites often contain years of PDFs, Word files, presentations, spreadsheets, agendas, forms, reports, and public notices. The rule includes limited exceptions for certain preexisting conventional electronic documents and archived content, but those exceptions are specific.
For example, DOJ guidance explains that a preexisting document may not qualify for the exception when it is still being used to apply for, access, or participate in a government service, program, or activity.
Instead of assuming all older PDFs are exempt, classify documents by purpose and current use. Prioritize active forms, current instructions, notices, meeting materials, applications, and documents people need to access government services.
8. Include Mobile Apps in the Testing Plan
The rule covers mobile apps as well as web content. If your entity provides an iOS or Android app for public services, include it in the accessibility program rather than treating the website as the entire project.
Testing should address platform-specific accessibility behavior, including accessible names, focus order, touch interaction, screen-reader output, text resizing, orientation, and error handling. Our mobile app accessibility testing guide provides additional technical context.
9. Create a Remediation Backlog With Clear Ownership
An audit is useful only if findings move into remediation. Convert confirmed accessibility findings into a backlog that developers, content teams, designers, document owners, and vendors can act on.
Each finding should be specific enough to reproduce and should identify the affected component or workflow, relevant accessibility requirement, expected behavior, and verification method. Assign owners and target dates rather than leaving findings in a report until the end of the project.
For large sites, fixing shared templates and reusable components can remove the same barrier from many pages at once.
10. Retest Fixes and Representative User Flows
Do not treat a developer ticket marked “done” as verification that an accessibility barrier has been resolved. Retest corrected components and the workflows in which they appear.
Regression testing is especially important when design systems, content management systems, third-party scripts, or SaaS platforms change frequently. A fix can be technically correct in one release and later be affected by another update.
11. Put Accessibility Into Procurement and Content Governance
Title II readiness is not only a one-time cleanup project. The DOJ guidance says that after the applicable compliance date, state and local governments must continue to make sure covered web content and mobile apps meet WCAG 2.1 Level AA.
That makes ongoing governance important. Consider incorporating accessibility into:
- Website and application procurement requirements
- Vendor evaluation and contract language
- Design-system acceptance criteria
- Developer QA processes
- Content publishing workflows
- Document creation templates
- Release testing and regression testing
- Staff training and responsibility assignments
12. Run a Final Readiness Review Before April 26, 2027
Before the deadline, review whether the inventory is complete, priority services have been tested, confirmed barriers have owners, vendor products have been evaluated, relevant documents have been addressed, and fixes have been retested.
A readiness review should also identify unresolved issues clearly. The purpose is not to generate a reassuring score. It is to give the organization an accurate technical picture of what has been tested, what has been fixed, and what still requires work.
Start With an Accessibility Audit
For public entities preparing for the 2027 Title II date, an accessibility audit can establish a practical baseline for remediation planning. ADA Access Group combines automated testing with manual accessibility evaluation to identify confirmed barriers and provide actionable remediation guidance.
Request an Accessibility Audit to review your website, web application, or digital service and build a prioritized remediation plan before the 2027 deadline.
This article provides general technical accessibility information and is not legal advice. Public entities should review the DOJ rule and official guidance when determining how specific requirements, exceptions, and compliance dates apply to their organization.