RAAM 1.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. For texts whose size (normal or enlarged) cannot be appreciated with the naked eye, you will have to measure it (see the dedicated section in the methodology).
4. Activate the Colour Contrast Analyser software on the computer and capture the foreground and background colours:
   • 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. For the texts with issues identified previously, check:
   • For texts that are less than 24px in size without a bold effect, or less than 18.5px with a bold effect, that the contrast value is at least 4.5:1;
   • For texts that are 24px or larger without a bold effect, or 18.5px or larger with a bold effect, that the contrast value 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 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. For texts whose size (normal or enlarged) cannot be appreciated with the naked eye, you will have to measure it (see the dedicated section in the methodology).
4. Activate the Colour Contrast Analyser software on the computer and capture the foreground and background colours:

• 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).

1. For the texts with issues identified previously, check:
   • For texts that are less than 24px in size without a bold effect, or less than 18.5px with a bold effect, that the contrast value is at least 4.5:1;
   • For texts that are 24px or larger without a bold effect, or 18.5px or larger with a bold effect, that the contrast value is at least 3:1.
2. 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 application's replacement mechanism to display graphic elements 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 information is present, including dialogue).
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 pre-recorded and live 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 on the screen pre-recorded and live synchronised time-based media that require captions.
2. Check that the captions are
   • relevant (all important audio information is present, including dialogue);
   • in the language of the video;
   • 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 validated.

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 on the screen pre-recorded synchronised time-based media with a synchronised caption track or audio description.
2. Check that it is possible to activate and deactivate captions or audio description without any additional steps compared to the main features (play, pause, etc.).
3. If this is the case, the criterion is validated.

Example: If the play button can be activated from the interface by a simple tap (without the need to activate a component first to display a drop-down menu, for example), the captions feature must be available in the same way, with a simple tap. Conversely, if the captions feature is available from a drop-down menu that has to be activated first (by a tap, for example), it will not be considered to be at the same level, as there will be an additional step to perform.

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 or send a video by e-mail), convert (convert a video in .avi format into an .mpg format, for example) or record pre-recorded synchronised time-based media (record a video from a broadcast platform onto a personal computer, for example).
2. Execute each function (transmit, convert and record).
3. For each function, check if captions:
   • are still present;
   • can be displayed;
   • are correctly synchronised;
   • keep their key features (for example, if in the original media the captions were coloured according to the speaker, these colours must be reused).
4. If this is the case, the criterion is validated.

iOS and Android

1. Identify the functions used to transmit, convert or record synchronised time-based media. For example: send content to another device or by e-mail, convert a video in .avi format into an .mpg format, record a video from a broadcast platform onto a personal computer.
2. Execute each function (transmit, convert and record).
3. For each of these functions, check that audio description:
   • is present;
   • can be activated;
   • is correctly synchronised:
     • the sounds and words of the audio description do not overlap with those of the original soundtrack and do not 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 validated.

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.
   • Check that the Override custom settings parameter at the bottom of the screen is deactivated.
   • Define one or more caption presentation parameters from the customisation options provided by the platform, for example: caption size, colour, caption border style, background colour, background opacity, etc. (Note: the standard does not give a precise list of parameters that must be defined, so the possibility of modifying a single caption characteristic is sufficient to make the criterion compliant).
3. Check that the settings defined at platform level are applied to the captions.
4. If this is not the case, look for a feature on the screen that allows you to change the caption presentation settings (on-screen or directly from the media player).
5. Check that the defined parameters 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 caption presentation parameters from the customisation options provided by the platform, for example: caption size, colour, caption border style, background colour, background opacity, etc. (Note: the standard does not give a precise list of parameters that must be defined, so the possibility of modifying a single caption characteristic is sufficient to make the criterion compliant).
3. Check that the settings defined at platform level are applied to the captions.
4. If this is not the case, look for a feature on the screen that allows you to change the caption presentation settings (on-screen or directly from the media player).
5. Check that the defined parameters are applied to the captions.
6. If this is the case, the criterion is validated.

iOS and Android

1. Identify on the screen pre-recorded synchronised time-based media with subtitles.
2. Check for the presence of a sound track that would be the vocalised version of the subtitles:
   • activate the sound track;
   • check that the vocalised subtitles match the displayed subtitles.
3. If this is not the case:
   • check that there is a feature that allows you to vocalise subtitles;
   • activate the feature;
   • start playing the multimedia content;
   • check that the texts displayed by this means are vocalised.
