Website Accessibility: A Complete Guide for 2026

2. Keyboard Navigation

Every interactive element must be reachable and operable via keyboard alone. Tab through your site without using a mouse. Can you reach every link, button, and form? Can you submit forms? Can you close modals?

Focus indicators must be visible. The default browser outline is fine if you do not override it. If you do override it (most designers do), provide a clear custom focus state. Removing focus indicators entirely is one of the most common WCAG failures.

3. Color Contrast

The AA requirement is 4.5:1 contrast ratio for normal text and 3:1 for large text (18pt or 14pt bold). Plug your colors into WebAIM’s contrast checker or any browser DevTools to verify.

Common failures: light gray text on white backgrounds, low-contrast placeholder text in forms, button text that fails contrast against the button color, and link colors that fail contrast against body text.

4. Alt Text

Every meaningful image needs descriptive alt text. “Headshot of Sarah Chen, CEO of Example Corp” is good. “Image” is useless. Decorative images (icons that repeat next to text labels, purely decorative shapes) should have empty alt attributes (`alt=””`) so screen readers skip them.

5. Captions and Transcripts

Every video needs captions. Every audio file needs a transcript. The W3C considers this non-negotiable at the AA level. Auto-generated captions are a starting point but should be reviewed and corrected.

6. Accessible Forms

Every form input needs a label. The label should be associated with the input via `` or by wrapping the input. Placeholder text is not a label. Error messages should be announced to screen readers via `aria-live` regions, and inputs with errors should be marked with `aria-invalid`.

7. ARIA (Used Sparingly)

ARIA (Accessible Rich Internet Applications) attributes add accessibility information when HTML alone is not enough. The first rule of ARIA is: do not use ARIA. Native HTML is almost always better. The second rule: when you must use ARIA, use it correctly. Bad ARIA is worse than no ARIA.

The patterns where ARIA is genuinely needed: custom dropdowns, tabs, modals, and live regions for dynamic content updates.

Testing Tools That Actually Find Issues

Automated Tools

axe DevTools (Chrome extension): the industry standard for automated accessibility testing. Run it on every page during development.

WAVE (browser extension): visual indicators on top of your page showing issues in context. Great for spot-checking.

Lighthouse (built into Chrome): includes an accessibility audit alongside performance and SEO.

Automated tools catch about 30-40% of WCAG issues. They cannot test things like “is this alt text actually descriptive” or “does this focus indicator stand out enough.” Manual testing covers the rest.

Manual Testing

The minimum manual testing checklist:

• Tab through every page using only the keyboard
• Test with a screen reader (VoiceOver on Mac, NVDA on Windows)
• Zoom to 200% and verify the layout still works
• Disable images and verify the page still makes sense
• Check color contrast on every text/background combination
• Test forms with assistive technology

User Testing

The gold standard. Recruit users with disabilities and watch them use your site. Companies like Fable and AccessibilityOz offer paid user testing services with people who use assistive technology daily.

The Legal Landscape

The legal picture has shifted dramatically.

United States

The Americans with Disabilities Act (ADA) has been interpreted by courts to apply to commercial websites. Title III lawsuits over inaccessible websites hit roughly 4,500 in 2024 and continued climbing in 2025. Most settle. The DOJ issued formal guidance in 2024 affirming that public-facing websites of state and local governments must be accessible.

European Union

The European Accessibility Act came into force on June 28, 2025. It requires all consumer-facing websites, apps, and digital products to meet accessibility standards. Enforcement is national; some EU members have implemented stiff fines for non-compliance.

Other Jurisdictions

Canada (the Accessible Canada Act), Australia (the Disability Discrimination Act with WCAG 2.0 AA standard), and the UK (the Equality Act 2010, plus public sector regulations) all impose similar obligations.

The risk is no longer hypothetical. If your site is consumer-facing and operates in any of these jurisdictions, accessibility is a compliance requirement.

Common Accessibility Mistakes

The same patterns show up on most non-compliant sites.

1. Light gray text on white backgrounds (failing contrast)
2. Forms with placeholder text instead of proper labels
3. Removed focus indicators with no replacement
4. Modals that trap focus incorrectly or cannot be closed by keyboard
5. Custom dropdowns and date pickers that are inaccessible
6. Images without alt text or with useless alt text
7. Videos without captions
8. Color-only error indicators (red border with no text)
9. Auto-playing audio or video that cannot be stopped
10. Animations that cannot be paused for visitors with vestibular disorders

Building Accessible from Day One

Retrofitting accessibility is harder and more expensive than building it in. The order:

1. Use semantic HTML by default. Buttons are buttons, links are links.
2. Pick accessible color combinations at the design stage, not in QA.
3. Design focus states as part of the design system.
4. Audit components for accessibility when you add them, not when you ship.
5. Run automated audits in CI to catch regressions.
6. Test with real users at major milestones.

Teams that follow this process spend less total time than teams that bolt accessibility on at the end, and they end up with sites that are genuinely usable rather than minimally compliant.

Accessibility on Different Platforms

WordPress sites: depend on the theme. Many popular themes have accessibility issues. Some (StudioPress, GeneratePress) are accessibility-ready. Plugins can either help or hurt; audit them.

Webflow sites: the platform has improved markedly. Built-in accessibility features include semantic HTML by default and ARIA attribute support. Custom code can still break accessibility.

Framer sites: accessible defaults across components. Focus indicators, semantic markup, and contrast-aware components are built in. The main optimization lever is custom interaction design.