Accessibility Testing
axe-core is the open source accessibility testing engine behind most automated a11y tooling: axe DevTools browser extension, @axe-core/playwright, jest-axe, and commercial tools like Deque's axe DevTools Pro. Understanding how axe works — and how to configure it — determines whether your automated accessibility testing is actually
Accessibility Testing
Simple semantic HTML is enough for most UI elements — buttons, links, forms, headings. But complex interactive patterns like modals, tabs, accordions, and disclosure menus don't have native HTML equivalents. These require ARIA roles and attributes to communicate structure and state to assistive technology. The ARIA Authoring Practices Guide
Accessibility Testing
Most teams integrate @axe-core/playwright and call it done. You get a scan, you fix the violations, you ship. But axe-core catches maybe 30–40% of real accessibility issues. The rest — focus management failures, broken ARIA live regions, keyboard traps, flawed reading order — require behavioral testing that axe
Accessibility Testing
Pa11y CI is a command-line accessibility testing tool built for CI pipelines. Unlike browser-extension audits, it runs headlessly, accepts a list of URLs, and exits with a non-zero code when violations exceed your threshold. That makes it a straightforward gate in any pipeline. This guide covers production-
Accessibility Testing
Deque Attest (formerly WorldSpace Attest) is Deque's enterprise accessibility platform. It sits above axe DevTools and axe-core in Deque's product stack, targeting organizations that need coordinated testing across dozens of apps, centralized reporting, and issue tracking integrated into existing workflows. This post covers where Attest
Accessibility Testing
Axe-core tells you whether your ARIA attributes are structurally correct. A screen reader tells you whether those attributes produce coherent output. These are different questions. A button can have aria-label="Submit form" and pass every automated check while a real screen reader announces it as "
Accessibility Testing
Color contrast and keyboard navigation are two of the most commonly failed WCAG criteria. Color contrast (SC 1.4.3) requires a 4.5:1 ratio for normal text and 3:1 for large text. Keyboard accessibility (SC 2.1.1) requires all functionality to be operable from a keyboard.