Accessibility Testing: Or How to Save Your Code a Trip to the Alt

Building accessible websites is no mean feat. The WebAIM Million survey found that home pages with ARIA present averaged 41% more detectable errors than those without. While ARIA is essential for complex apps, a growing suite of tools can help ensure you're using it correctly, catching issues, and streamlining the entire process without burning out your QA team.

Addressing ARIA and Its Quirks

TPGi's WAI-ARIA bookmarklet is a quick win. It scans your page, validates all elements, roles, and ARIA attributes, then opens a new tab with results. You'll see the total number of valid roles, any detected errors, and code snippets of where things broke.

One thing it doesn't test for explicitly is duplicate landmarks. Roles like banner or contentinfo should appear once per page. Adrian Roselli's CSS-based bookmarklet adds a red outline to any offending elements.

For dynamic content, the NerdeRegion Chrome extension logs all output from aria-live regions. Timestamped announcements and their source elements appear in a DevTools panel. This helps you determine whether a bug lies in your code or in a specific screen reader/browser combination, which often have inconsistent behaviors.

Automating Scans with Core Tools

Automated testing tools catch errors that aren't obvious in source code. The important caveat? They require manual testing for full context, but they offer a solid head start. Since many tools build on axe-core, choosing one often comes down to UI preference and result depth—running Lighthouse after a clean axe DevTools scan is likely redundant, as it uses only a partial set of axe rules.

Axe DevTools (available as a Chrome or Firefox extension) adds a DevTools panel for scanning a whole page or a section. Issues are sorted by severity with code snippets. Its Intelligent Guided Tests handle as much as possible before querying the tester, letting you catch more errors. Results are exportable for collaborative fix sessions.

Accessibility Insights also runs on axe-core but adds an inspector and works on Android, Windows, and web. Its Assessment feature combines automated, guided, and manual tests for full reporting.

WAVE by WebAIM loads a side panel on your page for a holistic view as you develop. Disabling styles helps you find errors in the DOM. Its heading and landmark feature validates document semantics. If you want to address conformance levels or severity, SiteImprove's free Chrome extension adds those filters, which helps weed out false positives.

Ready to automate this process in your CI? Adrián Bolonio's tutorial walks through configuring GitHub Actions to run axe, pa11y, Lighthouse, and unit tests on every pull request. The PR will crash and block merging until errors are resolved.

Contrasting Color Palettes

Last year, low contrast text errors appeared on 86.4% of homepages. Setting an accessible palette early on—before code locks everything in—is critical.

Are My Colors Accessible calculates contrast ratios for any two colors, laying out all conformance levels it meets based on font size and weight. HSL range sliders allow tweaks with automatic updates. Palette mode compares every color in a set against each other, and any adjustment updates a permalink for easy team sharing. Prefer a picker? Atul Varma's similar tool uses one.

Geenes builds full tint/shade ranges for each color group for a full-color system. It includes contrast ratios, mockup previews, and color blindness emulation. For button-specific issues—where you must weigh text with background, background with page, and focus outlines—use Stephanie Eckles's ButtonBuddy, which explains requirements plainly.

Even combos that meet contrast requirements for typical vision can fail for others. Who Can Use applies visual filters to emulate color blindness types and calculate approximated ratios. For context on an existing site, the Stark Chrome extension simulates that too. Anna Monus's writeup covers built-in Chrome tools.

If you're deep in code, Alex Clapperton's CLI tool outputs ratios and passing standards in the terminal. The BBC's JavaScript checker integrates directly into test suites or design systems. A11y Color Tokens automatically generates passable shades and tints from an input color, outputting CSS or SASS tokens. Chrome and Firefox also now show contrast info in their DevTools color selectors, and Stephanie Walter offers more options in her post.

Working with Assistive Technology Compatibility

