A concrete checklist of web accessibility (a11y) best practices to ensure your sites and apps are usable by everyone, including people with disabilities, and compliant with WCAG 2.1 AA standards.
1. Use semantic HTML elements
Use native elements like <nav>, <main>, <article>, <button>, and <h1>–<h6> to convey structure and meaning. Screen readers and assistive technologies rely on semantics to navigate and interpret content correctly.
2. Provide descriptive alt text for all images
Every meaningful image must have an alt attribute that describes its purpose or content (e.g., alt='Bar chart showing Q3 revenue growth of 20%'). Decorative images should use an empty alt='' so screen readers skip them.
3. Ensure sufficient color contrast
Text and interactive elements must meet WCAG 2.1 AA minimums: 4.5:1 for normal text and 3:1 for large text (18pt+ or 14pt bold). Use tools like the WebAIM Contrast Checker or browser DevTools to verify ratios.
4. Make all functionality keyboard-accessible
Every interactive element — links, buttons, forms, modals, dropdowns — must be reachable and operable via keyboard alone (Tab, Shift+Tab, Enter, Space, arrow keys). Never remove or suppress default focus outlines without replacing them with a clearly visible custom style.
5. Manage focus in dynamic content and SPAs
When content changes (modal opens, route changes, alert appears), programmatically move focus to the new content using element.focus() or a live region. Unmanaged focus leaves keyboard and screen-reader users disoriented.
6. Label all form inputs explicitly
Associate every input with a <label> using a matching for/id pair, or use aria-label / aria-labelledby as a fallback. Placeholder text alone is insufficient because it disappears on input and has low contrast by default.
7. Use ARIA only when native HTML falls short
Apply ARIA roles, states, and properties (e.g., role='dialog', aria-expanded, aria-live) only when a native HTML element cannot achieve the same semantic result. Incorrect ARIA usage is worse than no ARIA at all.
8. Implement skip navigation links
Add a visible-on-focus 'Skip to main content' link as the first focusable element on every page. This lets keyboard users bypass repetitive navigation menus and jump directly to the primary content.
9. Caption all video and audio content
Provide synchronized captions for videos and transcripts for audio-only content. Captions must be accurate, time-aligned, and include descriptions of meaningful non-speech sounds (e.g., [applause], [alarm]).
10. Design responsive and zoom-friendly layouts
Ensure content remains fully readable and functional when text is scaled to 200% and when the browser is zoomed to 400%. Avoid fixed pixel heights on containers that clip overflowing text.
11. Avoid relying on color alone to convey information
Supplement color cues with icons, patterns, labels, or text (e.g., error fields should have a red border AND an error icon AND descriptive text). Users with color blindness will miss color-only signals.
12. Test with real screen readers regularly
Use NVDA+Firefox or JAWS+Chrome on Windows, and VoiceOver on macOS/iOS to manually navigate your UI. Automated tools catch only ~30–40% of accessibility issues; real assistive technology testing uncovers the rest.
13. Run automated accessibility audits in CI/CD
Integrate tools like axe-core, Lighthouse CI, or Pa11y into your pipeline to catch regressions on every pull request. Treat accessibility violations as blocking build failures, not optional warnings.
14. Write an accessibility statement and provide a feedback mechanism
Publish a public accessibility statement listing your conformance level, known limitations, and a clear contact method for users to report barriers. This demonstrates commitment and creates a feedback loop for continuous improvement.