5.1 Is each user interface component, if necessary, compatible with assistive technologies (excluding special cases)?

Test 1 (5.1)

The most comprehensive test is a rendering test using a screen reader. All the elements to be evaluated, if present, are rendered by the screen readers. Other tests with other assistive technologies may be necessary to ensure compatibility. Several more or less comprehensive evaluation methods are described below. Several methods are available for iOS, but only the test with VoiceOver enables all the elements required by the criterion to be evaluated. What's more, as with the web, there is no technical documentation to describe how it works and the expected implementations (for example, for modal windows or sliders). In the absence of such documentation, in order to evaluate this type of component as accurately as possible, it is still advisable to approach

• what is described in the ARIA specification for design patterns;
• the documentation from publishers of platforms dedicated to developers.

iOS with VoiceOver

1. Activate the screen reader.
2. Identify interactive components on the screen (e.g. button, link).
3. Access each interactive component using the screen reader gestures.
4. Check that
   • a role is rendered (e.g. button, edit zone, link);
   • the role rendered is relevant to the associated functionality (for example, a component that triggers the opening of a modal window and is rendered as a "edit zone" has an irrelevant role; it should be identified as a button);
   • a name is rendered and that this name is relevant, i.e. that it enables the function of the element to be understood (for form fields, please refer to the "Forms" theme for an assessment);
   • if the component has a visible name (a visible text), the text is rendered;
   • if the component has a perceptible state (activated, deactivated, selected), this state is rendered;
   • if the component can change state (e.g. toggle button, slider), perform the necessary actions to test the different states and check that each change of state is correctly rendered (switching to the selected state, increasing the slider);
   • if the component has a perceptible value (value of a slider), this value is rendered.
5. If this is the case, the criterion is validated.

iOS With Accessibility Inspector

1. Connect the iOS mobile device to the computer running macOS.
2. Activate the Accessibility Inspector software.
3. Choose the mobile device as the source and stay on the "Inspection" tab (buttons at top right).
4. Use the arrows in Accessibility Inspector to access each element of the interface.
5. Check that
   • a role is available in the "Traits" parameter (for example, Button, Tab, Text Field);
   • the role is relevant to the associated functionality (for example, a component which triggers the opening of a modal window and which is presented as Static text has an irrelevant role; it should be identified as a button);
   • a name is available in the "Label" parameter and that this name is relevant, i.e. that it allows the function of the element to be understood (for form fields, please refer to the "Forms" theme for an assessment);
   • if the component has a visible name (a visible text), the label defined in the "Label" parameter contains at least this label.
6. If the component has a perceptible state (activated, deactivated, selected), check that this state
   • is available in the "Traits" parameter;
   • or is indicated in the "Label" parameter.
7. If the component can change state (e.g. toggle button, slider), perform the necessary actions to test the different states and check that each change of state (switching to the selected state, increasing the slider)
   • is available in the "Traits" parameter;
   • or is indicated in the "Label" parameter.
8. If this is the case, the criterion is validated.

iOS With voice control

The voice control application allows users to navigate by voice. Criterion 5.1 in its entirety cannot be assessed with voice control, but one voice control feature (the display of labels) provides a quick overview of the status of interactive components. Voice control will enable us to detect the components that can be used by touch but are not interactive components detectable by assistive technologies, the presence of a label and its relevance, and the presence of the visible label in the accessible label.

1. Activate voice control: Settings > Accessibility > Voice control.
2. Display the accessible names of interactive components: from the voice control settings screen, go to the "Overlay" button and activate it, then choose "Element names".
3. From now on, when voice control is activated, grey tooltips will appear above interactive elements that have labels. Note that if the screen has a very large number of interactive controls, the labels will be displayed in successive groups (one group of labels disappears and another appears). What you need to know: only elements with interactive roles recognised by the Accessibility API will have a label. This will allow you to quickly identify which elements that can be used by touch are not recognised by the voice control and are therefore not interactive elements (which constitutes non-compliance). Procedure:
4. Identify all the interactive controls (that can be activated by touch) on the screen.
5. Activate the voice control and check that all the interactive controls identified have an associated label (grey tooltip).
6. If so, check that
   • the associated label is relevant;
   • and the visible name (if it has one) is included in this label.
7. If this is the case, the conditions regarding the relevance of the label and the presence of the visible name in the accessible name are met.

Android

1. Activate the screen reader.
2. Identify the interactive components on the screen (e.g. button, link).
3. Access each interactive component using the screen reader gestures.
4. Check that
   • a role is rendered (e.g. button, edit zone, link);
   • the role rendered is relevant to the associated functionality (for example, a component that triggers the opening of a modal window and is rendered as a "edit zone" has an irrelevant role; it should be identified as a button);
   • a name is rendered and that this name is relevant, i.e. that it allows the function of the element to be understood (for form fields, please refer to the "Forms" theme to evaluate them);
   • if the component has a visible name (a visible text), the label is rendered;
   • if the component has a perceptible state (activated, deactivated, selected), this state is rendered;
   • if the component can change state (e.g. toggle button, slider), perform the necessary actions to test the different states and check that each change of state is correctly rendered (switching to the selected state, increasing the slider);
   • that if the component has a perceptible value (value of a slider), this value is rendered.
5. If this is the case, the criterion is validated.