How to Test Your Site for Accessibility

Accessibility testing is where good intentions meet reality. You can make all the right design decisions and still ship a site that a keyboard user cannot navigate or a screen-reader user cannot understand. Testing is the verification layer. It requires a deliberate workflow, not a one-time scan.

The goal here is a repeatable process: automated tools to catch the obvious failures fast, manual keyboard and screen-reader passes for the things machines miss, a structured WCAG audit to set the baseline, and CI integration so regressions never reach production quietly.

Why automated tools are the floor, not the ceiling

The first instinct is to run a tool and call it done. Tools like axe, Lighthouse, WAVE, and IBM Equal Access Checker are genuinely useful: they catch missing alt text, insufficient color contrast, unlabeled form fields, and missing landmark regions in seconds. Run them. Run them early, run them often.

But automated tools reliably catch only around 30–40% of real WCAG failures. They cannot tell you that your focus order skips a section, that your custom modal traps keyboard users, that your carousel announces no useful context to a screen reader, or that your “click here” links are meaningless when heard out of order. Those failures require a human.

Automated testing is triage. It removes the low-hanging fruit so your manual pass can focus on the failures that actually break the experience.

Treat your automated suite as a fast feedback loop, not a pass/fail certificate. A clean axe report is a good start. It is not a green light.

Setting up an automated baseline

Run axe or a comparable tool at the page level, not just the component level. Component-level checks in Storybook or a unit test suite catch isolated issues but miss interaction between components, as on a page where every element is individually accessible but the reading order is broken.

For a quick start, the axe DevTools browser extension gives you a no-config scan on any live page. For integration into a build pipeline, @axe-core/playwright or jest-axe let you assert zero violations on rendered pages as part of your test suite.

Set a WCAG conformance target upfront. WCAG 2.1 AA is the current practical standard: it is what most legal frameworks reference and what most assistive technology users expect. WCAG 2.2 adds a handful of new criteria (focus appearance, accessible authentication, dragging alternatives) worth adopting now if you are building anything new.

The keyboard pass

Keyboard accessibility testing requires no software beyond a browser. Unplug the mouse, put it in a drawer, and try to accomplish every task on the page using only Tab, Shift+Tab, Enter, Space, and the arrow keys.

The questions to answer:

• Can you reach every interactive element? Links, buttons, form fields, custom controls, modals, dropdowns.
• Is the focus indicator visible? The default browser outline is often suppressed. If you can’t see where focus is, you can’t navigate.
• Does focus order match visual order? Reading a page top-to-bottom but tabbing in a scrambled sequence is disorienting.
• Do modals and dialogs trap focus correctly? When a modal opens, focus should move into it and stay there until the user dismisses it. Focus should then return to the element that triggered the modal.
• Does every keyboard trap have an escape? Custom components that intercept arrow keys (carousels, date pickers, multi-select dropdowns) need a clear keyboard exit.

Pay particular attention to custom interactive components. A <button> works with keyboard out of the box. A <div> styled to look like a button does not. If your codebase uses custom elements for interactive controls, every one of them needs a keyboard pass.

Focus management after dynamic events

Single-page app transitions and dynamic content updates introduce a category of failure that static sites rarely see. When content updates without a page load, whether a filter changes results, a form submits and shows confirmation, or a step wizard advances, keyboard and screen-reader users need focus managed deliberately.

After a dynamic update, move focus to the new content or to a meaningful status announcement. If you do neither, the user has no indication anything changed. This is one of the most common accessibility failures in modern JavaScript-heavy apps, and no automated tool will reliably catch it.

Screen-reader testing

Screen-reader testing is the most time-consuming part of accessibility testing, and it is the part most teams skip. That is also where the most severe failures hide.

The major screen readers to test with:

• NVDA + Firefox or JAWS + Chrome on Windows, covering the majority of assistive technology users.
• VoiceOver + Safari on macOS and iOS, essential for Apple device audiences.
• TalkBack on Android, for mobile coverage.

You do not need to master each tool to do useful testing. The basic workflow: turn on the screen reader, close your eyes, and try to understand and use the page from what you hear alone.

Things to verify:

