Avoid DOJ Risk: Prioritized ADA Website Fixes for U.S. Businesses

by | Sep 29, 2026 | Blog | 0 comments

If your business is open to the public, your website almost certainly falls under Title III of the Americans with Disabilities Act, and the practical target to work toward is WCAG 2.1 Level AA. State and local government sites face a separate, codified rule with firm deadlines. Either way, the next step is the same: test your site, fix what blocks access, and document the process.

TL;DR:

  • Most small and midsize businesses fall under Title III of the ADA, making WCAG 2.1 Level AA the practical accessibility standard to target.
  • Compliance deadlines for government sites are set for April 26, 2027, for larger entities and April 26, 2028, for smaller ones, extending the timeline for some.
  • Automated testing alone is insufficient; manual and user testing with assistive technology are essential for verifying actual accessibility.
  • Prioritizing fixes should focus on critical transaction flows like checkout, forms, and booking pages, with ongoing monitoring and retesting.
  • Documenting all remediation efforts, staff training, and feedback channels is crucial for demonstrating good-faith compliance efforts.
Ibrand
Build A More Accessible Website
Ibrand provides mobile-friendly web design and digital marketing services for small businesses building a stronger online presence.
Explore Ibrand

Table of Contents

What the ADA requires: Title II versus Title III and how to tell which applies

The Americans with Disabilities Act splits obligations by who runs the website. Title II covers state and local government entities: city halls, public school districts, transit authorities, public university portals. Title III covers private businesses that operate as “public accommodations,” which includes most retail sites, restaurants, medical practices, law firms, and service businesses with a website customers use to browse, book, or buy.

The practical difference matters more than the legal label. Title II now has a specific technical rule requiring WCAG 2.1 AA for government web content and mobile apps, with fixed compliance dates. Title III has no single codified technical standard. Instead, the Department of Justice frames the obligation around effective communication and equal access: a business can choose its own methods, but it still has to deliver an equivalent experience to visitors using screen readers, keyboard navigation, or other assistive technology. WCAG functions as the field’s practical yardstick even though DOJ has not declared it the only lawful path for private businesses.

A short checklist helps determine which framework applies to a given site:

  • Ownership test: Is the entity operating the site a government body, or a government contractor building something on its behalf? If yes, Title II and the new technical rule likely apply.
  • Public accommodation test: Does the business fall into a category the ADA lists as a public accommodation, such as retail, hospitality, health care, or professional services offered to the public?
  • Digital-storefront test: Does the site let visitors book appointments, buy products, fill out forms, or otherwise complete a transaction that would normally happen in a physical location?
  • Contractor test: If you build or manage websites for government clients, your contracted work is covered by their Title II obligations even though you are a private vendor.

Most small and midsize businesses land squarely in the Title III category, which means the WCAG-based approach described in the sections below is the sensible starting point regardless of what a specific court eventually rules in any single case.

Recent DOJ rule changes and what they mean for vendors and contractors

In 2024, the Department of Justice finalized a rule under Title II that adopts WCAG 2.1 Level AA as the binding technical standard for state and local government web content and mobile applications. This was the first time DOJ tied a specific, testable technical benchmark to ADA digital obligations, rather than leaving the standard open to interpretation case by case.

Shortly after, DOJ issued an Interim Final Rule extending the original compliance dates. The current schedule gives public entities more runway:

  • Entities serving a population of 50,000 or more must comply by April 26, 2027.
  • Smaller entities and special districts have until April 26, 2028.

These dates and the rationale behind the extension are documented in the Federal Register’s interim final rule notice.

The part that catches many vendors off guard: a government entity’s compliance obligation does not stop at content it builds in-house. If a city government hires a marketing agency to build its recreation department site, or a school district uses a third-party platform for enrollment forms, the government entity remains responsible for that content meeting the standard. Contractors and vendors serving public-sector clients should expect accessibility requirements to show up in contract language, procurement questionnaires, and acceptance testing well before the 2027 and 2028 deadlines arrive. Waiting until the deadline year to start remediation on a government-facing project is a real business risk for any agency or developer in that pipeline.

WCAG 2.1 AA in practice: what a web manager actually checks

Title III businesses do not have a single codified rule the way Title II now does, but DOJ has repeatedly pointed to WCAG as helpful technical guidance for what “effective communication” looks like online. Treating WCAG 2.1 AA as your working standard, even without a court mandate requiring it, is the most defensible position available right now.

