The ADA website deadline changed: understand the 2027–2028 dates

What changed

The Department of Justice's April 2026 interim final rule extended the Title II web and mobile accessibility compliance dates. State and local government entities with a population of 50,000 or more now have an April 26, 2027 date. Smaller entities and special district governments have an April 26, 2028 date. The technical standard remains WCAG 2.1 Level AA. See the DOJ's current fact sheet.

This article retains its earlier URL so readers following existing links reach the correction. Its old April 2026 countdown is withdrawn. The update date above records this editorial revision, not the start of an engagement or an assessment of your organization.

Identify your organization's scope first

The dates concern the Title II web rule for state and local governments. They should not be presented as a deadline applying to every private business website. A private business, public entity, contractor or federally funded program may face different requirements. Have the appropriate adviser identify the applicable framework before using a date to plan procurement.

For the underlying guidance, read the DOJ web-accessibility overview. An extension to a particular rule's compliance date is not a reason to ignore a barrier reported by a person trying to use your services.

Use the planning period to finish the whole journey

A deadline is only useful when it translates into an executable plan. Begin with the services people must access online and trace the steps needed to complete them. Include forms, uploaded documents, authentication, payments and any external service used along the way. A redesigned homepage does not resolve a barrier in the transaction that follows it.

Next, inventory the templates and shared components behind those journeys. Identify who can change each one. Your team may control some parts directly while others require a software vendor, document owner or procurement decision. Put those dependencies into the schedule before assigning a launch date.

Build the work around clear checkpoints

1. Scope: confirm the applicable target and the pages, processes and documents included.
2. Assess: gather reproducible findings using the agreed automated and manual methods.
3. Repair: assign owners and prioritize barriers that block important tasks.
4. Retest: verify the changed behaviour and the surrounding journey.
5. Operate: establish accessible publishing guidance and a feedback route.

What to ask an implementation partner

Ask whether the proposal includes assessment, remediation and retesting, or only one of those stages. Clarify which technologies will be used for manual checks and how the sample is selected. For a large site, the relationship between shared templates and sampled pages should be understandable to the people accepting the work.

Also ask what happens when an issue sits outside the provider's control. A vendor-dependent component still needs an owner and a decision. The project may require a supported alternative, a replacement or a documented escalation. It should not disappear from the report because another organization supplies the software.

Keep evidence tied to the released version

Maintain the original findings, the changes made and the retest results. Record which revision was assessed and whether subsequent content or interface changes affect that evidence. A general promise of compliance cannot substitute for an acceptance record describing what was reviewed.

Turn the date into a project brief

Once your organization has confirmed the applicable requirements, write a brief that a delivery team can act on. “Make the website compliant before the deadline” leaves too many decisions unresolved. Identify the public services involved, the websites and applications that support them, the people who own those systems and the evidence required at handover. Keep the legal determination and the technical delivery scope connected, while assigning each to the appropriate person.

A useful brief also explains the operating constraints. The website may need to stay available throughout the work. Some documents may come from departments with separate publishing processes. A payment or booking system may be supplied through a contract that cannot be changed immediately. These details affect the sequence of work and the time needed for decisions; leaving them out does not make the project smaller.

Questions to resolve at the start

• Which entity owns the service and who has confirmed the applicable requirements?
• Which websites, mobile applications, documents and external platforms support the service?
• Which tasks must a person be able to complete from beginning to end?
• Who can approve content, change the software and authorize vendor work?
• What assessment, remediation, retesting and operating records are included?
• Who receives accessibility feedback during delivery and after launch?

Record an answer or a named owner for each question. An unanswered item can be a real project dependency, particularly when several departments share a platform. The brief should make those dependencies visible enough for a manager to resolve them. It should not turn assumptions into facts just to make a procurement document look complete.

Build an inventory around services, not only URLs

A crawl can help identify pages, but it will not necessarily reveal everything a resident, applicant or customer needs to do. Start with services such as applying for a programme, booking a facility, paying an invoice or requesting information. Trace each service from its entry page through the final confirmation. Include the emails, documents and external systems encountered along the way, with a clear boundary around what the engagement will assess.

For example, a recreation booking journey might use a public information page, a third-party calendar, an account-creation form and a payment screen. Those interfaces may have different owners. A visitor experiences one task, so the delivery plan needs to explain how the owners will work together. Assessing the first page alone would leave the transaction unresolved.

Record enough detail to support a decision

For each item, record its purpose, owner, platform, content type and relationship to a service. Note whether it is actively maintained and whether people need it to complete a current task. Keep links to the editable source of documents where available. This helps the team distinguish a template repair that can be applied widely from a document that needs individual attention.

