New Release! AccessKit v0.2.0

Coverage

The next release of `@access-kit/react` is the biggest update since launch. What started as a wrapper around axe-core now has its own detection engine, three dedicated DevTools panels, visual bounding-box overlays, and coverage for WCAG 2.2 success criteria that no mainstream automated tool catches today.

Here's everything coming in v0.2.0.

A Rule Engine That Goes Beyond axe-core

axe-core is the gold standard for automated accessibility testing, and AccessKit still runs it under the hood. But axe has well-documented blind spots; meaningless alt text it can't flag, focus indicators it can't evaluate, authentication flows it can't inspect.

This release introduces a custom rule engine that runs alongside axe-core as a third audit phase. After the DOM scan and contrast sweep, AccessKit now executes its own detection rules and surfaces findings with a distinct AccessKit badge so you know exactly where the detection came from.

The engine ships with 30 custom rules across 10 rule modules, covering gaps in text alternatives, adaptable content, distinguishable UI, navigation, input assistance, keyboard accessibility, focus management, media, status messages, authentication, and input modalities. Every rule maps to a specific WCAG success criterion and includes a direct reference link.

A few highlights of what AccessKit now catches that axe-core doesn't:

• Meaningless alt text like alt="image", alt="photo1.jpg", or filename extensions
• Functional images with visual-only alt: an image inside a button described as "magnifying glass icon" instead of "Search"
• Canvas elements without fallback content or accessible names
• Missing autocomplete on personal data fields** (email, phone, name, address)
• Password fields that block paste, preventing password manager usage
• Login forms missing autocomplete attributes for credential autofill
• CAPTCHA elements on auth pages imposing cognitive function tests
• Draggable elements without single-pointer alternatives; sortable lists and kanban boards with no move buttons
• Multi-step forms without data persistence: shipping/billing flows without "same as" options
• Bare <div> click handlers with no role or accessible name
• aria-expanded mismatches: toggles that say they're collapsed when the panel is open
  

The engine detects React onClick handlers through internal __reactProps$ properties, so it works in React, Next.js, and Gatsby applications without any special configuration.

Tabbed DevTools: Issues, Keyboard, and Media

The DevTools panel has been completely restructured. What was a single 1,100-line monolithic component is now a clean tabbed architecture with three dedicated panels, each owning its domain exclusively; no duplicated findings across tabs.

Issues Tab

The Issues tab is the primary audit surface. It shows all WCAG findings from both axe-core and AccessKit's custom rules, with filters for severity, category, and WCAG level. Keyboard-specific and media-specific findings are routed to their respective tabs, keeping the Issues panel focused on structural, semantic, and content violations.

Keyboard Tab

The new Keyboard tab gives you an interactive view of your page's keyboard accessibility:

• Focusable element inventory: every keyboard-reachable element on the page, with its selector, role, tabindex, and focus visibility status
• Interactive focus walker: step through elements in tab order one by one, with a scroll-tracking highlight overlay that follows the focused element
• Focus visibility detection: scans stylesheets and inline styles for suppressed focus indicators (outline: none, outline: 0, outline-color: transparent) and checks for alternatives like box-shadow, border, or background changes
• Keyboard trap detection: flags dialogs and modals without visible dismiss affordances
• Positive tabindex warnings: highlights tabindex > 0 values that disrupt natural focus order
• Focus obscured detection: identifies focusable elements hidden behind position: fixed or position: sticky overlays (cookie banners, sticky headers, chat widgets)

Media Tab

The Media tab inventories every <video>, <audio>, and media-embed <iframe> on the page, plus all ARIA live regions:

• Media inventory: caption status, track listings, controls presence, and autoplay flags for each media element
• Live region scanner: finds all aria-live, role="status", role="alert", role="log", role="timer", and role="progressbar" elements with their ARIA configuration
• Issue detection: aria-live="off" silencing updates, role="alert" with overridden politeness, assertive live regions on non-critical content, autoplay media without controls, and video/audio elements missing captions or transcripts
  

