Accessibility

Every Chameleon component targets WCAG 2.2 AA, and works in Chromium, Firefox, and Safari. This page says what that covers, what is left to your app, where Chameleon still falls short, and how to tell us when it gets something wrong.

What every component does⁠

  • WCAG 2.2 AA is the target for every component: contrast, target size, focus appearance, and the rest.
  • Keyboard-complete. Every interactive control works without a mouse, and focus is always visible, in a focus ring that takes the theme's colors.
  • Standard patterns. Components follow the WAI-ARIA Authoring Practices for what they are, so a menu, a tab set or a slider behaves as screen-reader users expect.
  • Touch targets. Buttons, chips, checkboxes, radios, switches, sliders, dials, and list items keep a touch target of at least 48 by 48 pixels by default. touchTarget sets how far it reaches past the visible control.
  • Reduced motion. Animations follow the user's reduced-motion setting.
  • Forced colors. Components stay usable in Windows high-contrast mode, drawn in the system colors the user chose.
  • Right-to-left. Layout, icons, and keyboard direction follow the page's text direction.

Each component's Accessibility tab⁠

Every component page has an Accessibility tab, which lists what the component announces, which keys it answers to, and what you must supply, such as a label for an icon button. Read it before you ship a component for the first time.

How it's tested⁠

Every component is tested with keyboard and pointer, and for what it exposes to assistive technology, in Chromium, Firefox, and Safari. Automated axe-core checks cover the components in Chromium.

Automated checks catch a share of problems, not all of them. Components are also tested by hand with screen readers.

What your app is responsible for⁠

A component can only be as accessible as the page around it.

  • Name what has no visible label. An icon button, a dial, or a search field without a visible label needs an accessible name, set with aria-label.
  • Keep the heading outline. Choose heading levels for the document's structure and type styles for their look; Type theming explains why they're separate.
  • Check contrast after overriding colors. A generated theme pairs every color with text that clears contrast on it. A color you set by hand is outside that guarantee, so check it.
  • Announce what changes. When your app updates content the user didn't act on, tell assistive technology, for example with a live region or a toast.

Where Chameleon falls short⁠

Follow known gaps, and report new ones, in the issue tracker.

Conformance reports⁠

If your procurement process needs an Accessibility Conformance Report, talk to us.

Report a problem⁠

Accessibility is never finished. When we get something wrong, tell us: name the component, the browser, and the assistive technology, and say what you expected to happen.