10 ADA Website Compliance Fixes to Prioritize After the DOJ Rule

Yes, most business websites fall under ADA obligations, and government sites face an explicit federal rule. WCAG 2.1 Level AA is the technical benchmark regulators and courts point to. Accessibility is not a one-time project. Your first move: run an audit that pairs automated scanning with manual testing, then fix the highest-traffic pages first.

TL;DR:

• Achieving WCAG 2.1 Level AA compliance is critical for government sites and strongly recommended for most businesses to avoid legal risks.
• Prioritize fixing alt text, keyboard navigation, visible focus states, color contrast, and form labeling, especially on high-traffic and transaction pages.
• Conduct both automated scans and manual testing with assistive technology users, and document results with specific page and test details for defensibility.
• Build accessibility into your design, development, vendor contracts, and ongoing content practices to ensure continuous compliance and user experience.
• Address accessibility complaints promptly by verifying specific issues, fixing identified barriers, and maintaining detailed records to mitigate legal exposure.

Table of Contents

• ADA Website Compliance: How Title II and Title III Apply
• WCAG Explained: The Technical Standard Behind ADA Website Compliance
• Your ADA Compliance Checklist: Fixes That Actually Move the Needle
• Compliance Deadlines: What DOJ Rule Dates Mean for Your Business
• Testing for ADA Website Compliance: Why Automated Tools Aren’t Enough
• Building Accessible-By-Design Development Practices
• What to Do If You Get an Accessibility Complaint
• Accessibility as a Growth Lever, Not Just a Legal Shield
• Get a Website Accessibility Audit From Forefront Industries
• Authoritative Resources to Bookmark
• Sources

ADA Website Compliance: How Title II and Title III Apply

The Americans with Disabilities Act was written before the web existed, but the Department of Justice has spent three decades applying it to digital storefronts anyway. Two titles govern that application, and they work differently.

Title II covers state and local government entities, and it is no longer ambiguous. The DOJ’s final rule now requires most public entities to meet WCAG 2.1 Level AA on their websites and mobile apps, with specific compliance dates attached. If you run a city portal, a public school district site, or a transit authority’s booking tool, the rule applies to you directly, not by inference.

Title III covers businesses open to the public, meaning most commercial websites: retailers, service providers, healthcare practices, restaurants, law firms. There is no equivalent federal regulation spelling out a technical standard for Title III the way the DOJ did for Title II. Instead, DOJ guidance treats web accessibility as a matter of nondiscrimination, and courts have filled the gap through case law and settlements that consistently point back to WCAG as the practical yardstick.

“Nondiscrimination” and “effective communication” sound abstract until you map them to actual site features:

• A screen reader user can’t parse an image with no alt text, which is a communication failure, not just a technical gap.
• A form field with no visible label locks out anyone navigating by keyboard or voice command.
• Low-contrast text effectively excludes users with low vision from information sighted users get automatically.

Enforcement runs two tracks. The DOJ can investigate and bring actions directly, particularly for Title II entities now bound by explicit deadlines. For Title III, enforcement is largely private: individuals file suits, often through demand letters first, and remedies typically include a remediation timeline, attorney’s fees, and sometimes monitoring requirements. Neither track requires proof of intent to discriminate. Inaccessibility itself is the violation.

WCAG Explained: The Technical Standard Behind ADA Website Compliance

WCAG, the Web Content Accessibility Guidelines, is built on four principles: content must be perceivable, operable, understandable, and robust. Under those principles sit specific, testable success criteria, and each criterion is rated at one of three conformance levels, A, AA, or AAA, with AAA being the strictest.

WCAG 2.1 added criteria for mobile accessibility and low vision. WCAG 2.2 builds on that with a handful of new success criteria around focus visibility and authentication, and adopting it now protects you against near-term standard drift instead of retrofitting again in two years.

The number that matters most right now: the DOJ’s final rule requires WCAG 2.1 Level AA for covered state and local government entities. There is no equivalent federal mandate specifying a level for Title III businesses, but every major settlement and DOJ guidance document treats AA as the working standard. Treating anything less as sufficient is a bet against how every enforcement action has gone so far.

A conformance claim is not a marketing line, it’s a documented position. A real claim needs:

• The specific WCAG version and level being claimed (2.1 AA, 2.2 AA)
• The date the evaluation was performed
• The pages or page types the claim covers
• The testing methods used to reach that conclusion

Skipping documentation is the single most common mistake businesses make. If a complaint ever escalates, “we believe our site is accessible” carries no weight. A dated audit report with specific findings and remediation dates does.

Your ADA Compliance Checklist: Fixes That Actually Move the Needle

Not every accessibility fix carries equal weight. Some close real legal exposure and unlock major chunks of your audience; others are marginal polish. Here’s the order that matters, based on where lawsuits and DOJ complaints most often originate.