4. If this is not the case:
   • activate the screen reader and navigate to the media player;
   • activate the subtitles;
   • check that the vocalised subtitles match the subtitles displayed.
5. If this is not the case:
   • activate the screen reader and navigate to the media player;
   • activate the subtitles in the media player and play the video;
   • check that the displayed subtitles are rendered by the screen reader.
6. If this is not the case:
   • look for alternative media with a soundtrack containing subtitles for vocalised translation;
   • check that the displayed subtitles are rendered by the screen reader.
7. 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 name (a visible text), the text is rendered;
   • if the component has a perceptible state (activated, deactivated, selected), this state is rendered;
   • if the component can change state (e.g. toggle button, slider), perform the necessary actions to test the different states and check that each change of state is correctly rendered (switching to the selected state, increasing the slider);
   • if the component has a perceptible value (value of a slider), this value is rendered.
5. If this is the case, the criterion is validated.

iOS With Accessibility Inspector

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

iOS With voice control

The voice control application allows users to navigate by voice.

Criterion 5.1 in its entirety cannot be assessed with voice control, but one voice control feature (the display of labels) provides a quick overview of the status of interactive components.

Voice control will enable us to detect the components that can be used by touch but are not interactive components detectable by assistive technologies, the presence of a label and its relevance, and the presence of the visible label in the accessible label.

1. Activate voice control: Settings > Accessibility > Voice control.
2. Display the accessible names of interactive components: from the voice control settings screen, go to the "Overlay" button and activate it, then choose "Element names".
3. From now on, when voice control is activated, grey tooltips will appear above interactive elements that have labels. Note that if the screen has a very large number of interactive controls, the labels will be displayed in successive groups (one group of labels disappears and another appears).

What you need to know: only elements with interactive roles recognised by the Accessibility API will have a label. This will allow you to quickly identify which elements that can be used by touch are not recognised by the voice control and are therefore not interactive elements (which constitutes non-compliance).

Procedure:

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 on the screen items grouped together visually in the form a list.
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.
3. Open Control Centre and activate the Text size parameter (‘aA’ button) to display the font size gauge. Increase the value to 190%.
4. If necessary, restart the application to ensure that the parameter is taken into account by the application.
5. 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 not been enlarged or has disappeared, that there is a method on the screen for displaying the text on demand (for example, by a long press on an icon).
6. 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 font size value (slider at the bottom of the screen) to the maximum (see technical note).
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 not been enlarged or has disappeared, that there is a method on the screen for displaying the text on demand (for example, by a long press on an icon).
5. If this is the case, the criterion is validated.

Technical note: Before Android 14, on devices without a manufacturer's overlay, the font size setting did not allow you to enlarge to 200% of the default size. This is only possible from Android 14 onwards. If you are testing on an Android device with a version prior to 14, you can combine the font size setting and the display size setting to achieve a zoom close to 200%. From Android 14 onwards, the font size setting allows you to reach 200%. On the other hand, on some versions of Android, the slider gauge may be different and offer values that allow you to achieve a zoom greater than 200%, so you will need to check that the test is only performed for a value of 200%.

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 the application with the keyboard and check 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 the application with the keyboard and check:
   • if the test is carried out without activation of an accessibility service, that the focus is visible;
   • if the test is carried out with an accessibility service activated, that the focus as defined in the service is visible on all the 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;
   • and a visible indication near the field indicates that the form field is mandatory.
4. If the visible indication is made in a non-textual way (icon, '*', '!', etc.), the explanation of the meaning of this indication is placed visually, and in the reading order, before the first use of the indication.
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. 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 platform'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 or equal to 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 criterion 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 an authentication feature that uses fingerprint recognition, a button is available on the login screen to access password entry.
   • For authentication functionality that involves voice recognition, the application also offers fingerprint recognition.
3. If this is the case, the criterion is validated.

If the alternative method also relies on a biological characteristic, it is essential that it does not involve a similar biological characteristic. For example, if the initial method involves voice, the alternative method must not use voice.

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.
2. Identify the presence of accessibility features in the application.
3. Check that the documentation includes
   • a description of the application's accessibility features.
   • explanations of how to use these functions (where they are located, how to activate them);
   • a description of the complex components for which special management is in place depending on the assistive technology;
   • 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 the accessibility features described in the documentation. For example:
   • access a version of the content in simplified language;
   • enlarge text size.
