Accessibility in web applications is to make it available to as many people as possible, even if their abilities are limited. React fully supports building accessible websites, often by using standard HTML techniques. React Suite follows the WAI-ARIA 1.1 standard, and all components have appropriate attributes and keyboard interaction functions out of the box.
Use semantic markup in the component, or add the necessary semantic attribute
role to facilitate the provision of information for screen readers. For example layout components:
<Container> <Sidebar>...</Sidebar> <Container> <header>...</header> <content>...</content> <footer>...</footer> </Container> </Container>
Corresponding to the rendered HTML structure:
<section class="rs-container"> <header class="rs-header">...</header> <section class="rs-container"> <aside class="rs-sidebar">...</aside> <main class="rs-content">...</main> </section> <footer class="rs-footer">...</footer> </section>
Focus management and keyboard interactions
There are many functions that need to interact with users in web applications, which require components we provide to manage focus and keyboard interaction, such as:
- The Tab key can be used to switch the focus between Button,Input and other form components.
- When components such as Modal, Popover and Tooltip are in focus, the Enter key opens the pop-up window, and the ESC key closes the pop-up window.
- Use the ↓ ↑ → ← key to switch the focus on the component with option operation.
- Use the → ← key to expand and collapse the nodes of TreePicker and CheckTreePicker.
- When pickers is in the open state, press any character key, the search box will be focused.
Accessibility of non-semantic controls
There are many component functions beyond those available in standard HTML, such as Slider, Tree, InputPicker, Modal, etc. By using
roles, non-semantic element structures can be recognized as common UI functions.
Accessibility of form interaction
aria-* attribute in the form to make the form input components descriptive, which is convenient for screen readers to read the corresponding tags and descriptions of the components. For example: Automatically associate
aria-describedby through the
controlId property of Form.Group. When you try to submit the form, if there is a validation error, we will display an error message box under the form input component and include some ARIA properties. The following is the corresponding HTML structure:
<div role="alert" aria-relevant="all" class="rs-form-control-message">This field is required.</div>
role="alert"automatically turns the element it is applied to into a live region, so changes to it are read out.
allinstructs the screenreader to read out the contents of the error list when any changes are made to it.
- In order to let the screen reader skip the disabled component, the attribute
aria-disabled="true"is added to the component, such as disabling a Button.
- Many components have a selection operation. We will add the attribute
aria-selected="true"to the selected option. If the current option has sub-options, the attribute
aria-expandedwill be set to tell the screen reader whether the sub-option of the current option is Is unfolded. For example: Tree.
- Combo Box: https://www.w3.org/TR/wai-aria-practices/#combobox
The component has role
- The component has the
aria-expandedprop, the default value is
false, and the value is
truewhen the popup window is displayed.
- The popup of the component has a
- When an
idis set for a component, it will automatically generate an
idfor the popup, the value is
[id]-listbox, and it will also set
aria-controls=[id]-listboxand popup The id of the window is associated.