1. Add meaningful alt text to every functional image. Decorative images get empty alt attributes; product photos, icons, and infographics need descriptions that convey their actual purpose. The DOJ specifically calls out missing alt text as one of the most common barriers it encounters.
2. Fix keyboard navigation across every interactive element. Tab through your entire site with your mouse unplugged. If you hit a menu, modal, or form field you can’t reach or escape, that’s a hard blocker for keyboard-only users and many screen reader users.
3. Add visible focus states. A keyboard user needs to see exactly where they are on the page. Browsers provide a default focus outline; too many developers strip it out for aesthetics and never replace it with something equally visible.
4. Correct color contrast ratios. Body text needs a 4.5:1 contrast ratio against its background under WCAG AA; large text needs 3:1. Pair that with non-color status cues, since a red border alone doesn’t tell a colorblind user a form field failed validation.
5. Label every form field explicitly, and write error messages that state what went wrong and how to fix it, not just “invalid input.”
6. Use real semantic headings (H1 through H6 in logical order) instead of styled text that looks like a heading but isn’t coded as one. Screen readers rely on heading structure to let users jump around a page.
7. Add skip links so keyboard users can bypass repetitive navigation and reach main content directly.
8. Keep link text descriptive. A page full of “click here” links tells a screen reader user nothing when they pull up a list of links out of context.
9. Caption and transcribe all video and audio content, and make sure captions are synced and accurate, not auto-generated and unedited.
10. Tag PDFs properly or provide an HTML equivalent. An untagged PDF is often invisible to assistive technology no matter how clean it looks visually.

Prioritize by user journey, not by page count. Checkout flows, account login, appointment booking, and contact forms carry the highest risk because they’re where a blocked user actually can’t complete a transaction. Cross-reference that list against your analytics for high-traffic pages and any accessibility complaints you’ve already received, then build a remediation roadmap that tackles those pages first and lower-traffic content later.

Pro Tip: Run your top 10 pages by traffic through a contrast checker and a keyboard-only walkthrough before you touch anything else. That combination alone catches a disproportionate share of the issues that actually trigger complaints.

Compliance Deadlines: What DOJ Rule Dates Mean for Your Business

The DOJ’s rule for public entities carries real, calendar-bound deadlines. It took effect on June 24, 2024, with staggered compliance dates running into 2026 and 2027 depending on the size of the population the entity serves. Larger jurisdictions face earlier deadlines; smaller ones get more runway.

If you manage a website for a city, county, public university, or other government entity, don’t wait for a specific date to feel close before starting. The DOJ’s own first-steps guidance recommends starting now with these three moves:

• Inventory all web content and mobile app functionality to know what you’re working with.
• Determine which content is actually covered by the rule versus what falls under a limited exception.
• Train staff and review vendor contracts so future content additions don’t reintroduce the same barriers you just fixed.

Title III businesses face a different picture. There’s no single federal regulation naming a deadline the way the Title II rule does. That absence gets misread as low risk, but settlement patterns and DOJ guidance both lean on WCAG AA as the expected standard, and private lawsuits don’t wait for a formal rule to file. Treat the lack of a fixed date as a reason to move proactively, not a reason to deprioritize the work. A practical plan: inventory your site, run a gap analysis against WCAG 2.1 AA, and build a remediation timeline anchored to your business-critical pages first.

Testing for ADA Website Compliance: Why Automated Tools Aren’t Enough

Automated scanners are useful and completely insufficient on their own. The DOJ makes the comparison directly: an automated accessibility checker functions like a spelling checker, catching obvious, pattern-based errors while missing anything that requires judgment about context or actual usability.

A scanner can flag a missing alt attribute. It cannot tell you whether the alt text you wrote actually describes the image usefully, or whether a custom dropdown widget traps keyboard focus once a user opens it. Complex interactive components, dynamic ARIA states, and multi-step authentication flows routinely pass automated scans while remaining unusable for real assistive technology users.

A defensible testing process layers three things:

• Automated scanning for a fast first pass across the entire site, catching the high-volume, low-judgment errors.
• Manual expert review covering keyboard-only navigation, screen reader walkthroughs of key pages, and close attention to login, checkout, and any multi-step form.
• Real user testing with people who actually use assistive technology daily, since a sighted developer simulating a screen reader misses things a daily screen reader user catches instantly.

Document every test: the steps taken, the assistive technology used, the pages covered, and the specific results. That documentation becomes your reproducible regression script for the next audit, and it’s the evidence that separates “we tested this” from “we assume this works.”

Pro Tip: Keep a written test script for your five highest-risk flows (login, checkout, contact form, search, account settings) and rerun it after every major site update. Ad hoc testing catches today’s bugs; a script catches the ones a redesign quietly reintroduces.

