RAAM 1: Criteria and tests

iOS and Android

1. Activate the screen reader.
2. Identify the decorative graphic elements on the screen (see glossary note on the particularities of rendering).
3. Check that
   • they cannot be reached with the screen reader;
   • their content is not being rendered from another element on the screen.
4. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Identify graphic element conveying informations on the screen (see glossary note on the particularities of rendering), for example an image or icon.
3. Check
   • that they can be reached with the screen reader;
   • or that the information they convey is rendered from another element on the screen.
4. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Identify the graphic element conveying informations on the screen (see glossary note on the particularities of rendering).
3. Check
   • that the alternative rendered by the screen reader is relevant;
   • or that the information rendered from another element on the screen is relevant.
4. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Identify the graphic elements used as CAPTCHAs on the screen (see glossary note on the particularities of rendering).
3. Check that the alternative rendered by the screen reader makes it possible to understand the function of the graphic element (e.g. "Secret code to enter", "Security code").
4. If this is the case, the criterion is validated.

iOS and Android

1. Identify the graphic elements used as CAPTCHAs on the screen (see glossary note on the particularities of rendering).
2. Check
   • the presence of a non-graphic alternative (sound or logical CAPTCHA);
   • or the presence of another solution for accessing the functionality secured by the CAPTCHA (sending an SMS code, sending a confirmation email, etc.).
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify the graphic elements conveying information on the screen that require a detailed description (see glossary note on the particularities of rendering). For example
   • graphic elements for which the alternative to be provided is too long (more than one sentence, for example) or requires structuring (headings, lists or tables);
   • graphic elements which combine several issues (information through colour, text graphic element, contrasts, etc.) such as graphs or maps.
2. Check for
   • the presence of a clearly identifiable detailed description adjacent to the graphic element;
   • or the presence of a function (a button, a link) providing access to a detailed description.
3. If not, activate the screen reader and navigate to the graphic element.
4. Check that the screen reader displays a detailed description.
5. If it does, the criterion is validated.

iOS and Android

1. Identify the graphic elements on the screen that have a detailed description.
2. Check that each detailed description is relevant. It should contain all the information required to understand the content of the graphic element.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify the graphic elements conveying information in the screen (see glossary note on the particularities of rendering)
   • Activate the screen reader, browse the content and identify whether the elements displayed as "graphic element" or "image" contain text conveying information.
2. Check
   • that there is a mechanism for replacing text graphic elements with text that can be modified according to the user's display preferences (size, colour, font, etc.);
   • or that styles and effects cannot be reproduced using styled text.
3. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Navigate to the graphic elements with legends.
3. Check that the legend for the graphic element is displayed when the focus reaches the graphic element (the graphic element and the legend are contained in a single element that can be reached by the screen reader).
4. If this is the case, the criterion is validated.

iOS

1. Activate the Differentiate without colour option (Settings > Accessibility > Text display and size > Differentiate without colour).
2. Identify on the screen words or sets of words, texts, graphic elements conveying information and time-based media whose colouring conveys information.
3. Check that there is another visual way of retrieving this information: the presence of an icon or a graphic effect of shape or position, a typographic effect, etc.
4. Using the screen reader, access the information provided by the colour.
5. Check that equivalent information is rendered by the screen reader (for example the "selected" status of a green button).
6. If this is the case, the criterion is validated.

Android

1. Identify on the screen words or sets of words, texts, graphic elements conveying information and time-based media whose colouring conveys information.
2. Check that there is another visual way of retrieving this information: the presence of an icon or a graphic effect of shape or position, a typographic effect, etc.
3. Using the screen reader, access the information provided by the colour.
4. Check that equivalent information is rendered by the screen reader (for example the "selected" status of a green button).
5. If this is the case, the criterion is validated.

iOS

1. Activate the Increase contrast option (Settings > Accessibility > Text display and size > Increase contrast) or if present in the application, activate the replacement mechanism enabling the application to be displayed with a sufficient contrast ratio.
2. Identify on the screen the texts, the texts contained in graphic elements and the texts embedded in videos that could cause contrast problems.
3. Activate the Colour Contrast Analyser software on the computer and capture the foreground and background colours on the mobile device either
   • by broadcasting the screen of the mobile device to the computer;
   • by taking screenshots of the elements to be evaluated (and importing them onto the computer).
4. Check:
   • for normal size text, that the contrast value is 4.5:1, at least;
   • for large text, that the contrast value is at least 3:1.
5. If this is the case, the criterion is validated.

Note: It is possible to use the Accessibility Inspector application available on macOS to carry out a quick evaluation of screen contrasts. The software has an "Audit" function which allows you to automatically test certain text and graphic elements on screens. This function does not detect all contrast faults, and additional tests following the methodology described above will be necessary.

Android

1. If it exists in the application, activate the replacement mechanism to display the application with a sufficient contrast ratio.
2. Identify on the screen the texts, the texts contained in graphic elements and the texts embedded in videos that could cause contrast problems.
3. Activate the Colour Contrast Analyser software on the computer and capture the foreground and background colours on the mobile device either
   • by broadcasting the screen of the mobile device to the computer;
   • by taking screenshots of the elements to be evaluated (and importing them onto the computer).
4. Check:
   • for normal size text, that the contrast value is 4.5:1, at least;
   • for large text, that the contrast value is at least 3:1.
5. If this is the case, the criterion is validated.

Note: It is possible to use the Accessibility Scanner application to carry out a quick evaluation of screen contrasts. The application does not detect all contrast defects, and additional tests following the methodology described above will be necessary.

iOS

1. Activate the Increase contrast option (Settings > Accessibility > Text display and size > Increase contrast) or, if present in the application, activate the replacement mechanism enabling graphic elements to be displayed with a sufficient contrast ratio.
2. Identify on the screen the graphic elements conveying information and for each
   • Identify which colour(s) of the component are necessary to identify the location and/or the information conveyed (this could be the border, the colour of an icon, the background colour);
   • Identify the adjacent colours that have an impact on the visibility of the component colour(s).
3. Identify on the screen the interactive components that may have several states (hovered, focused, activated, checked) and for each
   • Identify which colour(s) of the component are necessary to identify the location and/or the information conveyed and the state (this could be the border, the colour of an icon, the background colour) for each of the states;
   • Identify the adjacent colours that have an impact on the visibility of the component's colour(s).
4. Activate the Colour Contrast Analyser software on the computer and capture the foreground and background colours on the mobile device either
   • by broadcasting the screen of the mobile device to the computer;
   • by taking screenshots of the elements to be evaluated (and importing them onto the computer).
5. Check that the contrast ratio between the colours identified is at least 3:1.
6. If this is the case, the criterion is validated.

Note: It is possible to use the Accessibility Inspector application available on macOS to carry out a quick evaluation of screen contrasts. The software has an "Audit" function which allows you to automatically test certain text and graphic elements on screens. This function does not detect all contrast faults, and additional tests following the methodology described above will be necessary.

Android

1. If it exists in the application, activate the application's replacement mechanism to display graphic elements with a sufficient contrast ratio.
2. Identify on the screen the graphic element conveying informations and for each
   • Identify which colour(s) of the component are necessary to identify the location and/or the information conveyed (this could be the border, the colour of an icon, the background colour);
   • Identify the adjacent colours that have an impact on the visibility of the component colour(s).
3. Identify on the screen the interactive components that may have several states (hovered, focused, activated, checked) and for each
   • Identify which colour(s) of the component are necessary to identify the location and/or the information conveyed and the state (this could be the border, the colour of an icon, the background colour) for each of the states;
   • Identify the adjacent colours that have an impact on the visibility of the component's colour(s).