Debugging for assistive tech means considering browser/technology combinations, not just your code. Keep a list of bug trackers handy to check if bugs are known. Support also varies: HTML5 Accessibility tracks default implementations of newer HTML features, while Accessibility Support benchmarks ARIA roles across popular reader/browser pairings.

A Focus on Keyboard Navigation

Complex apps need logical focus order, correct focus movement, and clear styles. This bookmarklet labels every focusable element to assess a logical flow. Firefox users have this since version 84 in the Accessibility Inspector. When something drags focus unexpectedly, Scott Vinkle's snippet highlights the focused element on blur/change. Swap in console.trace for console.log to determine exactly which function moves focus.

For visual consistency across focus states, Scott O'Hara's script cycles through every element programmatically, avoiding the tedious tab. Beware of positive tabindex values: they force browsers to jump to those elements first, which often creates more issues than it fixes. Paul J. Adam's bookmarklet highlights any element with a tabindex for review.

Laying Out vs. Rendering Order

Heavy CSS Grid or Flexbox ordering can break the visual and accessibility sequence. Adrian Roselli's reading order bookmarklet helps you pass the WCAG meaningful sequence guideline. Steve Faulkner's text spacing bookmarklet applies required settings to all text, checking your site against WCAG parameters without fixed heights that clip overflow. Jared Smith's bookmarklet turns your cursor into a 44×44 pixel box to visually test recommended target sizes.

Linters and Markup Validation

Instead of changing workflows, layer on linters. eslint-plugin-jsx-a11y adds JSX accessibility checks right in your text editor; Scott Vinkle's guide covers setup. Deque's axe Linter (a GitHub app or VS Code extension) checks React, Vue, HTML, and Markdown with zero configuration. It separates WCAG 2 from WCAG 2.1 rules for specific targets.

Bad markup perpetuates accessibility issues silently. The W3C HTML Validator catches structural errors, while Deque's bookmarklet version can reach localhost and authenticated pages. For CMS editing environments, sa11y presents non-technical warnings to content authors. And a11y.css is a stylesheet/bookmarklet highlighting markup risks with adjustable language and verbosity.

Writing for Everyone

Cognitive accessibility—aimed at a 7th–9th grade reading level (WCAG 3.1.5)—begins with content. The Hemingway Editor grades readability as you write, while Jackaroo's readability tool analyzes published URLs against three algorithms. Be aware the latter includes all page text, like navigation and footers, which can skew results.

Integrating Tests into Your Pipeline

Manual browser scanning isn't scalable. Writing custom tests helps you tap into knowledge that generic automated tools don't have. Marcy Sutton has a framework-agnostic guide spanning unit and integration testing. Where the tooling overlaps on axe-core, integration ease matters most. Ready-built libraries exist for common frameworks—cypress-axe and jest-axe are good examples.

Pa11y and its CI version provides flexible configuration. The actions feature passes an array of actions before testing, useful for pages that require authentication. In less formalized testing, Magica11y helps you detect user preferences like motion or dark mode so you can reproduce the exact environments consumers report issues from.

Automated Testing Isn't Enough

Industry estimates suggest that automated accessibility checks catch roughly 30% of all errors. That number isn't a failure of tooling so much as a reflection of how subjective and context-dependent accessibility can be. No tool can evaluate whether a keyboard focus order feels logical to a screen reader user, or whether color contrast is comfortable over a long reading session.

This is why tooling is best deployed as a first line of defense. When developers and designers run scans throughout the workflow—not just in a final QA pass—common issues like missing alt text, empty links, and low-contrast text get fixed in minutes rather than surviving to production. It shifts the burden off testers and disabled users, who currently end up doing the heavy lifting of reporting obvious errors that should have been caught long before.

For teams that want to expand their toolkit, both The A11y Project and Stark keep curated lists of tools for developers and end users. These resources are useful jumping-off points for discovering apps, browser extensions, and libraries that fit specific stacks or testing routines.

Further Reading

Smashing Editorial