Key Takeaways
- WCAG 2.1 Level AA is the legal standard in most jurisdictions; non-compliance risks lawsuits and fines
- Semantic HTML provides 80% of accessibility for free; use correct elements before reaching for ARIA
- All interactive elements must be fully keyboard accessible with visible focus indicators
- Automated tools catch only 30% of accessibility issues; manual and screen reader testing are essential
- Accessibility is an ongoing process, not a one-time audit; embed it in design and code reviews
Semantic HTML as the Accessibility Foundation
Semantic HTML is the single most important accessibility technique. When you use the correct HTML elements, browsers and assistive technologies automatically provide the right behavior, roles, and keyboard interactions.
| Instead Of | Use | Why |
|---|---|---|
| <div onclick> | <button> | Keyboard accessible, screen reader announced as button |
| <div> for nav | <nav> | Screen readers announce navigation landmark |
| <div> for main | <main> | Screen readers can skip directly to content |
| <span> for heading | <h1>-<h6> | Creates document outline for navigation |
| <div> for list | <ul>/<ol> | Screen readers announce list with item count |
| Placeholder text only | <label> | Persistent, accessible input identification |
The first rule of ARIA is: do not use ARIA if a native HTML element provides the same semantics. A <button> is always better than a <div role='button'>. Native elements include built-in keyboard handling and focus management.
- Use one <h1> per page, followed by <h2>-<h6> in logical order (no skipping levels)
- Use <nav>, <main>, <aside>, <header>, <footer> for page landmarks
- Use <button> for actions and <a> for navigation (never interchange them)
- Use <table> with <thead>, <tbody>, <th> for data tables (not for layout)
Keyboard Navigation and Focus Management
Keyboard accessibility is critical for users who cannot use a mouse, including people with motor disabilities, power users, and screen reader users. Every interactive element must be operable with keyboard alone.
| Interaction | Expected Key | Implementation |
|---|---|---|
| Navigate between elements | Tab / Shift+Tab | Natural focus order (DOM order) |
| Activate button | Enter or Space | Native <button> (automatic) |
| Follow link | Enter | Native <a> (automatic) |
| Close modal/popup | Escape | Add keydown listener |
| Navigate within widget | Arrow keys | Custom roving tabindex |
| Select option | Enter or Space | Custom handler on focused item |
- Never set outline: none without providing a visible alternative focus indicator
- Use tabindex='0' to add elements to the natural tab order (avoid positive tabindex values)
- Trap focus inside modal dialogs (Tab should cycle within the modal, not escape to the page behind)
- Move focus to newly opened content (modals, dropdowns, alerts)
- Return focus to the trigger element when closing modals or popups
Modal dialogs MUST trap focus. When a modal is open, pressing Tab should cycle through focusable elements within the modal only. Focus must not escape to the page behind the modal. Use a focus-trap library for reliable implementation.
Color, Contrast, and Visual Accessibility
Visual accessibility ensures content is perceivable by users with low vision, color blindness, or other visual impairments. Color contrast requirements are the most commonly failed WCAG criteria.
| Element | Minimum Contrast Ratio | WCAG Level |
|---|---|---|
| Normal text (<18px) | 4.5:1 | AA |
| Large text (>18px or >14px bold) | 3:1 | AA |
| UI components and graphics | 3:1 | AA |
| Normal text (enhanced) | 7:1 | AAA |
| Large text (enhanced) | 4.5:1 | AAA |
- Test all color combinations with WebAIM Contrast Checker or browser DevTools
- Never use color as the only way to convey information (add icons, patterns, or text)
- Ensure text remains readable when the page is zoomed to 200%
- Support prefers-reduced-motion for users who are sensitive to animation
- Support prefers-color-scheme for users who need dark or light mode
8% of men and 0.5% of women have some form of color blindness. Test your UI with color blindness simulation tools (Chrome DevTools has built-in simulation). Ensure color is never the sole indicator of state (error, success, active).
Accessibility Testing Strategy
A comprehensive accessibility testing strategy combines automated scanning, manual testing, and assistive technology testing. No single approach catches all issues.
| Testing Method | Issues Caught | Cost/Effort | Frequency |
|---|---|---|---|
| Automated scan (axe, Lighthouse) | ~30% of WCAG violations | Low | Every commit (CI/CD) |
| Keyboard testing | Focus order, missing handlers | Low | Every feature |
| Screen reader testing | Announcements, navigation flow | Medium | Monthly / major releases |
| User testing (people with disabilities) | Real-world usability | High | Quarterly |
| Manual WCAG audit | Comprehensive compliance | High | Annually |
- Add axe-core or jest-axe to your CI/CD pipeline for automated regression testing
- Test every new feature with keyboard-only navigation before merging
- Learn the basics of VoiceOver (Mac) or NVDA (Windows) for screen reader testing
- Include accessibility acceptance criteria in every user story and design review
- Create an accessibility checklist for code reviewers to follow
Install the axe DevTools browser extension (free). Run it on every page you build. It catches contrast violations, missing alt text, form label issues, and ARIA errors. This alone prevents the most common accessibility failures.
Frequently Asked Questions
Related services from Verbsz Technologies
If this article is relevant to a project on your roadmap, these are the services our team typically delivers.