EN 301 549 Exigences d’accessibilité pour les produits et services TIC - 11. Logiciel

 

11.0 Généralités (informatif)

Cet article décrit les exigences concernant :

  • les logiciels plate-forme ;
  • les logiciels qui fournisseur une interface utilisateur comportant du contenu intégré au logiciel ;
  • les outils d’édition ;
  • les logiciels fonctionnant comme technologies d’assistance ;
  • les applications mobiles.

NOTE 1 : Les agents utilisateurs sont des exemples de logiciels fournissant une interface utilisateur. Ils récupèrent, restituent et facilitent l’interaction de l’utilisateur final avec un contenu créé. Les agents utilisateurs jouent un rôle nécessaire en matière d’accessibilité des contenus créés restitués dans l’interface utilisateur. UAAG 2.0 [i.33] fournit des conseils supplémentaires pour ceux qui créent des agents utilisateurs et qui souhaitent accroître la fonctionnalité lors de la restitution d’un contenu créé d’une manière accessible.

NOTE 2 : Les exigences relatives au contenu Web, notamment du logiciel constituant du contenu Web, figurent à l’Article 9.

NOTE 3 : Les exigences relatives aux documents, pouvant être présentés par des agents utilisateur, figurent à l’Article 10.

NOTE 4 : Bien que l’accessibilité des interfaces de ligne de commande ne soit pas traitée dans le présent document, l’accessibilité peut être obtenue par des exigences spécifiques au contexte dont certaines se trouvent dans les Articles 5 ou 11.

Les exigences des paragraphes 11.1 à 11.5 s’appliquent aux logiciels :

  • qui ne sont pas des pages Web ;
  • qui ne sont pas intégrés dans des pages Web ni utilisés dans la restitution ou le fonctionnement de la page.

L’Article 9. contient les exigences pour les logiciels qui se trouvent dans des pages Web ou qui sont intégrés dans des pages Web et qui sont utilisés dans la restitution ou sont destinés à être restitués conjointement avec la page Web dans laquelle ils sont intégrés.

Certaines exigences dans les paragraphes 11.1 à 11.5 ont des versions différentes pour la fonctionnalité ouverte ou verrouillée. Dans ces cas, le paragraphe correspondant sera divisé en deux sous-paragraphes.

Les critères de succès définis dans les paragraphes 11.1 à 11.5 sont destinés à l’harmonisation avec la Note du Groupe de travail du W3C [i.26] produite par le Groupe d’étude WCAG2ICT du W3C.

NOTE 5 : Les logiciels qui fournissent une interface utilisateur incluent leur propre contenu. Parmi les exemples de contenu inclus dans les logiciels, on peut citer les commandes et le texte affichés dans une barre de menus d’une application d’interface utilisateur graphique, les images affichées dans une barre d’outils, les messages oraux dans une interface utilisateur auditive, d’autres commandes d’interaction utilisateur, ainsi que d’autres textes, graphismes ou objets qui ne sont pas chargés à partir de l’extérieur du logiciel.

NOTE 6 : Des paragraphes « Vide » ont été insérés afin de conserver l’alignement de la numérotation dans les Articles 9, 10 et 11

11.1 Perceptible

11.1.1 Équivalents textuels

11.1.1.1 Contenu non textuel

