Frequently Asked Questions
Common questions about ADA website compliance, WCAG requirements, and web accessibility.
Common questions about ADA website compliance, WCAG requirements, and web accessibility.
Yes. While the Americans with Disabilities Act (ADA) was enacted in 1990 before the modern web existed, courts have consistently interpreted Title III of the ADA to apply to websites. The Department of Justice has confirmed that websites of businesses open to the public must be accessible to people with disabilities.
This interpretation applies whether your business has a physical location or operates entirely online. E-commerce sites, service providers, restaurants with online menus, healthcare providers with patient portals, and virtually any business that serves the public can be held liable for inaccessible websites.
Yes. ADA website lawsuits have increased dramatically in recent years, with over 4,000 lawsuits filed in 2023 alone. These lawsuits typically target businesses of all sizes, from major retailers to small local businesses. Plaintiffs' attorneys often use automated tools to identify accessibility issues and file multiple lawsuits simultaneously.
Settlements typically range from $10,000 to $150,000 or more, depending on the size of the business and severity of the issues. Beyond the direct costs, businesses also face legal fees, remediation costs, and potential damage to their reputation. The most effective protection is proactive accessibility testing and remediation.
There is no single federal law that specifies exact technical requirements for website accessibility. However, WCAG 2.1 Level AA has emerged as the de facto standard through court decisions and Department of Justice guidance. Most ADA settlement agreements require conformance with WCAG 2.1 AA.
Some specific regulations do reference technical standards. Section 508 of the Rehabilitation Act requires federal agencies to follow WCAG 2.0 Level AA. The European Accessibility Act references WCAG 2.1. When courts evaluate ADA claims, they typically look to WCAG as the benchmark for what constitutes "accessible."
The ADA does not provide a blanket exemption for small businesses when it comes to website accessibility. While Title III of the ADA includes some limitations based on business size for physical accommodations, courts have generally not applied similar exemptions to digital accessibility.
That said, smaller businesses may face less aggressive targeting by plaintiffs' attorneys simply because the potential settlement amounts are lower. However, accessibility lawsuits against small businesses do occur regularly. The best approach for any business is to address accessibility proactively, which is often more cost-effective than defending a lawsuit.
There is no legally mandated timeline for remediation unless you're responding to a lawsuit or demand letter. However, if you've received legal notice, you typically have 30 to 60 days to respond, and settlement agreements often require full remediation within 6 to 12 months.
For proactive remediation, prioritize critical issues first, particularly those that completely block access for users with disabilities. A phased approach that addresses the most severe barriers first while working toward full compliance is generally accepted as demonstrating good faith effort.
WCAG stands for Web Content Accessibility Guidelines. It is an international standard developed by the World Wide Web Consortium (W3C) that explains how to make web content accessible to people with disabilities. WCAG addresses accessibility for users who are blind, deaf, have motor impairments, cognitive disabilities, and other conditions.
WCAG matters because it provides concrete, testable criteria for accessibility. Rather than vague requirements to be "accessible," WCAG gives specific success criteria that can be verified through automated testing and manual review. Following WCAG not only reduces legal risk but also improves usability for all users.
WCAG defines three conformance levels, each building on the previous one. Level A is the minimum standard, addressing the most severe accessibility barriers that would make content completely impossible to use. Examples include providing text alternatives for images and ensuring all functionality is available via keyboard.
Level AA is the recommended standard for most websites and is what most legal settlements require. It includes Level A requirements plus additional criteria like sufficient color contrast (4.5:1 for normal text), captions for live video, and consistent navigation across pages.
Level AAA is the highest standard and includes requirements that may not be feasible for all content, such as sign language interpretation for audio content and enhanced contrast ratios. Most organizations aim for AA conformance with AAA where practical.
WCAG 2.0 was published in 2008 and established the core accessibility principles. WCAG 2.1, released in 2018, added 17 new success criteria addressing mobile accessibility, low vision, and cognitive disabilities. WCAG 2.2, finalized in 2023, added 9 more criteria focusing on users with cognitive disabilities and improving mobile usability.
Each version is backward compatible: a site that meets WCAG 2.2 also meets 2.1 and 2.0. Most current legal references point to WCAG 2.1 Level AA, though this is expected to shift toward 2.2 as it becomes more widely adopted. Our scanner tests against WCAG 2.2 AA to ensure you're meeting the most current standards.
Perceivable: Information and user interface components must be presentable to users in ways they can perceive. This means providing text alternatives for images, captions for videos, sufficient color contrast, and content that can be presented in different ways without losing meaning.
Operable: User interface components and navigation must be operable. All functionality must work with a keyboard, users must have enough time to read content, content shouldn't cause seizures, and users must be able to navigate and find content easily.
Understandable: Information and operation of the user interface must be understandable. Text must be readable, pages must behave predictably, and users must be helped to avoid and correct mistakes.
Robust: Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. This means using valid, semantic HTML and following ARIA specifications correctly.
Alt text (alternative text) is a written description of an image that is read aloud by screen readers. When a blind or visually impaired user encounters an image, the screen reader announces the alt text so the user understands what the image conveys. Without alt text, users may hear only "image" or the file name, leaving them unable to understand the content.
Good alt text is concise but descriptive. For a photo of a team meeting, "Team meeting in conference room" is better than just "meeting" or a file name like "IMG_2847.jpg". Decorative images that don't convey meaningful content should have empty alt attributes (alt="") so screen readers skip them entirely.
Color contrast refers to the difference in brightness between text and its background. Low contrast makes text difficult or impossible to read for users with low vision, color blindness, or even users viewing screens in bright sunlight. WCAG specifies minimum contrast ratios to ensure readability.
For WCAG AA compliance, normal text (under 18pt or 14pt bold) requires a contrast ratio of at least 4.5:1. Large text (18pt+ or 14pt+ bold) requires at least 3:1. User interface components and graphics require 3:1 contrast against adjacent colors. Tools like our scanner automatically check these ratios.
A keyboard trap occurs when a user navigating with a keyboard can enter a component or section of a page but cannot exit it using standard keyboard controls. This typically happens with modal dialogs, video players, or complex widgets that capture keyboard focus but don't provide a way to escape.
Keyboard traps are critical accessibility failures because they completely prevent keyboard users from continuing to navigate the page. The solution is ensuring that every interactive element can be exited using the Tab key, Escape key, or another clearly documented keyboard method.
Form labels tell users what information to enter in each field. While visual users can often infer the purpose from placeholder text or nearby content, screen reader users rely on properly associated labels. A label must be programmatically linked to its input using the "for" attribute matching the input's "id".
Placeholder text alone is not sufficient because it disappears when users start typing, making it difficult to remember what was requested. Labels also provide larger click targets; clicking a label focuses its associated input, which helps users with motor impairments.
ARIA (Accessible Rich Internet Applications) is a set of attributes that can be added to HTML elements to provide additional accessibility information. ARIA can define roles (what an element is), states (its current condition), and properties (its characteristics) for assistive technologies.
The first rule of ARIA is to avoid using it when native HTML will work. A <button> element is always preferable to a <div role="button">. Use ARIA when you need to create custom widgets that don't have native HTML equivalents, or to enhance complex interactions. Incorrect ARIA is worse than no ARIA because it can confuse assistive technologies and make content less accessible.
No. Automated testing tools like our scanner can identify approximately 30-40% of WCAG violations. They excel at finding technical issues like missing alt text, insufficient color contrast, missing form labels, and invalid ARIA usage. These are objective issues with clear pass/fail criteria.
However, automated tools cannot evaluate whether alt text is actually meaningful, whether content makes sense when read linearly, whether the tab order is logical, or whether error messages are helpful. Comprehensive accessibility testing requires both automated scanning and manual testing by humans, ideally including users who rely on assistive technologies.
We recommend testing whenever you make significant changes to your website, such as new pages, redesigns, new features, or content management system updates. For actively maintained sites, monthly automated scans provide a good baseline for catching regressions.
If you're in a high-risk industry (retail, healthcare, finance, hospitality) or have previously received legal demands, more frequent testing may be appropriate. Setting up automated testing in your development pipeline helps catch issues before they reach production.
Start by prioritizing issues by severity. Critical issues that completely block access (keyboard traps, missing page titles, auto-playing media without controls) should be fixed first. Then address serious issues like missing alt text and form labels. Moderate issues like inadequate focus indicators can follow.
Document your remediation efforts. Create a prioritized list of issues, assign responsibility for fixes, and track progress. This documentation can be valuable if you ever face legal action, as it demonstrates good faith effort toward compliance. For complex issues, consider consulting with accessibility specialists.
Yes. Many accessibility best practices directly improve SEO. Alt text helps search engines understand image content. Proper heading structure (H1, H2, H3) creates clear content hierarchy that search engines use for indexing. Descriptive link text provides context for both users and crawlers.
Accessible sites also tend to have cleaner code, faster load times, and better mobile experiences, all factors that search engines consider in rankings. While Google hasn't explicitly confirmed accessibility as a ranking factor, the correlation between accessible sites and good SEO is well documented.
According to the CDC, 1 in 4 adults in the United States, about 61 million people, lives with a disability. This includes people who are blind or have low vision (about 12 million), people who are deaf or hard of hearing (about 11 million), and people with mobility or cognitive disabilities that affect how they use computers and the web.
Beyond permanent disabilities, many more people experience temporary or situational limitations. A broken arm, eye surgery, a loud environment, or bright sunlight can all create accessibility needs. Building accessible websites means reaching more customers and providing better experiences for everyone.
Building accessibility into a new project costs relatively little, typically 1-3% of development budget when considered from the start. Retrofitting an existing site costs more, but is almost always less expensive than defending a lawsuit. A typical settlement includes $10,000-$75,000 in damages plus legal fees plus mandatory remediation.
The key is integrating accessibility into your development process rather than treating it as an afterthought. Training developers on accessibility basics, using accessible frameworks and components, and testing regularly all reduce long-term costs while minimizing legal risk.
Run a free scan to see how your website measures up, or explore our resources for more detailed guides.
Run Free Scan Browse Resources