How to Test Your Site for Accessibility Issues

Accessibility testing is not a one-time checkbox. It’s an ongoing practice that makes your site usable for everyone, including people with disabilities. But where do you start? The key is a layered approach: automated tools for quick wins, manual checks for deeper issues, and real user testing for real-world results. This guide walks you through a practical workflow to test your site comprehensively.

What Does Accessibility Testing Actually Cover?

Accessibility testing checks how well people with disabilities can use your site. This includes visual impairments, hearing loss, motor disabilities, and cognitive differences. The Web Content Accessibility Guidelines (WCAG) provide a standard framework, organized around four principles: Perceivable, Operable, Understandable, and Robust.

A thorough test covers keyboard accessibility, screen reader compatibility, color contrast, text scaling, focus indicators, form labels, error messages, and more. It also tests that the site works with assistive technologies like screen readers, voice control, and switch devices.

What Automated Tools Can You Use?

Automated tools are your first line of defense. They scan your HTML, CSS, and JavaScript against WCAG rulesets and flag violations. They’re fast and cover a wide surface area, but they only catch 30-50% of issues. You need them, but you can’t stop there.

Popular Automated Accessibility Checkers

• axe DevTools: Browser extension and CLI tool. It’s the industry standard for accuracy. Use the free version for basic scans or the paid version for advanced features.
• Google Lighthouse: Built into Chrome DevTools. It generates an accessibility score and lists failed audits. It’s a good starting point for a quick health check.
• WAVE: Browser extension and online tool. It overlays icons on your page to show errors, alerts, and ARIA features. Great for visual learners.
• Pa11y: Open-source command-line tool. Good for integrating into CI/CD pipelines.

Run a scan with at least one tool. Look for issues like missing alt text, low contrast, empty links, missing form labels, and improper heading hierarchy. Fix those first — they’re often the easiest to address.

How Do You Test Keyboard Accessibility?

Many users navigate the web using only the keyboard. This includes people with motor disabilities who use tab keys or switch devices, as well as power users who prefer keyboard shortcuts. Keyboard testing checks that all interactive elements are reachable and operable without a mouse.

1. Start tabbing: Press Tab to move forward, Shift+Tab to move backward. You should see a visible focus ring on each focusable element: links, buttons, form fields, and custom widgets.
2. Check order: The tab order should match visual order. A logical flow is left-to-right, top-to-bottom. Use positive tabindex values rarely — 0 or -1 is almost always better.
3. Activate everything: Use Enter and Space to activate buttons and links. Use arrow keys for sliders, tabs, and menus. Confirm that all functionality works.
4. Watch for traps: Keyboard traps occur when focus gets stuck on an element and you can’t tab away. A common culprit is custom modal dialogs that don’t trap focus correctly. Make sure users can close modals with the Escape key.

A site passes keyboard testing if you can complete every task using only the keyboard. If you can’t navigate a dropdown menu or submit a form, that’s a failure.

How Do You Use a Screen Reader for Testing?

Screen readers convert text and UI elements to speech or braille. The most common ones are NVDA (Windows, free), JAWS (Windows, paid), and VoiceOver (Mac, built-in). Testing with a screen reader reveals bad semantics, missing labels, and confusing navigation flows.

Here’s a quick testing routine with VoiceOver on Mac (similar steps on other platforms):

1. Turn on VoiceOver (Command+F5) and navigate using tab and arrow keys.
2. Listen to headings: Use the rotor (Control+Option+Right Arrow) to list headings. They should describe the page structure logically. No skipped levels (like jumping from h2 to h4).
3. Check landmarks: The reader should announce regions like navigation, main, and footer. Use HTML5 landmark elements (<nav>, <main>, <aside>) for consistency.
4. Test forms: Tab into a text input. The screen reader should announce the label. If it says “Edit text” without a label, that’s a problem. Every input needs a proper <label> or aria-label.
5. Test dynamic content: If your site loads new content without a page reload (like an auto-complete search), verify that the screen reader announces the update using aria-live regions.