• Page title is meaningful and unique.
• Heading structure creates a logical outline. Screen-reader users navigate by headings. An H1 followed by H3s with no H2 is disorienting.
• Images have alt text that conveys meaning, not just describes appearance. Decorative images have empty alt (alt="").
• Form labels are programmatically associated with their inputs, not just visually adjacent.
• Error messages are announced. A red border on an invalid field is invisible to a screen reader.
• Live regions announce dynamic updates. Status messages, validation feedback, and loading states need ARIA live regions to be heard.
• Custom widgets implement the correct ARIA roles, states, and properties per the ARIA Authoring Practices Guide.

The combination of keyboard + screen reader testing will surface 80–90% of real-world accessibility failures. The automated scan handles the rest.

Conducting a WCAG audit

A WCAG audit is a structured evaluation against specific success criteria. Unlike an ad-hoc test, it is methodical, documented, and produces a gap analysis you can act on.

The WCAG 2.1 AA criteria fall under four principles: Perceivable, Operable, Understandable, Robust (POUR). An audit works through each applicable criterion and records a pass, fail, or not-applicable verdict with evidence.

Practical steps for a self-audit:

1. Define scope. Audit representative pages: homepage, a key landing page, the primary conversion flow, a form, a page with dynamic content. You cannot audit every page, so cover the patterns.
2. Use the W3C’s WCAG-EM methodology as a framework. It standardizes how you sample pages and record findings.
3. Document failures with enough context to fix them. A finding that says “color contrast fails” is less useful than “the body text at 14px on the card component (#6B7280 on #FFFFFF) returns a ratio of 4.4:1, below the 4.5:1 minimum for normal text at AA.”
4. Prioritize by impact. A missing heading level is a navigation inconvenience. A form with no accessible error handling may make the primary conversion path unusable. Fix the unusable things first.

An audit is a point-in-time snapshot. Pair it with ongoing automated testing so failures surface before the next formal review.

Wiring accessibility into CI

An audit done once and forgotten is worth little. The leverage is in preventing regressions. Wiring accessibility checks into your CI pipeline means every pull request is tested before it merges.

A practical CI accessibility stack:

• axe-core via Playwright or Cypress: run page-level scans against your critical paths on every CI run. Assert zero violations at the WCAG AA level. Fail the build on violation.
• Storybook + axe: the @storybook/addon-a11y panel adds an axe scan to every story. Developers see violations at the component level before integration.
• Contrast linting: tools like eslint-plugin-jsx-a11y catch common JSX/React accessibility issues at the linting stage, before code even runs.

The goal is to push accessibility feedback as early as possible in the development loop. A failure caught by a linter in a developer’s editor costs minutes to fix. The same failure caught in a post-launch audit costs days.

One caveat: CI automation still only catches the automatable third. It supplements manual testing; it does not replace it. Build a cadence: a keyboard pass before every significant release, a screen-reader pass when adding new interactive patterns, a formal audit annually or after major redesigns.

Where this fits in the broader build process

Accessibility testing is the testing counterpart to accessibility as a design decision. The design phase is where you establish the right contrast ratios, semantic structure, focus behavior, and motion choices. The testing phase is where you confirm those decisions were implemented correctly and haven’t been eroded by later changes.

This relationship matters for how you scope work. On a project where accessibility is designed in from the start, with thoughtful semantics, keyboard-first interaction patterns, and deliberate ARIA use, the testing workflow is confirmatory. On a project where accessibility was retrofitted, testing becomes a repair audit. The former is faster and produces better outcomes.

If your site is also pursuing strong performance (accessibility correlates strongly with it, since both reward clean semantics and lean markup), the Core Web Vitals guide covers the performance testing counterpart to this workflow. For teams building with Astro, its static HTML default means semantic structure is server-rendered and visible to assistive technology without JavaScript execution, a meaningful advantage for the sites we build with Astro from the start.

How Strynal approaches accessibility testing

At Strynal, accessibility testing is not a phase at the end of a project. On every web and app build, automated axe scans are part of the CI pipeline from day one. Keyboard and screen-reader passes happen before any launch, and we conduct a WCAG 2.1 AA gap analysis as part of the final quality review.

Clients don’t receive a site and then discover it needs remediation. They receive a site already tested against the patterns their users rely on.

If you’re building something new or auditing what exists, we’re glad to help scope the work. Get in touch and we’ll talk through what a testing engagement looks like for your specific build.