In practical terms, a site working toward this standard needs the following, translated from the DOJ’s own list of checks:

  1. Alt text on meaningful images so screen reader users get the same information a sighted visitor gets from a photo, icon, or chart.
  2. Semantic heading structure, meaning H1 through H6 tags used in logical order rather than styled text pretending to be a heading.
  3. Sufficient color contrast between text and its background, so low-vision users can read body copy and buttons without strain.
  4. Full keyboard operability, letting a visitor tab through every link, menu, and form field without needing a mouse.
  5. Usable zoom and text resizing that does not break layout or hide content when a visitor magnifies the page.
  6. Labeled form fields and clear error messages, so a screen reader announces what each field expects and what went wrong if a submission fails.
  7. Captions or transcripts for video and audio content, covering everything from product demos to recorded webinars.
  8. Accessible PDF and document formats, since a scanned image posing as a PDF is invisible to assistive technology even if the site around it is perfect.

The most common mistake among businesses trying to move fast is leaning entirely on automated overlays or a single scanning tool and calling the job done. DOJ guidance is explicit that automated testing is supplemental, not a substitute for manual and user testing. An overlay widget can adjust contrast or add keyboard shortcuts, but it cannot restructure broken markup or fix a form that was never coded with proper labels in the first place. A clean automated report is not proof of accessibility, and treating it as a legal shield has repeatedly failed to hold up.

Pro Tip: Run an automated scan first to catch the obvious issues fast, then have a real person navigate your checkout or booking flow using only a keyboard and a screen reader like NVDA or VoiceOver before you consider anything “fixed.”

A prioritized remediation checklist and inventory process

Fixing everything at once is not realistic for most small businesses, and it is not what DOJ’s own process guidance expects. The Title II accessibility checklist, while written with government sites in mind, lays out an operational sequence that works just as well for a private business: inventory, scan, manually test, remediate, retest, monitor.

Step 1: Build the inventory. Start by listing every page and flow that matters to revenue or access, not every page on the site. Priorities usually include:

  • The homepage and main navigation, since it is the entry point for every visitor.
  • Contact and lead forms, since a broken form blocks the primary reason many visitors arrive.
  • Booking, checkout, or appointment-scheduling flows, since these are direct revenue paths.
  • Account login and account management pages, since locked-out users cannot self-serve.
  • Location or hours pages, especially for multi-location businesses.
  • Downloadable PDFs and documents tied to services, pricing, or legal disclosures.

Step 2: Run automated scans, then read past the summary score. Automated tools are useful for surfacing missing alt attributes, contrast failures, and empty links quickly across hundreds of pages. Treat the resulting report as a starting map, not a finished audit; a page can pass every automated check and still be unusable with a keyboard.

Step 3: Manually test the priority flows. This is where most of the real barriers surface, particularly in checkout forms, date pickers, and modal pop-ups.

Web manager testing checkout keyboard navigation

Step 4: Triage and assign. Not every issue belongs to the same team. Some fixes live in code (missing ARIA attributes, broken tab order), some live in content (missing alt text, unclear link text), and some live with a third-party vendor (an embedded booking widget or chat tool that was never built accessibly). Assign each finding to the right owner and set a realistic fix window.

Accessibility findings routed to responsible owners

Step 5: Stage releases and retest. Push fixes to a staging environment first, retest the specific flow that was broken, and only then release to production. This avoids a common failure mode where a fix for one issue quietly introduces a new one, such as a contrast fix that also breaks a hover state used for keyboard focus.

Step 6: Monitor going forward. New content, new landing pages, and marketing campaigns can reintroduce the same problems. Build a lightweight recurring scan into your content publishing process rather than treating remediation as a one-time project.

A simple prioritization rubric keeps the work from stalling:

  • Critical, fix immediately: issues that stop a transaction entirely, such as a checkout button that cannot be reached by keyboard or a required form field with no accessible label.
  • High, fix within the next release cycle: issues that make a task difficult but not impossible, such as low contrast on secondary buttons or a confusing heading structure.
  • Moderate, schedule normally: cosmetic or minor UX issues that do not block a task, such as a missing alt tag on a decorative background image.

Pro Tip: Fix the booking or checkout flow first, even if it means leaving a lower-traffic landing page imperfect for another month. DOJ enforcement and complaints both tend to focus on whether a visitor could actually complete a transaction, not whether every page hit a perfect score.

Accessible conversion paths also tend to convert better for everyone, a point covered in more detail in how UX changes drive more sales and in strategies for increasing website conversions.

Testing strategy: tools, manual methods, and realistic timelines

A testing plan that only runs once a year will not catch problems introduced by a new landing page campaign or a redesigned contact form. Build testing into your release cadence rather than treating it as an annual event.