Screen reader testing can feel awkward at first. But it’s one of the most effective ways to find issues that automated tools miss.

What Manual Checks Should You Perform?

Manual testing fills the gap between automated scans and user testing. These checks require human judgment and cover things machines can’t test reliably.

Color Contrast

Use a color contrast analyzer like the WebAIM Contrast Checker or the Colour Contrast Analyzer (CCA) tool. WCAG Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). Check all text on backgrounds, including placeholder text, link hover states, and error messages.

Zoom and Resize

Zoom your browser to 200% in desktop mode. Does the layout break? Do text cut off or overlap? Do buttons become inaccessible? WCAG requires that content work at 400% zoom on a 1280px viewport, but 200% is a good practical minimum. Also test that text can be resized up to 200% without assistive technology.

Audio and Video

If your site has embedded media, check for captions on videos and transcripts for audio. Also ensure that auto-playing content has a pause button and that media controls are keyboard accessible.

Forms and Error Handling

Submit a form with empty required fields. Does the error message clearly describe what’s wrong? Are errors announced to screen readers? Do error messages appear next to the relevant field, or only in a summary at the top? Both locations are fine, but you need at least one.

Why Is Real User Testing Important?

Automated tools and your own manual checks are necessary but not sufficient. They can’t replicate the experience of a person who uses assistive technology every day. Real user testing uncovers issues that even experienced developers miss, like unexpected behavior in a specific screen reader version or device.

Recruit testers with disabilities. You can find them through accessibility consulting firms, disability advocacy groups, or user testing platforms. If that’s not feasible, ask colleagues or friends who use assistive technology. Even testing with one or two users can reveal critical issues.

During a test session, ask users to complete specific tasks: sign up for a newsletter, purchase a product, or find a contact number. Observe where they struggle. Ask them to think aloud. Then prioritize fixes based on severity.

How Do You Integrate Accessibility Testing into Your Workflow?

Running tests once is better than nothing, but accessibility is easier to maintain when it’s baked into your process.

Phase	Action	Tool or Method
Design	Check color contrast early	WebAIM Contrast Checker
Development	Run linters and automated checks	axe-core, eslint-plugin-jsx-a11y
Code review	Check for accessibility in pull requests	Manual review + axe CLI
QA	Full manual accessibility audit	Keyboard, screen reader, contrast tools
Pre-release	User testing with people with disabilities	Usability sessions
Monitoring	Continuous scanning	Pa11y CI or axe-core in CI/CD

Start small. Pick one tool, run it on your main pages, fix issues. Then add keyboard testing. Then screen reader testing. Over time, it becomes second nature.

Key Takeaways to Remember

Accessibility testing is a skill you build with practice. No tool or checklist replaces the insight you get from understanding how real people use your site. Combine automated scans with manual checks and real user feedback. Test early and often. It’s not about perfection — it’s about continuous improvement.

Frequently asked questions

What is the easiest way to start testing accessibility?

Run an automated tool like Google Lighthouse or axe DevTools on your most visited pages. It will flag common issues like missing alt text, low contrast, and empty links. Fix those first. Then move to keyboard testing and screen reader checks.

Do I need to test every page on my site?

Not every page, but you should test all unique templates and component types. For example, test a blog post, a product page, a form page, and your homepage. Also test pages with dynamic content like modals or dropdowns. This covers the majority of patterns.

Can automated accessibility testing replace manual testing?

No. Automated tools catch only 30-50% of WCAG issues. They miss context-dependent problems like logical heading order, keyboard trap detection, and screen reader pronunciation. Manual testing is essential for a complete audit.

How often should I run accessibility tests?

Run automated checks on every commit or pull request. Do a manual keyboard and screen reader audit before each major release. Schedule a full user-testing session at least once per quarter or whenever you redesign a core page.

What should I do if I can’t afford professional accessibility testing?

Use free tools like axe, Lighthouse, and WAVE. Watch screen reader demos on YouTube. Ask a friend who uses assistive technology to test your site for 15 minutes. There are also free webinar checklists from organizations like WebAIM and the W3C.