Accessibility is not a nice-to-have — it is a legal requirement, a moral imperative, and a business advantage. One in four adults lives with a disability, and an accessible site reaches all of them. Here is a practical checklist to get your site to WCAG 2.2 AA compliance.
Color contrast: the easiest win
Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text above 24px). This is the most common accessibility failure and the easiest to fix. Use a contrast checker, audit every text-background combination in your design system, and adjust colors until they pass. Pay special attention to placeholder text, disabled states, and text over images.
Keyboard navigation: can you use your site without a mouse?
Every interactive element must be reachable and operable with a keyboard alone. Tab through your site: can you reach every link, button, and form field? Is the focus indicator visible at all times? Can you open and close modals, dropdowns, and menus with arrow keys? If you cannot use your site with a keyboard, neither can users with motor impairments.
Screen reader compatibility
Screen readers read your site aloud to blind users. Every image needs an alt attribute (or empty alt for decorative images). Every form field needs a label. Every interactive element needs an accessible name. Use semantic HTML — button, nav, main, article — instead of divs with click handlers. Test with NVDA (free) or VoiceOver (built into macOS and iOS).
Focus management for single-page apps
In single-page apps, page changes do not trigger a screen reader announcement by default. When a user navigates to a new view, move focus to the new content and use aria-live regions to announce dynamic updates. Without this, screen reader users are stuck on a page that visually changed but audibly did not.
Reduced motion and animation
Some users experience motion sensitivity or vestibular disorders. Respect the prefers-reduced-motion media query and disable or simplify animations for users who request it. Large parallax effects, auto-playing carousels, and zooming transitions can cause nausea and discomfort for these users.
Accessible forms
Every form field needs a visible label, not just a placeholder. Error messages must be announced to screen readers and associated with the correct field using aria-describedby. Do not disable the submit button until after a validation attempt — let users submit and show errors, so screen readers can announce them.
Test with real users
Automated tools catch 30-40% of accessibility issues. Manual testing with keyboard and screen readers catches another 40%. Testing with real users who rely on assistive technology catches the rest. No tool replaces human testing. Budget for it.
Accessibility is not a checkbox — it is a practice. Build it into your design and development workflow, test continuously, and treat it as a quality bar, not a compliance afterthought.