4. Activate the Colour Contrast Analyser software on the computer and capture the foreground and background colours on the mobile device
   • either by broadcasting the screen of the mobile device to the computer;
   • or by taking screenshots of the elements to be evaluated (and importing them onto the computer).
5. Check that the contrast ratio between the colours identified is at least 3:1.
6. If this is the case, the criterion is validated.

Note: It is possible to use the Accessibility Scanner application to carry out a rapid assessment of screen contrasts. The application does not detect all contrast defects, and additional tests following the methodology described above will be necessary.

iOS

1. Check that the Increase contrast option (Settings > Accessibility > Text display and size > Increase contrast) is deactivated.
2. Check for the presence of a replacement mechanism enabling the application to be displayed with a sufficient contrast ratio.
3. Check that it is not activated (i.e. the screen is displayed with the default contrast).
4. Activate the Colour Contrast Analyser software on the computer and capture the foreground and background colours on the mobile device
   • either by broadcasting the screen of the mobile device to the computer;
   • or by taking screenshots of the elements to be evaluated (and importing them onto the computer).
5. If the replacement mechanism is identified by text, capture the foreground and background colours and check
   • For normal size text, that the contrast value is at least 4.5:1;
   • For enlarged text, that the contrast value is at least 3:1.
6. If the replacement mechanism is identified by a non-text element only (an icon for example):
   1. Identify which colour(s) of the component are necessary to identify the location and/or information (this could be the border, the colour of an icon, the background colour);
   2. Identify adjacent colours that have an impact on the visibility of the colour;
   3. Check that the contrast ratio between the colours identified is at least 3:1.
7. If this is the case, the criterion is validated.

Android

1. Identify the presence of a replacement mechanism enabling the application to be displayed with a sufficient contrast ratio.
2. Check that it is not activated (i.e. the screen is displayed with the default contrast).
3. Activate the Colour Contrast Analyser software on the computer and capture the foreground and background colours on the mobile device
   • either by broadcasting the screen of the mobile device to the computer;
   • or by taking screenshots of the elements to be evaluated (and importing them onto the computer).
4. If the replacement mechanism is identified by text, capture the foreground and background colours and check
   • For normal size text, that the contrast value is at least 4.5:1;
   • For enlarged text, that the contrast value is at least 3:1.
5. If the replacement mechanism is identified by a non-text element only (an icon for example):
   1. Identify which colour(s) of the component are necessary to identify the location and/or information (this could be the border, the colour of an icon, the background colour);
   2. Identify adjacent colours that have an impact on the visibility of the colour;
   3. Check that the contrast ratio between the colours identified is at least 3:1.
6. If this is the case, the criterion is validated.

iOS and Android

1. Identify on the screen the audio-only time-based media that require text transcription.
2. Check for:
   • the presence of a transcript accessible via an adjacent component (a button or a link);
   • or the presence of a clearly identifiable adjacent transcript.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify on the screen text transcripts of audio-only time-based media.
2. Check that each text transcript is relevant (all important audio or visual information is present, including dialogue and embedded text).
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify on the screen video-only time-based media that require a text-based transcript.
2. Check for
   • the presence of an alternative audio-only version accessible via an adjacent component (a button or a link);
   • or the presence of an adjacent audio-only alternative version;
   • or the presence of an adjacent text transcript (a button or a link);
   • or the presence of a clearly identifiable adjacent text transcript;
   • or the presence of a synchronised audio description;
   • or the presence of an alternative version with a synchronised audio description accessible via an adjacent component (a button or a link).
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify on the screen video-only time-based media with an alternative (text transcript or audio-only version).
2. If the text transcript is present, check
   • that it is relevant (all important audio or visual information is present, including dialogue and embedded text).
3. If there is an audio description, check
   • that it is relevant (all the important visual information is present);
   • and that it is correctly synchronised (the audio description soundtrack coincides correctly with the video).
4. If there is an "audio only" version, check
   • that it is relevant (all important audio or visual information is present, including dialogue and embedded text).
5. If this is the case, the criterion is validated.

iOS and Android

1. Identify on the screen synchronised time-based media that require a text transcript.
2. Check for
   • the presence of a clearly identifiable adjacent text transcript;
   • or the presence of a transcript accessible via an adjacent component (a button or a link);
   • or the presence of a synchronised audio description;
   • or the presence of an alternative version with a synchronised audio description accessible via an adjacent component (a button or a link).
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify on the screen synchronised audio description or transcript (time-based media).
2. If an audio description is present, check
   • that it is relevant (all the important visual information is present);
   • and that it is correctly synchronised (the audio description soundtrack coincides correctly with the video).
3. If a text transcript is present, check
   • that it is relevant (all important audio or visual information is present, including dialogue and embedded text).
4. If this is the case, the criterion is validated.

iOS and Android

