Website Accessibility (ADA Compliance): A Practical Guide (2026)
APPSWEBDEV
Website Accessibility
A Practical ADA Guide
Website accessibility lawsuits under the ADA have increased sharply in recent years, and most of the businesses getting sued had no idea their site had a problem until a legal letter arrived. Beyond the legal risk, an inaccessible website simply excludes a meaningful share of potential customers — people using screen readers, people with motor impairments, people with color blindness — from being able to use it at all. This guide covers what web accessibility actually requires in practice.
What “ADA Compliance” for a Website Actually Means
The Americans with Disabilities Act doesn’t contain website-specific technical standards, but courts and the Department of Justice have consistently pointed to the Web Content Accessibility Guidelines (WCAG), currently at version 2.1 or 2.2, as the practical standard for what an accessible website looks like. Most legal risk in practice centers on WCAG 2.1 Level AA conformance.
The Four Principles Behind WCAG
Perceivable
Content must be presentable in ways all users can perceive — alt text for images so screen reader users know what’s there, captions for video, sufficient color contrast for users with low vision or color blindness.
Operable
All functionality must work via keyboard alone, not just mouse or touch — critical for users who can’t use a mouse due to motor impairments, and often the single most commonly failed requirement on real-world sites.
Understandable
Content and navigation need to be predictable and clearly labeled — form fields with real labels (not just placeholder text that disappears on focus), consistent navigation patterns, clear error messages.
Robust
Content needs to work reliably across assistive technologies (screen readers, screen magnifiers) both now and as those technologies continue to evolve — generally achieved through clean, standards-compliant code.
The Most Common Real-World Accessibility Failures
- Missing or unhelpful alt text on images, or images used as buttons/links with no text alternative at all
- Insufficient color contrast between text and background, common in modern minimalist design trends
- Content only accessible via mouse hover (dropdown menus, tooltips) with no keyboard equivalent
- Form fields with no proper labels, relying only on placeholder text that vanishes once someone starts typing
- Video content with no captions, excluding deaf and hard-of-hearing users entirely
- Focus indicators removed via CSS for aesthetic reasons, leaving keyboard users with no visual indication of where they are on the page
How to Actually Test a Website’s Accessibility
Automated scanning tools catch a meaningful share of common issues (missing alt text, contrast failures, missing form labels) quickly and cheaply, but automated tools alone typically catch only a fraction of real-world accessibility problems. Manual testing — navigating the entire site using only a keyboard, and testing with an actual screen reader — catches issues automated tools consistently miss, particularly around logical navigation order and whether interactive elements are genuinely operable without a mouse.
The Overlay Widget Problem
Many businesses install a third-party “accessibility overlay” widget expecting it to fully solve compliance on its own. These tools can help with some surface-level issues, but they don’t fix underlying code problems, and several have themselves been named in accessibility lawsuits for failing to actually make sites usable with assistive technology. An overlay is not a substitute for building accessibility into the site itself.
Building Accessibility In From the Start
Retrofitting an existing, inaccessible site is meaningfully more expensive and time-consuming than building accessibility in during initial development — semantic HTML, proper heading structure, sufficient contrast in the original design, and keyboard-operable components from day one prevent the majority of common issues before they ever exist.
Common Accessibility Mistakes
- Relying entirely on an accessibility overlay widget instead of fixing underlying code
- Testing only with automated scanning tools and skipping manual keyboard/screen-reader testing
- Treating accessibility as a one-time fix rather than an ongoing standard applied to all new content and features
- Removing visible focus indicators for purely aesthetic reasons
- No captions on video content
What Accessibility Remediation Should Cost
An accessibility audit for a small-to-mid-sized site typically runs $1,500–$4,000. Remediation cost varies significantly with how many issues are found, typically ranging from $2,000 for a handful of straightforward fixes to $10,000+ for a large site with deep structural issues.
FAQ
Is website accessibility legally required?
The ADA doesn’t name websites explicitly, but courts have consistently applied it to websites, and WCAG 2.1 AA is the standard most commonly referenced in both lawsuits and settlements.
Will an accessibility overlay widget make my site compliant?
Not fully — overlays can help with some surface issues but don’t fix underlying code problems, and several have themselves faced legal challenges for not actually working with assistive technology.
How do I know if my current website has accessibility issues?
An automated scan is a reasonable first step, but a proper audit includes manual keyboard navigation and screen reader testing, since automated tools miss a large share of real issues.
What’s the most commonly failed accessibility requirement?
Keyboard operability — many sites work fine with a mouse but break down entirely for someone navigating with a keyboard alone.
Does accessibility work overlap with SEO?
Significantly — semantic HTML, proper heading structure, and descriptive alt text benefit both accessibility and search engine understanding of a page.
See our web development services, or review the official WCAG guidelines from the W3C for the full technical standard.