Accessible components: what WCAG asks of a component library

In WebAIM's February 2026 scan of the top million home pages, pages that used ARIA averaged 59.1 detected accessibility errors, against 42 on pages without it. ARIA isn't the villain. Components that announce a role without the keyboard behavior that role promises are.

An accessible component is one that people can perceive, operate by keyboard and pointer, and understand through assistive technology, in every state it can render. For a component library, that means each component meets the WCAG Level A and AA success criteria that apply to it, so product teams inherit accessibility instead of re-earning it on every screen.

What does WCAG require of a component library?

WCAG conformance is claimed for full pages, not for a button in isolation. A library can't make a product conformant, but it decides whether conformance is cheap or expensive, because most criteria are met or failed inside components:

• 1.1.1 Non-text Content: icon buttons need an accessible name.
• 1.3.1 Info and Relationships: labels, groups, and table headers exist in code, not only visually.
• 1.4.3 and 1.4.11 Contrast: 4.5:1 for text, 3:1 for component boundaries and focus indicators.
• 2.1.1 Keyboard and 2.4.7 Focus Visible: everything works without a mouse, and you can see where you are.
• 4.1.2 Name, Role, Value: a custom switch reports that it is a switch and whether it is on.

What changed in WCAG 2.2?

WCAG 2.2 became a W3C Recommendation on 5 October 2023, with an updated edition dated 12 December 2024. It adds nine criteria and removes 4.1.1 Parsing as obsolete.

Four land squarely on a component library: focus not obscured, dragging, target size, and authentication inputs.

Keyboard and focus: follow the APG patterns

The WAI-ARIA Authoring Practices Guide (APG) makes keyboard behavior specific across 30 patterns, from combobox to tree view. Two examples:

1. Modal dialog. Focus moves inside when it opens. Tab and Shift+Tab cycle within it. Escape closes it. Focus returns to the element that opened it. The container has role="dialog", aria-modal="true", and a name.
2. Tabs. Tab moves focus into the tab list, landing on the active tab. Arrow keys move between tabs. Tab again moves to the panel. Each tab has aria-selected and aria-controls.

The APG's own warning is blunt: "No ARIA is better than Bad ARIA." ARIA roles don't make browsers supply keyboard behavior, so <div role="button"> announces as a button and ignores Enter until you write that code. WebAIM's 2026 report found that 22% of ARIA menus on home pages introduced barriers through incomplete markup and interactions.

A role is a promise, and the keyboard code is how you keep it.

Native elements first, primitives second, hand-rolled ARIA last. A role is a promise, and the keyboard code is how you keep it.

Target sizes and contrast

WCAG 2.2's success criterion 2.5.8 sets a 24 by 24 CSS pixel minimum for pointer targets at Level AA. Smaller targets can pass through spacing, an equivalent control, inline text, or browser-set sizing. The older 2.5.5 asks for 44 by 44 at AAA.

For a library, that means a 24-pixel floor on icon buttons, checkboxes, and close buttons, using padding to enlarge the hit area.

Low-contrast text was the most commonly detected failure in WebAIM's 2026 scan, found on 83.9% of home pages. Components own much of it: placeholder text, pale secondary text, and input borders under 3:1.

How do you test accessible components?

Automation first, then people. Deque's 2021 study of over 2,000 audits and 13,000 pages found its axe tools caught 57% of issues by volume. Run axe on every story in CI, so a contrast or missing-name regression fails the build.

The remaining issues need manual passes, per component, per state:

• Keyboard only. Reach, operate, and leave every control without a mouse.
• Screen reader. Check name, role, and state in one desktop and one mobile reader; the APG calls this testing essential.
• Reflow. At 320 CSS pixels wide, content reflows without two-way scrolling.
• Obscured focus. Tab through a page with a sticky header and an open toast.

The per-component accessibility checklist

The legal picture as of October 2026

The European Accessibility Act entered into application on 28 June 2025, covering e-commerce, banking, e-books, computers, and more. In the US, the Department of Justice's Title II rule names WCAG 2.1 Level AA for state and local government web content; an interim final rule published 20 April 2026 moved compliance to 26 April 2027 for larger entities and 26 April 2028 for smaller ones. Meanwhile the W3C recommends WCAG 2.2 as the conformance target for new work.

Where Pegasus fits

Pegasus is built to WCAG 2.1 AA, with keyboard paths, focus states, and contrast documented per component, so each of the 1,540 Figma components and its React counterpart carry the same expectations. The React components are built on Base UI primitives, whose documentation says they follow the WAI-ARIA authoring practices for keyboard support and focus management, and on shadcn/ui and Tailwind CSS.

Storybook ships with stories and tests for the components, a natural home for automated checks and manual passes. Pegasus doesn't claim WCAG 2.2 conformance. If 2.2 AA is your target, the checklist above shows the additions to verify on top: target size, focus not obscured, dragging alternatives, and authentication inputs. Labels and content remain yours, as they would with any library.

FAQ

Is WCAG 2.2 backward compatible with WCAG 2.1?

Yes. The W3C states that content conforming to WCAG 2.2 also conforms to WCAG 2.0 and 2.1. Version 2.2 adds nine success criteria and removes 4.1.1 Parsing as obsolete. Teams bound by a 2.1 policy can adopt 2.2, though the W3C notes they may still need to test and report 4.1.1.

Can a component library be WCAG compliant on its own?

Not formally. WCAG conformance applies to full pages, so product teams still control headings, labels, content, and structure. A library can ship components that meet the criteria they touch: keyboard operation, focus visibility, contrast, and name, role, and value. That turns conformance from a per-page project into using the components correctly.

What is the minimum target size in WCAG 2.2?

Success criterion 2.5.8 requires pointer targets of at least 24 by 24 CSS pixels at Level AA. Smaller targets pass with enough spacing, an equivalent full-size control, inline placement in text, or browser-set sizing. Criterion 2.5.5 asks for 44 by 44 at AAA.

Sources

• The WebAIM Million 2026, WebAIM (2026)
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C (2024)
• What's new in WCAG 2.2, W3C Web Accessibility Initiative
• ARIA Authoring Practices Guide: patterns and Read Me First, W3C WAI
• Accessibility, Base UI docs
• Automated testing study identifies 57 percent of digital accessibility issues, Deque (2021)
• The EU becomes more accessible for all, European Commission (2025)
• Fact sheet: new rule on the accessibility of web content and mobile apps, ADA.gov