State and local governments now have a specific federal technical standard for accessible websites and mobile apps. The standard is Web Content Accessibility Guidelines 2.1 Level AA, commonly shortened to WCAG 2.1 AA.
The U.S. Department of Justice also revised the compliance timeline in April 2026. Public entities serving 50,000 or more people now have until April 26, 2027. Entities serving fewer than 50,000 people and special district governments have until April 26, 2028.
That extension gives public agencies more time, but it should not be mistaken for permission to wait. A government website may contain thousands of pages, years of documents, multiple third-party systems and content maintained by dozens of departments. Accessibility work at that scale requires an inventory, a design system, clear ownership and a sustainable publishing process.
This guide explains what the rule means and how public-sector teams can turn it into a practical implementation plan.
This article provides general technical information, not legal advice. Public entities should work with their legal counsel to interpret their specific obligations.
What the ADA Title II Web Rule Requires
Title II of the Americans with Disabilities Act applies to state and local government services, programs and activities. The Department of Justice's web and mobile application rule establishes WCAG 2.1 AA as the technical standard for covered web content and mobile apps.
In practice, the rule affects much more than a government homepage. Covered digital services may include:
Department and program pages
Online forms and applications
Public meeting information
Agendas, minutes and staff reports
Utility payment and permit systems
Parks and recreation registration
Emergency information
Maps and interactive tools
Documents and downloadable files
Mobile applications
Content delivered through outside vendors
The Department of Justice provides limited exceptions for certain categories of content. Those exceptions are specific, and they do not eliminate a public entity's broader responsibility to provide effective communication and equal access. The safest operational approach is to treat accessibility as a service requirement, not as a one-time compliance project.
The Department of Justice maintains an updated Title II web rule resource and a detailed guide to first steps for public entities.
The Current Compliance Deadlines
As of August 2026, the federal compliance dates are:
Public entityCompliance datePopulation of 50,000 or moreApril 26, 2027Population below 50,000April 26, 2028Special district governmentApril 26, 2028
The applicable population is not always the number of people who directly use a department's services. A department may be evaluated according to the population of the larger government entity of which it is a part. The Department of Justice provides examples for cities, counties, school districts, universities, libraries and special districts in its implementation guidance.
Why an Automated Accessibility Scan Is Not Enough
Automated testing is useful. It can quickly identify missing alternative text, unlabeled form controls, empty links, color-contrast failures and certain structural problems.
It cannot determine everything.
An automated tool may confirm that an image has alternative text, but it cannot reliably decide whether that text communicates the image's purpose. It may detect a heading element, but it cannot always determine whether the page's heading structure makes sense. It cannot complete a resident's task and judge whether the experience is understandable.
A credible accessibility program combines:
Automated testing across templates and representative pages
Keyboard-only testing
Screen-reader testing
Visual review at different zoom levels
Mobile and touch-target testing
Document review
Testing of forms, errors and status messages
Review by people who understand real resident tasks
WCAG is organized around four principles: content should be perceivable, operable, understandable and robust. The W3C WCAG reference provides the detailed success criteria and implementation techniques.
A Practical Seven-Step Compliance Plan
1. Establish Ownership
Accessibility work often stalls because everyone supports it but no one owns it.
Identify an executive sponsor and a working group that includes the people responsible for:
ADA coordination
Information technology
Communications
Department content
Procurement
Legal review
Human resources and training
Third-party applications
Define who makes decisions, who approves remediation, who monitors progress and who responds when a resident reports a barrier.
2. Build a Complete Digital Inventory
Create an inventory before choosing tools or estimating the work.
The inventory should include:
Public domains and subdomains
Content management systems
Mobile apps
Online forms
Payment portals
Permit and licensing systems
Meeting-management platforms
Recreation systems
Embedded maps and dashboards
PDFs, Word documents and spreadsheets
Videos, livestreams and recorded meetings
Vendor-managed pages
Record the owner, platform, audience, traffic, business importance and known accessibility status of each item. This turns an abstract mandate into a manageable portfolio.
3. Prioritize Essential Resident Tasks
Do not begin with the easiest pages simply because they are easy. Begin with the services residents depend on.
High-priority journeys often include:
Paying a utility bill
Applying for a permit
Finding emergency instructions
Registering for a program
Reading a public-meeting agenda
Reporting a problem
Requesting an accommodation
Applying for a job
Contacting an elected representative
Test each journey from beginning to end. A form is not accessible if the landing page works but the validation errors cannot be understood by a screen reader.
4. Fix the Design System Before Fixing Every Page
When the same navigation, form control, accordion or alert appears across hundreds of pages, repairing the shared component produces a much larger benefit than patching individual instances.
A government design system should define accessible versions of:
Headers and navigation
Buttons and links
Forms and validation messages
Accordions and tabs
Alerts and emergency banners
Tables
Cards and content listings
Modal dialogs
Search interfaces
Pagination
Media players
Build accessibility into the component library, then restrict editors to approved patterns. This reduces future drift and makes conformance easier to maintain across departments.
5. Remediate Content and Documents
Technical templates are only part of the problem. Editors also need to publish accessible content.
Review pages and files for:
Descriptive page titles
Logical heading order
Meaningful link text
Useful alternative text
Captions and transcripts
Clear form instructions
Accessible tables
Sufficient color contrast
Plain, understandable language
Properly tagged documents
PDF remediation can become a major workstream on government websites. Inventory documents by use, age, traffic and legal importance. Avoid converting inaccessible source documents into PDFs and expecting the conversion to solve the problem. Accessibility begins in the source file.
6. Bring Vendors and Procurement Into the Program
A third-party logo does not make an inaccessible resident experience disappear. Public agencies should evaluate the accessibility of systems they purchase and the content vendors publish on their behalf.
Procurement questions should include:
Which WCAG version and conformance level does the product support?
Can the vendor provide a current Accessibility Conformance Report?
Which functions have been tested manually?
Are all workflows usable by keyboard?
How are accessibility defects reported and prioritized?
What remediation commitments will appear in the contract?
Can the agency independently test the product before acceptance?
What happens if an update introduces a new barrier?
Accessibility requirements should appear in the scope, evaluation criteria, acceptance testing and ongoing service agreement.
7. Create an Ongoing Governance Process
Websites change every day. New pages, documents, videos, vendor widgets and software releases can introduce barriers after an audit is complete.
A sustainable program includes:
Required accessibility training for content editors
Pre-publication checklists
Scheduled automated scans
Periodic manual testing
A clear public feedback channel
Documented response and remediation procedures
Accessibility checks in software release workflows
Quarterly reporting to leadership
Annual review of policies, vendors and design components
The goal is not to produce a perfect audit report once. The goal is to keep digital services usable as the organization changes.
Common Government Website Accessibility Problems
Public-sector websites frequently struggle with the same recurring issues:
Unlabeled Forms
Residents may hear “edit blank” instead of “email address” or “permit number.” Every input needs a programmatically associated label, and errors must explain what went wrong and how to correct it.
Keyboard Traps
A person using a keyboard may enter a menu, map or modal and be unable to leave. Every interactive element should be reachable and operable without a mouse, with a visible focus indicator.
Inaccessible PDFs
Scanned documents may contain no readable text. Other PDFs may lack headings, tags, reading order or meaningful link labels. High-use documents deserve both proper remediation and an accessible HTML alternative when appropriate.
Missing Captions and Transcripts
Public meetings, instructional videos and announcements need accurate captions. Important audio-only information should have a transcript.
Low Contrast and Color-Only Instructions
Text and controls must remain understandable for people with low vision or color-vision differences. Instructions such as “required fields are shown in red” need an additional text or icon indicator.
Inaccessible Third-Party Widgets
Chat tools, calendars, payment systems, maps and embedded documents can create barriers even when the main site is well built. Test the entire resident journey, including the handoff to another platform.
Should a Public Agency Target WCAG 2.1 or WCAG 2.2?
The Title II rule names WCAG 2.1 AA as the required technical standard. WCAG 2.2 is a newer W3C Recommendation that adds success criteria addressing areas such as focus visibility, target size, dragging movements and accessible authentication.
For a new design system or redesign, targeting WCAG 2.2 AA is a sensible engineering decision because it includes the WCAG 2.1 requirements while addressing additional barriers. The legal standard and the project's technical target should be documented separately so there is no ambiguity.
What Public-Sector Leaders Should Do Next
If your organization has not started, the next useful step is not buying an overlay or scheduling a single automated scan. It is creating an inventory, identifying high-priority resident tasks and assigning ownership.
If an audit already exists, convert it into a remediation backlog organized by severity, reach and service impact. Repair shared components first, then address content and documents. Add accessibility requirements to every new procurement and software release.
Redkey Web Design builds and modernizes accessible government websites, Drupal platforms and multi-department design systems. Our public-sector work includes the City of Riverside website program, RiversideTV, the Festival of Lights and Join Riverside Fire.
Explore our government and Drupal website services or request a website audit to turn the 2027 or 2028 deadline into a practical implementation plan.