Do not confuse a long inventory with a finished assessment. The inventory tells you what exists and who can change it. Testing establishes the barriers in the agreed scope. Procurement decides how repairs will be supplied. Keeping those stages distinct makes it easier to estimate effort and explain progress without claiming that a spreadsheet has made the service accessible.

Review third-party dependencies early

Ask vendors for evidence relevant to the actual product version and configuration you use. A general accessibility statement may be useful background, but your implementation may include custom forms, branding, integrations or older components. Request a demonstration of the important journey and a route for reporting defects. Record the vendor's response and the person responsible for following it through.

If a supplier cannot resolve an issue within the project schedule, bring the decision back to the service owner. The options may include configuration changes, an alternative product or another supported path. Have the appropriate adviser assess any legal implications. The issue should remain visible in the project record until there is a documented resolution or decision.

Make document and content decisions deliberately

Do not start by assuming that every old document can be ignored or that every file needs the same treatment. The DOJ describes limited exceptions in the rule, along with conditions and continuing obligations. Use the official fact sheet and linked rule to guide the applicability review. A folder name, publication date or supplier label is not enough on its own to establish an exception.

For project planning, separate the legal decision from the editorial one. Even where an exception may apply, information can still be more useful when it is clearly organized and easy to request. Conversely, a document used for a current application process can have a direct effect on access to a service. Give the reviewer enough context to understand how people use the material.

Use the source file where possible

Find the original editable document before arranging repairs. A clean source with meaningful headings, properly structured tables and sensible reading order is easier to maintain than repeated repairs to an exported file. Assign responsibility for the export settings and the final check. Otherwise, the next routine update can overwrite the repaired version and recreate the same barrier.

Where a web page is a better way to provide current information, consider changing the format as part of the agreed scope. Preserve necessary records and links, and make sure any replacement still communicates the complete service information. Format changes should improve the task; they should not silently remove instructions, eligibility details or a way to submit the required information.

Procure assessment, repairs and retesting as clear pieces of work

A proposal titled “accessibility audit” can mean several things. It may be an automated scan, a manual evaluation, a sample-based assessment, or a package that also includes implementation. Ask for a deliverable example and a list of included methods. Compare providers on the same scope before comparing their fees. A lower quote may simply leave more work for your own team.

For a sampled assessment, ask how the sample represents your templates, content types and important processes. Require the report to identify the sample and its limits. If repairs are included, clarify whether the provider can change your platform directly or needs your developer to implement recommendations. Internal capacity belongs in the schedule even when the assessment itself is outsourced.

A practical acceptance record

The acceptance record can connect each agreed deliverable to the evidence that supports it: the assessed version, findings, repair references, retest results and remaining limitations. Include the technologies used for manual checks and the circumstances needed to reproduce a result. A screenshot of an improved score is insufficient to explain whether someone can complete an application or recover from a form error.

Agree how newly discovered issues will be handled. Retesting can reveal a separate problem, especially when a repaired component exposes the next step of a previously blocked journey. The agreement should explain whether that work is included, requires a scope change or moves into a subsequent phase. This avoids interpreting a commercial boundary as a technical assurance about untested material.

Use access that matches the work

Give the delivery team the permissions required for the agreed systems and establish how access will be removed at handover. Use test accounts and fictional submissions for transaction checks when possible. Keep personal information out of public reports and issue trackers. If production testing is necessary, agree the specific actions and their effects with the system owner before performing them.

These controls support a manageable project regardless of the deadline. They help the organization understand who can change content, who can see test records and how evidence is retained. They also make the handover easier when a contractor changes or an internal employee takes over responsibility for the website.

Sequence the work around dependencies

Build the schedule backward from the organization's required completion point, leaving room for decisions and retesting. Do not reserve all evaluation for the last week. A shared navigation issue discovered at the end can affect many pages, and a vendor replacement may take longer than a content repair. The schedule should expose those risks while there is still time to act on them.

First checkpoint: a usable scope and baseline

The first checkpoint produces the inventory, technical target, sample and ownership map. Confirm that the team has the access and test data needed to proceed. Review the critical journeys with the service owners, and document any system that remains outside the assessment. A clear boundary is more useful than an ambitious scope that nobody has the authority to implement.

Preserve the baseline findings and the version assessed. If the site is changing at the same time, record those releases so the assessment does not chase a moving target without explanation. A small content freeze around particular tests may be helpful, but the organization should agree it in light of its publishing needs.

Second checkpoint: representative repairs

Choose a set of repairs that tests the implementation approach. Include a shared component, a content issue and a complete interaction where relevant. Review the results before applying the pattern widely. This gives designers, developers and editors a concrete reference, and it can reveal problems with the publishing workflow that were not obvious from the initial assessment.