11.1.1.1.1 Contenu non textuel (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire au critère de succès WCAG 2.1 1.1.1 Contenu non textuel.

NOTE :    Actuellement, les CAPTCHA n’apparaissent pas en dehors du Web. Toutefois, s’ils apparaissent, cette recommandation est exacte.

11.1.1.1.2 Contenu non textuel (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire à l’exigence 5.1.3.6 (Sortie vocale pour contenu non textuel).

11.1.2 Média temporel

11.1.2.1 Contenu seulement audio ou vidéo (pré-enregistré)

11.1.2.1.1 Contenu seulement audio ou vidéo (pré-enregistré – fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès aux technologies d’assistance pour la lecture à l’écran et lorsque des informations auditives pré-enregistrées ne sont pas nécessaires pour permettre l’utilisation des fonctions verrouillées de la TIC, elle doit satisfaire au critère de succès WCAG 2.1 1.2.1 Contenu seulement audio ou vidéo (pré-enregistré).

NOTE :    Cette variante peut être proposée directement dans le logiciel, ou dans une version alternative qui satisfait au critère de succès.

11.1.2.1.2 Contenu seulement audio ou vidéo (pré-enregistré – fonctionnalité verrouillée)
11.1.2.1.2.1 Contenu seulement audio pré-enregistré (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux technologies d’assistance pour la lecture à l’écran et lorsque des informations auditives pré-enregistrées sont nécessaires pour permettre l’utilisation des fonctions verrouillées de la TIC, la fonctionnalité du logiciel qui réalise une interface utilisateur doit satisfaire à l’exigence 5.1.5 (Sortie visuelle pour informations audio).

11.1.2.1.2.2 Contenu seulement vidéo pré-enregistré (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire à l’exigence 5.1.3.7 (Sortie vocale pour les informations vidéo).

11.1.2.2 Sous-titres (pré-enregistrés)

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 1.2.2 Sous-titres (pré-enregistrés).

NOTE :    La définition des « sous-titres » selon WCAG 2.1 spécifie que « dans certaines langues comme l’anglais on distingue entre caption et subtitles, le terme caption étant parfois traduit en français par sous-titres pour malentendants ». Selon la définition des WCAG 2.1, afin de répondre à ce critère de succès, qu’il s’agisse de sous-titres ou de sous-titres pour malentendants, ceux-ci doivent fournir un « visuel synchronisé ou équivalent textuel pour l’information audio avec ou sans parole nécessaire à la compréhension du contenu d’un média » lorsque des informations non vocales contiennent « des effets sonores, de la musique, des rires, l’identification et le positionnement des interlocuteurs ».

11.1.2.3 Audiodescription ou version de remplacement pour un média temporel (pré-enregistré)

11.1.2.3.1 Audiodescription ou version de remplacement pour un média temporel (pré-enregistré – fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire au critère de succès WCAG 2.1 1.2.3 Audiodescription ou version de remplacement pour un média temporel (pré-enregistré).

NOTE 1 : La définition de « l’audiodescription » selon WCAG 2.1 indique que l’audiodescription est « également appelée « vidéodescription » et « narration descriptive » ».

NOTE 2 : Des pistes audio auxiliaires ou alternatives sont habituellement utilisées à cet effet.

11.1.2.3.2 Audiodescription ou version de remplacement pour un média temporel (pré-enregistré – fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire à l’exigence 5.1.3.7 (Sortie vocale pour les informations vidéo).

11.1.2.4 Sous-titres (en direct)

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 1.2.4 Sous-titres (en direct).

NOTE :    La définition des « sous-titres » selon WCAG 2.1 spécifie que « dans certaines langues comme l’anglais on distingue entre caption et subtitles, le terme caption étant parfois traduit en français par sous-titres pour malentendants ». Selon la définition des WCAG 2.1, afin de répondre à ce critère de succès, qu’il s’agisse de sous-titres ou de sous-titres pour malentendants, ceux-ci doivent fournir un « visuel synchronisé ou équivalent textuel pour l’information audio avec ou sans parole nécessaire à la compréhension du contenu d’un média » lorsque des informations non vocales contiennent « des effets sonores, de la musique, des rires, l’identification et le positionnement des interlocuteurs ».

11.1.2.5 Audiodescription (pré-enregistrée)

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 1.2.5 Audiodescription (pré-enregistrée).

NOTE 1 : La définition de « l’audiodescription » selon WCAG 2.1 indique que l’audiodescription est « également appelée « vidéodescription » et « narration descriptive » ».
NOTE 2 : Des pistes audio auxiliaires ou alternatives sont habituellement utilisées à cet effet.

11.1.3 Adaptable

11.1.3.1 Informations et relations

11.1.3.1.1 Informations et relations (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire au critère de succès WCAG 2.1 1.3.1 Informations et relations.

NOTE :    Dans les logiciels, la détermination par programme est facilitée par l’utilisation de services d’accessibilité offerts par les logiciels plate-forme afin de permettre l’interopérabilité entre le logiciel et les technologies d’assistance ainsi que les fonctionnalités d’assistance du logiciel. (Voir paragraphe 11.5 Interopérabilité avec les technologies d’assistance).

11.1.3.1.2 Informations et relations (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux technologies d’assistance pour la lecture à l’écran et si des informations sont affichées à l’écran, il convient que la TIC fournisse des informations auditives permettant à l’utilisateur de corréler l’audio avec les informations affichées à l’écran.

NOTE 1 : Un grand nombre d’individus considérés comme non-voyants au regard de la loi possèdent tout de même certaines capacités visuelles et utilisent des aspects de l’affichage visuel même s’ils ne peuvent pas l’appréhender totalement. Une alternative audio à la fois complète et complémentaire comprend toutes les informations visuelles, telles que le focus ou la mise en évidence, afin de permettre la corrélation entre l’audio et les informations visibles à l’écran, à tout moment.

NOTE 2 : La structure et les relations indiquées par la présentation constituent des exemples d’informations auditives permettant à l’utilisateur de corréler l’audio et les informations affichées à l’écran.

11.1.3.2 Ordre séquentiel logique

11.1.3.2.1 Ordre séquentiel logique (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire au critère de succès WCAG 2.1 1.3.2 Ordre séquentiel logique.

11.1.3.2.2 Ordre séquentiel logique (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux technologies d’assistance pour la lecture à l’écran et si des informations sont affichées à l’écran, il convient que la TIC fournisse des informations auditives permettant à l’utilisateur de corréler l’audio avec les informations affichées à l’écran.

NOTE 1 : Un grand nombre d’individus considérés comme non-voyants au regard de la loi possèdent tout de même certaines capacités visuelles et utilisent des aspects de l’affichage visuel même s’ils ne peuvent pas l’appréhender totalement. Une alternative audio à la fois complète et complémentaire comprend toutes les informations visuelles, telles que le focus ou la mise en évidence, afin de permettre la corrélation entre l’audio et les informations visibles à l’écran, à tout moment.

NOTE 2 : La structure et les relations indiquées par la présentation constituent des exemples d’informations auditives permettant à l’utilisateur de corréler l’audio et les informations affichées à l’écran.

11.1.3.3 Caractéristiques sensorielles

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 1.3.3 Caractéristiques sensorielles.

11.1.3.4 Orientation

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 1.3.4 Orientation.

11.1.3.5 Identification de l’objet de la saisie

11.1.3.5.1 Identification de l’objet de la saisie (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire au critère de succès WCAG 2.1 1.3.5 Identification de l’objet de la saisie.

11.1.3.5.2 Identification de l’objet de la saisie (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui est verrouillée aux technologies d’assistance, dans au moins un mode de fonctionnement, la TIC doit présenter à l’utilisateur, sous forme audio, l’objet de chaque champ de saisie qui collecte des informations à propos de l’utilisateur lorsque le champ de saisie a un rôle identifié dans la section WCAG 2.1 Objets de la saisie pour les composants de l’interface utilisateur.

11.1.4 Distinguable

11.1.4.1 Utilisation de la couleur

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 1.4.1 Utilisation de la couleur.

11.1.4.2 Contrôle du son

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur, elle doit satisfaire au critère de succès du Tableau 11.1.

Tableau 11.1 : Critère de succès des logiciels : Contrôle du son

Si du son dans un logiciel est audible automatiquement pendant plus de 3 secondes, un mécanisme est disponible pour le mettre en pause, l’arrêter ou pour en contrôler le volume de façon indépendante du niveau de volume du système général.

NOTE 1 :  Puisque toute partie d’un logiciel ne satisfaisant pas à ce critère de succès peut interférer avec la capacité de l’utilisateur à exploiter le logiciel entier, tout le contenu présent dans le logiciel (qu’il soit utilisé pour satisfaire à d’autres critères de succès ou non) doit satisfaire à ce critère de succès.

NOTE 2 :  Ce critère de succès est identique au critère de succès WCAG 2.1 1.4.2 Contrôle du son en remplaçant « sur une page Web » par « dans un logiciel », « tout contenu » par « toute partie d’un logiciel », « page entière » par « logiciel entier », « dans la page Web » par « dans le logiciel », en supprimant « Voir l’exigence de conformité 5 :
Non-interférence » et en ajoutant la Note 1.

11.1.4.3 Contraste (minimum)

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 1.4.3 Contraste (minimum).

11.1.4.4 Redimensionnement du texte

11.1.4.4.1 Redimensionnement du texte (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès aux fonctionnalités de grossissement de la plate-forme ou de la technologie d’assistance, elle doit satisfaire au critère de succès WCAG 2.1 1.4.4 Redimensionnement du texte.

NOTE 1 : Le contenu pour lequel il existe des lecteurs logiciels, des visionneuses ou des éditeurs permettant un grossissement de 200 % répondent automatiquement à ce critère de succès lorsqu’il est utilisé avec de tels lecteurs, à moins que le grossissement soit sans effet sur le contenu.

NOTE 2 : Ce critère de succès concerne la possibilité de permettre aux utilisateurs d’agrandir le texte à l’écran au moins jusqu’à 200 % sans nécessiter de technologies d’assistance. Cela signifie que l’application offre une méthode d’agrandissement du texte à 200 % (zoom ou autre) sans perte de contenu ou de fonction, ou que l’application fonctionne à l’aide des fonctions de la plate-forme répondant à cette exigence.

11.1.4.4.2 Redimensionnement du texte (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur qui n’est pas capable d’accéder à des fonctionnalités de grossissement de la plate-forme ou à une technologie d’assistance, elle doit satisfaire à l’exigence 5.1.4 (Fonctionnalité verrouillée à l’agrandissement du texte).

NOTE :    La prise en charge de la restitution du texte dans un environnement fermé pouvant être plus limité que la prise en charge qui se trouve dans les agents utilisateurs pour le Web, la réalisation du présent paragraphe dans un environnement fermé peut imposer un effort accru à l’auteur du contenu.

11.1.4.5 Texte sous forme d’image

11.1.4.5.1 Texte sous forme d’image (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire au critère de succès WCAG 2.1 1.4.5 Texte sous forme d’image.

11.1.4.5.2 Texte sous forme d’image (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire à l’exigence 5.1.3.6 (Sortie vocale pour contenu non textuel).

11.1.4.6 Vide

11.1.4.7 Vide

11.1.4.8 Vide

11.1.4.9 Vide

11.1.4.10 Refusion

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur elle doit satisfaire au critère de succès du Tableau 11.2.

Tableau 11.2 : Critère de succès des logiciels : Refusion

Le contenu peut être présenté sans perte d’informations ou de fonctionnalité et sans exiger un défilement dans deux dimensions pour :

  • Défilement vertical du contenu à une largeur équivalente à 320 pixels CSS ;
  • Défilement horizontal du contenu à une hauteur équivalente à 256 pixels CSS ;

à l’exception des parties du contenu qui exigent une mise en page bidimensionnelle pour l’usage ou la signification.

NOTE 1 :  320 pixels CSS équivalent à une largeur d’espace de restitution de départ d’une largeur de 1 280 pixels CSS à un zoom de 400 %. Pour les logiciels non Web qui sont conçus pour un défilement horizontal (par exemple qui contiennent un texte vertical), les 256 pixels CSS équivalent à une hauteur d’espace de restitution de départ de 1 024 pixels à un zoom de 400 %.

NOTE 2 :  Des exemples de contenus qui exigent une mise en page bidimensionnelle sont les images, les cartes, les diagrammes, la vidéo, les jeux, les présentations, les tableaux de données et les interfaces où il est nécessaire de garder les barres d’outils visibles pendant la manipulation du contenu.

NOTE 3 :  Ce critère de succès est identique au critère de succès WCAG 2.1 1.4.10 Refusion en remplaçant les notes originales des WCAG 2.1 par les notes 1 et 2 ci-dessus.

11.1.4.11 Contraste non textuel

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 1.4.11 Contraste non textuel.

11.1.4.12 Espacement de texte

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui ne possède pas une zone de mise en page du contenu de taille fixe qui est essentielle pour les informations transportées, elle doit satisfaire au critère de succès WCAG 2.1 1.4.12 Espacement de texte.

11.1.4.13 Contenu sur survol ou focus

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 1.4.13 Contenu sur survol ou focus

11.2 Utilisable

11.2.1 Accessibilité au clavier

11.2.1.1 Clavier

11.2.1.1.1 Clavier (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès aux claviers ou à une interface de clavier, elle doit satisfaire au critère de succès WCAG 2.1 2.1.1 Clavier.

NOTE :    Cela n’implique pas qu’il soit exigé que le logiciel prenne en charge directement un clavier ou une « interface clavier ». Cela n’implique pas non plus qu’il soit exigé que le logiciel offre un clavier virtuel. Les logiciels plate-forme sous-jacents peuvent fournir des services de saisie indépendants du périphérique aux applications qui permettent une utilisation via un clavier. Les logiciels qui prennent en charge l’utilisation via ces services indépendants des plates-formes pourraient être utilisés à l’aide d’un clavier et seraient conformes.

11.2.1.1.2 Clavier (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux claviers ou interfaces de clavier, elle doit satisfaire à l’exigence 5.1.6.1 (Utilisation sans interface clavier : Fonctionnalité verrouillée).

11.2.1.2 Pas de piège au clavier

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur, elle doit satisfaire au critère de succès du Tableau 11.3.

Tableau 11.3 : Critère de succès des logiciels : Pas de piège au clavier

Si le focus du clavier peut être positionné sur un élément du logiciel à l’aide d’une interface clavier, réciproquement, il peut être déplacé hors de ce même composant simplement à l’aide d’une interface clavier et, si ce déplacement exige plus que l’utilisation d’une simple touche flèche ou tabulation ou toute autre méthode standard de sortie, l’utilisateur est informé de la méthode permettant de déplacer le focus hors de ce composant.

NOTE 1 :  Puisque toute partie d’un logiciel ne satisfaisant pas à ce critère de succès peut interférer avec la capacité de l’utilisateur à exploiter le logiciel entier, il est nécessaire que tout le contenu présent dans le logiciel (qu’il soit utilisé pour satisfaire à d’autres critères de succès ou non) satisfasse à ce critère de succès.

NOTE 2 :  Les méthodes de sortie normalisées peuvent varier selon les plates-formes. Sur de nombreuses plates-formes bureautiques, par exemple, la touche Échap est une méthode de sortie normalisée.

NOTE 3 :  Ce critère de succès est identique au critère de succès WCAG 2.1 2.1.2 Pas de piège au clavier en remplaçant « contenu », « page » et « page Web » par « logiciel », en supprimant « Voir l’exigence de conformité 5 : Non-interférence » et en ajoutant la Note 2 ci-dessus ainsi que la Note 1 ci-dessus révisée pour éviter l’utiliser du mot « doit ».

11.2.1.3 Vide

11.2.1.4 Raccourcis clavier

11.2.1.4.1 Raccourcis clavier (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 2.1.4 Raccourcis clavier.

11.2.1.4.2 Raccourcis clavier (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux claviers ou interfaces de clavier, elle doit satisfaire à l’exigence 5.1.6.1 (Utilisation sans interface clavier : Fonctionnalité verrouillée).

11.2.2 Délai suffisant

11.2.2.1 Réglage du délai

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur, elle doit satisfaire au critère de succès du Tableau 11.4.

Tableau 11.4 : Critère de succès des logiciels : Réglage du délai

Pour chaque limite de temps fixée par le logiciel, au moins l’un des points suivants est vrai :

  • Suppression : L’utilisateur a la possibilité de supprimer la limite de temps avant de la rencontrer ; ou
  • Ajustement : L’utilisateur a la possibilité d’ajuster la limite de temps avant de la rencontrer dans un intervalle d’au moins dix fois la durée paramétrée par défaut ; ou
  • Extension : L’utilisateur est averti avant que la limite de temps n’expire et il lui est accordé au moins 20 secondes pour étendre cette limite par une action simple (par exemple, « appuyer sur la barre d’espace ») et l’utilisateur a la possibilité d’étendre la limite de temps au moins dix fois ; ou
  • L’exception du temps réel : La limite de temps est une partie constitutive d’un événement en temps réel (par exemple, une enchère) et aucune alternative n’est possible ; ou
  • L’exception de la limite essentielle : La limite de temps est essentielle et l’étendre invaliderait alors l’activité ; ou
  • L’exception des 20 heures : La limite de temps est supérieure à 20 heures.

NOTE 1 :  Ce critère de succès permet de s’assurer que les utilisateurs peuvent compléter leurs tâches sans changement inattendu de contenu ou de contexte résultant de la limite de temps. Il convient d’utiliser ce critère de succès conjointement avec le critère de succès 3.2.1 des WCAG 2.1, qui pose des limites aux changements de contenu ou de contexte résultant d’une action de l’utilisateur.

NOTE 2 :  Ce critère de succès est identique au critère de succès WCAG 2.1 2.2.1 Réglage du délai en remplaçant « le contenu » par « le logiciel » et avec l’expression « WCAG 2.1 » ajoutée après l’expression « critère de succès » dans la Note 1 ci-dessus.

11.2.2.2 Mettre en pause, arrêter, masquer

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur, elle doit satisfaire au critère de succès du Tableau 11.5.

Tableau 11.5 : Critère de succès des logiciels : Mettre en pause, arrêter, masquer

Pour toute information en mouvement, clignotante, défilante ou mise à jour automatiquement, tous les points suivants sont vrais :

  • Déplacement, clignotement, défilement : Pour toute information en mouvement, clignotante ou défilante qui (1) démarre automatiquement, (2) dure plus de cinq secondes et (3) est présentée conjointement avec un autre contenu, il y a un mécanisme à la disposition de l’utilisateur pour la mettre en pause, l’arrêter ou la masquer, à moins que le mouvement, le clignotement ou le défilement s’avère un élément essentiel au bon déroulement de l’activité ; et
  • Mise à jour automatique : Pour toute information mise à jour automatiquement qui (1) démarre automatiquement (2) et est présentée conjointement avec un autre contenu, il y a un mécanisme à la disposition de l’utilisateur pour la mettre en pause, l’arrêter ou pour en contrôler la fréquence des mises à jour à moins que la mise à jour automatique s’avère essentielle au bon déroulement de l’activité.

NOTE 1 :  Pour les exigences relatives au contenu scintillant ou flashant, se référer à la Règle 2.3 des WCAG 2.1.

NOTE 2 :  Ce critère de succès s’applique à tous les contenus dans le logiciel (qu’il existe ou non un mode d’utilisation alternatif accessible du logiciel), car toute partie d’un logiciel qui ne satisfait pas à ce critère de succès peut interférer avec l’aptitude d’un utilisateur à utiliser l’ensemble du logiciel (y compris un élément de l’interface utilisateur qui permet à l’utilisateur d’activer le mode d’utilisation alternatif).

NOTE 3 :  Il n’est pas exigé que le contenu mis à jour périodiquement par logiciel ou diffusé en flux à l’agent utilisateur conserve ou présente l’information générée ou reçue entre la mise en pause et la reprise de la présentation, puisque cela peut ne pas être techniquement possible et s’avérer trompeur dans beaucoup de situations.

NOTE 4 :  Une animation survenant dans une phase de pré-chargement ou dans une situation similaire peut être considérée comme essentielle si aucune interaction n’est permise à tous les utilisateurs durant cette phase et si l’absence d’indication de progression est susceptible de perturber les utilisateurs ou de leur faire croire que le contenu est figé ou défectueux.

NOTE 5 :  Ceci est à appliquer à l’intégralité du contenu. Tout contenu, qu’il soit informatif ou décoratif, qui est mis à jour automatiquement, clignote ou se déplace, peut créer une barrière d’accessibilité.

NOTE 6 :  Ce critère de succès est identique au critère de succès WCAG 2.1 2.2.2 Mettre en pause, arrêter, masquer en remplaçant « page » et « page Web » par « logiciel », en supprimant « Voir l’exigence de conformité 5 : Non-interférence » dans la Note 2 du critère de succès, avec l’expression « WCAG 2.1 » ajoutée avant l’expression « Règle » dans la Note 1 ci-dessus et avec la Note 2 ci-dessus révisée pour éviter l’utiliser du mot « doit » et en ajoutant la Note 5 ci-dessus.

11.2.3 Crises et réactions physiques

11.2.3.1 Pas plus de trois flashs ou sous le seuil critique

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur, elle doit satisfaire au critère de succès du Tableau 11.6.

Tableau 11.6 : Critère de succès des logiciels : Pas plus de trois flashs ou sous le seuil critique

Les logiciels doivent être exempts de tout élément qui flashe plus de trois fois dans n’importe quel intervalle d’une seconde ou ce flash doit se situer sous le seuil de flash générique et le seuil de flash rouge.

NOTE 1 :  Ce critère de succès s’applique à tous les contenus dans le logiciel (qu’il existe ou non un mode d’utilisation alternatif accessible du logiciel), car toute partie d’un logiciel qui ne satisfait pas à ce critère de succès peut interférer avec l’aptitude d’un utilisateur à utiliser l’ensemble du logiciel (y compris un élément de l’interface utilisateur qui permet à l’utilisateur d’activer le mode d’utilisation alternatif).

NOTE 2 :  Ce critère de succès est identique au critère de succès WCAG 2.1 2.3.1 Pas plus de trois flashs ou sous le seuil critique en remplaçant « pages Web » par « logiciels », « l’ensemble de la page » par « l’ensemble du logiciel », « la page Web » par « le logiciel » et en supprimant « Voir l’exigence de conformité 5 : Non-interférence » et avec la Note 1 ci-dessus révisée pour éviter l’utiliser du mot « doit ».

11.2.4 Navigable

11.2.4.1 Vide

NOTE 1 : L’exigence de page Web associée, « Contourner des blocs » ne s’applique pas aux programmes logiciels uniques, mais à une définition spécifique des « ensembles de programmes logiciels » qui sont extrêmement rares.

NOTE 2 : Bien qu’il ne s’agisse pas d’une exigence, il est généralement considéré comme la meilleure pratique, et pour aborder les besoins des utilisateurs, d’être apte à contourner les blocs de contenu qui sont répétés au sein du logiciel.

11.2.4.2 Vide

NOTE 1 : L’exigence de page Web associée, « Titre de page » ne s’applique pas aux programmes logiciels uniques, mais à une définition spécifique des « ensembles de programmes logiciels » qui sont extrêmement rares.

NOTE 2 : Bien que le nom d’un produit logiciel puisse être un titre suffisant s’il décrit le sujet ou l’objectif, les noms de logiciels sont des marques déposées qui ne peuvent pas, de par la loi, être des noms de nature descriptive. Il n’est pas pratique de rendre les noms de logiciel à la fois uniques et descriptifs.

11.2.4.3 Parcours du focus

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur, elle doit satisfaire au critère de succès du Tableau 11.7.

Tableau 11.7 : Critère de succès des logiciels : Parcours du focus

Si un logiciel peut être parcouru de façon séquentielle et que les séquences de navigation affectent la signification ou l’action, les éléments reçoivent le focus dans un ordre qui préserve la signification et l’opérabilité.

NOTE :    Ce critère de succès est identique au critère de succès WCAG 2.1 2.4.3 Parcours du focus en remplaçant « page Web » par « logiciel ».

11.2.4.4 Fonction du lien (selon le contexte)

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 2.4.4 Fonction du lien (selon le contexte).

11.2.4.5 Vide

NOTE :    L’exigence de page Web associée pour des « Accès multiples » s’applique aux « ensembles » de pages Web. Dans le logiciel, l’équivalent de « ensembles de pages Web » serait des « ensembles de logiciels », mais ceux-ci sont extrêmement rares et un équivalent n’est pas inclus dans ce paragraphe concernant les exigences relatives au logiciel.

11.2.4.6 En-têtes et étiquettes

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 2.4.6 En-têtes et étiquettes.

NOTE :    Dans les logiciels, les en-têtes et les étiquettes sont respectivement utilisés pour décrire des sections du contenu et des éléments de commande. Dans certains cas, il peut être difficile de déterminer si un texte statique est un en-tête ou une étiquette. Mais dans les deux cas, l’exigence est la même : s’ils existent, ils décrivent le sujet ou le but du ou des termes auxquels ils sont associés.

11.2.4.7 Visibilité du focus

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 2.4.7 Visibilité du focus.

11.2.5 Modalités de saisie

11.2.5.1 Gestes du pointeur

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur, elle doit satisfaire au critère de succès du Tableau 11.8.

Tableau 11.8 : Critère de succès des logiciels : Gestes du pointeur

Toutes les fonctionnalités qui emploient des gestes multipoint ou basés sur un trajet pour une opération peuvent être utilisées avec un pointeur unique sans geste basé sur un trajet, sauf si un geste multipoint ou basé sur un trajet est essentiel.

NOTE 1 :  Cette exigence s’applique à un logiciel non Web qui interprète les actions du pointeur (c’est-à-dire qu’elle ne s’applique pas aux actions qui sont exigées pour utiliser l’agent utilisateur ou la technologie d’assistance).

NOTE 2 :  Ce critère de succès est identique au critère de succès WCAG 2.1 2.5.1 Gestes du pointeur en remplaçant la note originale des WCAG 2.1 par la note 1 ci-dessus.

11.2.5.2 Annulation du pointeur

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur, elle doit satisfaire au critère de succès du Tableau 11.9.

Tableau 11.9 : Critère de succès des logiciels : Annulation du pointeur

Pour une fonctionnalité qui peut être utilisée à l’aide d’un pointeur unique au moins l’un des points suivants est vrai :

  • Pas d’événement de descente : l’événement de descente du pointeur n’est pas utilisé pour exécuter une partie quelconque de la fonction.
  • Abandonner ou annuler : la fonction est achevée sur l’événement d’élévation et il existe un mécanisme qui permet d’abandonner la fonction avant son achèvement ou d’annuler la fonction avant son achèvement.
  • Inversion par montée : l’événement de montée inverse tout résultat de l’événement de descente précédent.
  • Essentielle : il est essentiel d’achever la fonction sur l’événement de descente.

NOTE 1 :  Les fonctions qui émulent un clavier ou un pavé numérique sont considérées essentielles.

NOTE 2 :  Cette exigence s’applique à un logiciel non Web qui interprète les actions du pointeur (c’est-à-dire qu’elle ne s’applique pas aux actions qui sont exigées pour utiliser l’agent utilisateur ou la technologie d’assistance).

NOTE 3 :  Ce critère de succès est identique au critère de succès WCAG 2.1 2.5.2 Annulation du pointeur en remplaçant la note originale des WCAG 2.1 par les notes 1 et 2 ci-dessus.

11.2.5.3 Étiquette dans nom

11.2.5.3.1 Étiquette dans nom (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 2.5.3 Étiquette dans nom.

11.2.5.3.2 Étiquette dans nom (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux technologies d’assistance pour la lecture à l’écran, il convient qu’elle satisfasse à l’exigence 5.1.3.3 (Corrélation de sortie auditive).

11.2.5.4 Actionnement du mouvement

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 2.5.4 Actionnement du mouvement

11.3 Compréhensible

11.3.1 Lisible

11.3.1.1 Langue du logiciel

11.3.1.1.1 Langue du logiciel (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire au critère de succès du Tableau 11.10.

Tableau 11.10 : Critère de succès des logiciels : Langue du logiciel

La langue par défaut du logiciel peut être déterminée par un programme informatique.

NOTE 1 :  Lorsque les plates-formes logicielles disposent d’un réglage « paramètres régionaux/langue », les applications qui l’utilisent et affichent leur interface avec ces « paramètres régionaux/langue » sont conformes à ce critère de succès. Les applications qui n’utilisent pas les « paramètres régionaux/langue » de la plate-forme mais, au lieu de cela, une méthode avec prise en charge de l’accessibilité pour afficher la langue du logiciel sont également conformes à ce critère de succès. Les applications mises en œuvre dans des technologies ne permettant pas aux technologies d’assistance de pouvoir déterminer la langue et ne prenant pas en charge le réglage « paramètres régionaux/langue » peuvent ne pas être en mesure de satisfaire ce critère de succès dans les paramètres régionaux ou la langue concernés.

NOTE 2 :  Ce critère de succès est identique au critère de succès WCAG 2.1 3.1.1 Langue de la page en remplaçant « de chaque page Web » par « du logiciel » et avec l’ajout de la Note 1 ci-dessus.

11.3.1.1.2 angue du logiciel (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire à l’exigence 5.1.3.14 (Langues parlées).

11.3.1.2 Vide

NOTE :    L’application de l’exigence de page Web associée pour la « Langue d’un passage » au logiciel exigerait le balisage de la totalité du texte à tous les endroits du logiciel. Cela serait impossible, un équivalent n’est donc pas inclus dans ce paragraphe concernant les exigences relatives au logiciel.

11.3.2 Prévisible

11.3.2.1 Au focus

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 3.2.1 Au focus.

NOTE :    Certains documents composés et leurs agents utilisateur sont conçus pour offrir une fonctionnalité de visualisation et d’édition nettement différente en fonction de la portion du document composé avec laquelle a lieu l’interaction (par exemple une présentation qui contient une feuille de calcul intégrée, où les menus et les barres d’outils de l’agent utilisateur varient en fonction de l’interaction de l’utilisateur avec le contenu de la présentation ou le contenu de la feuille de calcul intégrée). Si l’utilisateur emploie un mécanisme autre que le placement du focus sur la portion du document composé avec laquelle il veut interagir (par exemple par une sélection dans un menu ou une manipulation spéciale du clavier), tout changement de contexte qui en résulterait ne serait pas soumis au présent critère de succès car il n’aurait pas été provoqué par une modification du focus.

11.3.2.2 À la saisie

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 3.2.2 À la saisie.

11.3.2.3 Vide

NOTE :    L’exigence de page Web associée pour « Navigation cohérente » s’applique aux « ensembles » de pages Web. Bien que la cohérence au sein du logiciel soit souhaitable, les « ensembles de logiciels » au même sens que les « ensembles de pages Web » sont extrêmement rares et un équivalent n’est pas inclus dans ce paragraphe concernant les exigences relatives au logiciel.

11.3.2.4 Vide

NOTE :    L’exigence de page Web associée pour « Identification cohérente » s’applique aux « ensembles » de pages Web. Dans le logiciel, l’équivalent de « ensembles de pages Web » serait des « ensembles de logiciels », mais ceux-ci sont extrêmement rares et un équivalent n’est pas inclus dans ce paragraphe concernant les exigences relatives au logiciel.

11.3.3 Assistance à la saisie

11.3.3.1 Identification des erreurs

11.3.3.1.1 Identification des erreurs (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire au critère de succès WCAG 2.1 3.3.1 Identification des erreurs.

11.3.3.1.2 Identification des erreurs (fonctionnalité verrouillée)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée aux technologies d’assistance pour la lecture à l’écran, elle doit satisfaire à l’exigence 5.1.3.15 (Identification non visuelle des erreurs).

11.3.3.2 Étiquettes ou instructions

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 3.3.2 Étiquettes ou instructions.

11.3.3.3 Suggestion après une erreur

Lorsque la TIC est un logiciel non Web disposant d’une interface utilisateur, elle doit satisfaire au critère de succès WCAG 2.1 3.3.3 Suggestion après une erreur.

11.3.3.4 Prévention des erreurs (juridiques, financières, de données)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur, elle doit satisfaire au critère de succès du Tableau 11.11.

Tableau 11.11 : Critère de succès des logiciels : Prévention des erreurs
(juridiques, financières, de données)

Pour les logiciels qui entraînent des engagements juridiques ou des transactions financières de la part de l’utilisateur, qui modifient ou effacent des données contrôlables par l’utilisateur dans des systèmes de stockages de données, qui enregistrent les réponses de l’utilisateur à un test ou un examen, au moins l’une des conditions suivantes est vraie :
1)  Réversible : Les actions d’envoi sont réversibles.
2)  Vérifiée : Les données saisies par l’utilisateur sont vérifiées au niveau des erreurs de saisie et la possibilité est donnée à l’utilisateur de les corriger.
3)  Confirmée : Un mécanisme est disponible pour revoir, confirmer et corriger les informations avant leur soumission finale.

NOTE :    Ce critère de succès est identique au critère de succès WCAG 2.1 3.3.4 Prévention des erreurs (juridiques, financières, de données) en remplaçant « pages Web » par « logiciel ».

11.4 Robuste

11.4.1 Compatible

11.4.1.1 Analyse syntaxique

11.4.1.1.1 Analyse syntaxique (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès à des technologies d’assistance, elle doit satisfaire au critère de succès du Tableau 11.12.

Tableau 11.12 : Critère de succès des logiciels : Analyse syntaxique

À moins que les spécifications ne le permettent, dans les logiciels qui emploient des langages de balisage de telle sorte que le balisage est exposé séparément et disponible aux technologies d’assistance ainsi qu’aux fonctionnalités ou logiciels d’accessibilité ou à un agent utilisateur pouvant être sélectionné par l’utilisateur, les éléments ont des balises de début et de fin complètes, ils sont imbriqués conformément à leurs spécifications, ils ne contiennent pas d’attributs dupliqués et chaque ID est unique.

NOTE 1 :  Les balises de début et de fin auxquelles il manque un caractère critique, comme un chevron fermant ou un guillemet pour une valeur d’attribut, sont considérées incomplètes.

NOTE 2 :  Le balisage n’est pas toujours disponible pour les technologies d’assistance ou les agents utilisateur pouvant être sélectionnés par l’utilisateur tels que les navigateurs. Dans ces cas, la conformité à cette [exigence] n’aurait aucun impact sur l’accessibilité comme elle pourrait en avoir un pour le contenu Web lorsqu’il est exposé.

NOTE 3 :  Les documents codés en HTML, ODF et OOXML constituent des exemples non exhaustifs de balisage qui est exposé séparément et disponible pour les technologies d’assistance et les agents utilisateur. Dans ces exemples, le balisage peut être analysé entièrement de deux manières : (a) par des technologies d’assistance qui peuvent ouvrir directement le document, (b) par des technologies d’assistance qui emploient les API DOM des agents utilisateur pour des formats de document.

NOTE 4 :  XUL et FXML constituent des exemples non exhaustifs de balisage utilisé en interne pour la persistance de l’interface utilisateur du logiciel qui ne sont jamais exposés à une technologie d’assistance. Dans ces exemples, la technologie d’assistance interagit uniquement avec l’interface utilisateur du logiciel généré.

NOTE 5 :  Ce critère de succès est identique au critère de succès WCAG 2.1 4.1.1 Analyse syntaxique en remplaçant « dans un contenu implémenté via un langage de balisage » par « dans les logiciels qui emploient des langages de balisage de telle sorte que le balisage est exposé séparément et disponible aux technologies d’assistance ainsi qu’aux fonctionnalités ou logiciels d’accessibilité ou à un agent utilisateur pouvant être sélectionné par l’utilisateur » en ajoutant les notes 2, 3 et 4 ci-dessus.

11.4.1.1.2 Analyse syntaxique (fonctionnalité verrouillée)

Sans objet.

NOTE :    Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée à toutes les technologies d’assistance, elle ne doit pas nécessairement satisfaire au critère de succès « Analyse syntaxique » du Tableau 11.12, car le but de ce critère de succès est d’offrir une cohérence afin que des agents utilisateur ou des technologies d’assistance différents produisent le même résultat.

11.4.1.2 Nom, rôle et valeur

11.4.1.2.1 Nom, rôle et valeur (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur et qui prend en charge l’accès à des technologies d’assistance, elle doit satisfaire au critère de succès du Tableau 11.13.

Tableau 11.13 : Critère de succès des logiciels : Nom, rôle et valeur

Pour tout composant d’interface utilisateur (comprenant mais n’étant pas limité aux éléments de formulaire, liens et composants générés par des scripts), le nom et le rôle peuvent être déterminés par un programme informatique ; les états, les propriétés et les valeurs qui peuvent être paramétrés par l’utilisateur peuvent être définis par programmation ; et la notification des changements de ces éléments est disponible aux agents utilisateurs, incluant les technologies d’assistance.

NOTE 1 :  Ce critère de succès s’adresse en priorité aux développeurs de logiciels qui développent ou utilisent leurs propres composants d’interface utilisateur. Sur la majorité des plates-formes avec prise en charge de l’accessibilité, les composants d’interface utilisateur normalisés répondent déjà à ce critère de succès s’ils sont utilisés conformément aux spécifications.

NOTE 2 :  Pour la conformité à ce critère de succès, il est généralement d’usage que les interfaces utilisateur du logiciel emploient les services d’accessibilité fournis par le logiciel plate-forme. Ces services d’accessibilité permettent l’interopérabilité entre les interfaces utilisateur du logiciel et à la fois les technologies d’assistance et les fonctionnalités ou logiciels d’accessibilité de manière normalisée. La majorité des services d’accessibilité de plate-forme vont au-delà de l’exposition par programme du nom et du rôle et du réglage par programmation des états, propriétés et valeurs (et notification de ceux-ci), et spécifient des informations supplémentaires qui pourraient être ou qu’il convient d’exposer et/ou de définir (par exemple une liste des actions disponibles pour un composant d’interface utilisateur donné et des moyens d’exécution par programme de l’une des actions énumérées).

NOTE 3 :  Ce critère de succès est identique au critère de succès WCAG 2.1 4.1.2 Nom, rôle et valeur en remplaçant la note originale des WCAG 2.1 par : « Ce critère de succès s’adresse en priorité aux développeurs de logiciels qui développent ou utilisent leurs propres composants d’interface utilisateur. Sur la majorité des plates-formes avec prise en charge de l’accessibilité, les composants d’interface utilisateur normalisés répondent déjà à ce critère de succès s’ils sont utilisés conformément aux spécifications. » et en ajoutant la Note 2 ci-dessus.

11.4.1.2.2 Nom, rôle et valeur (fonctionnalité verrouillée)

Sans objet.

NOTE :    Lorsque la TIC est un logiciel non Web qui dispose d’une interface utilisateur verrouillée à toutes les technologies d’assistance, elle ne doit pas nécessairement satisfaire au critère de succès « Nom, rôle et valeur » du Tableau 11.13, car ce critère de succès nécessite des informations sous une forme déterminable par programmation.

11.4.1.3 Messages d’état

11.4.1.3.1 Messages d’état (fonctionnalité ouverte)

Lorsque la TIC est un logiciel non Web, elle doit satisfaire au critère de succès WCAG 2.1 4.1.3 Messages d’état.

11.4.1.3.2 Messages d’état (fonctionnalité verrouillée)

Sans objet

11.5 Interopérabilité avec les technologies d’assistance

11.5.1 Fonctionnalité verrouillée

Lorsque la fonctionnalité verrouillée du logiciel est conforme au paragraphe 5.1 (Fonctionnalité verrouillée), il ne doit pas être exigé qu’elle soit conforme aux paragraphes 11.5.2 à 11.5.2.17.

11.5.2 Services d’accessibilité

11.5.2.1  Prise en charge des services d’accessibilité de plate-forme pour les logiciels disposant d’une interface utilisateur

Les logiciels plate-forme doivent offrir un ensemble de services de plate-forme documentés permettant aux logiciels qui disposent d’une interface utilisateur exécutée sur le logiciel plate-forme d’interfonctionner avec les technologies d’assistance.

Lorsqu’un concept d’interface utilisateur correspondant à l’un des paragraphes 11.5.2.5 à 11.5.2.17 est pris en charge dans l’environnement du logiciel, il convient que le logiciel plate-forme prenne en charge cette exigence. Les attributs de sélection du paragraphe 11.5.2.14 (Modification du focus et des attributs de sélection), par exemple, peuvent ne pas exister dans les environnements qui n’autorisent pas la sélection, laquelle est fréquemment associée aux fonctions de copier/coller.

NOTE 1 : Celles-ci définissent la fonctionnalité minimale des logiciels disposant d’interfaces utilisateur lors de l’utilisation de services de plate-forme.

NOTE 2 : Sur certaines plates-formes, ces services peuvent être appelés services d’accessibilité, mais sur d’autres plates-formes, ils peuvent être offerts dans le cadre des services d’interface utilisateur.

NOTE 3 : Les services d’interface utilisateur qui offrent une prise en charge de l’accessibilité par défaut sont considérés comme appartenant aux services offerts pour conformité avec ce paragraphe (c’est-à-dire le service de création d’un nouvel élément d’interface utilisateur fournit le rôle, l’état, la limite, le nom et la description).

NOTE 4 : Pour être conforme à cette exigence, le logiciel plate-forme peut fournir son propre ensemble de services ou afficher les services fournis par ses couches de plate-forme sous-jacentes, si ces services sont conformes à cette exigence.

NOTE 5 : Au sein d’environnements de programmation spécifiques, les attributs techniques associés avec les propriétés d’interface utilisateur décrites aux paragraphes 11.5.2.5 à 11.5.2.17 peuvent avoir des noms différents de ceux utilisés dans les paragraphes.

11.5.2.2 Prise en charge des services d’accessibilité de plate-forme pour les technologies d’assistance

Les logiciels plate-forme doivent offrir un ensemble de services d’accessibilité de plate-forme documentés permettant aux technologies d’assistance d’interfonctionner avec le logiciel qui dispose d’une interface utilisateur exécutée sur le logiciel plate-forme.

Lorsqu’un concept d’interface utilisateur correspondant à l’un des paragraphes 11.5.2.5 à 11.5.2.17 est pris en charge dans l’environnement du logiciel, il convient que le logiciel plate-forme prenne en charge cette exigence. Les attributs de sélection du paragraphe 11.5.2.14 (Modification du focus et des attributs de sélection), par exemple, peuvent ne pas exister dans les environnements qui n’autorisent pas la sélection, laquelle est fréquemment associée aux fonctions de copier/coller.

NOTE 1 : Celles-ci définissent la fonctionnalité minimale accessible aux technologies d’assistance lors de l’utilisation de services de plate-forme.

NOTE 2 : La définition de plate-forme au paragraphe 3.1 s’applique aux logiciels fournissant des services à d’autres logiciels, notamment et sans exhaustivité, les systèmes d’exploitation, les navigateurs Internet, les machines virtuelles.

NOTE 3 : Sur certaines plates-formes, ces services peuvent être appelés services d’accessibilité, mais sur d’autres plates-formes, ils peuvent être offerts dans le cadre des services d’interface utilisateur.

NOTE 4 : Ces services appartiennent généralement au même ensemble de services que ceux décrits au paragraphe 11.5.2.1.

NOTE 5 : Pour être conforme à cette exigence, le logiciel plate-forme peut fournir son propre ensemble de services ou afficher les services fournis par ses couches de plate-forme sous-jacentes, si ces services sont conformes à cette exigence.

11.5.2.3 Utilisation des services d’accessibilité

Lorsque le logiciel dispose d’une interface utilisateur, il doit utiliser les services d’accessibilité de plate-forme documentés applicables. Si les services ne permettent pas au logiciel de satisfaire aux exigences applicables des paragraphes 11.5.2.5 à 11.5.2.17, les logiciels disposant d’une interface utilisateur doivent utiliser d’autres services pour interfonctionner avec les technologies d’assistance.

NOTE :    L’expression « services d’accessibilité de plate-forme documentés » concerne l’ensemble des services offerts par la plate-forme conformément aux paragraphes 11.5.2.1 et 11.5.2.2.

Il est d’usage de développer des logiciels en utilisant des kits de développement qui mettent en œuvre automatiquement les services sous-jacents d’accessibilité de la plate-forme.

11.5.2.4 Technologie d’assistance

Lorsque la TIC est une technologie d’assistance, elle doit utiliser les services d’accessibilité de plate-forme documentés.

NOTE 1 : L’expression « services d’accessibilité de plate-forme documentés » concerne l’ensemble des services offerts par la plate-forme conformément aux paragraphes 11.5.2.1 et 11.5.2.2.

NOTE 2 : La technologie d’assistance peut également utiliser d’autres services d’accessibilité documentés.

11.5.2.5 Informations sur les objets

Lorsque le logiciel dispose d’une interface utilisateur, il doit, à l’aide des services décrits au paragraphe 11.5.2.3, permettre la détermination par programme du rôle, des états, de la limite, du nom et de la description des éléments d’interface utilisateur, par les technologies d’assistance.

11.5.2.6 Ligne, colonne et en-têtes

Lorsque le logiciel dispose d’une interface utilisateur, il doit, à l’aide des services décrits au paragraphe 11.5.2.3, permettre la détermination par programme de la ligne et de la colonne de chaque cellule dans un tableau de données, notamment les en-têtes de ligne et de colonne le cas échéant, par les technologies d’assistance.

11.5.2.7 Valeurs

Lorsque le logiciel dispose d’une interface utilisateur, il doit, à l’aide des services décrits au paragraphe11.5.2.3, permettre la détermination par programme de la valeur actuelle d’un élément d’interface utilisateur et des valeurs minimum et maximum de la plage, si l’élément transmet des informations sur une plage de valeurs, par les technologies d’assistance.

11.5.2.8 Relations par étiquettes

Lorsque le logiciel dispose d’une interface utilisateur, il doit afficher la relation qu’un élément d’interface utilisateur et possède sous forme d’étiquette d’un autre élément, ou l’étiquetage par un autre élément, à l’aide des services décrits au paragraphe 11.5.2.3, afin que ces informations puissent être déterminées par programme par les technologies d’assistance.

11.5.2.9 Relations parent-enfant

Lorsque le logiciel dispose d’une interface utilisateur, il doit, à l’aide des services décrits au paragraphe 11.5.2.3, permettre la détermination par programme de la relation entre un élément d’interface utilisateur et des éléments parents ou enfants, par les technologies d’assistance.

11.5.2.10 Texte

Lorsque le logiciel dispose d’une interface utilisateur, il doit, à l’aide des services décrits au paragraphe 11.5.2.3, permettre la détermination par programme du contenu textuel, des attributs textuels et de la limite du texte affiché à l’écran, par les technologies d’assistance.

11.5.2.11 Liste des actions disponibles

Lorsque le logiciel dispose d’une interface utilisateur, il doit, à l’aide des services décrits au paragraphe 11.5.2.3, permettre la détermination par programme d’une liste des actions disponibles et qui sont exécutables sur un élément d’interface utilisateur, par les technologies d’assistance.

11.5.2.12 Exécution des actions disponibles

Si les exigences de sécurité le permettent, les logiciels offrant une interface utilisateur doivent, à l’aide des services décrits au paragraphe 11.5.2.3, permettre l’exécution par programme des actions affichées conformément au paragraphe 11.5.2.11, par les technologies d’assistance.

NOTE 1 : Dans certains cas, les exigences de sécurité imposées pour un produit logiciel peuvent interdire l’interaction d’un logiciel externe avec le produit TIC. Les systèmes soumis à des exigences strictes de sécurité sont, par exemple, les systèmes traitant d’activités de renseignement, d’activités cryptologiques associées à la sécurité nationale, au commandement et au contrôle des forces armées.

NOTE 2 : Il peut être exigé que les technologies d’assistance maintiennent le même niveau de sécurité que les mécanismes de saisie normalisés pris en charge par la plate-forme.

11.5.2.13 Suivi du focus et des attributs de sélection

Lorsque le logiciel dispose d’une interface utilisateur, il doit, à l’aide des services décrits au paragraphe 11.5.2.3, permettre la détermination par programme des informations et des mécanismes nécessaires au suivi du focus, du point d’insertion de texte et des attributs de sélection des éléments d’interface utilisateur, par les technologies d’assistance.

11.5.2.14 Modification du focus et des attributs de sélection

Si les exigences de sécurité le permettent, les logiciels disposant d’une interface utilisateur doivent, à l’aide des services décrits au paragraphe 11.5.2.3, permettre aux technologies d’assistance de modifier par programme le focus, le point d’insertion de texte et les attributs de sélection des éléments d’interface utilisateur si l’utilisateur peut modifier ces éléments.

NOTE 1 : Dans certains cas, les exigences de sécurité imposées pour un produit logiciel peuvent interdire l’interaction d’un logiciel externe avec le produit TIC et par conséquent, cette exigence ne s’applique pas. Les systèmes soumis à des exigences strictes de sécurité sont, par exemple, les systèmes traitant d’activités de renseignement, d’activités cryptologiques associées à la sécurité nationale, au commandement et au contrôle des forces armées.

NOTE 2 : Il peut être exigé que les technologies d’assistance maintiennent le même niveau de sécurité que les mécanismes de saisie normalisés pris en charge par la plate-forme.

11.5.2.15 Notification des modifications

Lorsque le logiciel dispose d’une interface utilisateur, il doit, à l’aide des services décrits au paragraphe 11.5.2.3, informer les technologies d’assistance sur les modifications des attributs déterminables par programme des éléments d’interface utilisateur mentionnés dans les paragraphes 11.5.2.5 à 11.5.2.11 et 11.5.2.13.

11.5.2.16 Modifications des états et propriétés

Si les exigences de sécurité le permettent, les logiciels disposant d’une interface utilisateur doivent, à l’aide des services décrits au paragraphe 11.5.2.3, permettre aux technologies d’assistance de modifier par programme les états et les propriétés des éléments d’interface utilisateur si l’utilisateur peut modifier ces éléments.

NOTE 1 : Dans certains cas, les exigences de sécurité imposées pour un produit logiciel peuvent interdire l’interaction d’un logiciel externe avec le produit TIC et par conséquent, cette exigence ne s’applique pas. Les systèmes soumis à des exigences strictes de sécurité sont, par exemple, les systèmes traitant d’activités de renseignement, d’activités cryptologiques associées à la sécurité nationale, au commandement et au contrôle des forces armées.

NOTE 2 : Il peut être exigé que les technologies d’assistance maintiennent le même niveau de sécurité que les mécanismes de saisie normalisés pris en charge par la plate-forme.

11.5.2.17 Modifications de valeurs et de texte

Si les exigences de sécurité le permettent, les logiciels disposant d’une interface utilisateur doivent, à l’aide des services décrits au paragraphe 11.5.2.3, permettre aux technologies d’assistance de modifier par programme les valeurs et le texte des éléments d’interface utilisateur en utilisant les méthodes de saisie de la plate-forme, si l’utilisateur peut modifier ces éléments sans utiliser les technologies d’assistance.

NOTE 1 : Dans certains cas, les exigences de sécurité imposées pour un produit logiciel peuvent interdire l’interaction d’un logiciel externe avec le produit TIC et par conséquent, cette exigence ne s’applique pas. Les systèmes soumis à des exigences strictes de sécurité sont, par exemple, les systèmes traitant d’activités de renseignement, d’activités cryptologiques associées à la sécurité nationale, au commandement et au contrôle des forces armées.

NOTE 2 : Il peut être exigé que les technologies d’assistance maintiennent le même niveau de sécurité que les mécanismes de saisie normalisés pris en charge par la plate-forme

11.6 Usage documenté de l’accessibilité

11.6.1 Commande par l’utilisateur des fonctions d’accessibilité

Lorsque le logiciel est une plate-forme, il doit offrir suffisamment de modes de fonctionnement pour permettre la commande par l’utilisateur des fonctions d’accessibilité de plate-forme documentées comme étant destinées aux utilisateurs.

11.6.2 Continuité des fonctions d’accessibilité

Lorsque le logiciel dispose d’une interface utilisateur, il ne doit pas interrompre les fonctions d’accessibilité documentées définies dans la documentation de la plate-forme, sauf si l’utilisateur le demande pendant le fonctionnement du logiciel.

11.7 Préférences d’utilisateur

Lorsque le logiciel n’est pas conçu pour être isolé de sa plate-forme et dispose d’une interface utilisateur, cette interface utilisateur doit suivre les valeurs des préférences d’utilisateur pour les paramètres de la plate-forme d’unités de mesure, de couleur, de contraste, de type de police, de taille de police et de curseur de sélection, sauf lorsqu’elles sont annulées par l’utilisateur.

NOTE 1 : Un logiciel isolé de sa plate-forme sous-jacente ne permet pas d’accéder aux paramètres d’utilisateur de la plate-forme et par conséquent, ne peut pas les respecter.

NOTE 2 : Pour le contenu Web, la plate-forme sous-jacente est l’agent utilisateur.

NOTE 3 : Cela n’empêche pas le logiciel de disposer de valeurs supplémentaires pour un réglage, tant qu’il existe un mode dans lequel l’application suit les réglages du système, même s’ils sont plus restrictifs.

11.8 Outils d’édition

11.8.0 Généralités (informatif)

Pour ceux créant des outils d’édition de contenu Web, le document ATAG 2.0 [i.32] fournit des informations qui peuvent présenter un intérêt pour ceux qui souhaitent passer au-delà de ces exigences.

NOTE : Cela s’applique aussi bien à des outils d’édition indépendants qu’à ceux basés sur le Web.

11.8.1 Technologie de contenu

Les outils d’édition doivent être conformes aux paragraphes 11.8.2 à 11.8.5 dans la mesure où les informations exigées pour l’accessibilité sont prises en charge par le format utilisé pour la sortie de l’outil de création.

11.8.2 Création de contenu accessible

Les outils d’édition doivent permettre et guider la production de contenu conforme aux Articles 9 (Contenu Web) ou 10 (Contenu non Web), selon le cas.

NOTE :    Les outils d’édition peuvent utiliser des outils supplémentaires si la conformité aux exigences spécifiques n’est pas possible à l’aide d’un seul outil. Un outil d’édition vidéo, par exemple, peut permettre la création de fichiers vidéo pour distribution via la télédiffusion et le Web, mais l’édition des fichiers de sous-titrage pour différents formats peut être réalisée par un autre outil.

11.8.3 Conservation des informations d’accessibilité lors des conversions

Si l’outil d’édition réalise des conversions avec restructuration ou des conversions avec reprogrammation, les informations d’accessibilité doivent alors être conservées en sortie si des mécanismes équivalents existent dans la technologie de contenu de la sortie.

NOTE 1 : Les conversions avec restructuration sont des conversions dans lesquelles la technologie de contenu ne change pas, mais les fonctions structurelles du contenu sont modifiées (par exemple tables de linéarisation, division d’un document en pages).

NOTE 2 : Les conversions avec reprogrammation sont des conversions dans lesquelles la technologie utilisée pour coder le contenu est modifiée.

11.8.4 Assistance au dépannage

Si les fonctions de vérification d’accessibilité d’un outil d’édition peuvent détecter que le contenu n’est pas conforme à une exigence desArticles 9 (Web) ou 10 (Documents non Web), selon le cas, l’outil d’édition doit alors fournir une ou plusieurs suggestions de dépannage.

NOTE :    Cela n’interdit pas le dépannage automatique ou semi-automatique possible (et encouragé) pour de nombreux types de problèmes d’accessibilité de contenu.

11.8.5 Modèles

Si un outil d’édition fournit des modèles, au moins un modèle prenant en charge la création de contenu conforme aux exigences des Articles 9 (Web) ou 10 (Documents non Web), selon le cas, doit être disponible et identifié en tant que tel.