1. Identify on the screen synchronised time-based media that require captions (i.e. where the soundtrack provides information, such as a person's speech).
2. Check
   • that there are synchronised captions;
   • or that there is an alternative version with synchronised captions accessible via an adjacent component (a button or a link).
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify synchronised time-based media with captions on the screen.
2. Check that the captions are
   • relevant (all important audio information is present, including dialogue);
   • correctly synchronised. If there is no delay between the spoken word and the appearance of the captions, the captions are correctly synchronised. The reference standard specifies that captions should appear within 100 ms of the caption time stamp.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify pre-recorded video-only and synchronised time-based media on the screen that require audio description.
2. Check for:
   • the presence of a synchronised audio description;
   • or the presence of an alternative version with a synchronised audio description adjacent to or accessible via an adjacent component (a button or a link).
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify on the screen video-only or synchronised time-based media with audio description.
2. Check that the audio description is
   • relevant (all important visual information is present);
   • correctly synchronised
     • the sounds and words of the audio description do not overlap with those of the original soundtrack to cause perception and comprehension problems;
     • the information conveyed in the audio description is given at the same time as the equivalent visual information appears.
3. If this is the case, the criterion is met.

iOS and Android

1. Identify pre-recorded synchronised or audio only or video only time-based media on the screen.
2. Check that:
   • a text passage (a heading or paragraph, for example) that identifies the time-based media immediately precedes or follows it;
   • that the text passage is located outside the media content player.
3. If this is the case, the criterion is validated.

iOS and Android

1. When the screen loads, if a sound is triggered automatically, check
   • that the sound sequence lasts 3 seconds or less;
   • or that a component (a button, for example) on the element that triggered the sound, or on the screen, can be used to stop it;
   • or that the volume of the sequence can be controlled by the user, independently of the system volume control.
2. If this is the case, the criterion is validated.

iOS and Android

1. Identify pre-recorded time-based media on the screen.
2. Check that at least the following features are present:
   • a play function;
   • a pause or stop function;
   • if the media has a sound track, a function that enables the sound to be switched on and off;
3. If the media has audio description, check that there is a function that enables audio description to be switched on and off.
4. If the media has synchronised captions:
   • if the captions are embedded (open captions) as an image, check that they are displayed when the video is played;
   • otherwise, in the case of closed captions, check that there is a function that allows you to activate and deactivate these captions.
5. If this is the case, the criterion is validated.

iOS and Android

1. Identify pre-recorded time-based media with an alternative (synchronised captions or audio description) on the screen.
2. If captions are present, check that the functionality that enables captions to be activated and deactivated is presented at the same level as the other features (such as the playback functionality, for example), i.e. that it is not necessary to perform more actions to trigger captions than to trigger the other features. For example, if the play button can be activated from the interface by a simple tap gesture (without the need to activate a first component), the captions function should be available in the same way, with a simple tap gesture. If the captions function is available from a drop-down menu that needs to be activated (by a tap gesture, for example), it will not be considered to be at the same level because there will be an additional step to perform.
3. If audio description is present, check that the function that enables you to activate and deactivate audio description is presented at the same level as the other functions.
4. If this is the case, the criterion is validated.

Note: Although volume and playback controls may be physical components of the devices (volume buttons on a smartphone for example), it is not required that these devices have physical controls dedicated to activating captions and audio description or that these controls, if they exist, are located at the same level.

iOS and Android

1. Identify the functions used to transmit (e.g. send content to another device), convert or record time-based media.
2. Execute each function (transmit, convert and record).
3. For each of the media resulting from the function, check
   • whether the captions are still present;
   • whether the captions can be displayed;
   • whether the captions are correctly synchronised;
   • whether the key features of captions are preserved (for example, if in the original media the captions were coloured according to the speaker, this colouring must be retained in the media resulting from the functionality).
4. If this is the case, the criterion is validated.

iOS and Android

1. Identify the functions used to transmit (e.g. send content to another device), convert or record time-based media.
2. Execute each function (transmit, convert and record).
3. For each of the media resulting from the function, check
   • whether audio description is present;
   • whether audio description can be activated;
   • whether the audio description is correctly synchronised:
     • the sounds and words of the audio description do not overlap with those of the original soundtrack to cause perception and comprehension problems;
     • the information conveyed in the audio description is given at the same time as the equivalent visual information appears.
4. If this is the case, the criterion is met.

iOS

1. Identify pre-recorded time-based media with captions on the screen.
2. Modify the subtitle presentation settings from the platform:
   • Go to Settings > Accessibility > Subtitles and Captioning > Style;
   • Select Create a style to define a personalised and recognisable subtitle style.
   • Define one or more of the following parameters: subtitle size, colour, subtitle border style, background colour or background opacity (check that the Video Override parameter at the bottom of the screen is deactivated).
3. Check that the settings defined at platform level are applied to the captions.
4. If this is not the case, check the media for a function that allows you to modify the subtitle presentation settings.
5. Check that the parameters defined above are applied to the captions.
6. If this is the case, the criterion is validated.

Android

1. Identify pre-recorded time-based media with captions on the screen.
2. Modify the subtitle presentation settings from the platform:
   • Go to Settings > Accessibility > Caption preferences > Caption size and style;
   • Define one or more of the following parameters: text size, colour, caption border style, background colour or background opacity.
3. Check that the platform settings are applied to the captions.
4. If this is not the case, check the media for a function that allows you to modify the captions presentation parameters.
5. Check that the parameters defined above are applied to the captions.
6. If this is the case, the criterion is validated.

iOS

1. Identify pre-recorded synchronised time-based media with translation subtitles on the screen.
2. Check that the subtitles are in a standardised format (for example, .srt format).
3. If not, activate the screen reader and navigate to the media player.
4. Activate the rotor.
5. Scroll through the rotor settings and find the "Multimedia Description" option.
6. If so, scroll up and select the "Enunciation" option.
7. Activate the video subtitles and play the video.
8. Check that the subtitles displayed are rendered by the screen reader.
9. If this is not the case, check that there is an additional sound track in the media player, which would be the vocalised version of the subtitles.
10. Activate the additional audio track and check that the spoken subtitles correspond to the subtitles displayed.
11. If this is the case, the criterion is validated.

Note: If the "Multimedia description" option is not available in the rotor, move the focus of the screen reader to the video and use the rotor again. If the option still does not appear, the screen reader will not be able to render the subtitles and the criterion is not met.

Android

1. Identify pre-recorded synchronised time-based media with translation subtitles on the screen.
2. Check that the subtitles are in a standardised format (e.g. .srt).
3. If not, check that there is an additional sound track in the media player that is the vocalised version of the subtitles.
4. Activate the additional audio track and check that the spoken subtitles correspond to the subtitles displayed.
5. If this is the case, the criterion is validated.

iOS and Android

1. Identify complex data tables on the screen.
2. Activate the screen reader.
3. Check
   • that a summary is displayed when the screen reader reaches the table;
   • or that a summary is available before the table, in the form of text preceding the table.
4. If this is the case, the criterion is validated.

iOS and Android

1. Check that each summary (of table) is relevant, i.e. that it makes it possible to understand the nature of the data and the construction of the table.
2. If this is the case, the criterion is validated.

iOS and Android

1. Identify the data tables on the screen.
2. Activate the screen reader.
3. Check that a title is rendered when the screen reader reaches the table.
4. If so, the criterion is validated.

iOS and Android

1. Check that each data table title is relevant, i.e. that it identifies the nature of the data presented in the table.
2. If this is the case, the criterion is validated.

iOS and Android

1. Identify the data tables on the screen.
2. Activate the screen reader and browse the data cells.
3. Check that the headings are correctly rendered.
4. If so, the criterion is validated.

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 label (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:

1. Identify all the interactive controls (that can be activated by touch) on the screen.
2. Activate the voice control and check that all the interactive controls identified have an associated label (grey tooltip).
3. If so, check that
   • the associated label is relevant;
   • and the visible name (if it has one) is included in this label.
4. 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.

The aim here is to ensure that the component can be used by the screen reader, voice control, an external keyboard or any other external switch. The tests can be limited to a few pointing devices since the characteristics required (on interactive components) are similar.

It is nevertheless necessary to test at least with the screen reader and an external keyboard.

For the external keyboard, some settings are necessary for the device to be fully functional.

iOS and Android

1. Activate the screen reader.
2. Browse all the interactive components.
3. For each interactive component, check that
   • it can be reached with the screen reader;
   • it can be activated with the screen reader.
4. If this is the case a modifiable component (input field, tick box, slider), check that it can be modified with the screen reader.
5. Connect an external keyboard (and configure keyboard navigation).
6. Browse all the interactive components.
7. For each interactive component, check that
   • it can be reached using the keyboard keys;
   • it can be activated using the dedicated key on the keyboard.
8. If this is the case a modifiable component (input field, check box, slider), check that it can be modified using the keyboard keys.
9. If this is the case, the criterion is validated.

iOS and Android

1. Identify all events in the screen that initiate a change of context, for example
   • dynamic updating of form fields;
   • opening a new page when a list entry is selected;
   • updating an essential part of the screen without user action;
   • automatic launch of a video player when a playlist is selected;
   • focus manipulation that changes the user's current position on the screen.
2. Check that:
   • the user is warned by text of the type of change before it is triggered;
   • or the change of context is initiated by an explicit button or link.
3. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Perform the actions required for a status message to appear, for example:
   • filling in a form correctly and validating it to display a message indicating successful submission;
   • submitting a form with mandatory fields without input to display a message indicating the presence of errors;
   • accessing a screen that takes a certain amount of time to load, so that a progress message or a loading progress indicator is displayed.
3. Check that when the status appears, the screen reader renders the information and that this information is understandable.
4. If this is the case, the criterion is validated.

iOS and Android

1. Identify toggle controls on the screen (buttons with one or more states, e.g. checkboxes, radio buttons, switches).
2. Check that it is possible to determine the state of the control on the basis of its presentation in the interface (for example, a change in shape when the control goes from one state to another).
3. Activate the screen reader and navigate to the control.
4. Check that the state of the control is rendered by the screen reader without having to interact with the control.
5. If this is the case, the criterion is validated.

iOS

1. Go to Settings > Accessibility > VoiceOver > Speech and activate the "Detect languages" setting.
2. Activate the screen reader and browse through all the elements on the screen.
3. Check that the text is rendered in the main language of the screen.
4. If this is the case, the criterion is validated.

Android

1. Go to Settings > Accessibility > TalkBack > Settings > Text-to-Speech Settings (depending on the platform version, the path may be different):
   • Check that the "Preferred engine" setting is "Google Text-to-Speech";
   • Activate the text-to-speech settings (button to the right of "Preferred engine") and check that the "Language detection" setting is "Aggressive".
2. Activate the screen reader and browse through all the elements on the screen.
3. Check that the text is rendered in the main language of the screen.
4. If this is the case, the criterion is validated.

This criterion only checks elements that should not be interactive (text elements, tables for example).

iOS with VoiceOver

1. Activate the screen reader and browse all the elements on the screen.
2. Check that the role rendered by the screen reader corresponds to the nature of the element (for example, when the screen reader reaches what appears to be a paragraph and renders "Button", this is an error, no role is rendered for the paragraphs).
3. 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 the role available in the "Traits" parameter is relevant to the nature of the associated element (for example, simple text acting as a button would be considered non-compliant and should be identified as static text).
6. If this is the case, the criterion is validated.

Android

1. Activate the screen reader and browse all the elements on the screen.
2. Check that the role rendered by the screen reader corresponds to the nature of the element (for example, when the screen reader reaches what appears to be a paragraph and returns "Button", this is an error - no role is rendered for the paragraphs).
3. If this is the case, the criterion is validated.

iOS with VoiceOver

1. Activate the screen reader.
2. Use the rotor and select "Headings".
3. Browse through the headings by sliding your finger up or down.
4. Check that
   • each text structure on the screen can be reached;
   • each heading reached is relevant, i.e.
     • the heading is useful for structuring the screen;
     • the text contained in the heading makes it possible to understand the content of the section thus titled.
5. If this is the case, the criterion is validated.

iOS with Accessibility Inspector

1. Connect the iOS mobile device to the computer using 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
   • for each text that structures the screen, the "Traits" parameter contains the value "Headings";
   • that each text whose "Traits" parameter contains the value "Headings" is relevant, i.e.
     • the heading thus declared is useful for structuring the screen;
     • the text contained in the heading makes it possible to understand the content of the section thus titled.
6. If this is the case, the criterion is validated.

Android

1. Activate the screen reader.
2. Use the playback controls menu and select "Headings".
3. Browse through the headings by sliding your finger up or down.
4. Check that
   • each text structure on the screen is reached in this way and is rendered as a heading;
   • that each heading is relevant, i.e.
     • the heading is useful for structuring the screen;
     • that the text contained in the heading makes it possible to understand the content of the section thus titled.
5. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Find items on the screen in the form of lists.
3. Check that the screen reader renders "List" when it reaches the group of items.
4. If it does, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Scroll through all the items using the screen reader gestures.
3. Check that all the information visible on the screen is rendered by the screen reader.
4. If this is the case, the criterion is validated.

Note: In applications, items can be grouped together. For example, in a product catalogue, each item has a title, a price and a description. Instead of having the screen reader focus on each of the 3 items, the application can be designed so that the screen reader only accesses the item as a whole, so that the screen reader displays all the information without the user having to make several gestures to reach the 3 items. This is acceptable (and even encouraged, since it limits the number of actions required to browse the content), but care must be taken to ensure that all the text is rendered by the screen reader.

iOS

1. Access the font size settings for the platform: Settings > Accessibility > Display and text size > Larger text.
2. Activate the "Larger accessibility sizes" button and increase the value of the font size (slider at the bottom of the screen) until a magnification of 200% is reached (the maximum of the gauge allows a zoom greater than 200%, so the test can be limited to increasing the zoom using the penultimate position of the slider).
3. If necessary, restart the application to ensure that the parameter is taken into account by the application.
4. Check that
   • all the texts in the interface have been enlarged;
   • all the text in the interface remains legible and the functions usable;
   • content has not disappeared;
   • if any text has disappeared, that there is a method on the screen for displaying the text on demand (for example, by holding down an icon).
5. If this is the case, the criterion is validated.

Android

1. Access the font size settings for the platform: Settings > Accessibility > Font size (depending on the version of the platform, the access path may be different);
2. Increase the value of the font size (slider at the bottom of the screen) until you reach a magnification of 200% (on some devices, the slider gauge may be different and offer values that allow you to achieve a zoom greater than 200%, so check that the test is only carried out for a value of 200%).
3. If necessary, restart the application to ensure that the parameter is taken into account by the application.
4. Check that
   • all the texts in the interface have been enlarged;
   • all the text in the interface remains legible and the functions usable;
   • content has not disappeared;
   • if any text has disappeared, that there is a method on the screen for displaying the text on demand (for example, by holding down an icon).
5. If this is the case, the criterion is validated.

iOS

1. Activate the Differentiate without colour option (Settings > Accessibility > Text display and size > Differentiate without colour).
2. Activate the Increase contrast option (Settings > Accessibility > Text display and size > Increase contrast) or if present in the application, activate the replacement mechanism enabling the application to be displayed with a sufficient contrast ratio.
3. Identify user interface components (links, buttons) with text embedded in a text environment (in a sentence, for example), identified only by colour (without any other formatting that distinguishes them from the rest of the text in which they are embedded).
4. Activate the Colour Contrast Analyser software on the computer and capture the colours of the surrounding text and the interactive component on the mobile device,
   • either by broadcasting the screen of the mobile device on the computer;
   • or by taking screenshots of the elements to be evaluated (and importing them onto the computer).
5. Check that the contrast between the font colour of the component and the font colour of the surrounding text is at least 3:1.
6. If this is the case, the criterion is validated.

Android

1. If it exists in the application, activate the replacement mechanism to display the application with a sufficient contrast ratio.
2. Identify user interface components (links, buttons) with text embedded in a text environment (in a sentence, for example) identified solely by colour (without any other formatting that distinguishes them from the rest of the text in which they are embedded).
3. Activate the Colour Contrast Analyser software on the computer and capture the colours of the surrounding text and the interactive component on the mobile device,
   • either by broadcasting the screen of the mobile device on the computer;
   • or by taking screenshots of the elements to be evaluated (and importing them onto the computer).
4. Check that the contrast between the font colour of the component and the font colour of the surrounding text is at least 3:1.
5. If this is the case, the criterion is validated.

iOS and Android

1. Identify user interface components (links, buttons) with text embedded in a text environment (in a sentence, for example), identified solely by colour (without any other formatting that distinguishes them from the rest of the text in which they are embedded).
2. Connect an external keyboard (and set keyboard navigation parameters).
3. Check that the focus visibility as defined at system level is preserved on these elements.
4. Connect a mouse.
5. Check that hovering over interactive components in a text environment is indicated by means other than colour (bolding, underlining for example).
6. If this is the case, the criterion is validated.

iOS

1. Connect an external keyboard (and configure keyboard navigation).
2. Enable all available focus style settings.
3. Navigate through the application and assess whether the focus visibility as defined at system level is preserved for all elements of the application.
4. If this is the case, the criterion is validated.

Android

1. Connect an external keyboard (and configure keyboard navigation).
2. Navigate through the application and assess whether the focus visibility as defined at system level is preserved for all elements of the application.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify information on the screen given by shape, size or location in a text, graphic element, time-based or non-time-based media. This can be an icon positioned to the left of a component to indicate that it is active, or an instruction on the screen to activate a component positioned at a certain point on the screen.
2. Check that there is another way of retrieving this information from the screen (for example, a text that everyone can read and that gives the same information).
3. If this is not the case, activate the screen reader and check that information other than the shape, size or location is rendered by the screen reader.
4. If this is the case, the criterion is validated.

iOS

1. Connect an external keyboard (and configure keyboard navigation).
2. Browse the screen and locate the additional content that appears when focusing a user interface component.
3. Check that the additional content can be hidden using a keyboard key (the ESC key, for example).
4. Check that the additional content remains visible
   • until the focus is moved away from the user interface component and the additional content;
   • or as long as the focus is positioned on the user interface component or in the additional content;
   • or as long as the additional content is valid.
5. Connect a mouse.
6. Scan the screen with the mouse and locate the additional content that appears when a user interface component is hovered over.
7. Check that the additional content can be hovered over with the mouse.
8. Check that the additional content remains visible
   • until the mouse pointer is moved away from the user interface component and the additional content;
   • or as long as the mouse pointer hovers over the user interface component or the additional content;
   • or as long as the additional content is valid.
9. If this is the case, the criterion is validated.

Android

1. Connect an external keyboard (and configure keyboard navigation).
2. Browse the screen and locate the additional content that appears when focusing a user interface component.
3. Check that the additional content can be hidden by a key on the keyboard (generally the key or combination of keys that will have been associated in Switch Access for the Return parameter)
4. Check that the additional content remains visible
   • until the focus is moved away from the user interface component and the additional content;
   • or as long as the focus is positioned on the user interface component or in the additional content;
   • or as long as the additional content is valid.
5. Connect a mouse.
6. Scan the screen with the mouse and locate the additional content that appears when a user interface component is hovered over.
7. Check that the additional content can be hovered over with the mouse.
8. Check that the additional content remains visible
   • until the mouse pointer is moved away from the user interface component and the additional content;
   • or as long as the mouse pointer hovers over the user interface component or the additional content;
   • or as long as the additional content is valid.
9. If this is the case, the criterion is validated.

iOS and Android

1. Identify on the screen the form fields (input field, radio button, check box).
2. Check for the presence of an adjacent visible label.
3. Activate the form input field (e.g. enter text).
4. Check that the label remains visible.
5. If this is the case, the criterion is validated.

iOS with VoiceOver

1. Activate the screen reader.
2. Navigate to form elements using screen reader gestures.
3. Check that a label is rendered when the focus of the screen reader is on the form field.
4. If this is the case, the criterion is validated.

iOS with voice control

1. Activate voice control.
2. Identify all the form fields on the screen.
3. Check that a label is detected by Voice Control (a grey tooltip appears above the field).
4. If this is the case, the criterion is validated.

Android

1. Activate the screen reader.
2. Navigate to form elements using screen reader gestures.
3. Check that a label is rendered when the focus of the screen reader is on the form field.
4. If this is the case, the criterion is validated.

iOS with VoiceOver

1. Activate the screen reader.
2. Navigate to form elements using screen reader gestures.
3. Check that
   • the label rendered by the screen reader is relevant (it allows you to understand the nature of the expected input);
   • the visible label is contained in the label rendered by the screen reader.
4. If this is the case, the criterion is validated.

With voice control

1. Activate voice control.
2. Identify all the form fields on the screen.
3. Check that
   • the label detected by the voice control (grey tooltip) is relevant (it allows you to understand the nature of the expected input);
   • the visible label is contained in the label detected by the voice control (grey tooltip).
4. If this is the case, the criterion is validated.

Android

1. Activate the screen reader.
2. Navigate to form elements using screen reader gestures.
3. Check that
   • the label rendered by the screen reader is relevant (it allows you to understand the nature of the input required);
   • the visible label is contained in the label rendered by the screen reader.
4. If this is the case, the criterion is validated.

iOS and Android

1. Identify all the form fields on the screen.
2. For each form field, check that the visible label is adjacent to the field to which it is linked.
3. If this is the case, the criterion is validated.

2 evaluation methods are proposed for iOS. Both methods lead to the same results. Only one of these methods is required to evaluate the criterion on iOS.

iOS with VoiceOver

1. Activate the screen reader.
2. Navigate to the form buttons using the screen reader gestures.
3. Check that
   • the heading rendered by the screen reader is relevant (it allows you to understand the action of the button);
   • the visible label is contained in the label rendered by the screen reader.
4. If this is the case, the criterion is validated.

iOS with voice control

1. Activate voice control.
2. Identify the form buttons on the screen.
3. Check that
   • the heading detected by the voice control (grey tooltip) is relevant (it allows you to understand the action of the button);
   • the visible label is contained in the label detected by the voice control (grey tooltip);
4. If this is the case, the criterion is validated.

Android

1. Activate the screen reader.
2. Navigate to the form buttons using the screen reader gestures.
3. Check that
   • the heading rendered by the screen reader is relevant (it allows you to understand the action of the button);
   • the visible label is contained in the label rendered by the screen reader.
4. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Identify on the screen the fields of the same kind that need to be grouped together (for example, the fields for entering the different sequences of digits in a credit card code).
3. Check that
   • when the focus is placed on the first field, information is rendered identifying the group to which the field belongs (although this is important for users, it is not required that the grouping information is rendered on each of the form fields, but only on at least the first field in the grouping);
   • the information rendered is relevant, i.e. that it enables the nature of the grouping to be understood.
4. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Validate the form without entering any data in order to identify the mandatory fields.
3. For each mandatory field, check that
   • the information rendered by the screen reader when focused on the field contains the required nature;
   • a visible text near the field indicates that the form field is mandatory.
4. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Fill in form input fields with values that are likely to cause input errors (e.g. enter an incorrectly formed e-mail address).
3. Validate the form.
4. For each mandatory form field that has a format check (which will be displayed with an error after validation), check that
   • the expected data type and/or format are rendered by the screen reader when focused on the field;
   • a visible text near the field indicates the expected data type and/or format.
5. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Fill in form fields with values that are likely to cause input errors (leaving a field empty, entering a badly formed e-mail address, for example).
3. Validate the form.
4. For each field in error, check that
   • the error message is visible near the field;
   • the error message is rendered by the screen reader when focused on the field.
5. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Fill in form input fields with values that are likely to cause input errors (e.g. entering an incorrectly formed e-mail address).
3. Validate the form.
4. For each field in error that has a format check, check that the error message includes a real example of an input (for example, for an e-mail address, check that the pattern refers to a real address, like "jean.schmitt@accessibilite.lu").
5. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Fill in the form.
3. For all data of a financial (e.g. income), legal (e.g. reference to an administrative act) or personal (e.g. telephone number) nature, for each form that transmits answers to a test or examination, check that the user can:
   • modify or cancel data and carried out actions on that data while it is being entered (e.g. field entry and the browser's undo editing functionality are not disabled);
   • or explicitly confirm the sending of this data via a dedicated mechanism (for example, a form field or an additional step).
4. For each form that modifies or deletes data (for example, deleting a postal address), check that the user can
   • retrieve the deleted data during input;
   • or explicitly confirm the deletion of this data via a dedicated mechanism (for example, a form field or an additional step).
5. If this is the case, the criterion is validated.

iOS

1. Access each of the form fields (tap on the input field, for example, to activate the appearance of input controls).
2. For each field that expects personal data about the user, check that the appropriate platform-native controls are presented to the user. For example
   • for a field requesting the user's e-mail address, the keyboard shown has the @ character without the user having to perform any keyboard operations (such as displaying the secondary keyboard);
   • for a field asking the user to enter a telephone number, the numeric keypad is presented directly to the user;
   • and so on.
3. Check that the form is compatible with an auto-fill mechanism. For example, iOS allows fields to be filled in automatically on the basis of the last values entered, depending on their nature (postal address, town, surname, first name, e-mail address). Check that relevant values are suggested for these fields.
4. If so, the criterion is validated.

Android

1. Access each of the form fields (tap on the input field, for example, to activate the appearance of input controls).
2. For each field that expects personal data about the user, check that the appropriate platform-native controls are presented to the user. For example
   • for a field requesting the user's e-mail address, the keyboard shown has the @ character without the user having to perform any keyboard operations (such as displaying the secondary keyboard);
   • for a field asking the user to enter a telephone number, the numeric keypad is presented directly to the user;
   • and so on.
3. Check that the form is compatible with an autofill mechanism. For example, Google provides an auto-fill system on Android. Go to Settings > System > Languages and input > Advanced settings > Autofill service (depending on the version of the platform, the path may be different) to activate and set the parameters.
4. On the application form, check that the system offers you an option to fill in the data automatically.
5. If it does, the criterion is validated.

iOS and Android

1. Connect an external keyboard (and configure keyboard navigation).
2. Navigate through all the elements on the screen and check that the navigation sequence remains consistent. The navigation sequence does not have to follow the natural reading order (left to right and top to bottom, for example) as long as the elements are accessible in a consistent order.
3. Identify on the screen components (buttons for example) that update content (display hidden elements, dynamic content updates for example):
   1. activate the component;
   2. after displaying the updated content, check that the tabulation remains consistent.
4. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader.
2. Navigate all the elements on the screen using the screen reader gestures and check that the order of access to the elements on the screen (interactive components and text) remains consistent. The order does not have to follow the natural reading order (from left to right and from top to bottom, for example) as long as the elements are accessible in a coherent order that does not cause comprehension problems.
3. Identify components on the screen (buttons for example) that update content (display hidden elements, dynamic content updates for example):
   1. activate the component;
   2. after displaying the updated content, check that the screen reader's path remains consistent.
4. If this is the case, the criterion is validated.

Example of content whose implementation causes comprehension problems: An arrival time and a departure time are displayed on the screen in the form of two blocks of visual information (arrival time 17:00; departure time 18:00). The screen reader sequentially reaches "arrival time" then "departure time" then "17:00" and finally "18:00". The reading order does not correspond to the visual order, and the reading order is problematic because it does not allow the information to be linked together.

iOS

1. Connect an external keyboard (and configure keyboard navigation).
2. Navigate all the elements on the screen using the dedicated keyboard keys (by default in iOS, the Tab and arrow keys are used to navigate content).
3. Check that
   • from the current position, the next or previous focusable item can be reached using the keyboard navigation keys;
   • the element currently in focus offers a method that can be used with the keyboard (for example, a keyboard shortcut) to reach the next or previous element.
4. If this is the case, the criterion is validated.

Note: Some complex elements, often managed by the platform, can call on optimised navigations which generally use the direction arrows to move from one part of the component to another. The keyboard trap test is then limited to checking that the component can be reached and that it is possible to move on to the next component or return to the previous component. The actual use of the component is not checked in this criterion.

Android

1. Connect an external keyboard (and configure keyboard navigation).
2. Navigate through all the elements on the screen using the keys on the keyboard (the keys or combination of keys that will have been associated in Switch Access for the "Next" and "Previous" parameters).
3. Check that
   • from the current position, the next or previous focusable element can be reached using the keyboard navigation key;
   • the element currently in focus offers a method that can be used with the keyboard (for example, a keyboard shortcut) to reach the next or previous element.
4. If this is the case, the criterion is validated.

Note: Some complex elements, often managed by the platform, can call on optimised navigations which generally use the direction arrows to move from one part of the component to another. The keyboard trap test is then limited to checking that the component can be reached and that it is possible to move on to the next component or return to the previous component. The actual use of the component is not checked in this criterion.

iOS and Android

1. Connect an external keyboard (and configure keyboard navigation).
2. From the application, successively press each of the printable character keys (lowercase letters a-z, uppercase letters A-Z, numbers 0-9, all symbols such as $,*,%,! etc. as long as they can be written on the screen).
3. If the keyboard shortcut is associated with a single component isolated from the screen, check that it can only be activated if the keyboard focus is inside that component.
4. Otherwise, if an action is triggered, check that there is a configuration menu in the application which allows you to
   • disable these one-touch keyboard shortcuts;
   • configure these keyboard shortcuts by adding a modifier key (Ctrl, Alt, Shift, etc.).
5. If this is the case, the criterion is validated.

iOS and Android

1. Identify processes that limit session time (e.g. after authentication).
2. Check
   • for the presence of a mechanism enabling the user to remove the time limit (for example, a toggle button enabling the user to activate or deactivate the session time limit);
   • or for the presence of a mechanism allowing the user to increase the time limit (for example, a drop-down list with available connection time values);
   • or for the presence of a mechanism which warns the user of the imminence of the time limit and allows the user at least 20 seconds to increase the time limit (for example, the opening of a modal with a button allowing the time limit to be increased);
   • or that the time limit is at least twenty hours.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify session time limits (for example, logging out of a customer account).
2. Check
   • the presence of a mechanism enabling the user to remove the time limit (for example, a button with an explicit label);
   • or the presence of a mechanism enabling the user to increase the time limit (for example, a parameter available in the application to manage session times);
   • or that the duration of the session is at least twenty hours.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify the components on the screen (a link, a button (form) or a download form for example) used to download a file in office format (.doc, .docx, .pdf for example).
2. For each file offered for download in an office format, check that an alternative version is presented as accessible.
3. If the alternative is offered in an office format (pdf, odt, doc, docx, EPUB/DAISY):
   • download the file containing the proposed alternative;
   • if this file is in PDF format, check that it complies with the PDF accessibility assessment framework (RAPDF 1).
   • if the file is in another format, check that it complies with the criteria of section 10 Non-web documents of European standard EN 301 549 v3.2.1.
4. If the alternative is proposed in the application, check that the content complies with this framework.
5. Otherwise, for documents in office format (pdf, odt, doc, docx, EPUB/DAISY):
   • download the file;
   • if the file is in PDF format, check that it complies with the PDF accessibility assessment framework (RAPDF 1).
   • if the file is in another format, check that it complies with the criteria of section 10 Non-web documents of European standard EN 301 549 v3.2.1.
6. If this is the case, the criterion is validated.

iOS and Android

1. For each file offered for download in a desktop format that has an alternative version presented as accessible, check that both documents (the original document and the accessible version in a desktop format or in the application) offer the same information.
2. If this is the case, the criterion is validated.

iOS and Android

1. Identify cryptic content on the screen (ascii art, emoticons, cryptic syntax).
2. Check that a definition is available in the adjacent context (immediately before or after the cryptic content, in the adjacent text or via the activation of a user interface component).
3. If not, activate the screen reader.
4. Navigate to the cryptic content and check that an alternative is rendered.
5. If this is the case, the criterion is validated.

iOS and Android

1. For each cryptic content item that has an alternative, check that the alternative given is relevant (it enables the content or function to be understood).
2. If this is the case, the criterion is validated.

iOS and Android

1. Identify content on the screen that flashes or causes flash effects: animated graphic element, video or animation, formatting effect.
2. Check that
   • the frequency of the effect is less than 3 flashes per second;
   • or that the total surface area is less than 21,824 pixels.
3. If this is the case, the criterion is validated.

Note: The PEAT tool can be used to analyse videos in .avi format.

iOS and Android

1. Identify moving or blinking content on the screen (e.g. a graphic element, formatting effect or carousel) that is triggered automatically when the screen loads or when content is displayed (see note).
2. Check
   • that the total duration of movement or blinking is less than 5 seconds;
   • or that there is a mechanism (e.g. a button) to stop and restart the movement or blinking;
   • or the presence of a mechanism (e.g. a button) that allows the moving or blinking content to be hidden and displayed again;
   • or the presence of a mechanism (such as a button) that allows the content to be displayed without movement or blinking.
3. If this is the case, the criterion is validated.

Note:

• the stopping or pausing of moving or blinking content when focused (the effect is suspended only while focused, but resumes once the focus is lost) or by touching moving content (the effect is suspended only while pressure is applied to the content, but resumes once the pressure is released) are not considered to be compliant processes.
• in some cases, the movement cannot be stopped, for example a progress bar, in which case the criterion is not applicable.

iOS

1. Open the Control Center.
2. Check that the screen orientation is not locked in the platform settings (see official documentation).
3. Display the application and toggle the device between landscape and portrait mode.
4. Check that
   • the application can be used in both orientations, i.e. that the elements of the application are repositioned so that they can be read;
   • the content available in one orientation is still available in the other orientation (directly or by activating an additional component, for example).
5. If this is the case, the criterion is validated.

Android

1. Open the Quick settings panel.
2. Check that "Auto-rotate" is enabled (see official documentation).
3. Display the application and toggle the device between landscape and portrait mode.
4. Check that
   • the application can be used in both orientations, i.e. that the elements of the application are repositioned so that they can be read;
   • the content available in one orientation is still available in the other orientation (directly or by activating an additional component, for example).
5. If this is the case, the criterion is validated.

iOS and Android

1. Identify functions on the screen that require complex gestures (look for instructions in the interface or in documentation associated with the application), for example
   • using two or more fingers simultaneously;
   • tracing a trajectory (such as the swipe gesture).
2. Check that there is an alternative method of performing the associated action using a simple gesture, for example pressing a single key on the keyboard or a button.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify on the screen functions that require two or more actions to be performed simultaneously, for example
   • using two or more keys on a keyboard at the same time;
   • having to say a voice command and touch the screen at the same time to perform an action.
2. Check that the screen or application provides an alternative method of performing the action associated with a single action, for example pressing a button.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify interactive components (e.g. buttons or links) on the screen.
2. For each interactive component, press and hold the button.
3. Move your finger outside the interactive zone and check that the associated action is not triggered.
4. If this is the case, the criterion is validated.

iOS and Android

1. Identify functions on the screen that are triggered by a movement of the device or a gesture towards the device (for example, look for instructions in the interface or in documentation associated with the application that describe this type of triggering).
2. Check
   • that the functionality can be triggered without movement, for example by activating a button or a link;
   • and that the application provides a method for deactivating motion detection (for example, a parameter in the application).
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify document conversion functions on the screen (e.g. export to PDF, .odt, HTML etc.)
2. Identify accessibility information in the original content (e.g. an alternative graphic element, headings levels, table of contents).
3. Check that the accessibility information is still present in the converted document (unless the conversion format chosen does not support the accessibility information in the source document).
4. If this is the case, the test is validated.

iOS and Android

1. Identify on the screen the identification (authentication) and control functions that are based on the use of biological characteristics (e.g. voice recognition, fingerprint, facial recognition).
2. Check that there is an alternative method of performing the action, for example
   • for an authentication feature that uses fingerprint recognition, a button is available on the login screen to access password entry instead.
   • for authentication functionality that involves voice recognition, the application also offers fingerprint recognition (if the alternative method also relies on a biological characteristic, it is desirable that it does not involve a similar biological characteristic. For example, if the initial method involves voice, the alternative method should not involve voice)
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify the presence of a key repeat function in the application (for example, look for instructions in the interface or in documentation associated with the application).
2. Check that the delay before the repeat function is activated (the time between the very first key press to be repeated and the repeat function being activated)
   • is at least 2 seconds;
   • or that there is a method for setting it to at least 2 seconds (for example, an input field in the application's user parameters).
3. Check that the delay between two repetitions
   • is at least 2 seconds;
   • or that there is a method for setting it to at least 2 seconds (for example, an input field in the application's user parameters).
4. If this is the case, the test is validated.

iOS and Android

1. Identify the presence of documentation in the application, for example
   • a help screen;
   • an accessibility statement;
   • any other content that serves as documentation.
2. Identify the presence of accessibility features in the application.
3. Check that the documentation includes
   • a description of the application's accessibility features, for example
     • accessibility parameters integrated into the application, such as colour management, font sizes, animation management, etc;
     • a customised rotor on certain screens (the rotor is a screen reader feature that enables rapid navigation between different types of elements on a screen; some platforms allow you to define application-specific rapid navigation elements in this rotor. See a demonstration);
     • gestures or device movements that trigger functions;
     • special keyboard shortcuts available for certain assistive technologies.
   • a description of the complex components for which special management is in place depending on the assistive technology;
   • explanations of how to use these functions (where they are located, how to activate them);
   • a description of the elements that do not comply or are not compatible with certain assistive technologies, and the presence of alternatives where appropriate.
4. If this is the case, the criterion is validated.

iOS and Android

1. Identify in the application the accessibility features described in the documentation. For example
   • a feature that provides access to a simplified language version of the application;
   • a feature that locks the orientation of a screen.
2. Check that it is possible for users who need to
   • perceive the presence of this functionality in the interface;
   • activate this functionality. For example, if a functionality is available that allows access to a simplified language version of the application, then all the components that make up the path to the functionality must be in simplified language.
3. If this is the case, the criterion is validated.

iOS

1. Identify the accessibility features made available to users in the platform documentation (see the documentation concerning the accessibility features provided by iOS.
2. Check that the application does not prevent their use, for example
   • if the application implements interactions that trigger features, these interactions do not prevent the platform's accessibility features such as the screen reader or other touch-based features from working properly;
   • if the application includes voice recognition, then the use of the voice command integrated into the platform is not disrupted;
   • if the application implements keyboard shortcuts, these do not use key combinations already employed by the platform for accessibility features (VoiceOver can be used with a keyboard for example, the proposed shortcuts must not interfere);
   • or any other application functionality.
3. If this is the case, the criterion is validated.

Android

1. Identify the accessibility features made available to users in the platform documentation (see the documentation concerning accessibility features provided by Android).
2. Check that the application does not prevent their use, for example
   • if the application implements interactions that trigger features, these interactions do not prevent the platform's accessibility features, such as the screen reader or other touch-based features, from working properly;
   • if the application includes voice recognition, then the use of the voice command integrated into the platform is not disrupted;
   • if the application implements keyboard shortcuts, these do not use key combinations already employed by the platform for accessibility features (TalkBack can be used with a keyboard for example, the proposed shortcuts must not interfere);
   • or any other application functionality.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify the presence of documentation in the application, for example
   • a help screen;
   • an accessibility statement;
   • any other content that acts as documentation (this could be a pdf document or an external HTML page readable in a web browser).
2. If this is the case, check for each item of documentation:
   • If this is the case a web page, that it complies with RAWeb1;
   • If this is the case an office document in PDF format, that it complies with the PDF accessibility assessment framework (RAPDF 1).
   • If this is the case an office document in another format, that it complies with the criteria of section 10 Non-web documents of European standard EN 301 549 v3.2.1;
   • If this is the case an application screen, that the present framework is complied with (the Requirements page also details that screens relating to documentation must be included in the evaluation sample).
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify the editing functions in the tool (for example, a text editor, but it could also be a media library or any other interface that lets you enter text or define properties).
2. Check that it is possible to define the accessibility information needed to make the content RAWeb-compliant. For example
   • defining the text alternative for an image from the text editor or a media library;
   • define an accessible name (of a link);
   • etc.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify in the tool the presence of help with creating accessible content. This may include
   • user documentation that explains how to define accessibility properties for each content item;
   • automatic or semi-automatic tests available from the editing functions;
   • manual tests available from the editing functions to guide authors in detecting errors.
2. Check that the help with creating accessible content is relevant, i.e. that it enables accessible content to be created.
3. If this is the case, the criterion is validated.

iOS and Android

1. From the editing functions (a text editor, but it can also be a media library or any other interface that lets you enter text or define properties), enter the types of content proposed by the editor (heading, list, table, image, etc.). Also use the various parameters for defining accessibility information (enter the text alternative for an image, add a description to a link, etc.)
2. Save your entries.
3. View the generated content
   • in the editing function (for example, in the text editor);
   • in the content publication interface (for example, the publication web page).
4. Check that
   • accessibility information (e.g. alternative image, heading levels) is preserved in the generated content;
   • the technology supports the accessibility information for the restructured form of the information (check that the transformation of the information is compatible with the technology, in particular to ensure that this information can be used by assistive technologies).
5. If this is the case, the criterion is validated.

iOS and Android

1. Identify the presence of automatic or semi-automatic test functions in the tool.
2. Modify the values or content in the editing zones to create accessibility errors in the content generated (web and non-web).
3. Activate the test functions.
4. Check that the tool
   • automatically repairs the error;
   • or provides the author with repair suggestions.
5. In the case of a semi-automatic test, check that the tool
   • provides decision support and repair suggestions;
   • or provides the author with explanations enabling him to carry out the repair.
6. If this is the case, the criterion is validated.

iOS and Android

1. Identify the presence of templates provided by the editing tool.
2. Test compliance with the RAWeb criteria and check that at least one of the templates is fully compliant.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify the presence of templates fully compliant with the RAWeb provided by the editing tool.
2. Check that there is an explicit reference to identify them. For example, in the list of templates, compliant templates have an "accessible template" label.
3. If this is the case, the criterion is validated.

iOS and Android

1. Find out whether a support service is available in the application.
2. If this is the case, look for documentation in the application, for example:
   • a help screen;
   • an accessibility statement;
   • any other content that serves as documentation.
3. Identify the presence in the documentation of
   • a description of the application's accessibility features, for example
     • accessibility parameters built into the application, such as colour management, font sizes, animation management, etc;
     • a customised rotor on certain screens (the rotor is a screen reader feature that enables rapid navigation between different types of elements on a screen; some platforms allow you to define application-specific rapid navigation elements in this rotor. See a demonstration);
     • gestures or device movements that trigger functions;
     • special keyboard shortcuts available for certain assistive technologies.
   • a description of the complex components for which special management is in place depending on the assistive technology;
   • explanations of how to use these functions (where they are located, how to activate them);
   • a description of the elements that do not comply or are not compatible with certain assistive technologies, and the presence of alternatives where appropriate.
4. Check that the support service provides information about these features.
5. If this is the case, the criterion is validated.

iOS and Android

1. Identify the presence of a support service in the application.
2. If so, check that the support service can be used by all people with disabilities. It may be useful to search the application documentation to find this information. For example, if the support service is available from a telephone number, check that there are alternative means for users who cannot express themselves orally (deaf or hard of hearing people) or who cannot use verbal language (people with aphasia). For example
   • instant messaging, which provides an equivalent service (real-time dialogue with a human operator);
   • the provision of simultaneous written or visual translation of oral or audio information, or the provision of a sign language interpreter (use of a relay service).
3. If this is the case, the criterion is validated.

iOS and Android

The safest way to assess this criterion is to search either the interface or the application documentation for this information. It is also recommended that you ask the application publisher to provide this information.

An implementation of ITU-T Recommendation G.722 for example seems to be an optimal solution.

iOS and Android

1. Check that the application allows two-way voice communication.
2. If it does, check that there is a real-time text function (it may sometimes be necessary to activate a dedicated parameter in the application to enable real-time text).
3. If not, check whether the application can connect to a terminal with real-time text functionality (this may be difficult to assess without a real-time communication terminal or if the network used by the terminal does not support real-time text protocols. A first step may be to search the documentation or ask the application publisher directly)
4. If this is the case, the criterion is validated.

iOS and Android

1. Check that the application allows two-way voice communication.
2. If it does, check that it has a real-time text (RTT) function.
3. If this is the case, check that it is possible to use both modes of communication at the same time, i.e. users can send RTT messages at the same time as other users are speaking, for example.
4. If this is the case, the criterion is validated.

iOS and Android

1. Activate the application and the application's RTT functionality on two terminals and connect them to the same session.
2. Send a text message from both terminals to obtain messages with different statuses (sent and received).
3. Check that
   • sent and received messages are visually separated (for example, sent messages are in one window and received messages in another, or there is a line break between each received and sent message if they are presented in the same window);
   • it is visually possible to distinguish between messages sent and messages received (for example, the words "Sent" near a message sent or "Received" near a message received);
   • if the interlocutor is identified for oral communication (for example, the avatar of the person speaking), that the authors of written messages are also identified (for example, the presence of a name or an identifier preceding the message).
4. Activate the screen reader and navigate through the messages.
5. Check that the screen reader displays
   • the sent or received status of each message;
   • identification of the author of the message.
6. If this is the case, the criterion is validated.

iOS and Android

1. Check that the application allows two-way voice communication and RTT communication or real-time video broadcasting.
2. If this is the case, activate the application on two terminals and connect them to the same session.
3. Have a user speak from one of the terminals.
4. Check that a visual indicator appears on the interface to identify that a person is speaking. It is not necessary for this criterion to identify who is speaking, but simply to identify that there is a person speaking. For example, a halo around or an icon near the avatar of the person speaking.
5. If this is the case, the criterion is validated.

iOS and Android

No evaluation method is proposed for this criterion.

Important note: This criterion is very complex to assess and requires a certain mastery of all interoperability concepts and standards. If the application you are assessing or developing needs to cover this criterion, we refer you to the full text of criterion 6.2.3 Interoperability in the EN 301 549 standard.

iOS and Android

1. Check that the application supports real-time text (RTT) communication.
2. If so, activate the application and the written communication functionality on two separate terminals and connect them to the same session.
3. Enter text on the first terminal and observe its appearance on the second terminal. The appearance on the second terminal must be instantaneous (less than half a second). Depending on how the functionality works, each character is not sent individually. In fact, if the RTT communication functionality implements word prediction, it is when the desired word is selected that it is sent, not when the first characters used to trigger the suggestion display are entered. A simple observation test may be sufficient to observe the instantaneous appearance on the terminal receiving the written message.
4. If this is the case, the criterion is validated.

iOS and Android

1. Activate the screen reader from a terminal.
2. From a second terminal, make a call to the first terminal.
3. When the incoming call appears, check
   • that the caller identification is available in visible text format (for example, a name or a telephone number);
   • and that this identification is correctly rendered by the screen reader.
4. If this is the case, the criterion is validated.

iOS and Android

1. Activate the application and launch a video call between the two terminals.
2. Check that the terminal receiving the call has a method enabling sign language users to identify the caller.
3. If this is the case, the criterion is validated.

iOS and Android

1. Identify the features available (apart from the oral communication feature) that are based on listening to information or issuing commands, for example
   • voicemail;
   • an automatic switchboard (e.g. one that requires you to say a number between 1 and 4 to be redirected to a service);
   • or any other interactive voice server.
2. Check:
   • that the information is available without having to listen or speak;
   • that the actions can be carried out without having to listen or speak, or that there is an alternative to the functionality that can be used without having to listen or speak.
3. If this is the case, the criterion is validated.

iOS and Android

For conditions relating to resolution and frame rate, the safest way to assess this criterion is to search either the interface or the application's documentation for this information. It is also advisable to ask the application's publisher to provide these technical details.

For the last condition concerning the time lag between video and audio, the test can be established by simple observation:

1. Activate the application on two devices.
2. Establish a video call connection between the two devices.
3. Check that speech and video are synchronised (lip-sync, lip movement).
4. If this is the case, the criterion is validated.