📊 Accessibility by the Numbers
Why Accessibility Matters
Web accessibility means designing and developing websites that people with disabilities can perceive, understand, navigate, and interact with. This includes people who are blind or have low vision, deaf or hard of hearing, have motor disabilities, cognitive disabilities, or temporary impairments (like a broken arm).
Reach More Users
15-20% of the global population has a disability. An accessible site reaches everyone, including 70+ million Americans with disabilities and the aging population whose needs overlap significantly with accessibility requirements.
Legal Compliance
The ADA (US), EAA (EU), AODA (Canada), and Equality Act (UK) all require website accessibility. Non-compliance leads to lawsuits, fines, and reputational damage. Over 4,000 lawsuits were filed in the US alone in 2025.
Better SEO
Accessibility and SEO overlap heavily: semantic HTML, proper headings, alt text, descriptive link text, fast loading times, mobile-friendliness, and structured content all improve both accessibility AND search rankings.
Better UX for Everyone
Accessible design improves usability for all users: captions help in noisy environments, keyboard navigation helps power users, clear contrast helps in bright sunlight, and simple language helps non-native speakers.
Legal Requirements (ADA, EAA, AODA)
| Law | Region | Who Must Comply | Standard | Penalties |
|---|---|---|---|---|
| ADA Title III | 🇺🇸 US | Any business open to the public (physical or online). Courts have consistently ruled websites are 'places of public accommodation.' | WCAG 2.1 AA | $5K-$250K+ per lawsuit |
| Section 508 | 🇺🇸 US (Gov) | Federal agencies and contractors. All government-funded technology must be accessible. | WCAG 2.0 AA | Loss of contract, complaints |
| European Accessibility Act | 🇪🇺 EU | All commercial websites and apps serving EU users. Effective June 28, 2025. | WCAG 2.1 AA (EN 301 549) | Up to €100K per violation |
| AODA | 🇨🇦 Ontario | Organizations with 50+ employees and all public sector organizations. | WCAG 2.0 AA | $100K/day (corp) |
| Equality Act 2010 | 🇬🇧 UK | Service providers, including those with websites accessible to UK users. | WCAG 2.1 AA | Unlimited damages |
| DDA | 🇦🇺 Australia | All organizations providing services online to Australian users. | WCAG 2.0 AA | Complaints + damages |
WCAG 2.2 Explained
The Web Content Accessibility Guidelines (WCAG) are organized around four principles, known by the acronym POUR. Every accessibility requirement falls under one of these:
Perceivable
Users must be able to perceive the content. This means providing text alternatives for images, captions for video, sufficient color contrast, and content that can be presented in different ways (e.g., larger text, simpler layout) without losing meaning.
Key criteria: Alt text on images, video captions, 4.5:1 color contrast ratio, resizable text up to 200%
Operable
Users must be able to operate the interface. All functionality must be available via keyboard (no mouse required), users must have enough time to read content, content must not cause seizures, and navigation must be clear and consistent.
Key criteria: Keyboard navigation, skip links, visible focus indicators, no auto-playing content, clear page titles
Understandable
Users must be able to understand the content and interface. Language must be identified, navigation must be consistent, input errors must be clearly identified with suggestions, and the interface must behave predictably.
Key criteria: Language attribute set, consistent navigation, form validation messages, predictable behavior
Robust
Content must be robust enough to work with current and future assistive technologies. This means using valid HTML, proper ARIA attributes, and ensuring compatibility with screen readers, magnifiers, and alternative input devices.
Key criteria: Valid HTML, proper ARIA roles, semantic elements, no duplicate IDs, status messages for screen readers
🆕 What's New in WCAG 2.2
Released October 2023, WCAG 2.2 added 9 new success criteria focused on:
- • Focus Appearance (AA): Focus indicators must be clearly visible (minimum 2px outline, 3:1 contrast)
- • Dragging Movements (AA): Any drag-and-drop action must have a click/tap alternative
- • Target Size Minimum (AA): Interactive targets must be at least 24×24 CSS pixels
- • Consistent Help (A): Help mechanisms must appear in the same location across pages
- • Accessible Authentication (AA): Login must not require cognitive function tests (CAPTCHAs must have alternatives)
- • Redundant Entry (A): Don't ask users to re-enter information already provided
How Hosting Affects Accessibility
Most accessibility issues are in your frontend code, but your hosting infrastructure creates the foundation. A poorly configured host can undermine even perfectly accessible HTML:
Page Speed & Performance
Slow sites disproportionately affect users with cognitive disabilities, older devices, and low-bandwidth connections. A 3-second load time is frustrating for anyone, for someone using a screen reader that needs to parse the entire DOM, it's a significant barrier.
Action: Choose hosting with <200ms TTFB, HTTP/2+, CDN, and Brotli/gzip compression. Target Core Web Vitals: LCP <2.5s, FID <100ms, CLS <0.1.
SSL/HTTPS
Mixed content warnings and insecure connections can break assistive technology. Screen readers may not announce security warnings clearly, leaving users confused. HTTPS is also a ranking factor that affects discoverability.
Action: Use hosting with free automatic SSL (Let's Encrypt). Enforce HTTPS redirects. Ensure all resources load over HTTPS (no mixed content).
Server Response Headers
Missing or incorrect Content-Type, charset (UTF-8), and lang headers cause assistive technology to misinterpret content. Special characters, accented text, and non-Latin scripts won't render correctly.
Action: Configure proper Content-Type: text/html; charset=UTF-8 headers. Set the HTML lang attribute. Use proper content negotiation.
Error Pages (404, 500)
Your hosting provider's default error pages are almost never accessible. No alt text, no landmarks, no keyboard navigation, often auto-generated HTML without semantic structure.
Action: Create custom, accessible error pages for 404 and 500 errors. Include navigation, search, heading structure, and a clear error message.
Uptime & Reliability
A website that's down is 100% inaccessible. For users who depend on web services (online banking, government services, healthcare portals), downtime can have serious real-world consequences.
Action: Choose hosting with 99.9%+ uptime SLA. Implement status pages. Have a fallback/maintenance page that's accessible.
CDN & Caching
Aggressive caching can serve stale accessibility fixes to users. CDN edge nodes may strip important headers. Some CDN configurations break JavaScript-based accessibility features.
Action: Configure cache headers properly. Test accessibility after CDN setup. Ensure dynamic accessibility features (live regions) aren't cached.
ADA Compliance Checklist
This comprehensive checklist covers the most critical WCAG 2.2 Level AA requirements. Use it to audit your site and prioritize fixes:
🖼️ Images & Media
⌨️ Keyboard & Navigation
🎨 Color & Contrast
📝 Forms & Input
📄 Content & Structure
🖥️ Hosting & Infrastructure
Accessibility Testing Tools
| Tool | Type | Cost | Best For |
|---|---|---|---|
| axe DevTools | Browser extension | Free (core) | Developers: in-browser testing, finds ~57% of WCAG issues automatically. Industry standard. |
| WAVE | Browser extension | Free | Visual overview: highlights errors directly on the page with icons. Great for non-developers. |
| Lighthouse | Built into Chrome | Free | Quick audits: accessibility score + performance. Built into Chrome DevTools. Good starting point. |
| Pa11y | CLI / CI tool | Free (open source) | Automated testing in CI/CD pipelines. Run accessibility checks on every deployment. |
| NVDA | Screen reader | Free (Windows) | Manual testing: experience your site as blind users do. Essential for thorough testing. |
| VoiceOver | Screen reader | Free (macOS/iOS) | Manual testing on Apple devices. Built into every Mac, iPhone, and iPad. |
| Colour Contrast Analyser | Desktop app | Free | Check specific color combinations against WCAG contrast requirements. |
| Siteimprove | SaaS platform | $300+/mo | Enterprise: continuous monitoring, reporting, prioritized fix suggestions. |
⚠️ Automated Tools Only Catch ~30-40% of Issues
Tools like axe and WAVE are essential but limited. They can check if an image has alt text, but not if the alt text is meaningful. They can verify heading structure, but not if the headings make logical sense. They can detect color contrast, but not if color is the only way to convey information. Always combine automated testing with manual testing: navigate your site with keyboard only, test with a screen reader (NVDA or VoiceOver), and ideally conduct user testing with people who have disabilities.
Most Common Violations
The WebAIM Million report (2025) analyzed the top 1,000,000 websites and found that 96.3% had detectable WCAG failures. The most common issues are also the easiest to fix:
Low contrast text
Use contrast ratio of 4.5:1 for normal text, 3:1 for large text. Tools: WebAIM Contrast Checker, Colour Contrast Analyser. Most common offenders: light gray text on white backgrounds, placeholder text in forms.
Missing alt text on images
Add descriptive alt text to informational images. Use alt="" for decorative images. Don't start with 'Image of...' Screen readers already announce it's an image. For complex images (charts), add a longer description nearby or via aria-describedby.
Missing form input labels
Every <input>, <select>, and <textarea> needs an associated <label> element (using for/id pairing) or aria-label. Placeholder text is NOT a label, it disappears when the user starts typing.
Empty links or buttons
Links with only icons (social media, hamburger menu) need aria-label or visually hidden text. <a href='...'><svg>...</svg></a> is meaningless to screen readers. Add aria-label='Open menu' or <span class='sr-only'>Menu</span>.
Missing document language
Add lang='en' (or appropriate language code) to the <html> element. Without it, screen readers can't determine pronunciation. One-line fix: <html lang='en'>. For multilingual content, use lang attribute on specific elements.
Missing or broken skip navigation
Add a 'Skip to main content' link as the first focusable element. It should be visually hidden until focused (show on Tab). Links to #main-content where <main id='main-content'> begins. Saves keyboard users from tabbing through 50+ navigation links on every page.
Hosting Features That Help Accessibility
| Feature | Why It Matters | Providers |
|---|---|---|
| Free SSL/HTTPS | Secure connections prevent mixed content that breaks assistive tech | All modern hosts |
| CDN with Brotli/gzip | Faster loading = better for cognitive disabilities & low-bandwidth users | Cloudflare, SiteGround, Kinsta |
| HTTP/2 or HTTP/3 | Multiplexing loads CSS/JS faster, reducing time to interactive | Most premium hosts |
| Custom error pages | Default 404s are inaccessible. Custom ones can include navigation & search | All hosts (configure yourself) |
| Server-side redirects | Proper 301s prevent broken links. Broken URLs = dead ends for assistive tech | All hosts (.htaccess, nginx.conf) |
| Image optimization | Compressed images load faster. WebP/AVIF support reduces bandwidth needs | Cloudflare, Kinsta, SiteGround |
| Staging environment | Test accessibility fixes before deploying to production | SiteGround, Kinsta, Cloudways |
CMS & Platform Accessibility
| Platform | Base Accessibility | Key Considerations |
|---|---|---|
| WordPress | ⭐⭐⭐ | Core is accessibility-ready. Theme choice is critical; use 'accessibility-ready' tagged themes. Many plugins add inaccessible markup. Test with each plugin you add. |
| Shopify | ⭐⭐ | Improving rapidly. Dawn theme is well-structured. Checkout accessibility has improved. Third-party apps often introduce issues. |
| Wix | ⭐⭐ | Built-in accessibility checker. Auto-generates alt text (review for accuracy). Some templates have poor heading structure. Better than it used to be. |
| Squarespace | ⭐⭐ | Templates vary widely in accessibility. Limited control over HTML output. No accessibility-specific templates. Manual fixes may require custom code injection. |
| Next.js / React | ⭐⭐⭐ | Full control over HTML output. Excellent accessibility if developers follow best practices. Need ESLint plugin eslint-plugin-jsx-a11y. Client-side routing needs focus management. |
| Static (Hugo, Astro) | ⭐⭐⭐ | Clean HTML output. Fast performance. Full control. Choose accessible themes and maintain semantic HTML. |
Writing an Accessibility Statement
An accessibility statement demonstrates your commitment and provides a way for users to report issues. Many jurisdictions (EU, UK) require one. Include these elements:
"[Organization] is committed to ensuring digital accessibility for people with disabilities."
"We aim to conform to WCAG 2.2 Level AA."
Honestly state what level you've achieved and known gaps: "We are currently partially conformant with WCAG 2.2 Level AA."
List specific areas that aren't fully accessible yet and your timeline for fixing them.
Email address and/or phone number for users to report accessibility barriers. Respond within 2-5 business days.
When the statement was last updated and when the site was last audited.
(EU/UK) Link to the relevant enforcement body if users can't resolve issues directly with you.
Remediation Roadmap
If your site isn't accessible, here's a prioritized plan to get compliant without overwhelming your team:
Add alt text to all images. Set HTML lang attribute. Fix color contrast (body text, headings, links). Add form labels. Create skip navigation link. Fix page titles. These 6 fixes address ~60% of common violations and take 1-2 days for most sites.
Ensure all interactive elements are keyboard accessible. Add visible focus indicators. Fix tab order. Handle modals/dropdowns correctly (focus trapping, Escape to close). Test by navigating your entire site with keyboard only (no mouse).
Fix form validation and error handling. Add ARIA live regions for dynamic content updates. Ensure toast notifications are announced by screen readers. Fix any custom components (accordions, tabs, carousels) for keyboard and screen reader support.
Add captions to all videos. Add audio descriptions where needed. Ensure PDFs are accessible (tagged PDF) or provide HTML alternatives. Review all content for readability and clear language. Fix data tables with proper headers.
Run full automated audit (axe, Pa11y). Conduct manual screen reader testing (NVDA + VoiceOver). Test at 200% and 400% zoom. Test on mobile with assistive tech. Fix remaining issues. Write accessibility statement.
Add accessibility checks to CI/CD pipeline (Pa11y, axe-core). Train developers on accessible coding practices. Include accessibility in QA checklists. Re-audit quarterly. Monitor for regressions after updates.
Frequently Asked Questions
Can I get sued for having an inaccessible website?
Do accessibility overlays (like AccessiBe or UserWay) make my site ADA compliant?
What WCAG level do I need to comply with?
How does my hosting provider affect website accessibility?
How much does it cost to make a website accessible?
Find Accessible-Friendly Hosting
Fast, reliable hosting with free SSL, CDN, and staging environments creates the foundation for an accessible website. Find the right provider for your needs.
Find Hosting