2. Check that the users concerned by each accessibility feature are able to access it. For example:
   • Alternative version in simplified language: the mechanism or set of mechanisms which enable the functionality to be activated must be understandable and identifiable by a person who benefits from simplified language (for example, the use of the Easy to read logo to identify the mechanism is a compliant solution).
   • Larger font size: if the mechanism contains text, then the text must be displayed by default with a font size equivalent to 200% of the initial font size.
3. Check that it is possible to activate this feature.
4. 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 a documentation in the application or accessible from the application.
2. For a documentation in web format (HTML, CSS), check that it complies with the RAWeb criteria.
3. For a documentation in PDF format, check that it complies with the RAPDF criteria.
4. For a documentation in non-web format (other than PDF), check that it complies with the section 10 Non-web documents criteria of the European standard EN 301 549 v3.2.1.
5. For a documentation made available in a mobile application, check that it complies with the RAAM criteria.
6. If this is the case, the criterion is validated.

Note: the documentation will be considered non-compliant as soon as an error is identified with regard to the target criteria, even if the error is part of the template elements (menu, footer) and not just part of the content of the isolated documentation.

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. For functions that allow content to be created in web format (HTML, CSS), check that it is possible to define the accessibility information needed to make the content compliant with the RAWeb. For example:
   • defining a text alternative for an image from the text editor or a media library;
   • defining the accessible name of a link;
   • etc.
3. For functions that allow content to be created in PDF format, check that it is possible to define the accessibility information required to make the content compliant with the RAPDF. For example:
   • defining a text alternative for an image from the text editor or a media library;
   • defining the accessible name of a link;
   • etc.
4. For functions that allow content to be created in non-web format (other than PDF), check that it is possible to define the accessibility information required to make the content compliant with the criteria in section 10 Non-web documents of the European standard EN 301 549 v3.2.1. For example:
   • defining a text alternative for an image from the text editor or a media library;
   • defining the accessible name of a link;
   • etc.
5. For functions that enable content to be created and delivered in a mobile application, check that it is possible to define the accessibility information needed to make the content compliant with the RAAM criteria. For example:
   • defining the text alternative for an image from the text editor or a media library;
   • defining the accessible name of a link;
   • etc.
6. 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
   • automatic or semi-automatic tests available from the editing functions;
   • other automatic tools (a chatbot for instance);
   • documentation that explains how to define accessibility properties for each content item;
   • 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 the given results or indications enable to create content that complies with digital accessibility rules.
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);
   • and in the content publication interface (for example, the publication web page).
4. For each piece of content in web format (HTML, CSS), check that:
   • the information necessary for it to comply with the RAWeb (e.g. the alternative of an image, the headings levels) is preserved in the generated content;
   • the information, if restructured, remains compatible with assistive technologies (for example, if the author enters an HTML table and, after saving, the tool linearises the table, the restructured information must be understandable to assistive technology users as it would have been in its original form).
5. For each content item in PDF format, check that:
   • the information necessary for it to comply with the RAPDF (e.g. alternative image, headings levels) is preserved in the generated content;
   • the information, if restructured, remains compatible with assistive technologies (for example, if the author enters a table and, after saving, the tool linearises the table, the restructured information must be understandable to assistive technology users as it would have been in its original form).
6. For all content in non-web format that is not PDF, check that:
   • the information required to comply with section 10 Non-web documents of the European standard EN 301 549 v3.2.1 is preserved in the generated content;
   • the information, if restructured, remains compatible with assistive technologies (for example, if the author enters a table and, after saving, the tool linearises the table, the restructured information must be understandable to assistive technology users as it would have been in its original form).
7. For each content displayed in a mobile application, check that:
   • the information necessary for it to comply with the RAAM (e.g. alternative image, identification of headings) is preserved in the content generated;
   • the information, if restructured, remains compatible with assistive technologies (for example, if the author enters an HTML table and, after saving, the tool linearises the table, the restructured information must be understandable to assistive technology users as it would have been in its original form).
8. 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. Generate web and non-web content with accessibility errors, using the editing tool.
3. Activate the test functions.
4. Check that the tool
   • automatically repairs the error (automatic test);
   • or provides the author with repair suggestions (semi-automatic test).
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. For templates in web format (HTML, CSS), check that at least one template meets all the RAWeb criteria.
3. For templates in PDF format, check that at least one template complies with all the RAPDF criteria.
4. For templates in non-web format (other than PDF), check that at least one template meets all the criteria of section 10 Non-web documents of European standard EN 301 549 v3.2.1.
5. For templates used to distribute content in a mobile application, check that at least one template meets all the RAAM criteria.
6. If this is the case, the criterion is validated.

