Website accessibility wasn't something most people thought about five years ago. It was a niche concern, primarily for government sites and large institutions. Then came the lawsuits—thousands of them—and suddenly accessibility became a board-level concern for businesses of all sizes.
The legal landscape is still evolving, but the direction is clear: websites need to be accessible to people with disabilities. What's less clear is exactly what that means and how to achieve it.
Why Accessibility Matters Legally
The Americans with Disabilities Act
The ADA was passed in 1990, well before the modern web existed. It prohibits discrimination against people with disabilities in "places of public accommodation." Courts have increasingly interpreted this to include websites, especially websites connected to physical businesses.
The ADA doesn't specify technical standards for websites. This ambiguity has created confusion—and litigation. Plaintiffs' attorneys have filed thousands of lawsuits against businesses whose websites allegedly violate the ADA because they're inaccessible to people with disabilities.
These cases typically settle. The settlements aren't always huge (often five figures), but the legal costs and reputational impact can be significant. More importantly, they create ongoing remediation obligations.
Section 508
Section 508 of the Rehabilitation Act applies to federal agencies and organizations receiving federal funding. It requires electronic and information technology to be accessible to people with disabilities.
Section 508 is more specific than the ADA—it references WCAG (Web Content Accessibility Guidelines) as the technical standard. If you work with the federal government, Section 508 compliance is often a contractual requirement.
State Laws
Several states have their own accessibility requirements. California's Unruh Civil Rights Act has been used extensively in website accessibility lawsuits. New York and other states have similar laws.
International Requirements
The EU's Web Accessibility Directive requires public sector websites and apps to be accessible. The European Accessibility Act, effective 2025, extends requirements to private sector products and services.
Canada's Accessible Canada Act establishes accessibility requirements for federally regulated industries. Provincial laws like Ontario's AODA have website accessibility provisions.
WCAG: The Technical Standard
Web Content Accessibility Guidelines, published by the W3C, are the de facto standard for website accessibility. When laws reference accessibility, they typically mean WCAG compliance.
WCAG Versions
WCAG 2.0 was published in 2008. WCAG 2.1 (2018) added additional criteria, particularly for mobile and cognitive accessibility. WCAG 2.2 (2023) added further requirements.
Most legal requirements reference WCAG 2.0 or 2.1 at the AA level. WCAG 2.1 Level AA is the most commonly cited standard for accessibility compliance.
Conformance Levels
Level A: Minimum accessibility. Meeting this level removes the most significant barriers but leaves many accessibility issues unaddressed.
Level AA: The standard target for most organizations. Addresses the most common barriers for the largest number of users.
Level AAA: The highest level, often impractical to meet for all content. Usually targeted for specific purposes or audiences.
The Four Principles
WCAG is organized around four principles (POUR):
Perceivable: Users must be able to perceive the content. This means text alternatives for images, captions for video, sufficient color contrast, and content that works without color.
Operable: Users must be able to operate the interface. This means keyboard accessibility, adequate time to interact, no content that causes seizures, and navigable structure.
Understandable: Content and interface must be understandable. This means readable text, predictable behavior, and input assistance to help users avoid errors.
Robust: Content must work with current and future technologies, including assistive technologies. This primarily means valid, well-structured HTML.
Common Accessibility Issues
Most accessibility problems fall into predictable categories:
Missing Alt Text
Images need alternative text describing their content for screen reader users. Missing alt text is one of the most common issues—and one of the easiest to fix.
Poor Color Contrast
Text must have sufficient contrast against its background. Light gray text on white backgrounds looks elegant but is hard to read for people with low vision.
Keyboard Inaccessibility
Everything clickable must be reachable and activatable using only a keyboard. Many users can't use a mouse. Custom interactive elements often break keyboard navigation.
Missing Form Labels
Form fields need associated labels so screen readers can announce what each field is for. Placeholder text doesn't substitute for proper labels.
Missing Skip Navigation
Keyboard users need a way to skip repeated navigation and jump to main content. Without it, they must tab through the entire menu on every page.
Inaccessible PDFs and Documents
Documents must be accessible too. Scanned PDFs (images of text) are completely inaccessible to screen readers. Properly tagged PDFs are essential.
Video Without Captions
Videos need captions for deaf and hard-of-hearing users. Auto-generated captions are better than nothing but often insufficient.
Missing Heading Structure
Content should use proper heading levels (H1, H2, H3) in a logical hierarchy. Screen reader users navigate by headings—random or missing headings make content incomprehensible.
Getting Started with Accessibility
Automated Testing
Tools like WAVE, axe, or Lighthouse can scan your site and identify many accessibility issues. These catch perhaps 30-40% of problems—useful but not comprehensive.
Run automated scans regularly. Fix what they find. But don't assume passing automated tests means you're accessible.
Manual Testing
Test your site with a keyboard—can you navigate everywhere without a mouse? Test with a screen reader (VoiceOver on Mac, NVDA or JAWS on Windows). Experience what users with disabilities experience.
Manual testing reveals issues automated tools miss, like confusing navigation flows or content that's technically accessible but practically unusable.
User Testing
The gold standard is testing with actual users who have disabilities. Their feedback reveals real-world barriers that testing tools and developers without disabilities might miss.
Building Accessibility In
Retrofitting accessibility is expensive. Building it in from the start is far more efficient:
Use semantic HTML: Proper use of HTML elements (buttons for buttons, links for links, headings for headings) provides accessibility by default.
Choose accessible frameworks: Many UI component libraries now include accessibility. Choose tools that support ARIA and keyboard navigation.
Design with accessibility in mind: Ensure sufficient contrast, don't rely only on color, and plan for keyboard navigation during design—not as an afterthought.
Include accessibility in QA: Make accessibility testing part of your standard quality assurance process, not a separate initiative.
Accessibility Statements and Policies
An accessibility statement communicates your commitment to accessibility. It typically includes:
- Your accessibility commitment
- What standard you're working toward (WCAG 2.1 Level AA)
- Known limitations
- Contact information for accessibility concerns
- How you're improving accessibility over time
An accessibility statement doesn't make you compliant, but it demonstrates good faith and provides users with recourse when they encounter barriers.
Responding to Accessibility Complaints
If someone contacts you about accessibility barriers, take it seriously:
- Respond promptly and professionally
- Understand the specific barrier they encountered
- Provide alternative access if possible (for example, offer to provide information by phone if the website is inaccessible)
- Document the issue and your response
- Work to fix the underlying problem
Many accessibility complaints can be resolved through genuine engagement. Users generally want access, not litigation—they pursue legal action when they're ignored.
The Business Case
Beyond legal compliance, accessibility makes business sense:
Expanded audience: About 15% of the world's population has some form of disability. Accessible sites serve this market.
SEO benefits: Many accessibility practices (like alt text and proper headings) improve search engine optimization.
Better usability for everyone: Accessibility improvements often benefit all users—captions help people in noisy environments, good contrast helps everyone in bright sunlight.
Future-proofing: As populations age, accessibility becomes more important. Building accessible now prepares you for changing demographics.
Moving Forward
Accessibility isn't a one-time project—it's an ongoing commitment. Start where you are, fix the biggest barriers first, and improve incrementally. Perfect accessibility from day one isn't realistic, but continuous progress is achievable.
The legal requirements will keep expanding. The lawsuits will continue. But fundamentally, accessibility is about building a web that works for everyone. That's not just a legal requirement—it's the right thing to do.