For example, a corrected form label may solve the template issue, while editor instructions prevent new forms from repeating it. A fixed menu may need to be tested alongside the consent banner and mobile header. Record both the successful change and the surrounding checks so later work has a reliable starting point.

Third checkpoint: complete journeys and unresolved decisions

Retest the tasks from arrival through completion, including errors and recovery. Confirm that a successful submission produces the expected receipt and reaches the agreed destination. Where a journey moves into an external system, keep that part in the evidence or clearly state the boundary. Do not describe the whole service as reviewed when the most important transaction was excluded.

Bring unresolved matters to the person authorized to decide them. A backlog should distinguish a repair awaiting implementation from a vendor dependency, an applicability question or a proposed change in scope. Each needs a next action and owner. One generic “open” status can conceal why a task has stopped moving.

Fourth checkpoint: operational handover

Before closing the project, make sure the organization can find and use the records. Provide instructions for ordinary publishing, identify changes that need review and confirm the accessibility-feedback route. Name the owner of ongoing maintenance. If maintenance is a separate service, make its scope and start date explicit rather than assuming that launch includes unlimited future testing.

Review the public accessibility statement against the work actually completed. It should describe the relevant scope and known limitations accurately. Avoid carrying forward wording from a template that describes methods the project did not use. The statement, report and release record should tell a consistent story about the current service.

Report progress without hiding unfinished work

Count work in a way that supports decisions. A team can report which critical journeys have been assessed, which shared components have been repaired and retested, and which dependencies need management attention. Explain the definitions beside the counts. “Pages reviewed” is different from “findings closed,” and neither automatically establishes conformance across the entire service.

Where one repair affects many pages, show the relationship rather than multiplying the achievement into several unrelated claims. Where an issue recurs in independently authored documents, track the instances that still need attention. The reporting model should help the service owner understand the remaining effort instead of producing the largest possible completion percentage.

A concise review agenda

1. Review changes completed since the last meeting and the evidence for their status.
2. Walk through one important journey or representative repair.
3. Resolve decisions that block another team or supplier.
4. Check whether new content or platform changes affect the assessment.
5. Agree the next deliverables, owners and acceptance checks.

Use the meeting to make decisions, then retain a short written record. Long status presentations cannot compensate for an unassigned vendor issue. A visible owner and a specific next action make the schedule easier to manage and help the organization distinguish normal delivery work from a decision that needs escalation.

What private businesses should take from the change

The Title II dates should not be used as a universal countdown in a private business's marketing or procurement plan. Start with the rules and contractual requirements that apply to your own organization. Then identify barriers in the customer journey and define the technical work needed to address them. A restaurant, retailer and public agency may share interface patterns without sharing the same legal timetable.

A private supplier working with a public entity should also clarify the requirements in its contract and the service being provided. Ask the public entity for the applicable technical target and acceptance expectations. Do not assume that supplying a generic widget removes the need to assess how it works in the actual service. Equally, do not describe every commercial website project as subject to the government's compliance dates.

For a business considering a rebuild, use accessibility requirements during content planning, design and component development. That lets the team test representative patterns before they spread across the site. Keep the evaluation focused on the customer tasks and agreed standard; predicted lawsuit costs, ranking gains or settlement savings are not a substitute for a delivery plan.

Questions about the revised deadline

Does the extension change the technical standard?

The extension changes the compliance dates described above; the stated technical target remains WCAG 2.1 Level AA. A procurement team may choose additional requirements, but it should identify those separately. Keep the standard, version and level visible in the brief so a provider does not silently substitute a different checklist.

Can we meet the deadline by installing a tool?

Evaluate what the tool actually does and the evidence for the complete service. A scan can help find issues and a software product may address particular barriers, but neither automatically establishes that every relevant page, document and interaction meets the agreed target. The plan still needs ownership, implementation and retesting.

What if the website is being replaced?

Coordinate current repairs with the replacement project. Identify barriers that can be addressed now, requirements the new platform must support and vendor decisions that affect both. Preserve useful assessment evidence, but retest the replacement. An old site's report does not describe a new site's behaviour merely because the organization and domain stay the same.

What should we send an implementation partner first?

Share the service list, websites and applications involved, confirmed requirements, existing assessment records and the decision timeline. Identify your content and technical owners. You can begin with a public-site review before granting more access. Avoid sending passwords, real applicant records or unnecessary personal information as part of an initial inquiry.

How do we know when to update this plan?

Review it when the applicable guidance, service scope, platform or ownership changes. Keep a dated source reference for the legal timetable and a release reference for technical evidence. A change to one does not automatically change the other. The DOJ's current guidance is the starting point for checking the rule, while your project records explain what was actually delivered.

Our website accessibility guide explains the assessment and repair process in more detail. If you need delivery support, see our accessibility service or share the systems and deadline involved.