Test Your Site for Accessibility Issues: A Developer’s Guide

Accessibility testing is often treated as a last-minute checkbox, but it shouldn’t be. If you’re building for the web, you’re building for everyone — including the 15% of the global population with some form of disability. Testing early and often saves you from costly redesigns later. This guide covers the practical methods you can use to test your site for accessibility issues, from automated scans to manual checks and real user feedback. You’ll walk away with a repeatable process that fits into your existing workflow.

Why You Need a Multi-Layered Testing Approach

Relying on a single tool to catch everything is a common mistake. Automated tools are fast and consistent, but they only detect around 30% of WCAG failures. The rest require human judgment — things like logical focus order, meaningful alt text, and whether a custom widget behaves as expected. A comprehensive test combines automated scans, manual inspections, and assistive technology testing.

Think of it like code linting. A linter catches syntax errors and obvious style violations, but it can’t tell you if your business logic is correct. Similarly, an accessibility checker flags missing alt attributes or low contrast, but it can’t tell you if the page makes sense when read aloud. Both layers are necessary.

Automated Testing: Your First Pass

Start with automated tools to catch the low-hanging fruit. They’re great for finding issues like missing form labels, insufficient color contrast, and improperly nested headings. Here are the tools you should know:

• axe DevTools — Browser extension that scans pages and gives clear, actionable results. Integrates with your browser’s developer tools.
• WAVE — Another browser extension that provides visual feedback directly on the page, highlighting issues with icons and color coding.
• Lighthouse — Built into Chrome DevTools. It runs an accessibility audit as part of its full report. Good for a quick check.
• Pa11y — A command-line tool you can integrate into your CI/CD pipeline. Great for running automated checks on every deploy.

Run these tools on every page template, not just the homepage. Forms, modals, and dynamic content areas often have unique issues. Log the results and fix the critical errors first — things that block users from completing a task.

One common pitfall with automated tools is false positives. A tool might flag a color contrast issue that’s actually fine for large text, or miss a contrast issue on a gradient background. Always verify flagged items manually. Also, automated tools can’t catch missing heading hierarchy if there are no headings at all — they can only report on what’s there. So use them as a starting point, not the final word.

Manual Keyboard Testing: Navigate Without a Mouse

Many users with motor disabilities rely solely on a keyboard. Unplug your mouse (or just put it aside) and try to navigate your entire site using only the Tab, Shift+Tab, Enter, and Arrow keys. Here’s what to check:

1. Focus visibility — Can you see a clear focus indicator (usually a blue outline) on every interactive element? Some sites hide it for design reasons — that’s a fail.
2. Logical tab order — Does focus move in a predictable order? It should follow the visual layout, left to right, top to bottom.
3. No keyboard traps — Can you tab into and out of all elements? A common trap is a modal that won’t let you tab back to the page behind it.
4. All functionality reachable — Can you activate every button, link, and form control with the keyboard? Dropdown menus that require hover often break here.

If you hit a roadblock, that’s a real accessibility issue. Fix it before moving on.

A specific thing to watch for is custom dropdowns or date pickers. Many UI libraries ship components that look good but are a nightmare to navigate with a keyboard. Test them thoroughly. Also, make sure that using Escape closes modals or menus, and that the focus returns to the element that triggered them. This is a common oversight.

Screen Reader Testing: Experience Your Site Audibly

Screen readers like NVDA (Windows, free) and VoiceOver (macOS, built-in) convert visual content to speech. Testing with one reveals semantic problems that automated tools miss. Here’s a quick checklist:

• Headings — Do they accurately describe the content? Use the heading list shortcut (NVDA+Insert+F6) to see the structure.
• Images — Are decorative images ignored (empty alt attribute) and informative images given meaningful alt text?
• Forms — Are all inputs associated with a label? Tab through a form to hear if labels are announced.
• Dynamic content — Do updates like error messages or new content get announced? Use ARIA live regions where needed.

Don’t worry about memorizing every shortcut. Just open a screen reader and navigate your site naturally. The pain points will be obvious.

One practical tip: when testing forms, intentionally submit with empty fields or invalid data. Listen to how the error messages are announced. Many sites visually show an error but don’t move focus to it, so the screen reader user never hears the message. Use aria-describedby or aria-live to ensure errors are read out. Also, test with a real email address to see if auto-fill suggestions interfere with navigation.

Color Contrast Checks: See the Difference