iOS and Android

1. Identify the presence of templates fully compliant with digital accessibility rules 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.
3. Identify the presence in the documentation of
   • a description of the accessibility features offered by the application;
   • 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 this is the case, 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 have little or no access to spoken language (deaf or hard of hearing people) or who cannot use verbal language (people with aphasia). For example
   • an e-mail address or an online form;
   • instant messaging;
   • 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

1. Identify the presence of a documentation provided by the support service.
2. For documentation in web format (HTML, CSS), check that it complies with the RAWeb criteria.
3. For documentation in PDF format, check that it complies with the RAPDF criteria.
4. For documentation in non-web format (other than PDF), check that it complies with the criteria in section 10 Non-web documents of European standard EN 301 549 v3.2.1;
5. For documentation provided in a mobile application, check that it complies with the RAAM criteria.
6. If it does, the criterion is validated.

Note: the documentation will be considered non-compliant as soon as an error is identified with regard to the target criteria, even if the error is part of the template elements (menu, footer) and not just part of the content of the isolated documentation.

iOS and Android

1. Activate the application and launch a call between the two terminals.
2. Check that the quality of oral activity with the web application is at least equivalent to the quality of oral activity during a call with a fixed telephone.
3. If the test is unsatisfactory (e.g. poor understanding of certain words spoken by the caller, presence of extraneous noise, etc.), check the application documentation to ensure:
   • the presence of a reference to the implementation of ITU-T Recommendation G.722;
   • or the presence of a reference to the use of the WebRTC API opus codec;
   • or the presence of a reference to the use of encoding and decoding with a frequency greater than or equal to 7,000 Hz.
4. Otherwise, it is recommended that you ask the application publisher to provide these technical details, in particular by asking whether the web application implements, for example, ITU-T Recommendation G.722 or uses the WebRTC API opus codec.
5. If this is the case, the criterion is validated.

If the information cannot be found in the interface or its documentation, and the editor of the application is unable to answer about this technical characteristic, the criterion will be considered non-compliant.

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 this is the case, the criterion is validated.

If the information cannot be found in the interface or its documentation, and the editor of the application is unable to answer about this technical characteristic, the criterion will be considered non-compliant.

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. that it is possible for the same user to speak and use the RTT function simultaneously.

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) and with different authors.
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, by a layout or colour that differentiates them or by a visible text annotation (look for the words "Sent" near a sent message or "Received" near a received message);
   • information about the nature of the message (received or sent) is accessible to assistive technologies (text information is available to provide this information);
   • the authors of text messages are identified (for example, the presence of a name or identifier preceding the message).
4. 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

This criterion is very complex to assess and requires a certain mastery of all interoperability concepts and standards.

We recommend to ask the application publisher to check that all the requirements described in criterion 6.2.3 Interoperability of European standard EN 301 549 are met.

It is also advisable to search the documentation or ask the application publisher directly.

If the information cannot be found in the interface or its documentation, and the application publisher is unable to provide an answer on this technical characteristic, the criterion will be considered non-compliant.

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 is configured, 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, and 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 application and 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 visually available in the form of text of an understandable nature (for example, a name or a telephone number);
   • 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. Initiate an oral activity, and check that the second terminal has information to identify this activity (for example, the presence of a coloured halo around the thumbnail of the speaker in activity).
3. If this is the case:
   • look for the presence of a manual mechanism (e.g. a button) that would allow the person signing to indicate that they are signing;
   • if not, perform gestures in front of the camera (see note) and check that information is automatically displayed to identify this visual activity.
4. If this is the case, the criterion is validated.

Note: in communication applications, the identification of a spoken activity is not based on the identification of an intelligible verbal message (a word or sentence, for example), but solely on the identification of a sound (a noise, for example). In this way, visual activity, even if it does not correspond to an element that can be understood in sign language, could be detected automatically by this application and would therefore serve as a mechanism for identifying the activity of a person who signs. It is therefore possible to test by performing gestures even if they do not correspond to an element of meaning in sign language.

iOS and Android

1. Identify in the application 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 (e.g. via a text transcript or a chat system);
   • 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.

If the information cannot be found in the interface or its documentation, and the application publisher is unable to provide an answer on this technical characteristic, these conditions cannot be validated, the criterion will be considered non-compliant.

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 test is validated.