ComplianceGovernment Web Accessibility Deadlines Changed in 2026: ADA Title II and HHS Section 504 Timelines
DOJ and HHS each extended major web and mobile accessibility compliance dates by one year in 2026. This briefing separates the current ADA Title II and HHS Section 504 timelines and turns the extensions into practical public-sector planning and procurement actions.
Accuracy-reviewed by the editorial team
Two major U.S. government accessibility timelines changed in 2026. The Department of Justice extended the ADA Title II web and mobile application compliance dates for state and local governments, and the Department of Health and Human Services extended parallel Section 504 dates for recipients of HHS financial assistance. The extensions are operationally important, but they are not a reason to stop accessibility work. Both rule sets continue to point covered organizations toward WCAG 2.1 Level AA, and both agencies continue to describe web and mobile accessibility as part of broader nondiscrimination obligations.
For technology leaders, procurement teams, web owners, and vendors, the practical task is to use the extra year to move from broad intent to an evidence-backed program: identify which rule applies, inventory the digital services in scope, classify exceptions carefully, test high-value user journeys, fix procurement language, and preserve evidence that accessibility is being designed and validated throughout the lifecycle. this analysis is an operational summary, not legal advice; organizations should confirm applicability and interpretations with counsel or their responsible compliance authority.
The 2026 extensions created two different timelines
The Department of Justice issued an interim final rule effective April 20, 2026 extending the ADA Title II web and mobile accessibility compliance dates adopted in 2024. State and local government entities with a total population of 50,000 or more now have until April 26, 2027. Public entities with fewer than 50,000 people, and special district governments, now have until April 26, 2028. DOJ's updated fact sheet and planning guidance reflect those revised dates.
HHS issued a separate interim final rule effective May 7, 2026 for recipients of HHS financial assistance covered by the Department's Section 504 rule. Recipients with 15 or more employees now have until May 11, 2027 to meet the web and mobile accessibility requirements. Recipients with fewer than 15 employees now have until May 10, 2028. HHS described the change as a one-year extension and said the technical standard remains WCAG 2.1 Level AA.
Those dates are easy to blur together because the rules address similar accessibility outcomes. They should not be treated as interchangeable. ADA Title II status depends on the nature and population of the public entity. HHS Section 504 status depends on receipt of HHS financial assistance and the employee threshold used in that rule. Some organizations may be affected by both regimes, while others may fall under only one. The first project-management step is therefore a documented applicability map rather than a generic deadline entered into a calendar.
The extension is schedule relief, not a reset of accessibility obligations
DOJ's Title II resources emphasize that state and local governments already have obligations to provide accessible services, programs, and activities. The 2024 web rule adds specific technical requirements for web content and mobile applications, but the one-year extension does not convert accessibility into an optional future project. DOJ's planning guidance still tells public entities to identify responsible people, learn the rule, determine the compliance date, inventory web content and mobile apps, assess current accessibility, prioritize remediation, examine vendor contracts, and create policies.
HHS makes a similar distinction. Its 2026 announcement says the extension does not impose new obligations and gives recipients additional time to meet the specific technical standard. HHS also reminds recipients of continuing legal obligations to ensure programs and activities are accessible to people with disabilities. That matters for operational planning: a team should not interpret a 2027 or 2028 technical-conformance date as permission to leave a known barrier in a critical service untouched for another year.
A defensible roadmap separates immediate access problems from the full conformance program. High-consequence user journeys such as applying for benefits, accessing health information, submitting public forms, paying fees, requesting records, scheduling services, reviewing notices, or using authentication should receive priority based on user impact and service criticality. Lower-risk legacy content can then be handled through a documented inventory and remediation schedule, including evaluation of any rule-specific exceptions.
WCAG 2.1 Level AA is the common technical center of gravity
Both the DOJ Title II rule and the HHS Section 504 web and mobile provisions use WCAG 2.1 Level AA as the core technical standard. WCAG 2.1 includes testable criteria covering keyboard access, reflow, text spacing, non-text contrast, status messages, form semantics, orientation, input purpose, pointer interactions, and other accessibility needs. A program that treats accessibility as color contrast plus image alt text will miss a large portion of the actual interface and workflow risk.
Public-sector teams should also distinguish the legally referenced standard from newer design targets. WCAG 2.2 is available and may be valuable as an additional engineering target, but a procurement document should not casually substitute one standard for another without explaining the intended requirement. The strongest approach states the controlling legal or contractual baseline, any additional accessibility objective, the product and content scope, and the acceptance method.
This precision matters when buying software. A vendor may provide an Accessibility Conformance Report based on a particular VPAT edition, WCAG version, product release, or configuration. Buyers should compare the report to the rule and the actual deployed system rather than assuming that the word accessible is a complete answer. Zeph Tech's accessibility procurement checklist is designed to help teams request comparable evidence before award.
Inventory the service, not just the public website
DOJ's Title II rule reaches web content and mobile apps a public entity provides or makes available directly or through contractual, licensing, or other arrangements. HHS similarly addresses web content and mobile applications provided or made available by covered recipients. That means an accessibility inventory should include more than the main public website. Teams should look for SaaS portals, embedded payment services, appointment systems, document viewers, online forms, authentication flows, public records tools, kiosks where relevant, mobile applications, and third-party components that are part of the user journey.
The inventory should identify ownership and control. Record the service owner, vendor, contract, product version, authentication method, content owner, critical workflows, known accessibility evidence, current defects, and renewal or replacement date. This converts accessibility from a vague web-team responsibility into a governed technology portfolio. It also exposes procurement use: a system renewing six months before the compliance date deserves a different plan than one entering a five-year term now.
For document-heavy services, classify the document problem separately from application accessibility. PDFs, spreadsheets, presentations, word-processing documents, scanned images, and generated reports can create barriers even when the surrounding portal is accessible. Both DOJ and HHS rules include carefully bounded exceptions for certain content, but exceptions should be evaluated against the actual rule text and service context rather than used as a blanket reason to ignore archives or preexisting documents.
Turn the extra year into contract use
One of the highest-value uses of the extension is procurement cleanup. Every new solicitation, renewal, amendment, or major implementation creates an opportunity to require clearer accessibility evidence. Ask vendors for the current Accessibility Conformance Report for the exact product and version proposed, the test methods used, known defects affecting material workflows, remediation commitments, the accessibility product owner, and the event that triggers a new report or retest.
Acceptance language should define what happens when an accessibility defect is found. Identify which severity levels block release, who validates remediation, how retesting is documented, whether accessibility defects affect service-level or quality obligations, and how major interface changes are reviewed. For configurable systems, divide responsibility among the platform vendor, implementation partner, content authors, and agency. Accessible components can still produce inaccessible configured workflows, and accessible source content can still be rendered poorly by a product.
Public portal procurement deserves special attention because the public experience often combines search, filters, tables, forms, downloads, account functions, and records. Teams evaluating a portal should test representative workflows with keyboard-only navigation and appropriate assistive technology instead of accepting a home-page scan. The public-sector software RFP checklist and software evaluation scorecard can be used alongside accessibility evidence so the requirement affects the actual selection decision.
Build a 2026-to-2028 evidence trail
A good accessibility program should be able to show how it moved from discovery to measurable improvement. Start with a dated inventory and applicability decision. Preserve baseline testing results for critical workflows. Create remediation tickets tied to specific success criteria or user barriers. Record product versions and test environments. Keep vendor ACRs and clarification responses. Capture acceptance decisions and any documented exceptions or limitations. Repeat material tests after major releases rather than treating accessibility as a one-time certification exercise.
For large state and local governments and larger HHS-funded recipients, the revised 2027 dates make 2026 the year to establish the operating model. For smaller entities and special districts with 2028 dates, the longer runway should enable phased remediation instead of deferral. Early inventory also improves budgeting because it reveals whether the largest cost is content remediation, vendor replacement, application development, document conversion, testing capacity, or governance.
Organizations should also monitor the agencies' official rule pages for further changes. A static project plan is risky when regulatory materials can be amended, clarified, or supplemented. The safest practice is to store the authoritative source URL next to each compliance milestone and assign someone to re-verify it before major procurement, release, or audit decisions.
Questions to take into the next accessibility review
- Which entities, programs, websites, mobile apps, and vendor-operated services are in scope for us?
- Are we tracking the correct 2027 or 2028 deadline for each applicable rule?
- Which critical public or patient workflows have been manually tested, not merely scanned?
- Do current contracts require product-specific accessibility evidence and dated remediation commitments?
- Which documents or archived materials are being treated as exceptions, and is that classification defensible?
- What product, interface, or content change triggers retesting?
- Can leadership see a dated evidence trail from baseline findings through remediation and acceptance?
The 2026 extensions create breathing room, but the most valuable outcome is not a later deadline. It is the opportunity to replace reactive remediation with a repeatable accessibility operating model. Teams that use the additional year to improve inventory, procurement, testing, ownership, and evidence will be in a stronger position for compliance and will also deliver digital services that work better for the people who depend on them.
Continue in the Compliance pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Third-Party Compliance Oversight Guide
Operate evidence-based third-party compliance oversight after vendor selection: obligations, monitoring, control evidence, findings, incidents, reassessment, concentration signals…
-
Privacy Enforcement Readiness Guide
Build an evidence-based privacy enforcement readiness program around current EU GDPR priorities, California CCPA regulations, U.S. sensitive-data restrictions, rights operations…
-
Compliance Operations Evidence System
Build a compliance operating model that turns applicable obligations into owned controls, evidence, monitoring, findings, investigations, and decision-ready reporting using current…
Coverage intelligence
- Published
- Coverage pillar
- Compliance
- Source credibility
- 40/100 — low confidence
- Topics
- ADA Title II · Section 504 · WCAG 2.1 AA · Government Web Accessibility · Public Sector Accessibility · Digital Services
- Sources cited
- 6 sources (ada.gov, hhs.gov, 3.org)
- Reading time
- 8 min
Further reading
- Extension of Compliance Dates for Accessibility of Web Information and Services of State and Local Government Entities — U.S. Department of Justice
- Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments — ADA.gov / U.S. Department of Justice
- State and Local Governments: First Steps Toward Complying with the ADA Title II Web and Mobile Application Accessibility Rule — ADA.gov / U.S. Department of Justice
- HHS Office for Civil Rights Extends Web and Mobile Accessibility Compliance Deadline — U.S. Department of Health and Human Services
- Section 504 Final Rule: Section by Section Fact Sheet for Recipients of Financial Assistance from HHS — U.S. Department of Health and Human Services
- Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
Source feedback
Editorial
Found a factual issue, superseded source, broken citation, or important context we should review? Send the specific claim and supporting source through the correction path so it can be evaluated against the article record.