Every finding in both tabs includes a click-to-scroll action that jumps to the element on the page with a temporary highlight overlay.

Visual Bounding Box Overlays

When you hover over a finding in any DevTools tab, AccessKit now draws a bounding box overlay directly on the offending element in the page. This makes it immediately clear which element has the violation; no more hunting through the DOM inspector to match a CSS selector to a visual element.
The overlay tracks the element across scroll events and repositions in real time, so it stays accurate even on long pages with dynamic layouts.

WCAG 2.2 Coverage

WCAG 2.2 added 9 new success criteria (and removed one). Most automated tools only cover 2.5.8 Target Size through axe-core's built-in target-size rule. This release adds AccessKit detection for several more:

For Level AA conformance, the most common regulatory target, this means AccessKit now has detection for 5 of the 6 new criteria that AA requires. The remaining gap (3.2.6 Consistent Help) gets a checklist-style advisory since it requires multi-page structural analysis.

Focus Management Fixes

Two important fixes improve the keyboard experience of AccessKit's own components:

1. Removed focus trap from the floating widget. The accessibility widget previously trapped keyboard focus, meaning Tab and Shift+Tab cycled within the widget instead of letting users continue through the page. This was ironically an accessibility barrier in an accessibility tool. The widget now uses standard focus flow with onKeyDown triggers, so keyboard users can enter and exit freely.
2. Focus returns to the dropdown trigger after selection. In the DevTools panel, selecting an option from a dropdown previously left focus in an ambiguous state. Focus now returns to the trigger element after a selection, following the ARIA combobox pattern.
   

OWASP-Aligned Regex Hardening

The custom detection rules rely on regex patterns to identify phone numbers, chat widgets, authentication fields, and shipping/billing inputs. This release tightens those patterns following OWASP validation guidance:

• Phone detection replaced an overly broad regex with a two-branch pattern: E.164 international format (+ prefix, 7-14 digits) and US/NANP format (mandatory separators, word-bounded). This eliminates false positives on strings like "EN 301 549" and other specification numbers.
• Chat widget detection replaced a greedy .* with [^"]* to prevent potential ReDoS backtracking.
• Authentication and shipping/billing field detection added \b word boundaries to prevent substring matches (e.g., "reuser" matching "user", "worship" matching "ship").

Developer Experience Improvements

A few more quality-of-life changes round out the release:

• Panel state resets on route changes in SPAs, so stale findings from a previous page don't persist
• Changesets integration for automated release tracking going forward
  

What's Next

We will continue to develop custom rules as needed to ensure that all possible bases are covered. The initial priority will be to continue testing the package across different scenarios/websites to identify potential bugs or improvements to address. Once we feel even more comfortable with where we stand, we will focus on finding further gaps not covered by the existing axe-core and custom rulesets, as well as finding gaps for the additional tags such as best-practice.

We also have a major plan to start a video series, with short videos covering each accessibility issue’s description, how it generally looks in code, how AccessKit detects it, and how to resolve it. The goal is to have these short videos be a visual reference that’s easily accessible and straight to the point for the visual learners out there. These will be available here on the site and on the YouTube channel, which will be created soon.

Upgrade

npm install @access-kit/react@latest

The new tabs, custom rules, and bouding box overlays activate automatically; no configuration needed.

One breaking change to note: the AccessKitWcagLevel type has been renamed to AccessKitWCAGLevel (uppercase “WCAG”). If you’re importing this type, update the casing.

New exports include registerRules, getRegisteredRules, and the types AccessKitRule, AccessKitRuleFinding, AccessKitFindingSource, and AuditScanPhase for consumers who want to register their own custom detection rules.

The public API is unchanged. AccessKitDevToolsProps and all existing exports remain the same. The new tabs, custom rules, and bounding box overlays activate automatically.

If you're using AccessKit for the first time, check out the [documentation](https://xskit.dev/docs) to get started.