Automated tools are genuinely good at catching a specific category of problem: missing alt attributes, empty link text, contrast ratio failures, and malformed HTML. What they consistently miss is anything requiring judgment, such as whether alt text actually describes the image usefully, or whether a screen reader announces a form error in a way a real user would understand.

Every release, regardless of size, should include these manual checks on anything that changed:

  • Keyboard-only navigation through every new or modified interactive element, checking that focus order makes sense.
  • Visible focus indicators, so a keyboard user can see where they are on the page at all times.
  • Zoom behavior at 200% and 400%, confirming content does not overlap or disappear.
  • Form labels and error messaging, confirmed with a screen reader, not just visually.
  • Captions on any new video or audio content.
  • Text availability in any new PDF, confirmed by selecting and copying text rather than assuming a document is accessible because it looks like one.

Beyond routine release testing, periodic testing with real assistive-technology users adds a layer automated tools and even experienced testers using screen readers themselves cannot fully replicate. A reasonable cadence is testing with actual assistive-technology users around major redesigns or launches, and at least monthly for sites with frequent content changes, such as e-commerce catalogs or active blogs.

DOJ guidance is explicit that automated testing alone is not sufficient evidence of compliance: the department’s own guidance calls for combining automated scans with manual keyboard, screen-reader, and mobile testing, which means a business relying solely on a scanning tool’s clean report is not meeting the standard DOJ itself describes.

For remediation timelines, DOJ settlement agreements offer a useful benchmark even for businesses that have never faced a complaint. Consent decrees such as the Meijer settlement commonly set short fix windows for critical, transaction-blocking issues and longer windows for lower-severity findings, paired with recurring testing and reporting obligations. Adopting similar internal SLAs, fast turnarounds for anything blocking a purchase or signup, and reasonable turnarounds for everything else, keeps a business ahead of the kind of finding that turns into a demand letter.

Documentation, accessibility statements, and vendor oversight

Good technical fixes matter, but the paper trail around them is what demonstrates good-faith effort if a complaint ever arrives. An operational accessibility statement should include a direct contact method for accessibility issues, a stated response time, and a clear description of what the statement covers, such as the main website versus a separate ordering platform.

Training and vendor oversight round out the picture:

  • Staff training for anyone who publishes content, covering how to write alt text, structure headings, and avoid color-only cues, refreshed at least annually.
  • Contractor and developer training for anyone touching site code, focused on semantic HTML, ARIA usage, and form labeling.
  • Vendor contract language that assigns explicit responsibility for accessibility in any third-party widget, booking tool, or embedded chat system.
  • Feedback channel monitoring, since a stated contact method is only useful if someone actually reviews and acts on what comes in.
  • Recordkeeping of scan results, manual test notes, and remediation dates, since this is exactly what a lawyer or DOJ investigator will ask for first.

Pro Tip: Keep a simple remediation log, even a shared spreadsheet, that timestamps when an issue was found, who fixed it, and when it was retested. That single document does more to demonstrate a good-faith process than any amount of after-the-fact explanation.

Enforcement examples and lessons from DOJ settlements

DOJ’s public settlement agreements with retailers including Meijer, Rite Aid, Kroger, and CVS reveal a consistent pattern of failure points rather than a series of unrelated complaints. The issues that show up again and again are unlabeled form controls that leave screen reader users guessing what a field wants, missing keyboard access on interactive elements like date pickers and dropdown menus, low color contrast on buttons and pricing text, and booking or registration flows that break entirely for assistive-technology users partway through.

The remedies DOJ negotiated in these cases also follow a repeatable structure:

  • WCAG 2.1 AA remediation scoped to the specific content and flows named in the complaint, not necessarily the entire site.
  • Combined automated and manual testing schedules, run on a recurring basis rather than once.
  • User testing involving people who actually use assistive technology, not just internal staff running a scanner.
  • Staff training requirements tied to the remediation timeline.
  • Accessibility statements and feedback mechanisms made publicly available and monitored.

The recurring lesson across these settlements is not that any single flaw triggered enforcement. It was the combination of blocked transactions, no clear way for a visitor to report the problem, and no evidence of an ongoing testing process.

The practical takeaway for a business that has never faced a complaint: the fastest way to reduce your own exposure is to fix the same categories these settlements addressed, form labels, keyboard access, contrast, and booking flows, before a visitor or advocacy group flags them first. None of the required remedies in these settlements were exotic. They were the same checklist items covered earlier in this guide, applied late instead of early.

A few signals mean it is time to involve counsel rather than continuing to self-remediate on your own timeline: a formal demand letter, a public complaint or social media post naming your business, or confirmation that a core transaction, like checkout or appointment booking, is genuinely unreachable for assistive-technology users.