Building Accessible-By-Design Development Practices

Retrofitting accessibility onto a finished site is slower and more expensive than building it in from the start. Practitioners increasingly treat “accessible-by-design” as the standard workflow rather than an add-on, folding accessibility checks into wireframes, component libraries, and code review the same way security and performance already get checked.

That shift touches three parts of an organization:

• Design and development process. Accessibility criteria belong in your design system and component library from the first sketch, not bolted onto a finished template. A custom-coded build gives you the flexibility to bake in semantic structure and keyboard behavior at the component level instead of fighting a rigid theme later.
• Vendor contracts and statements of work. Any agency or freelancer building or maintaining your site should have WCAG 2.1 AA acceptance criteria written into the contract, along with an obligation to remediate defects and support regression testing after future updates. Verbal assurances don’t hold up if a complaint ever lands on your desk.
• Ongoing content operations. Editors and marketers publishing blog posts, product pages, and PDFs need basic training on alt text, heading structure, and document tagging. Pair that with change control on deployments and a recurring audit schedule, and accessibility metrics belong on the same dashboard you already use for uptime and page speed.

Roles matter here. Someone in your organization, whether that’s a compliance officer, a web manager, or an outside consultant, needs explicit ownership of the accessibility program. Developers own implementation. Content creators own day-to-day hygiene like alt text and document formatting. Without a named owner, accessibility quietly becomes everyone’s job and therefore no one’s.

What to Do If You Get an Accessibility Complaint

1. Acknowledge the complaint immediately and log the date, the reported issue, and who filed it. A documented response timeline matters as much as the fix itself.
2. Audit the specific issue reported, not just the general area of the site. Confirm the barrier, understand its scope, and check whether it exists on other pages using the same component or template.
3. Fix the confirmed issue and communicate a realistic remediation timeline to the person who complained. Silence reads as indifference even when a fix is already in progress.
4. Preserve every log and record of the remediation steps taken. If the complaint escalates toward legal action, bring in counsel and an accessibility consultant early rather than after a demand letter arrives.

Accessibility as a Growth Lever, Not Just a Legal Shield

Most compliance content treats accessibility as risk avoidance and stops there. That framing misses the more useful half of the story. A site built with real keyboard navigation, clear form labeling, and legible contrast doesn’t just satisfy an auditor; it removes friction for every visitor, including the ones filling out a lead form on a cracked phone screen in bright sunlight.

Accessibility should be built into custom sites at the component level rather than patched in after launch, because retrofitting a templated site often consumes most remediation budgets. That approach comes out of the same discipline behind enterprise CRM and lifecycle marketing work for large organizations. It carries over directly: clean semantic structure and well-labeled forms are also what push inbound lead quality up, which is exactly where clients have seen measurable gains.

The audit-to-maintenance sequence in this article, audit, prioritized roadmap, remediation, QA, ongoing monitoring, isn’t a compliance checklist bolted onto a website. It’s how a site should get built in the first place.

- Jeremy

Get a Website Accessibility Audit From Forefront Industries

Forefront Industries is the alternative to a generic overlay plugin or a one-time compliance scan: instead of a script bolted onto your existing template, you get a custom-coded rebuild where accessibility is part of the architecture, not an afterthought patched in after a demand letter arrives.

The engagement flow is straightforward. It starts with a free website audit that combines automated scanning with manual review of your highest-traffic pages, then moves into a prioritized remediation roadmap ranked by legal exposure and user impact. From there, Forefront Industries handles the custom development work itself, runs acceptance testing against WCAG 2.1 AA criteria, and sets up ongoing maintenance so new pages and content don’t quietly reintroduce the same barriers you just fixed. Explore the full range of web design and development services to see how audits, remediation, and CRM work fit together for service businesses.

If your site handles bookings, quote requests, or client portals, accessibility gaps in those flows are also lead-generation gaps. Visit Forefront Industries and request a free accessibility audit to see exactly where your site stands and what a prioritized fix plan would look like.

Authoritative Resources to Bookmark

For primary legal and technical detail, go straight to the source rather than a secondhand summary:

• DOJ Guidance on Web Accessibility and the ADA
• DOJ Final Rule Fact Sheet on Web and Mobile App Accessibility
• Final Rule PDF (28 CFR Part 35)
• W3C Web Content Accessibility Guidelines (WCAG) 2.2
• U.S. Access Board: Guide to the ADA Accessibility Standards
• For the discoverability angle, see this breakdown of accessibility and SEO impact.

Sources

• Guidance on Web Accessibility and the ADA
• Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments
• Web Content Accessibility Guidelines (WCAG) 2.2
• Accessibility of Web Content and Mobile Apps Provided by State and Local Government Entities (DOJ final rule PDF)

Recommended

• Free Website Audit