Low contrast is one of the most common (and frustrating) accessibility issues. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (above 18px bold or 24px regular). Non-text elements like icons and borders also need sufficient contrast. Use tools like the Color Contrast Ratios: A Practical Developer Guide to understand the math. You can also use the browser’s built-in contrast checker in Chrome DevTools or Firefox’s Accessibility Inspector. Run these checks on text against its background, link colors against surrounding text, and input borders against their background.

One tricky area is hover and focus states. A button might have sufficient contrast in its default state, but when hovered or focused, the color change might drop below the threshold. Test all interactive states. Also, remember that placeholder text has a lower requirement (3:1 for AA), but it’s still important for users who rely on it. If your placeholders are too light, consider darkening them.

Real User Testing: The Gold Standard

No amount of automated or manual testing replaces feedback from real people with disabilities. Recruit users who rely on assistive technologies and watch them use your site. Their observations will surface issues you never thought of, like a confusing error message or a poorly labeled button. If you don’t have access to a user panel, consider services like Fable or UserZoom that connect you with testers. Even a single session can uncover showstopper bugs.

When conducting a session, avoid leading questions. Instead of asking “Did you find the search button?”, ask “Can you try to find a way to search for something?” You want to observe their natural behavior. Record the session (with permission) so you can review pain points later. After the test, prioritize the issues they encountered. Often, one user’s struggle represents a dozen others who just left your site.

Integrating Accessibility Testing Into Your Workflow

Testing once isn’t enough. Accessibility should be part of your development process from start to finish. Here’s how to bake it in:

Stage	Action
Design	Review mockups for color contrast and focus indicators.
Development	Run automated checks on every commit via CI.
QA	Include keyboard and screen reader tests in your test plan.
Deployment	Perform a final full audit before launch.

This doesn’t mean you need to be perfect on day one. But every fix you make now saves a user from frustration later. Start with the automated tools, then layer in manual checks. Before long, testing becomes second nature.

Common Pitfalls and How to Avoid Them

Even with a solid process, some issues slip through. Here are a few you should watch for:

• Overusing ARIA — Adding ARIA attributes carelessly can create more problems than it solves. Follow the first rule of ARIA: don’t use it if native HTML works. For example, use instead of
  .
• Inconsistent focus management — When a modal opens, focus should move to the modal. When it closes, focus should return to the triggering element. Forgetting this creates a lost user.
• Missing landmarks — Screen reader users jump between regions using landmarks like , , . If your page lacks them, navigation becomes tedious.
• Language attribute — Always set lang on the element. Screen readers use it to choose pronunciation rules. A missing or wrong value leads to garbled speech.

To catch these, add a quick landmark check to your screen reader testing. Most screen readers have a shortcut to list landmarks (Shift+D in NVDA). Verify that all major sections are represented and labeled correctly.

Building a Repeatable Testing Routine

Consistency matters more than depth on any given day. Aim to run a quick automated scan on every feature branch, and schedule a full manual test (keyboard + screen reader) before each release. If you're on a agile team, include accessibility testing in the definition of done for each ticket. That way it's never an afterthought.

Consider creating a checklist that covers the most common failures. Print it out or keep it in your team's documentation. Over time, the checks become muscle memory. And when you do find an issue, fix the root cause rather than patching the symptom. For example, if you discover a missing heading, update your component's template, not just the current page.

For a deeper dive, check out our guide on How to Test Your Site for Accessibility Issues — yes, that's this one. But seriously, bookmark it as a reference. And if you're new to color contrast, the Color Contrast Ratios post will fill in the details.

Frequently asked questions

What is the best automated accessibility testing tool?

There is no single best tool because each has strengths. Axe DevTools is widely used for its high accuracy and clear explanations. WAVE provides excellent visual feedback on the page itself. For CI/CD pipelines, Pa11y is a good choice. Use a combination for the best coverage.

How often should I test my site for accessibility?

Test at every stage of development: during design review, on every commit with automated checks, and before each release with a full manual audit. Accessibility is not a one-time fix; new content and features can introduce issues.

Does my site need to be WCAG 2.1 AA compliant?

WCAG 2.1 AA is the standard recommended for most websites and is often required by law in many jurisdictions (e.g., Section 508 in the US and EN 301 549 in the EU). It provides a good balance of accessibility without excessive burden.

Can accessibility testing be fully automated?

No, automated tools can only detect about 30% of potential issues. Manual testing, especially with screen readers and keyboard navigation, is essential to catch semantic and usability problems that machines cannot evaluate.

What is the first thing I should test for accessibility?

Start with keyboard navigation. Unplug your mouse and try to complete all tasks using only the Tab, Enter, and arrow keys. This alone will reveal many critical issues like missing focus indicators and keyboard traps.