Before that call, gather what a lawyer will ask for immediately:

  • Your most recent automated scan results and any manual testing notes.
  • A written remediation plan with dates, even an informal one.
  • Records of any staff or contractor training related to accessibility.
  • Your current accessibility statement and any feedback submitted through it.
  • A timeline of when issues were identified and when fixes shipped.

If the issue is narrow, such as one broken form, immediate mitigation (fixing that one flow within days) is usually more useful than waiting for a full site audit to finish. If the complaint touches multiple flows or documents a pattern, a fuller remediation plan with documented timelines becomes the more defensible path, and that is a conversation worth having with counsel before committing to specific dates.

How an agency actually runs an accessibility project

A typical engagement starts with an audit covering the priority pages and conversion flows outlined earlier, usually taking one to two weeks depending on site size. That produces a prioritized list, critical issues first, moderate issues scheduled into the next few releases. A developer or accessibility specialist handles code-level fixes, a content editor handles alt text and copy issues, and any third-party widget problems get flagged to that vendor directly rather than patched around.

Retesting happens on the same flows that were originally broken, not just a fresh automated scan, because that is the only way to confirm the actual barrier is gone. After the initial round, ongoing monitoring gets folded into whatever the business already has in place for content updates, so new landing pages or seasonal campaigns get checked before launch instead of after a complaint.

Ownership matters more than most businesses expect going in. Someone internally, whether that is a web manager, marketing lead, or owner, needs to be the person who says yes or no before a new page goes live. Without that gate, accessibility work drifts back to where it started within a few content cycles. An agency coordinating this kind of project, including work we have done on sector-specific sites like dental practice websites, typically hands off both the fixes and a simple process the internal team can keep running afterward.

— TONY

How ibrand.media supports accessible website projects

Fixing ADA compliance issues on your own timeline, between other business priorities, is where most remediation efforts stall out. ibrand.media offers accessibility audits alongside our core Web Design and Website Development services, which means the fixes an audit surfaces get built into the same team doing the work rather than handed off to a separate contractor.

Ibrand

A typical engagement starts with an audit of your priority pages and conversion flows, the same inventory approach covered earlier in this guide. From there we prioritize fixes, apply them directly in code and content, retest the flows that were broken, and set up ongoing monitoring so new pages do not quietly reintroduce old problems. For businesses that would rather have a specialist handle the technical build-out directly, our UX/UI design partners at Odesa are also available for hands-on development work.

Our approach includes clear communication about pricing and progress, so you understand what was fixed and the impact, not just receive an invoice. If your site handles bookings, online orders, or lead forms and you have not run a real accessibility test in the past year, that is the place to start. Ibrand to talk through an audit and a practical remediation plan for your site.

Sources

For anything beyond this overview, work from the primary sources directly rather than secondhand summaries. Start with DOJ’s web accessibility guidance, the Title II interim final rule, the U.S. Access Board’s ADA standards, and the Federal Register’s rulemaking notices. Save copies of any settlement agreements or rule text you plan to reference. If you end up speaking with a lawyer, having the original documents on hand saves time counsel would otherwise spend tracking them down.

FAQ

Does the ADA legally require my business website to be accessible?

The ADA does not name websites explicitly, but DOJ has consistently applied Title III’s nondiscrimination requirements to the websites of businesses open to the public. Most practitioners treat WCAG 2.1 Level AA as the safest practical target even though no single Title III rule mandates it by name.

What is the deadline for state and local government websites to comply?

Under the Interim Final Rule, government entities serving a population of 50,000 or more must meet WCAG 2.1 AA by April 26, 2027, while smaller entities and special districts have until April 26, 2028. These dates apply to Title II public entities, not private businesses under Title III.

Is an accessibility overlay enough to make my site ADA compliant?

An overlay or plugin can help with some surface-level adjustments, but DOJ guidance treats automated tools as supplemental to manual and user testing, not a replacement for them. A clean automated scan does not confirm that a screen reader user can actually complete a checkout or booking flow.

What are the biggest risks if my website is not accessible?

The most direct risks are demand letters, complaints, and DOJ enforcement actions, which have resulted in consent decrees against retailers requiring scoped WCAG 2.1 AA remediation, recurring testing, staff training, and public accessibility statements. Beyond legal exposure, an inaccessible checkout or contact form also turns away visitors who cannot complete the task at all.

How do I choose a qualified accessibility consultant or vendor?

Look for a vendor who tests with real assistive technology and a keyboard, not just an automated scanner, and who can show a documented remediation process with prioritized fixes and retesting. Ask how they handle third-party widgets and embedded content, since those are common gaps that a surface-level audit misses.