Accessibility
Reakit strictly follows WAI-ARIA 1.1 standards and provides many of the widgets described in WAI-ARIA Authoring Practices 1.1, like Button, Dialog, Tab and others.
This means that DOM attributes like role and aria-* are added automatically.
#Accessibility warnings
When attributes can't be automatically inferred, Reakit will emit a warning to remind you to pass them. Like so:
⚠️ [reakit/Menu] You should provide either
aria-labeloraria-labelledbyprops. See https://www.w3.org/TR/wai-aria-practices-1.1/#wai-aria-roles-states-and-properties-13
#Focus management and keyboard interactions
Besides attributes, Reakit manages focus and keyboard interactions for components that need them. For example:
- Button should respond to Enter and Space keys even when it's not rendered as the native
<button>. - Focus should be trapped within the Modal Dialog when it's open.
- Pressing ↑ ↓ → ← should move focus between Tabs.
Reakit is built with composition in mind. Those components are built upon a few abstract components also provided by Reakit, for example:
- Tabbable implements all the interactions a component will need to be fully accessible when they aren't rendered as their respective native elements. This is used by Button, Checkbox, FormInput and Rover.
- Rover implements the roving tabindex method. This is used by Tab, MenuItem and other components that leverage this pattern.
Concrete components can also be composed to create other ones. Dialog, for example, is used by Popover underneath, which means it inherits all of Dialog features. Learn more about it in Composition.
Our goal is not only to be a library of accessible components, but also serve as a reference so others can build their own from scratch. So, feel free to dive into the code and discover more.