[Aller au contenu]

W3C

Understanding WCAG 2.0

Lead translating organization:
Association BrailleNet
INSERM - UPMC B23
9 quai Saint Bernard
75252 Paris Cedex 05
France
Web site: http://www.braillenet.org/
Coordinator of the translation: Sylvie DUCHATEAU (e-mail: sylvie.duchateau@accessiweb.org)

Traduction Française agréée

Publication le 6 juillet 2011

Cette version :
http://www.w3.org/Translations/NOTE-UNDERSTANDING-WCAG20-fr/NOTE-UNDERSTANDING-WCAG20-fr-20110706/
Version la plus récente :
http://www.w3.org/Translations/NOTE-UNDERSTANDING-WCAG20-fr/
Version originale (anglais) :
http://www.w3.org/TR/UNDERSTANDING-WCAG20/
Errata :
http://www.braillenet.org/accessibilite/wcag20/errata.html
Organisation coordinatrice de la traduction :
Association BrailleNet
INSERM - UPMC B23
9 quai Saint Bernard
75252 Paris Cedex 05
France
Site Web : http://www.braillenet.org/
Coordinatrice de la traduction : Sylvie DUCHATEAU (courriel : sylvie.duchateau@accessiweb.org)
Partenaires du comité de traduction :
15 octobre 2009 : notification d'intention au W3C pour continuer en tant qu'Organisation Leader de la Traduction (LTO) de Understanding WCAG 2.0 en français.
Résumé des commentaires publics sur la Traduction Candidate Agréée (CAT) :
http://lists.w3.org/Archives/Public/w3c-translators/2011AprJun/0120.html

Ceci est une traduction agréée d'un document du W3C. La publication de cette traduction a suivi les étapes décrites dans la Politique des Traductions Agréées du W3C. En cas de litiges, la version faisant foi est le document original en anglais.

Version française, 6 juillet 2011 : Comprendre les WCAG 2.0

Version réalisée par le Comité de traduction en français de comprendre les WCAG 2.0

Un guide pour comprendre et mettre en œuvre la version 2.0 des Règles pour l'accessibilité des contenus Web

Note du groupe de travail du W3C du 14 octobre 2010

Version actuelle (anglais) :
http://www.w3.org/TR/2010/NOTE-UNDERSTANDING-WCAG20-20101014/
Version la plus récente (anglais) :
http://www.w3.org/TR/UNDERSTANDING-WCAG20/
Version antérieure (anglais) :
http://www.w3.org/TR/2008/NOTE-UNDERSTANDING-WCAG20-20081211/
Auteurs :
Michael Cooper, W3C
Loretta Guarino Reid, Google, Inc.
Gregg Vanderheiden, Trace R&D Center, université du Wisconsin-Madison
Ben Caldwell, Trace R&D Center, université du Wisconsin-Madison
Anciens auteurs :
Wendy Chisholm (jusqu'à juillet 2006 lorsqu'elle était au W3C)
John Slatin (jusqu'à juin 2006 lorsqu'il était à Accessibility Institute, université du Texas à Austin)

Le document est également disponible dans les formats non normatifs suivants :


Résumé

Ce document, « Comprendre les WCAG 2.0 » est un guide essentiel à la compréhension et l'utilisation de la version 2.0 des Règles pour l'accessibilité des contenus Web (WCAG) (en anglais) [WCAG20] et fait partie d'un ensemble de documents les accompagnant. Notez que le contenu de ce document est de nature informative (il fournit des orientations) et non de nature normative (il n'établit pas d'exigences de conformité aux WCAG 2.0). Consulter la Présentation des Règles pour l'accessibilité des contenus Web (WCAG) (en anglais) pour une introduction aux WCAG, aux documents techniques d'accompagnement et au matériel éducatif.

Les WCAG 2.0 établissent un ensemble de critères de succès visant à définir la conformité aux règles des WCAG 2.0. Un critère de succès est un énoncé testable qui, lorsque appliqué à un contenu Web spécifique, se soldera par vrai ou par faux. « Comprendre les WCAG 2.0 » fournit des informations détaillées à propos de chaque critère de succès, incluant son objectif, les mots clés utilisés et la manière dont le critère de succès vient en aide aux personnes vivant avec différents types de handicaps. Ce document fournit également des exemples de contenus qui satisfont à ce critère de succès employant diverses technologies Web (comme par exemple HTML, CSS ou XML), ainsi que des exemples de contenus Web qui ne satisfont pas ce critère de succès.

Ce document présente des techniques précises pour satisfaire à chaque critère de succès. Des précisions sur la manière d'implémenter chaque technique sont disponibles dans le document Techniques pour les WCAG 2.0 (en anglais), mais « Comprendre les WCAG 2.0 » fournit des informations à propos des relations établies entre les techniques et les critères de succès. Les techniques sont catégorisées en fonction du degré de support qu'elles fournissent à un critère de succès. Les « Techniques suffisantes » sont des techniques jugées suffisantes pour satisfaire à un critère de succès particulier (soit par elles-mêmes, soit conjointement avec d'autres techniques), alors que d'autres techniques relèvent davantage de conseils et sont par conséquent optionnelles. Aucune des techniques n'est requise pour satisfaire aux WCAG 2.0, bien que certaines puissent s'avérer la seule méthode connue dans certains contextes technologiques. Les « Techniques recommandées », prises individuellement, sont insuffisantes pour satisfaire un critère de succès (parce qu'il est impossible de les tester ou parce qu'elles apportent une réponse incomplète), mais il est recommandé de les suivre lorsque c'est possible pour améliorer l'accessibilité. Les « Échecs fréquents », décrivent quant à eux des pratiques courantes reconnues comme n'assurant pas la conformité des contenus Web aux WCAG 2.0. Bien que les échecs fournissent de l'information sur certaines pratiques de publication, il est important de les éviter afin de satisfaire aux objectifs de conformité des critères de succès des WCAG 2.0.

Ce document fait partie d'un ensemble de documents publiés par la Web Accessibility Initiative (Initiative pour l'accessibilité du Web WAI) du W3C afin d'accompagner les WCAG 2.0. Ce document a été publié en tant que Note du groupe de travail simultanément à la publication des WCAG 2.0 en tant que Recommandation du W3C. Contrairement aux WCAG 2.0, il est prévu que les informations contenues dans Comprendre les WCAG 2.0 soient mises à jour régulièrement. Consulter la Présentation des Règles pour l'accessibilité des contenus Web (WCAG) (en anglais) pour une introduction aux WCAG, aux documents techniques d'accompagnement et au matériel éducatif.

Statut du présent document

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent le remplacer. Une liste des publications actuelles du W3C et la dernière version corrigée de ce rapport technique peuvent être trouvées dans le catalogue des rapports techniques du W3C (en anglais) sur http://www.w3.org/TR/.

Ceci est la Note « Comprendre les WCAG 2.0 », émanant du groupe de travail sur les Règles pour l'accessibilité des contenus Web. Le groupe de travail estime que ce document est important pour comprendre les critères de succès de la Recommandation Règles pour l'accessibilité des contenus Web 2.0 (WCAG). Notez que le contenu de ce document est de nature informative (il fournit des orientations) et non de nature normative (il n'établit pas d'exigences de conformité aux WCAG 2.0).

Understanding WCAG 2.0 a été tout d'abord publié le 11 décembre 2008 en tant que Note du groupe de travail. Cette nouvelle version met à jour les informations qui accompagnent les WCAG 2.0. Notez que les WCAG 2.0 en elles-mêmes restent inchangées, et que seuls les documents informatifs d'accompagnement ont été mis à jour. Les changements principaux comprennent l'ajout de techniques Flash, et des clarifications basées sur les commentaires du public et de traducteurs. Les changements sont mis en évidence dans la version annotée (en anglais).

Le groupe de travail demande que tous les commentaires soient faits en utilisant le formulaire de commentaire en ligne (en anglais). Si cela n'est pas possible, les commentaires peuvent également être envoyés à l'adresse public-comments-wcag20@w3.org. Les archives de la liste de commentaires publics (en anglais) sont accessibles au public. Les commentaires reçus concernant ce document peuvent être pris en compte dans des versions futures de ce document, ou d'une autre manière. Le groupe de travail n'envisage pas de produire des réponses formelles aux commentaires. Les archives des listes de discussions du groupe de travail sur les WCAG (en anglais) sont publiques et les travaux futurs entrepris par le groupe de travail pourront tenir compte des commentaires reçus sur ce document.

Ce document fait partie des travaux de l'Initiative pour l'accessibilité du Web (en anglais) (WAI) du W3C. Les objectifs du groupe de travail sur les WCAG sont présentés dans la charte du groupe de travail sur les WCAG (en anglais). Le groupe de travail sur les WCAG fait partie de l'activité technique de la WAI (en anglais).

La publication en tant que note du groupe de travail n'implique pas son approbation par les membres du W3C. C'est un document brouillon qui peut être mis à jour, remplacé ou rendu caduc à tout moment par un nouveau document. Il est inapproprié de le citer dans un autre contexte que celui d'un travail en cours.

Ce document a été produit par un groupe œuvrant dans le cadre de la politique de brevets du W3C du 5 février 2004 (en anglais). Le W3C conserve une liste publique de toutes les divulgations des brevets (en anglais) faites en relation avec les livrables du groupe ; cette page inclut également les instructions concernant la divulgation d'un brevet. Un individu ayant la réelle connaissance d'un brevet dont il pense qu'il contient des « droits essentiels (en anglais) », doit révéler cette information en accord avec la section 6 de la politique des brevets du W3C (en anglais).


Table des matières

Annexes


Introduction à Comprendre les WCAG 2.0

Comprendre les WCAG 2.0 est un guide essentiel à la compréhension et à l'utilisation des « Règles pour l'accessibilité des contenus Web 2.0 » [WCAG20]. Bien que les définitions normatives et les exigences pour WCAG 2.0 se retrouvent directement dans le document WCAG 2.0 en lui-même, les dispositions et les concepts peuvent être nouveaux pour certaines personnes. Comprendre les WCAG 2.0 fournit des informations complémentaires de nature non normative à propos de chaque règle et critère de succès afin de venir en aide aux lecteurs et permettre de mieux comprendre l'objectif et la relation entre les règles et les critères de succès. De plus, ce document fournit des exemples de techniques ou de combinaisons de techniques que le groupe de travail a identifiées comme étant suffisantes pour satisfaire à chaque critère de succès. Des liens supplémentaires sont également proposés pour chaque technique.

Ce document n'est pas un document introductif. Il s'agit de descriptions techniques détaillées pour les règles et leurs critères de succès. Consulter la Présentation des Règles pour l'accessibilité des contenus Web (WCAG) (en anglais) pour une introduction aux WCAG, aux documents techniques d'accompagnement et au matériel éducatif.

Comprendre les WCAG 2.0 est présenté par règle. Chaque règle comprend une section intitulée Comprendre la règle X.X. L'objectif et toutes techniques recommandées qui sont liées à une règle sans pour autant être rattachées à un critère de succès spécifique y sont également listées.

La section Comprendre la règle X.X est suivie d'une section Comprendre le critère de succès X.X.X et ce, pour chaque critère de succès rattaché à une règle. Chacune de ces sections contient :

Des liens sont établis entre chaque règle des WCAG 2.0 et la section Comprendre la règle X.X correspondante de ce document. De même, un lien est proposé à partir de chaque critère de succès des WCAG 2.0 vers la section Comprendre le critère de succès X.X.X correspondante de ce document.

Pour obtenir des informations sur une technique spécifique, suivez le lien correspondant dans ce document vers la technique qui vous intéresse en vous référant à Techniques pour les WCAG 2.0 (en anglais).

Pour des liens vers des informations sur les différentes limitations fonctionnelles et les technologies d'assistance, consulter Limitations fonctionnelles, chez Wikipédia (en anglais).

Comprendre les quatre principes de l'accessibilité

Les règles et les critères de succès sont organisés autour des quatre principes suivants, qui représentent la base nécessaire pour quiconque voulant accéder et utiliser les contenus Web. Chaque individu qui souhaite utiliser le Web doit avoir du contenu qui est :

  1. Perceptible - L'information et les composants de l'interface utilisateur doivent être présentés à l'utilisateur de façon à ce qu'il puisse les percevoir.

    • Cela signifie que l'utilisateur doit être capable de percevoir les informations présentées (elles ne peuvent être invisibles à tous leurs sens)

  2. Utilisable - Les composants de l'interface utilisateur et de navigation doivent être utilisables.

    • Cela signifie que l'utilisateur doit être en mesure d'utiliser l'interface (l'interface ne peut pas exiger une interaction qu'un utilisateur ne peut effectuer)

  3. Compréhensible - Les informations et l'utilisation de l'interface utilisateur doivent être compréhensibles.

    • Cela signifie que l'utilisateur doit être en mesure de comprendre l'information ainsi que l'utilisation de l'interface utilisateur (le contenu ou l'utilisation ne peuvent pas aller au-delà de sa compréhension.)

  4. Robuste - Le contenu doit être suffisamment robuste pour être interprété de manière fiable par une large variété d'agents utilisateurs, y compris les technologies d'assistance.

    • Cela signifie que l'utilisateur doit être en mesure d'accéder au contenu au fur et à mesure que les technologies progressent (au fur et à mesure que les technologies et les agents utilisateurs évoluent, le contenu doit rester accessible)

Si l'un de ces principes n'est pas vrai, les utilisateurs en situation de handicap ne seront pas en mesure d'utiliser le Web.

Après chaque principe il y a les règles et les critères de succès qui permettent d'appliquer ces principes pour les personnes en situation de handicap. Il y a beaucoup de règles générales sur la facilité d'utilisation qui rendent le contenu plus utilisable par tous, y compris les personnes avec des limitations fonctionnelles. Cependant, les WCAG 2.0 n'incluent que les règles qui gèrent les problèmes propres aux personnes en situation de handicap. Cela comprend les problèmes qui empêchent l'accès ou qui interfèrent plus sévèrement avec l'accès au Web pour les personnes avec des limitations fonctionnelles.

Les niveaux de lecture

Les règles

Après chaque principe il y a une liste de règles traitant de ce principe. Au total, il y a 12 règles. On trouve une liste pratique avec uniquement les règles dans la table des matières des WCAG 2.0. L'un des objectifs clés de ces règles et de faire en sorte que le contenu soit directement accessible au plus grand nombre possible de personnes, et qu'il puisse être représenté sous différentes formes pour répondre aux différentes capacités sensorielles, physiques et cognitives des personnes.

Les critères de succès

Après chaque règle, il y a des critères de succès décrivant spécifiquement ce qui doit être accompli pour être conforme à ce standard. Ces critères de succès sont similaires aux « points de contrôle (checkpoints) » dans les WCAG 1.0. Chaque critère de succès est écrit sous la forme d'un énoncé qui sera vrai ou faux lorsqu'un contenu Web spécifique est testé pour ce critère. Les critères de succès sont écrits de façon à être neutres par rapport à une technologie.

Tous les critères de succès des WCAG 2.0 sont écrits comme des critères testables afin de déterminer de façon objective si le contenu est conforme aux critères de succès. Tandis que certains des tests peuvent être automatisés à l'aide d'outils d'évaluation, d'autres nécessitent des êtres humains pour tout ou partie du test.

Même si le contenu satisfait aux critères de succès il peut ne pas toujours être utilisable par des personnes ayant une variété de limitations fonctionnelles. Des évaluations professionnelles utilisant une heuristique qualitative reconnue sont importantes afin d'atteindre l'accessibilité pour certains publics. De plus, des tests sur la facilité d'utilisation sont recommandés. Les tests sur la facilité d'utilisation ont pour but de déterminer dans quelle mesure on peut utiliser le contenu dans le but recherché.

Le contenu doit être testé par les gens qui comprennent comment les personnes ayant différents types de limitations fonctionnelles utilisent le Web. Il est recommandé que des utilisateurs en situation de handicap soient inclus dans les groupes de tests lorsque des tests humains sont effectués.

Chaque critère de succès d'une règle est lié à la section du document How to Meet (comment satisfaire) qui fournit :

  • des techniques suffisantes pour satisfaire au critère de succès,

  • des techniques recommandées optionnelles, et

  • la description de l'objectif du critère de succès, comprenant les avantages et des exemples.

Techniques suffisantes et recommandées

Au lieu d'avoir des techniques spécifiques à une technologie dans les WCAG 2.0, les règles et critères de succès ont été eux-mêmes écrits de façon à être neutres vis-à-vis d'une technologie. Afin de fournir un accompagnement et des exemples pour satisfaire aux règles en utilisant des technologies spécifiques (par exemple HTML), le groupe de travail a identifié des techniques suffisantes pour chaque critère de succès qui sont suffisantes pour satisfaire à ce critère de succès. Les techniques suffisantes sont proposées sous forme d'une liste numérotée dans laquelle chaque élément de liste fournit la technique ou la combinaison de techniques pouvant être utilisée pour satisfaire au critère de succès. S'il y a plusieurs techniques sur un élément de liste numéroté reliées par « ET » alors toutes les techniques doivent être utilisées. Par exemple, la situation B dans Comprendre le critère de succès 2.2.1 donne en troisième technique suffisante : SCR16 : Fournir un script qui avertit l'utilisateur que le délai va expirer (programmation par script) ET SCR1 : Permettre à l'utilisateur de prolonger le délai par défaut (programmation par script).

La liste des techniques suffisantes est maintenue dans le document « Comprendre les WCAG 2.0 » (et reprise dans le document How to Meet WCAG 2.0). L'introduction aux Techniques pour les WCAG 2.0 (en anglais) donne la liste des technologies pour lesquelles il existe actuellement des techniques suffisantes. En dissociant le document normatif des règles WCAG 2 des techniques utilisées pour satisfaire aux critères de succès de ces règles il est possible de mettre à jour la liste lorsque de nouvelles techniques sont découvertes, et au fur et à mesure que les technologies Web et les technologies d'assistance progressent.

Notez que toutes les techniques sont informatives. Les « techniques suffisantes » sont considérées comme suffisantes par le groupe de travail des WCAG pour satisfaire aux critères de succès. Cependant, il n'est pas nécessaire d'utiliser ces techniques particulières. Si des techniques autres que celles listées par le groupe de travail devaient être utilisées, alors une autre méthode permettant d'établir la capacité de la technique à satisfaire aux critères de succès serait nécessaire.

La plupart des critères de succès ont une liste de plusieurs techniques suffisantes. Toute technique suffisante listée peut être utilisée pour satisfaire au critère de succès. Il peut y avoir d'autres techniques qui ne sont pas documentées par le groupe de travail qui pourraient aussi satisfaire au critère de succès. Lorsque de nouvelles techniques seront identifiées elles seront ajoutées à la liste.

En complément des techniques suffisantes, il y a un nombre de techniques recommandées qui peuvent améliorer l'accessibilité, mais qui n'ont pas été considérées comme des techniques suffisantes car elles ne sont pas suffisantes pour répondre à toutes les exigences des critères de succès, elles ne sont pas testables, et/ou parce qu'il s'agit de techniques bonnes et efficaces dans certaines circonstances mais qu'elles ne sont pas efficaces ou utiles dans d'autres. Celles-ci sont listées comme techniques recommandées et se trouvent juste après les techniques suffisantes. Les auteurs sont encouragés à utiliser ces techniques là où elles sont appropriées pour augmenter l'accessibilité de leurs pages Web.

Note : les exemples de code qui se trouvent dans les techniques suffisantes ont pour but de montrer le principe traité dans la description de la technique. Le code n'a pas pour objectif de montrer d'autres aspects de l'accessibilité, de la facilité d'utilisation ou de bonnes pratiques de code qui ne sont pas liés à la technique.


Les équivalents textuels :
Comprendre la règle 1.1

Règle 1.1 : proposer des équivalents textuels à tout contenu non textuel qui pourra alors être présenté sous d'autres formes selon les besoins de l'utilisateur : grands caractères, braille, synthèse vocale, symboles ou langage simplifié.

Objectif de la règle 1.1

L'objectif de cette règle est de s'assurer que tout contenu non textuel est aussi disponible en texte. « Texte » fait référence au texte électronique, et non à un texte sous forme d'image. Le texte électronique a l'avantage unique d'être neutre d'un point de vue présentation. Ce qui signifie qu'il peut être restitué visuellement, auditivement, tactilement ou par n'importe quelle combinaison de ces moyens. Par conséquent, l'information en texte électronique peut être présentée sous la forme qui répond le mieux aux besoins de l'utilisateur. Elle peut aussi être facilement agrandie, lue à haute voix de façon à ce qu'elle soit plus facile à comprendre pour les personnes ayant des difficultés de lecture, ou être restituée sous la forme tactile qui répond le mieux aux besoins d'un utilisateur.

Note : quoique le changement de contenu en symboles inclue le changement en symboles graphiques pour les personnes ayant des problèmes de développement et des difficultés de compréhension du langage, cela ne se limite pas à une telle utilisation des symboles.

Techniques recommandées pour la règle 1.1 (sans rattachement à un critère de succès spécifique)

Les techniques spécifiques pour satisfaire à chaque critère de succès de cette règle sont listées dans les sections Comprendre de chaque critère de succès (énumérés ci-dessous). Cependant, si des techniques permettant de traiter cette règle ne se rapportent à aucun critère de succès, elles sont listées ici. Ces techniques ne sont pas requises ou suffisantes pour satisfaire à un critère de succès, mais peuvent rendre certains types de contenus Web plus accessibles à un plus grand nombre de personnes.

  • Fournir des vidéos en langue des signes pour les fichiers seulement audio (lien à venir)

Contenu non textuel :
Comprendre le CS 1.1.1

1.1.1 Contenu non textuel : tout contenu non textuel présenté à l'utilisateur a un équivalent textuel qui remplit une fonction équivalente sauf dans les situations énumérées ci-dessous. (Niveau A)

  • Composant d'interface ou de saisie : si le contenu non textuel est un composant d'interface ou s'il permet la saisie d'informations par l'utilisateur, alors il a un nom qui décrit sa fonction. (Se référer à la Règle 4.1 pour des exigences supplémentaires à propos des composants d'interfaces utilisateurs ou des contenus qui permettent la saisie d'informations par l'utilisateur.)

  • Média temporel : si le contenu non textuel est un média temporel, alors les équivalents textuels fournissent au moins une identification descriptive du contenu non textuel. (Se référer à la Règle 1.2 pour des exigences supplémentaires concernant les médias temporels.)

  • Test : si le contenu non textuel est un test ou un exercice qui serait invalide s'il était présenté en texte, alors les équivalents textuels fournissent au moins une identification descriptive du contenu non textuel.

  • Contenu sensoriel : si le contenu non textuel vise d'abord à créer une expérience sensorielle spécifique, l'équivalent textuel fournit au moins une identification descriptive de ce contenu non textuel.

  • CAPTCHA : si ce contenu non textuel vise à confirmer que le contenu est consulté par une personne plutôt que par un ordinateur, alors un équivalent textuel est fourni pour identifier et décrire la fonction du contenu non textuel, et des formes alternatives du CAPTCHA sont proposées pour différents types de perception sensorielle afin d'accommoder différents types de limitations fonctionnelles.

  • Décoration, formatage, invisibilité : si le contenu non textuel est purement décoratif, s'il est utilisé seulement pour un formatage visuel ou s'il n'est pas présenté à l'utilisateur, alors il est implémenté de manière à être ignoré par les technologies d'assistance.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de rendre accessible l'information transmise par un contenu non textuel par l'utilisation d'un équivalent textuel. Les équivalents textuels sont un moyen privilégié pour rendre l'information accessible, car ils peuvent être restitués selon n'importe quelle modalité sensorielle (par exemple visuelle, auditive ou tactile) pour répondre aux besoins de l'utilisateur. Fournir des équivalents textuels permet de présenter l'information de façons variées pour une diversité d'agents utilisateurs. Par exemple, une personne qui ne peut pas voir une image peut obtenir que l'équivalent textuel soit lu à haute voix par une synthèse vocale. Une personne qui ne peut entendre un fichier audio peut avoir l'équivalent textuel présenté de telle sorte qu'il ou elle peut le lire. À l'avenir, les équivalents textuels vont aussi permettre de traduire plus facilement l'information en langue des signes ou dans une forme plus simple de la même langue.

Note à propos des CAPTCHA

Les CAPTCHA (en français, test public de Turing entièrement automatique ayant pour but de distinguer les humains des ordinateurs), constituent un sujet controversé dans la communauté de l'accessibilité. Comme décrit dans le document L'inaccessibilité des CAPTCHA (en anglais), intrinsèquement, les CAPTCHA poussent les limites des capacités humaines dans une tentative de vaincre les processus automatisés. Chaque type de CAPTCHA sera insoluble par les utilisateurs ayant certaines limitations. Quoi qu'il en soit, ils sont largement utilisés, et le groupe de travail sur les Règles pour l'accessibilité des contenus Web croit que, si les CAPTCHA étaient interdits purement et simplement, des sites Web pourraient choisir de ne pas se conformer aux WCAG plutôt que d'abandonner les CAPTCHA. Cela créerait des barrières pour un plus grand nombre d'utilisateurs ayant des limitations. Pour cette raison, le groupe de travail a choisi de structurer les exigences à propos des CAPTCHA de façon à répondre aux besoins de la plupart des personnes ayant des limitations et à mériter considération en vue d'une adoption par les sites Web. Exiger deux formes différentes de CAPTCHA dans un même site assure que la plupart des personnes ayant des limitations trouveront une forme qu'ils seront en mesure d'utiliser.

Parce que certains utilisateurs ayant des limitations seront encore incapables d'accéder aux sites qui satisfont aux exigences minimales, le groupe de travail donne des recommandations pour aller plus loin. Les organisations qui veulent se conformer aux WCAG devraient être conscientes de l'importance de ce sujet et devraient aller aussi loin que possible au-delà des exigences minimales. Les étapes supplémentaires recommandées sont :

Informations supplémentaires

Le contenu non textuel peut prendre plusieurs formes et ce critère de succès précise comment chacune de ces formes sera traitée.

Pour un contenu non textuel qui n'est pas couvert par l'une des situations listées ci-dessous, comme des graphiques, des diagrammes, des enregistrements audio et des animations, les équivalents textuels peuvent rendre disponible la même information sous une forme qui peut être restituée par n'importe quelle modalité (par exemple visuelle, auditive ou tactile). Selon les besoins, des équivalents textuels brefs ou longs peuvent être utilisés pour transmettre l'information du contenu non textuel. Notez qu'un contenu seulement audio pré-enregistré et un contenu seulement vidéo pré-enregistré sont traités ici. Les fichiers seulement audio en direct et seulement vidéo en direct sont traités plus loin (au troisième paragraphe suivant celui-ci).

Pour un contenu non textuel qui est un composant d'interface ou de saisie, comme des images utilisées pour un bouton soumettre, des images à zones cliquables ou des animations complexes, un nom est fourni pour décrire la fonction du contenu non textuel de façon à ce que l'utilisateur sache ce qu'est ce contenu non textuel et pourquoi il est là.

Un contenu non textuel qui est un média temporel est rendu accessible par 1.2. Toutefois, il est important que les utilisateurs sachent de quoi il s'agit quand ils rencontrent ce contenu sur une page afin de savoir quelle action effectuer, s'il y a lieu, par rapport à celui-ci. Un équivalent textuel qui décrit le média temporel ou donne son titre est alors fourni.

Pour un contenu seulement audio ou seulement vidéo en direct, il peut être plus difficile de fournir un équivalent textuel qui donne une information équivalente à un contenu seulement audio ou seulement vidéo en direct. Pour ces types de contenu non textuel, les équivalents textuels fournissent une identification descriptive.

Dans certains cas, un test ou un exercice doit être partiellement ou entièrement présenté dans un format non textuel. L'information auditive ou visuelle alors donnée ne peut pas être transformée en texte parce que le test ou l'exercice doit être réalisé selon cette modalité sensorielle. Par exemple un test d'audition serait invalide si un équivalent textuel était fourni. De même, un exercice sur le développement d'habiletés visuelles perdrait tout son sens sous forme de texte, et un test d'épellation avec un équivalent textuel ne serait pas très efficace. Dans ces cas, des équivalents textuels devraient être fournis pour décrire la fonction du contenu non textuel ; bien sûr, l'équivalent textuel ne donnera pas la même information nécessaire à la réussite du test.

Un contenu vise parfois à créer une expérience sensorielle spécifique que des mots ne peuvent entièrement saisir. Parmi les exemples, mentionnons l'exécution d'une symphonie, des œuvres d'art visuel, etc. Pour de tels contenus, les équivalents textuels identifient le contenu non textuel avec une étiquette descriptive et, lorsque possible, un texte descriptif supplémentaire. Si la raison de l'inclusion de ce contenu dans la page est connue et peut être décrite, il est utile d'inclure cette information.

Des exercices non textuels sont parfois utilisés pour prouver que vous êtes humain. Un dispositif appelé CAPTCHA est utilisé pour éviter de donner accès à un site aux robots de pourriels et aux autres logiciels. Cela implique généralement une tâche visuelle ou auditive qui dépasse les capacités actuelles des robots. Fournir un équivalent textuel de ces tâches les rendrait toutefois exécutables par les robots et contredirait donc leur fonction. Dans un tel cas, l'équivalent textuel pourrait décrire la fonction du CAPTCHA et des formes alternatives seraient proposées pour différents types de perception sensorielle afin d'accommoder différents types de limitations fonctionnelles.

Certains contenus non textuels sont vraiment conçus dans le but de ne pas être vus ou compris par l'utilisateur. Des images transparentes utilisées pour placer du texte sur une page ; une image invisible qui est utilisée pour compiler des statistiques d'utilisation ; une spirale dans un coin qui n'est porteuse d'aucune information mais remplit simplement un espace vide pour créer un effet esthétique constituent autant d'exemples de ce type de contenus. Placer un équivalent textuel sur de tels éléments n'aboutirait qu'à distraire du contenu de la page les personnes utilisant des lecteurs d'écran. Ne pas marquer du tout ce contenu laisse les utilisateurs perplexes par rapport à ce qu'est ce contenu non textuel et à l'information qu'ils ont manquée (même si, en réalité, ils n'ont rien manqué). Ce type de contenu non textuel est donc marqué ou implémenté de façon à être ignoré par les technologies d'assistance (TA) sans que rien ne soit présenté à l'utilisateur.

Avantages spécifiques du critère de succès 1.1.1 :

  • Ce critère de succès aide les personnes qui ont de la difficulté à percevoir le contenu visuel. Les technologies d'assistance peuvent lire le texte à haute voix, le présenter visuellement ou le convertir en braille.

  • Les équivalents textuels peuvent aider certaines personnes ayant de la difficulté à comprendre la signification d'une photo, d'un dessin ou d'autres images (par exemple des dessins linéaires, des graphismes, des peintures, des représentations en trois dimensions), des graphiques, des diagrammes, des animations, etc.

  • Les personnes sourdes, malentendantes ou qui ont de la difficulté à comprendre l'information audio pour quelque raison peuvent lire la présentation textuelle. Par ailleurs, les recherches se poursuivent concernant la traduction automatique du texte en langue des signes.

  • Les personnes sourdes-aveugles peuvent lire le texte en braille.

  • De plus, les équivalents textuels donnent la possibilité de rechercher le contenu non textuel et de réutiliser ce contenu de diverses façons.

Exemples pour le critère de succès 1.1.1

  1. Un graphique

    Un graphique à barres compare combien d'accessoires ont été vendus en juin, juillet et août. La description brève dit : « Figure un - Ventes de juin, juillet et août. » La longue description précise le type de graphique, donne un résumé général des données, des tendances et des implications qui donne une information comparable à celle qui est disponible à partir du graphique. Et, lorsque cela est possible et pratique, les données réelles sont présentées dans un tableau.

  2. L'enregistrement audio d'un discours

    Le lien vers un clip audio dit : « Le président s'adresse à l'assemblée. » Un lien vers une transcription textuelle est placé immédiatement après le lien vers le clip audio.

  3. Une animation qui illustre le fonctionnement d'un moteur de voiture

    Une animation montre comment fonctionne le moteur d'une voiture. Il n'y a pas de piste audio et l'animation fait partie d'un tutoriel qui décrit le fonctionnement d'un moteur. Étant donné que le texte du tutoriel donne déjà une explication complète, l'image est un équivalent pour le texte et l'équivalent textuel inclut seulement une brève description de l'animation et réfère au texte du tutoriel pour plus d'information.

  4. Une webcaméra de circulation

    Un site Web permet aux utilisateurs de choisir parmi une variété de webcaméras situées à travers une ville importante. Une fois qu'une caméra est choisie, l'image est mise à jour toutes les deux minutes. Un court équivalent textuel identifie la webcaméra comme : « Webcaméra de circulation. » Le site offre aussi un tableau des temps de déplacement pour chacune des routes couvertes par la webcaméra. Le tableau est aussi mis à jour toutes les deux minutes.

  5. Une photo d'un événement historique dans un article des nouvelles

    Une photo de deux leaders mondiaux se donnant la main accompagne un article des nouvelles à propos d'une réunion internationale au sommet. L'équivalent textuel dit : « Le président X du pays X serre la main au premier ministre Y du pays Y. »

  6. Une photo d'un événement historique dans un contenu discutant des relations diplomatiques

    La même image est utilisée dans un contexte différent visant à expliquer les nuances dans les rencontres diplomatiques. L'image du président serrant la main au premier ministre apparaît sur un site Web qui discute de la complexité des relations diplomatiques. Le premier équivalent textuel se lit : « Le président X du pays X serre la main au premier ministre Y du pays Y, le 2 janvier 2009. » Un équivalent textuel supplémentaire décrit la pièce où se tiennent les leaders ainsi que les expressions de leurs visages et nomme les autres personnes présentes dans la pièce. La description supplémentaire peut être incluse sur la même page que la photo ou dans un fichier distinct associé à l'image par un lien ou par un autre mécanisme standard de programmation.

  7. Un enregistrement audio d'une conférence de presse

    Une page Web comporte un lien vers l'enregistrement audio d'une conférence de presse. Le libellé du lien identifie l'enregistrement audio. La page offre aussi un lien vers une transcription textuelle de la conférence de presse. La transcription inclut le verbatim de tout ce que disent les intervenants. Elle identifie la personne qui parle et note aussi tout bruit significatif qui fait partie de l'enregistrement comme les applaudissements, les rires, les questions du public et ainsi de suite.

  8. Une application d'apprentissage virtuel

    Une application d'apprentissage virtuel (e-learning) utilise des effets sonores pour indiquer si les réponses sont correctes ou non. Le carillon indique que la réponse est correcte alors que le bip indique que la réponse est incorrecte. Une description textuelle est aussi donnée pour que les personnes qui ne peuvent entendre ou comprendre le son puissent comprendre si la réponse est correcte ou incorrecte.

  9. Une vignette lien

    Une vignette de la une d'un journal est utilisée comme lien vers la page d'accueil du « Smallville Times ». L'équivalent textuel dit : « Smallville Times ».

  10. La même image utilisée sur différents sites

    Différents équivalents pour une image de la terre : une image de la terre utilisée sur un site de voyage comme lien vers la section sur les voyages internationaux comporte l'équivalent textuel suivant : « Voyages internationaux ». La même image est utilisée dans le site Web d'une université avec l'équivalent textuel : « Campus internationaux ».

  11. Une image à zones cliquables

    L'image du plan de l'étage d'un édifice est interactive afin de permettre à l'utilisateur de sélectionner une pièce particulière et de se diriger vers une page donnant de l'information à propos de cette pièce. Le bref équivalent textuel décrit l'image et sa fonction interactive : « Plan de l'étage de l'édifice. Sélectionner une pièce pour plus d'information. »

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.1.1 - Contenu non textuel

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : si une courte description peut remplir la même fonction et présenter la même information que le contenu non textuel :
  1. G94 : Fournir un court équivalent textuel pour un contenu non textuel qui a la même fonction et présente la même information que le contenu non textuel (en anglais) en utilisant une technique pour un bref équivalent textuel listée ci-dessous

Situation B : si une description courte ne peut pas remplir la même fonction et présenter la même information que le contenu non textuel (par exemple un graphique ou un diagramme) :
  1. G95 : Fournir un court équivalent textuel qui donne une brève description du contenu non textuel (en anglais) en utilisant une technique pour un bref équivalent textuel listée ci-dessous ET l'une des techniques suivantes pour une longue description :

Situation C : si un contenu non textuel est un composant d'interface ou s'il permet la saisie d'informations par l'utilisateur :
  1. G82 : Fournir un équivalent textuel qui identifie la fonction du contenu non textuel (en anglais) en utilisant une technique pour un bref équivalent textuel listée ci-dessous

  2. H44 : Utiliser l'élément label pour associer les étiquettes avec les champs de formulaire (en anglais) (HTML)

  3. H65 : Utiliser l'attribut title pour identifier un champ de formulaire quand l'élément label ne peut pas être utilisé (en anglais) (HTML)

  4. FLASH32 : Utiliser l'étiquetage automatique pour associer les étiquettes textuelles aux éléments de formulaire. (en anglais) (Flash)

  5. FLASH29 : Définir la propriété label pour les éléments de formulaire (en anglais) (Flash)

  6. FLASH25 : Donner une étiquette à un élément de formulaire en spécifiant sa propriété name (en anglais) (Flash)

  7. FLASH30 : Préciser la propriété name pour les boutons images (en anglais) (Flash)

  8. FLASH27 : Fournir des étiquettes de boutons qui en décrivent la fonction (en anglais) (Flash)

  9. FLASH6 : Créer des zones interactives accessibles en utilisant des boutons invisibles (en anglais) (Flash)

Situation D : si le contenu non textuel est un média temporel (incluant un contenu en direct seulement vidéo ou seulement audio) ; un test ou un exercice qui serait invalide s'il était présenté en texte ou un contenu qui vise d'abord à créer une expérience sensorielle spécifique :
  1. Fournir une étiquette descriptive en utilisant une technique pour un bref équivalent textuel listée ci-dessous

  2. G68 : Fournir une étiquette descriptive pour décrire la fonction d'un contenu en direct seulement audio et seulement vidéo (en anglais) en utilisant une technique pour un bref équivalent textuel listée ci-dessous

  3. G100 : Fournir le nom reconnu ou un nom descriptif pour un contenu non textuel (en anglais) en utilisant une technique pour un bref équivalent textuel listée ci-dessous

Situation E : si le contenu non textuel est un CAPTCHA :
  1. G143 : Fournir un équivalent textuel qui décrit la fonction du CAPTCHA (en anglais) ET G144 : S'assurer que la page Web contient un autre CAPTCHA remplissant la même fonction et utilisant une modalité différente (en anglais)

Situation F : si le contenu non textuel devait être ignoré par les technologies d'assistance :
  1. Implémenter ou marquer le contenu non textuel de façon à ce qu'il soit ignoré par les technologies d'assistance en utilisant l'une des techniques spécifiques à une technologie parmi celles listées ci-dessous

Techniques pour un bref équivalent textuel à utiliser dans les techniques suffisantes ci-dessus
  1. H36 : Utiliser un attribut alt sur une image utilisée comme bouton soumettre (en anglais) (HTML)

  2. H2 : Combiner en un même lien une image et un intitulé de lien pour la même ressource (en anglais) (HTML)

  3. H37 : Utiliser l'attribut alt sur l'élément img (en anglais) (HTML)

  4. H35 : Fournir un équivalent textuel pour l'élément applet (en anglais) (HTML)

  5. H53 : Utiliser le corps de l'élément object (en anglais) (HTML)

  6. H24 : Fournir un équivalent textuel pour l'élément area d'une image à zones cliquables (en anglais) (HTML)

  7. H86 : Fournir un équivalent textuel pour l'art ASCII, les émoticônes et le leetspeak (en anglais) (HTML)

  8. FLASH28 : Fournir un équivalent textuel pour l'art ASCII, les émoticones et le leetspeak dans Flash (en anglais) (Flash)

  9. H30 : Fournir un intitulé de lien qui décrit la fonction du lien pour un élément anchor (en anglais) (HTML)

  10. G196 : Utiliser un équivalent textuel sur un item d'un groupe d'images pour décrire l'ensemble des items du groupe (en anglais)

  11. FLASH1 : Définir la propriété name pour un objet non textuel (en anglais) (Flash)

Techniques pour un long équivalent textuel à utiliser dans les techniques suffisantes ci-dessus
  1. H45 : Utiliser longdesc (en anglais) (HTML)

  2. H53 : Utiliser le corps de l'élément object (en anglais) (HTML)

  3. FLASH2 : Définir la propriété description pour un objet non textuel dans Flash. (en anglais) (Flash)

  4. FLASH11 : Fournir une description textuelle plus longue pour un objet (en anglais) (Flash)

Techniques (recommandées) supplémentaires pour 1.1.1

Bien qu'elles ne soient pas nécessaires à la conformité, les supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Techniques générales (recommandées) pour un contenu non textuel informatif
  • Identifier un contenu non textuel informatif (lien à venir)

  • Garder brèves les descriptions courtes (lien à venir)

  • Décrire les images qui comportent du texte (lien à venir)

  • Fournir une description plus longue d'un contenu non textuel lorsque seule une étiquette descriptive est exigée, en utilisant une technique spécifique à une technologie (pour une technologie compatible avec l'accessibilité) pour une longue description ; techniques listées ci-dessus (lien à venir)

  • Fournir différentes tailles pour un contenu non textuel lorsqu'il ne peut avoir une version équivalente accessible (lien à venir)

  • Utiliser des scripts côté serveur pour modifier la taille des textes sous forme d'images (lien à venir)

Techniques générales (recommandées) pour un contenu non textuel en direct
  • Lier à de l'information textuelle qui donne une information comparable (par exemple pour une webcaméra de circulation, une municipalité fournit un lien vers un rapport textuel sur la circulation.) (lien à venir)

Techniques générales pour abaisser la barrière que constituent les CAPTCHA
  • Fournir plus de deux modalités de CAPTCHA (lien à venir)

  • Donner accès à un représentant du service à la clientèle qui peut passer outre au CAPTCHA (lien à venir)

  • Ne pas recourir au CAPTCHA pour les utilisateurs autorisés (lien à venir)

Techniques HTML (recommandées)
Techniques CSS (recommandées)
Techniques ARIA (recommandées)
  • Utiliser le rôle ARIA presentation pour indiquer les éléments utilisés uniquement à des fins de présentation (lien à venir)

Techniques des métadonnées (recommandées)
  • Utiliser des métadonnées pour associer une transcription textuelle avec une vidéo (lien à venir)

  • Utiliser des métadonnées pour associer une transcription textuelle avec un contenu seulement audio (lien à venir)

    • EXEMPLE : Fournir dans les métadonnées une ou des URI pointant vers une audio-description et une transcription textuelle pour une vidéo.

    • EXEMPLE : Fournir dans les métadonnées une ou des URI pointant vers plusieurs transcriptions textuelles d'un fichier audio (en français, en anglais et en néerlandais).

Échecs fréquents pour le CS 1.1.1

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.1.1.

Mots clés

CAPTCHA

sigle de « Completely Automated Public Turing test to tell Computers and Humans Apart » (test public de Turing entièrement automatique ayant pour but de distinguer les humains des ordinateurs)

Note 1 : les tests de type CAPTCHA demandent souvent à l'utilisateur de taper un texte présenté dans une image ou un extrait audio déformés.

Note 2 : un test de Turing est tout système de tests conçu pour distinguer un humain d'un ordinateur. Il est nommé en l'honneur du célèbre informaticien Alan Turing. Ce terme a été popularisé par les chercheurs de l'Université Carnegie Mellon. [CAPTCHA]

contenu non textuel

tout contenu qui n'est pas une suite de caractères déterminée par un programme informatique ou suite de caractères sans signification dans aucune langue

Note : cela inclut l'art ASCII (qui est un dessin à base de caractères), les émoticônes, l'écriture « leetspeak » (qui utilise la substitution de caractères) et les images représentant du texte.

équivalent textuel

Texte associé par programmation à un contenu non textuel ou dont il est fait mention depuis un texte associé par programmation à un contenu non textuel. Un texte associé par programmation est un texte dont l'emplacement peut être déterminé par programmation depuis le contenu non textuel.

Exemple : l'image d'un graphique est décrite textuellement dans le paragraphe suivant le graphique. Le bref équivalent textuel du graphique indique que la description suit celui-ci.

Note : se référer à Comprendre les équivalents textuels pour plus d'informations.

expérience sensorielle spécifique

une expérience sensorielle qui n'est pas purement décorative et dont l'objectif premier n'est pas de transmettre une information importante ou d'accomplir une fonction

Exemple : on compte parmi les exemples un morceau de flûte solo, des œuvres d'art visuel, etc.

nom

texte grâce auquel un logiciel peut identifier pour l'utilisateur un composant du contenu Web

Note 1 : le nom peut être caché et présenté seulement aux technologies d'assistance, alors qu'une étiquette est présentée à tous les utilisateurs. Dans de nombreux cas (mais pas dans tous), l'étiquette et le nom sont identiques.

Note 2 : celui-ci n'a pas de lien avec l'attribut HTML name.

purement décoratif

utilisé seulement dans un but esthétique, ne fournissant aucune information et n'ayant aucune fonctionnalité

Note : un texte est purement décoratif si les mots peuvent être réarrangés ou remplacés sans changer leur raison d'être.

Exemple : la page couverture d'un dictionnaire présente un arrière-plan estompé et constitué de mots choisis au hasard.

technologie d'assistance (tel qu'utilisé dans ce document)

matériel ou logiciel qui agit comme agent utilisateur ou simultanément avec un agent utilisateur usuel afin de fournir des fonctionnalités répondant aux besoins des utilisateurs ayant des limitations fonctionnelles, fonctionnalités qui vont au-delà de celles qui sont offertes par les agents utilisateurs usuels

Note 1 : les fonctionnalités fournies par les technologies d'assistance comprennent des présentations de remplacement (par exemple de la synthèse vocale ou du contenu agrandi), des méthodes de saisie alternatives (par exemple la voix), des mécanismes de navigation ou d'orientation supplémentaires et des transformations de contenu (par exemple pour rendre un tableau plus accessible).

Note 2 : les technologies d'assistance communiquent souvent les données et les messages aux agents utilisateurs usuels en utilisant et en surveillant le fonctionnement d'une API (interface de programmation).

Note 3 : la distinction entre agents utilisateurs usuels et technologies d'assistance n'est pas absolue. Plusieurs agents utilisateurs usuels comportent des fonctions d'assistance aux utilisateurs ayant des limitations fonctionnelles. La principale différence est que ces agents utilisateurs usuels visent un public large et diversifié qui comprend des personnes avec et sans limitations fonctionnelles. Les technologies d'assistance visent des populations plus restreintes d'utilisateurs ayant des limitations fonctionnelles particulières. L'assistance fournie par une technologie d'assistance est plus spécifique et appropriée aux besoins des utilisateurs visés. Un agent utilisateur usuel peut comporter des fonctionnalités importantes pour les technologies d'assistance comme l'extraction du contenu Web à partir d'objets de programmation ou l'analyse syntaxique du balisage par paquets identifiables.

Exemple : les technologies d'assistance qui sont importantes dans le contexte du présent document comprennent les technologies suivantes :

  • les agrandisseurs d'écran et les autres assistants de lecture visuelle qui sont utilisés par les personnes ayant des limitations de la vision, de la perception ou d'accès physique à l'imprimé pour modifier la police de caractères, la taille, l'espacement, la couleur, la synchronisation avec la synthèse vocale, etc. dans le but d'améliorer la lisibilité visuelle du rendu des textes et des images ;

  • les lecteurs d'écran qui sont utilisés par les personnes aveugles pour lire l'information textuelle en synthèse vocale ou en braille ;

  • les logiciels de conversion du texte en parole qui sont utilisés par certaines personnes ayant des limitations cognitives, des limitations du langage et des difficultés d'apprentissage pour convertir le texte en synthèse vocale ;

  • les logiciels de reconnaissance vocale qui peuvent être utilisés par les personnes ayant certaines limitations motrices ;

  • des claviers de remplacement qui sont utilisés par des personnes ayant certaines limitations motrices pour simuler le clavier (y compris des claviers de remplacement qui utilisent des pointeurs de tête, des commutateurs simples, des dispositifs d'aspiration/expiration et d'autres dispositifs spéciaux d'aide à la saisie.) ;

  • des dispositifs de pointage adaptés qui sont utilisés par des personnes ayant certaines limitations motrices pour simuler le pointeur de la souris et l'activation des boutons.

texte

séquence de caractères pouvant être déterminée par un programme informatique et exprimant quelque chose dans une langue donnée

Média temporel :
Comprendre la règle 1.2

Règle 1.2 : proposer des versions de remplacement aux médias temporels.

Objectif de la règle 1.2

Le but de cette règle est d'assurer l'accès aux médias temporels et aux médias synchronisés. Cela inclut un média qui est :

  • seulement audio

  • seulement vidéo

  • audio et vidéo

  • audio et/ou vidéo combiné avec de l'interactivité

Pour faciliter le travail des auteurs pour déterminer rapidement quel critère de succès s'applique à leur contenu, le type de média pour lequel chaque critère de succès s'applique est inclus dans son nom abrégé.

Pour un média seulement audio ou seulement vidéo, vous n'aurez besoin que d'appliquer le critère de succès qui stipule « seulement audio » ou « seulement vidéo » dans le nom abrégé. Si votre média n'est ni seulement audio ni seulement vidéo, alors tous les autres critères de succès s'appliquent.

Un média peut être aussi en direct ou pré-enregistré. Chaque nom abrégé d'un critère de succès indique clairement s'il s'applique à un média en direct ou pré-enregistré.

Un média synchronisé est défini dans le glossaire comme :

média synchronisé

flux audio ou vidéo synchronisé avec un autre format pour présenter de l'information et/ou comportant des composants temporels interactifs, à moins que le média soit un média de remplacement pour un texte clairement identifié comme telle

Notez qu'un fichier audio accompagné d'interactivité est traité ici, tout comme un fichier seulement vidéo qui implique de l'interaction. Ils sont traités ici, car l'interactivité doit avoir lieu à un instant particulier. Avoir une transcription textuelle disant, « Pour plus d'information, cliquer maintenant, » ne serait pas très utile puisque le lecteur ne saurait pas quand le flux audio disait « maintenant ». En conséquence, des sous-titres synchronisés seront nécessaires.

Parfois, il y a tellement de dialogues que l'audio-description ne peut pas s'intégrer dans les pauses au sein du dialogue. L'option, pour le niveau A, de fournir une version de remplacement pour un média temporel plutôt qu'une audio-description pour un média synchronisé, permettra d'accéder à toute l'information dans le média synchronisé. Cette option permettra également l'accès à l'information visuelle sous une forme non visuelle lorsque l'audio-description n'est pas fournie pour d'autres raisons.

Pour un média synchronisé incluant une interaction, les éléments interactifs (par exemple, les liens) peuvent être insérés dans la version de remplacement du média temporel.

Cette règle inclut également (au niveau AAA) une interprétation en langue des signes pour un média synchronisé tout comme une approche appelée audio-description étendue. Lors d'une audio-description étendue, la vidéo est périodiquement gelée pour permettre d'ajouter davantage de contenu à l'audio-description par rapport à la capacité offerte par les pauses existantes du dialogue. C'est un cas où les critères de succès d'un niveau plus élevé sont basés sur les exigences d'un critère de succès de niveau inférieur dans l'intention d'avoir des exigences cumulatives, progressivement plus importantes.

Techniques recommandées pour la règle 1.2 (sans rattachement à un critère de succès spécifique)

Les techniques spécifiques pour satisfaire à chaque critère de succès de cette règle sont listées dans les sections Comprendre de chaque critère de succès (énumérés ci-dessous). Cependant, si des techniques permettant de traiter cette règle ne se rapportent à aucun critère de succès, elles sont listées ici. Ces techniques ne sont pas requises ou suffisantes pour satisfaire à un critère de succès, mais peuvent rendre certains types de contenus Web plus accessibles à un plus grand nombre de personnes.

  • Toutes les techniques recommandées pour cette règle sont rattachées à un critère de succès spécifique et sont listées ci-dessous.

Contenu seulement audio ou vidéo (pré-enregistré) :
Comprendre le CS 1.2.1

1.2.1 Contenu seulement audio ou vidéo (pré-enregistré) : pour des médias pré-enregistrés seulement audio et pré-enregistrés seulement vidéo, ce qui suit est vrai, sauf si l'audio ou la vidéo sont un média de remplacement pour un texte et qu'ils sont clairement identifiés comme tels : (Niveau A)

  • Contenu pré-enregistré seulement audio : fournir une version de remplacement pour un média temporel, présentant une information équivalente au contenu seulement audio.

  • Contenu pré-enregistré seulement vidéo : fournir, soit une version de remplacement pour un média temporel, soit une piste audio (présentant une information équivalente) pour un contenu pré-enregistré seulement vidéo.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de rendre l'information transmise par un contenu pré-enregistré seulement audio et seulement vidéo accessible à tous les utilisateurs. Les versions de remplacement pour un média temporel, basées sur du texte, rendent l'information accessible car le texte peut être restitué dans n'importe quel mode sensoriel (par exemple, visuel, auditif ou tactile) pour correspondre aux besoins de l'utilisateur. Dans le futur, le texte pourrait être traduit en symboles, langue des signes ou une forme plus simple de la langue (futur).

Un film muet est un exemple de vidéo pré-enregistrée sans information sonore ou interaction de l'utilisateur. Le but de la transcription est de fournir un équivalent à ce qui est présenté visuellement. Pour le contenu vidéo pré-enregistré, les auteurs ont la possibilité de proposer une piste audio. L'objectif de la version de remplacement sonore est d'être un équivalent à la vidéo. Cela rend possible aux utilisateurs avec ou sans déficience visuelle de reconsidérer le contenu en simultané. Cette approche peut aussi faciliter l'accès à ceux qui ont des limitations cognitives et des troubles du langage et d'apprentissage, pour comprendre le contenu puisqu'elle permet de fournir une présentation en parallèle.

Note : un équivalent textuel n'est pas nécessaire pour de l'audio servant d'équivalent à une vidéo sans information sonore. Par exemple, il n'est pas nécessaire de sous-titrer la description de la vidéo fournie comme version de remplacement à un film muet.

Voir aussi Comprendre le critère de succès 1.2.9 Contenu seulement audio (en direct)

Avantages spécifiques du critère de succès 1.2.1 :

  • Ce critère de succès aide les personnes qui ont des difficultés à percevoir le contenu visuel. Les technologies d'assistance peuvent lire les équivalents textuels à haute voix, les présenter visuellement ou les convertir en braille.

  • Les versions de remplacement pour un média temporel, basées sur du texte, peuvent aider certaines personnes qui ont des difficultés à comprendre le sens d'un contenu vidéo pré-enregistré.

  • Les personnes sourdes, malentendantes ou qui ont des difficultés à comprendre une information audio quelle qu'en soit la raison, peuvent lire la présentation textuelle. Par ailleurs, les recherches se poursuivent concernant la traduction automatique du texte en langue des signes.

  • Les personnes sourdes-aveugles peuvent lire le texte en braille.

  • De plus, les équivalents textuels donnent la possibilité de rechercher le contenu non textuel et de réutiliser ce contenu de diverses façons.

Exemples pour le critère de succès 1.2.1

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.2.1 - Contenu seulement audio ou vidéo (pré-enregistré)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : si le contenu est pré-enregistré seulement audio :
  1. G158 : Fournir une version de remplacement pour un média temporel seulement audio (en anglais)

Situation B : si le contenu est pré-enregistré seulement vidéo :
  1. G159 : Fournir une version de remplacement pour un média temporel seulement vidéo (en anglais)

  2. G166 : Fournir une piste audio qui décrit le contenu important de la vidéo et l'identifier comme telle (en anglais)

Techniques (recommandées) supplémentaires pour 1.2.1

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir une transcription d'une présentation audio seulement en direct après coup (lien à venir)

  • Faire un lien vers une information textuelle qui donne une information comparable (par exemple pour une webcaméra de circulation, une municipalité pourrait fournir un lien avec un rapport textuel de circulation.) (lien à venir)

Mots clés

média de remplacement pour un texte

média qui ne donne pas plus d'information que ce que donne le texte (directement ou via un équivalent textuel)

Note : une version de remplacement pour un texte est fournie à ceux qui bénéficient de représentations équivalentes du texte. Les versions de remplacement de texte peuvent n'être que seulement audio, que seulement vidéo (y compris la vidéo en langue des signes) ou audio-vidéo.

pré-enregistré

information qui n'est pas diffusée en direct

seulement audio

une présentation temporelle qui contient seulement de l'audio (sans vidéo ni interaction)

seulement vidéo

une présentation temporelle qui ne contient que de la vidéo (aucun flux audio ni aucune interaction)

version de remplacement pour un média temporel

document renfermant dans un ordre correct une description des contenus visuels et sonores d'un média temporel et fournissant un moyen de réaliser les effets de toute interaction temporelle

Note : un scénario utilisé pour créer le contenu d'un média synchronisé serait conforme à cette définition seulement s'il a été corrigé afin de représenter fidèlement la version finale du média synchronisé après édition.

Sous-titres (pré-enregistrés) :
Comprendre le CS 1.2.2

1.2.2 Sous-titres (pré-enregistrés) : fournir des sous-titres pour tout contenu audio pré-enregistré dans un média synchronisé, excepté lorsque le média est un média de remplacement pour un texte et qu'il est clairement identifié comme tel. (niveau A)

Objectif de ce critère de succès

L’objectif de ce critère de succès est de permettre aux personnes sourdes ou malentendantes de regarder des présentations sous forme de médias synchronisés. Les sous-titres fournissent la partie du contenu disponible via la piste audio. Les sous-titres ne comprennent pas seulement les dialogues, mais identifient qui parle et incluent également la partie non verbale de l’information véhiculée par les bruits, dont les effets sonores significatifs.

Il est reconnu qu'il peut y avoir actuellement une difficulté à créer des sous-titres pour des contenus contraints par le temps et il peut en résulter que l'auteur soit face à un dilemme, soit de retarder la parution de l’information jusqu’à ce que les sous-titres soient disponibles, ou de publier du contenu inaccessible aux personnes sourdes, au moins pendant l'intervalle où les sous-titres sont indisponibles. Progressivement, les outils de sous-titrage, ainsi que l'intégration des sous-titres dans le processus de création, pourront réduire ou éliminer un tel délai.

Les sous-titres ne sont pas utiles lorsque le média synchronisé est lui-même une présentation alternative de l’information également présentée sous forme de texte sur une page Web. Par exemple, si l’information sur la page est accompagnée par une présentation sous forme d’un média synchronisé n’apportant pas plus d’information que celle présente dans le texte, mais plus facile à comprendre pour les personnes ayant des limitations cognitives, de difficultés de langage ou d’apprentissage, alors celle-ci ne nécessite pas de sous-titres puisque l'information est déjà présente sur la page dans le texte ou dans une version de remplacement pour du texte (par exemple, pour les images).

Voir aussi Comprendre le critère de succès 1.2.4 Sous-titres (en directe).

Avantages spécifiques du critère de succès 1.2.2 :

  • Grâce aux sous-titres, les personnes sourdes ou ayant perdu de l’audition peuvent avoir accès à l’information sonore du contenu de médias synchronisés.

Exemples pour le critère de succès 1.2.2

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Guides pour le sous-titrage

Ressources SMIL

Autres ressources pour le sous-titrage

Outils de sous-titrage

Techniques et échecs pour le critère de succès 1.2.2 - Sous-titres (pré-enregistré)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.2.2

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir une note disant « Aucun son n'est utilisé dans ce clip » pour les clips seulement vidéo (lien à venir)

  • Utiliser SMIL 1.0 pour fournir des sous-titres pour toutes les langues pour lesquelles il y a des pistes audio (lien à venir)

  • Utiliser SMIL 2.0 pour fournir des sous-titres pour toutes les langues pour lesquelles il y a des pistes audio (lien à venir)

Mots clés

audio

la technologie de reproduction des sons

Note : le son peut être créé de façon synthétique (y compris la synthèse vocale), être enregistré à partir de sons réels ou les deux.

média de remplacement pour un texte

média qui ne donne pas plus d'information que ce que donne le texte (directement ou via un équivalent textuel)

Note : une version de remplacement pour un texte est fournie à ceux qui bénéficient de représentations équivalentes du texte. Les versions de remplacement de texte peuvent n'être que seulement audio, que seulement vidéo (y compris la vidéo en langue des signes) ou audio-vidéo.

média synchronisé

flux audio ou vidéo synchronisé avec un autre format pour présenter de l'information et/ou comportant des composants temporels interactifs, à moins que le média soit un média de remplacement pour un texte clairement identifié comme tel

pré-enregistré

information qui n'est pas diffusée en direct

sous-titres

visuel synchronisé ou équivalent textuel pour l'information audio avec ou sans parole nécessaire à la compréhension du contenu d'un média

Note 1 : les sous-titres (en anglais captions) sont similaires à ceux qui sont utilisés seulement pour les dialogues (en anglais subtitles) sauf que les sous-titres ne communiquent pas seulement le contenu des dialogues parlés mais aussi des équivalents pour les informations audio autres que le dialogue et nécessaires à la compréhension du contenu du programme, y compris les effets sonores, la musique, les rires, l'identification et le positionnement des interlocuteurs.

Note 2 : les sous-titres codés sont de la même espèce mais peuvent être activés ou désactivés dans certains lecteurs multimédia.

Note 3 : les sous-titres visibles sont des sous-titres qui ne peuvent être désactivés. Par exemple, si les sous-titres sont un équivalent visuel en texte sous forme d'image intégré à la vidéo.

Note 4 : les sous-titres ne devraient pas masquer l'information pertinente de la vidéo, même partiellement.

Note 5 : 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.

Note 6 : l'audio-description peut aussi être sous-titrée, mais n'a pas besoin de l'être, étant donné qu'il s'agit d'une description d'information qui est déjà présentée visuellement.

Audio-description ou version de remplacement pour un média temporel (pré-enregistré) :
Comprendre le CS 1.2.3

1.2.3 Audio-description ou version de remplacement pour un média temporel (pré-enregistré) : fournir une version de remplacement pour un média temporel ou une audio-description du contenu vidéo pré-enregistré pour un média synchronisé, excepté quand le média est un média de remplacement pour un texte et qu'il est clairement identifié comme tel. (niveau A)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de fournir aux personnes qui sont aveugles ou ont des limitations visuelles, un accès à l'information visuelle dans une présentation sous forme de média synchronisé. Ce critère de succès décrit deux approches, l'une ou l'autre peut être utilisée.

La première approche est de fournir une audio-description du contenu vidéo. L'audio-description augmente la partie audio de la présentation avec l'information nécessaire quand la partie vidéo n'est pas disponible. Durant les pauses présentes dans le dialogue, l'audio-description fournit de l'information sur les actions, les changements de scène et le texte affiché à l'écran qui sont importants et qui ne sont pas décrits ou dits dans la piste audio principale.

La seconde approche implique de fournir toute l'information présente dans le média synchronisé (à la fois visuelle et sonore) sous forme de texte. Une version de remplacement pour un média temporel fournit une description, au fur et à mesure, de ce qui se produit dans le contenu du média synchronisé. La version de remplacement pour un média temporel se lit comme un scénario ou un livre. Contrairement à l'audio-description, la description d'une partie de la vidéo n'est pas limitée aux seules pauses dans le dialogue. Les descriptions complètes sont fournies pour toute information visuelle, y compris le contexte visuel, les actions et expressions des acteurs et les autres matériaux visuels. De plus, les sons hors dialogue (rires, voix off, etc.) sont décrits et les transcriptions de tout le dialogue sont incluses. L'enchaînement de la description et des transcriptions du dialogue sont identiques à l'enchaînement dans le média synchronisé. Par conséquent, la version de remplacement pour un média temporel peut fournir une représentation bien plus complète du contenu du média synchronisé que l'audio-description seule.

S'il existe de l'interactivité dans la présentation sous forme de média synchronisé (par exemple : « Appuyer maintenant pour répondre à la question »), alors la version de remplacement pour un média temporel devrait fournir des hyperliens ou quoique ce soit qui puisse assurer la même fonctionnalité.

Note 1 : pour 1.2.3, 1.2.5, et 1.2.7, si toute l'information de la piste vidéo est déjà fournie dans la piste audio, aucune audio-description n'est nécessaire.

Note 2 : 1.2.3, 1.2.5, et 1.2.8 se recoupent quelque peu. Cela permet de donner à l'auteur un choix au niveau de conformité minimal et de fournir des exigences supplémentaires aux niveaux supérieurs. Au niveau A pour le critère de succès 1.2.3, les auteurs ont le choix de fournir soit, une audio-description, soit une version de remplacement textuelle complète. S'ils veulent être conformes au niveau AA, pour le critère de succès 1.2.5, les auteurs doivent fournir une audio-description, une exigence déjà satisfaite s'ils choisissent cette alternative pour le 1.2.3, autrement c'est une exigence supplémentaire. Au niveau AAA, pour le critère de succès 1.2.8, ils doivent fournir une description textuelle étendue. C'est une exigence supplémentaire, si, à la fois, 1.2.3 et 1.2.5 ont été satisfaits en fournissant seulement une audio-description. Si, toutefois, 1.2.3 est satisfait en fournissant une description textuelle et l'exigence 1.2.5 pour une audio-description est satisfaite, alors 1.2.8 ne rajoute pas de nouvelles obligations.

Voir aussi Comprendre le critère de succès 1.2.5 Audio-description (pré-enregistrée), Comprendre le critère de succès 1.2.7 Audio-description étendue (pré-enregistrée) et Comprendre le critère de succès 1.2.8 Version de remplacement pour un média temporel (pré-enregistrée).

Avantages spécifiques du critère de succès 1.2.3 :

  • Ce critère de succès peut aider des personnes qui ont des difficultés à regarder des vidéos ou d'autres contenus sous forme de média synchronisé, y compris les personnes qui ont des difficultés à percevoir ou comprendre les images en mouvement.

Exemples pour le critère de succès 1.2.3

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.2.3 - Audio-description ou version de remplacement pour un média temporel (pré-enregistré)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.2.3

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir une audio-description dans plusieurs langues en SMIL 1.0 (lien à venir)

  • Fournir une audio-description dans plusieurs langues en SMIL 2.0 (lien à venir)

Échecs fréquents pour le CS 1.2.3

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.2.3.

(Aucun échec n'est actuellement documenté)

Mots clés

audio-description

narration ajoutée à une piste sonore pour décrire les détails visuels importants qui ne peuvent être compris à partir de la piste sonore principale seulement

Note 1 : l'audio-description d'une vidéo fournit de l'information à propos des actions, des personnages, des changements de scènes, du texte apparaissant à l'écran et d'autres contenus visuels.

Note 2 : dans une audio-description standard, la narration est ajoutée durant les pauses qui existent dans le dialogue. (Voir aussi audio-description étendue.)

Note 3 : lorsque toute l'information de la vidéo est déjà donnée dans la piste audio, aucune audio-description supplémentaire n'est requise.

Note 4 : aussi nommée « vidéo-description » et « narration descriptive ».

média de remplacement pour un texte

média qui ne donne pas plus d'information que ce que donne le texte (directement ou via un équivalent textuel)

Note : une version de remplacement pour un texte est fournie à ceux qui bénéficient de représentations équivalentes du texte. Les versions de remplacement de texte peuvent n'être que seulement audio, que seulement vidéo (y compris la vidéo en langue des signes) ou audio-vidéo.

média synchronisé

flux audio ou vidéo synchronisé avec un autre format pour présenter de l'information et/ou comportant des composants temporels interactifs, à moins que le média soit un média de remplacement pour un texte clairement identifié comme tel

pré-enregistré

information qui n'est pas diffusée en direct

version de remplacement pour un média temporel

document renfermant dans un ordre correct une description des contenus visuels et sonores d'un média temporel et fournissant un moyen de réaliser les effets de toute interaction temporelle

Note : un scénario utilisé pour créer le contenu d'un média synchronisé serait conforme à cette définition seulement s'il a été corrigé afin de représenter fidèlement la version finale du média synchronisé après édition.

vidéo

la technologie des images ou photos en mouvement ou en séquence

Note : une vidéo peut être constituée d'images fixes ou animées ou des deux.

Sous-titres (en direct) :
Comprendre le CS 1.2.4

1.2.4 Sous-titres (en direct) : fournir des sous-titres pour tout contenu audio en direct sous forme de média synchronisé. (niveau AA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de permettre aux personnes sourdes ou malentendantes de regarder des présentations en temps-réel. Les sous-titres fournissent la partie du contenu disponible via la piste audio. Les sous-titres n'incluent pas seulement le dialogue, mais aussi identifient l'orateur et transcrivent les effets sonores et les autres effets audios significatifs.

Avantages spécifiques du critère de succès 1.2.4 :

  • Grâce aux sous-titres, les personnes sourdes ou qui ont perdu de l'audition peuvent accéder aux informations sonores du contenu de médias synchronisés.

Exemples pour le critère de succès 1.2.4

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.2.4 - Sous-titres (en direct)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.2.4

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

(Aucune technique n'est actuellement documentée)

Échecs fréquents pour le CS 1.2.4

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.2.4.

(Aucun échec n'est actuellement documenté)

Mots clés

audio

la technologie de reproduction des sons

Note : le son peut être créé de façon synthétique (y compris la synthèse vocale), être enregistré à partir de sons réels ou les deux.

en direct

information captée depuis un événement du monde réel et transmise à un récepteur sans autre délai que celui de la diffusion

Note 1 : le délai de diffusion est un court délai souvent automatisé, utilisé par exemple pour permettre aux diffuseurs de mettre en liste d'attente ou de censurer le flux sonore (ou vidéo), mais insuffisant pour permettre un montage significatif.

Note 2 : si l'information est totalement générée par ordinateur il ne s'agit pas d'information en direct.

média synchronisé

flux audio ou vidéo synchronisé avec un autre format pour présenter de l'information et/ou comportant des composants temporels interactifs, à moins que le média soit un média de remplacement pour un texte clairement identifié comme tel

sous-titres

visuel synchronisé ou équivalent textuel pour l'information audio avec ou sans parole nécessaire à la compréhension du contenu d'un média

Note 1 : les sous-titres (en anglais captions) sont similaires à ceux qui sont utilisés seulement pour les dialogues (en anglais subtitles) sauf que les sous-titres ne communiquent pas seulement le contenu des dialogues parlés mais aussi des équivalents pour les informations audio autres que le dialogue et nécessaires à la compréhension du contenu du programme, y compris les effets sonores, la musique, les rires, l'identification et le positionnement des interlocuteurs.

Note 2 : les sous-titres codés sont de la même espèce mais peuvent être activés ou désactivés dans certains lecteurs multimédia.

Note 3 : les sous-titres visibles sont des sous-titres qui ne peuvent être désactivés. Par exemple, si les sous-titres sont un équivalent visuel en texte sous forme d'image intégré à la vidéo.

Note 4 : les sous-titres ne devraient pas masquer l'information pertinente de la vidéo, même partiellement.

Note 5 : 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.

Note 6 : l'audio-description peut aussi être sous-titrée, mais n'a pas besoin de l'être, étant donné qu'il s'agit d'une description d'information qui est déjà présentée visuellement.

Audio-description (pré-enregistrée) :
Comprendre le CS 1.2.5

1.2.5 Audio-description (pré-enregistrée) : fournir une audio-description pour tout contenu vidéo pré-enregistré sous forme de média synchronisé. (niveau AA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de fournir aux personnes aveugles ou qui ont des limitations visuelles, un accès à l'information visuelle dans une présentation sous forme de média synchronisé. L'audio-description augmente la partie audio de la présentation avec l'information nécessaire quand la partie vidéo n'est pas disponible. Durant les pauses présentes dans le dialogue, l'audio-description fournit de l'information sur les actions, les personnages, les changements de scène et le texte affiché à l'écran qui sont importants et qui ne sont pas décrits ou dits dans la piste audio principale.

Note 1 : pour 1.2.3, 1.2.5, et 1.2.7, si toute l'information de la piste vidéo est déjà fournie dans la piste audio, aucune audio-description n'est nécessaire.

Note 2 : 1.2.3, 1.2.5, et 1.2.8 se recoupent quelque peu. Cela permet de donner à l'auteur un choix au niveau de conformité minimal et de fournir des exigences supplémentaires aux niveaux supérieurs. Au niveau A pour le critère de succès 1.2.3, les auteurs ont le choix de fournir soit, une audio-description, soit, une version de remplacement textuelle complète. S'ils veulent être conformes au niveau AA, pour le critère de succès 1.2.5, les auteurs doivent fournir une audio-description, une exigence déjà satisfaite s'ils choisissent cette alternative pour le 1.2.3, autrement c'est une exigence supplémentaire. Au niveau AAA, pour le critère de succès 1.2.8, ils doivent fournir une audio-description étendue. C'est une exigence supplémentaire, si, à la fois, 1.2.3 et 1.2.5 ont été satisfaits en fournissant seulement une audio-description. Si, toutefois, 1.2.3 est satisfait en fournissant une description textuelle et l'exigence 1.2.5 pour une audio-description est satisfaite, alors 1.2.8 ne rajoute pas de nouvelles obligations.

Avantages spécifiques du critère de succès 1.2.5 :

  • Les personnes aveugles ou ayant des limitations visuelles, tout comme celles avec des limitations cognitives ayant des difficultés d'interprétation visuelle de ce qui se produit, bénéficient d'une audio-description de l'information visuelle.

Exemples pour le critère de succès 1.2.5

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.2.5 - Audio-description (pré-enregistrée)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.2.5

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir une audio-description dans plusieurs langues en SMIL 1.0 (lien à venir)

  • Fournir une audio-description dans plusieurs langues en SMIL 2.0 (lien à venir)

  • Fournir une audio-description pour un média synchronisé en direct (lien à venir)

Échecs fréquents pour le CS 1.2.5

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.2.5.

(Aucun échec n'est actuellement documenté)

Mots clés

audio-description

narration ajoutée à une piste sonore pour décrire les détails visuels importants qui ne peuvent être compris à partir de la piste sonore principale seulement

Note 1 : l'audio-description d'une vidéo fournit de l'information à propos des actions, des personnages, des changements de scènes, du texte apparaissant à l'écran et d'autres contenus visuels.

Note 2 : dans une audio-description standard, la narration est ajoutée durant les pauses qui existent dans le dialogue. (Voir aussi audio-description étendue.)

Note 3 : lorsque toute l'information de la vidéo est déjà donnée dans la piste audio, aucune audio-description supplémentaire n'est requise.

Note 4 : aussi nommée « vidéo-description » et « narration descriptive ».

média synchronisé

flux audio ou vidéo synchronisé avec un autre format pour présenter de l'information et/ou comportant des composants temporels interactifs, à moins que le média soit un média de remplacement pour un texte clairement identifié comme tel

pré-enregistré

information qui n'est pas diffusée en direct

vidéo

la technologie des images ou photos en mouvement ou en séquence

Note : une vidéo peut être constituée d'images fixes ou animées ou des deux.

Langue des signes (pré-enregistrée) :
Comprendre le CS 1.2.6

1.2.6 Langue des signes (pré-enregistrée) : fournir une interprétation en langue des signes pour tout contenu audio pré-enregistré sous forme de média synchronisé. (niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de permettre aux personnes sourdes ou ayant des limitations auditives, parlant couramment la langue des signes, de comprendre le contenu de la piste audio de présentations sous forme de média synchronisé. Du texte écrit, comme celui trouvé dans les sous-titres, est généralement une seconde langue. Puisque la langue des signes permet d'indiquer l'intonation, l'émotion et d'autres informations audio reproduites dans son interprétation, mais pas dans les sous-titres, la langue des signes fournit un accès enrichi et plus proche du média synchronisé. Les personnes qui communiquent principalement en langue des signes sont aussi plus rapides en langue des signes et, de plus, un média synchronisé est une présentation qui se déroule dans un temps donné.

Avantages spécifiques du critère de succès 1.2.6 :

  • Les personnes, dont la langue est la langue des signes, ont parfois des capacités de lecture limitées. Ces personnes peuvent être incapables de lire et de comprendre les sous-titres, et donc, elles ont besoin d'une interprétation en langue des signes pour accéder au contenu du média synchronisé.

Exemples pour le critère de succès 1.2.6

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.2.6 - Langue des signes (pré-enregistrée)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.2.6

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Techniques pour les métadonnées
  • Utiliser des métadonnées pour associer les versions équivalentes en langue des signes d'une vidéo afin de permettre le choix de la langue des signes (lien à venir)

    • EXEMPLE : fournir, dans les métadonnées, des URI qui pointent vers plusieurs traductions d'une page Web en différentes langues des signes anglaises (ASL, SASL, BSL, Auslan, ISL, NZSL).

Échecs fréquents pour le CS 1.2.6

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.2.6.

(Aucun échec n'est actuellement documenté)

Mots clés

audio

la technologie de reproduction des sons

Note : le son peut être créé de façon synthétique (y compris la synthèse vocale), être enregistré à partir de sons réels ou les deux.

interprétation en langue des signes

traduction d'une langue, généralement parlée, en langue des signes

Note : les véritables langues des signes sont des langues indépendantes qui ne sont pas attachées à la langue parlée de la même région ou du même pays.

média synchronisé

flux audio ou vidéo synchronisé avec un autre format pour présenter de l'information et/ou comportant des composants temporels interactifs, à moins que le média soit un média de remplacement pour un texte clairement identifié comme tel

pré-enregistré

information qui n'est pas diffusée en direct

Audio-description étendue (pré-enregistrée) :
Comprendre le CS 1.2.7

1.2.7 Audio-description étendue (pré-enregistrée) : lorsque les blancs présents dans le fond sonore ne sont pas suffisants pour permettre à l'audio-description de transmettre le sens de la vidéo, fournir une audio-description étendue pour tout contenu vidéo pré-enregistré sous la forme de média synchronisé. (niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de fournir aux personnes aveugles ou ayant des limitations visuelles, un accès à une présentation sous forme de média synchronisé au-delà de ce que peut fournir une audio-description standard. Cela est fait, en gelant périodiquement la présentation sous forme de média synchronisé et en lisant une audio-description additionnelle. Puis, la présentation sous forme de média synchronisée reprend.

Parce que cela perturbe la diffusion du média pour ceux qui n'ont pas besoin de description additionnelle, des techniques qui vous permettent d'activer/désactiver cette fonctionnalité sont souvent proposées. En alternative, des versions avec et sans description additionnelle peuvent être également proposées.

Avantages spécifiques du critère de succès 1.2.7 :

  • Les personnes aveugles, celles avec une basse vision ne pouvant voir l'écran, tout comme celles avec des limitations cognitives ayant des difficultés à interpréter visuellement ce qui se produit, utilisent souvent l'audio-description de l'information visuelle. Cependant, s'il y a trop de dialogues, l'audio-description est insuffisante. L'audio-description étendue peut, elle, fournir l'information additionnelle dont ils ont besoin pour comprendre la vidéo.

Exemples pour le critère de succès 1.2.7

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.2.7 - Audio-description étendue (pré-enregistrée)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

  1. G8 : Fournir un film avec audio-description étendue (en anglais) en utilisant l'une des techniques suivantes :

Techniques (recommandées) supplémentaires pour 1.2.7

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir une audio-description dans plusieurs langues en SMIL 1.0 (lien à venir)

  • Fournir une audio-description dans plusieurs langues en SMIL 2.0 (lien à venir)

Échecs fréquents pour le CS 1.2.7

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.2.7.

(Aucun échec n'est actuellement documenté)

Mots clés

audio-description

narration ajoutée à une piste sonore pour décrire les détails visuels importants qui ne peuvent être compris à partir de la piste sonore principale seulement

Note 1 : l'audio-description d'une vidéo fournit de l'information à propos des actions, des personnages, des changements de scènes, du texte apparaissant à l'écran et d'autres contenus visuels.

Note 2 : dans une audio-description standard, la narration est ajoutée durant les pauses qui existent dans le dialogue. (Voir aussi audio-description étendue.)

Note 3 : lorsque toute l'information de la vidéo est déjà donnée dans la piste audio, aucune audio-description supplémentaire n'est requise.

Note 4 : aussi nommée « vidéo-description » et « narration descriptive ».

audio-description étendue

audio-description ajoutée à une présentation audiovisuelle en mettant en pause la vidéo de manière à avoir le temps d'ajouter des descriptions supplémentaires

Note : cette technique est à utiliser seulement si le sens de la vidéo est perdu sans audio-description supplémentaire et que les pauses entre les dialogues ou la narration sont trop courtes.

média synchronisé

flux audio ou vidéo synchronisé avec un autre format pour présenter de l'information et/ou comportant des composants temporels interactifs, à moins que le média soit un média de remplacement pour un texte clairement identifié comme tel

pré-enregistré

information qui n'est pas diffusée en direct

vidéo

la technologie des images ou photos en mouvement ou en séquence

Note : une vidéo peut être constituée d'images fixes ou animées ou des deux.

Version de remplacement pour un média temporel (pré-enregistrée) :
Comprendre le CS 1.2.8

1.2.8 Version de remplacement pour un média temporel (pré-enregistrée) : fournir une version de remplacement pour un média temporel, pour tout contenu de type média synchronisé pré-enregistré et pour tout média pré-enregistré seulement vidéo. (niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de rendre le matériel audio-visuel disponible pour les personnes dont la vision est trop basse pour lire de manière fiable les sous-titres et pour celles dont l'audition est trop faible pour entendre un dialogue de manière fiable ainsi que l'audio-description. Cela est rendu possible grâce à la mise à disposition d'une version de remplacement pour un média temporel.

Cette approche nécessite de fournir toute l'information présente dans le média synchronisé (à la fois visuelle et sonore) sous forme de texte. Une version de remplacement pour un média temporel fournit une description, au fur et à mesure, de ce qui se produit dans le contenu du média synchronisé. La version de remplacement pour un média temporel se lit comme un livre. Contrairement à l'audio-description, la description d'une partie de la vidéo n'est pas limitée aux seules pauses dans le dialogue. Les descriptions complètes sont fournies pour toute information visuelle, y compris le contexte visuel, les actions et expressions des acteurs et les autres matériaux visuels. De plus, les sons hors dialogue (rires, voix off, etc.) sont décrits et les transcriptions de tout le dialogue sont incluses. L'enchaînement de la description et des transcriptions du dialogue sont identiques à l'enchaînement dans le média synchronisé. Par conséquent, la version de remplacement pour un média temporel peut fournir une représentation bien plus complète du contenu du média synchronisé que l'audio-description seule.

S'il existe de l'interactivité dans la présentation sous forme de média synchronisé (par exemple : « Appuyer maintenant pour répondre à la question »), alors la version de remplacement pour un média temporel devrait fournir des hyperliens ou quoique ce soit qui puisse assurer la même fonctionnalité.

Les personnes dont la vision est trop basse pour lire fidèlement les sous-titres et celles dont l'audition est trop faible pour entendre un dialogue de manière fiable peuvent accéder à la version de remplacement pour un média temporel en utilisant un afficheur braille éphémère.

Note 1 : pour 1.2.3, 1.2.5, et 1.2.7, si toute l'information de la piste vidéo est déjà fournie dans la piste audio, aucune audio-description n'est nécessaire.

Note 2 : 1.2.3, 1.2.5, et 1.2.8 se recoupent quelque peu. Cela permet de donner à l'auteur un choix au niveau de conformité minimal et de fournir des exigences supplémentaires aux niveaux supérieurs. Au niveau A pour le critère de succès 1.2.3, les auteurs ont le choix de fournir soit, une audio-description, soit, une version de remplacement textuelle. S'ils veulent être conformes au niveau AA, pour le critère de succès 1.2.5, les auteurs doivent fournir une audio-description, une exigence déjà satisfaite s'ils choisissent cette alternative pour le 1.2.3, autrement c'est une exigence supplémentaire. Au niveau AAA, pour le critère de succès 1.2.8, ils doivent fournir une description textuelle étendue. C'est une exigence supplémentaire, si, à la fois, 1.2.3 et 1.2.5 ont été satisfaits en fournissant seulement une audio-description. Si, toutefois, 1.2.3 est satisfait en fournissant une description textuelle et l'exigence 1.2.5 pour une audio-description est satisfaite, alors 1.2.8 ne rajoute pas de nouvelles obligations.

Avantages spécifiques du critère de succès 1.2.3 :

  • Les personnes ne pouvant pas bien voir ou pas du tout et celles qui ne peuvent pas bien entendre ou pas du tout, peuvent accéder à l'information des présentations audio visuelles.

Exemples pour le critère de succès 1.2.8

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.2.8 - version de remplacement pour un média temporel (pré-enregistrée)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : si le contenu est un média synchronisé pré-enregistré :
  1. G69 : Fournir une version de remplacement pour un média temporel (en anglais) en utilisant l'une des techniques suivantes

Situation B : si le contenu est vidéo seulement pré-enregistré :
  1. G159 : Fournir une version de remplacement pour un média temporel seulement vidéo (en anglais)

Techniques (recommandées) supplémentaires pour 1.2.8

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Échecs fréquents pour le CS 1.2.8

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.2.8.

Mots clés

média de remplacement pour un texte

média qui ne donne pas plus d'information que ce que donne le texte (directement ou via un équivalent textuel)

Note : une version de remplacement pour un texte est fournie à ceux qui bénéficient de représentations équivalentes du texte. Les versions de remplacement de texte peuvent n'être que seulement audio, que seulement vidéo (y compris la vidéo en langue des signes) ou audio-vidéo.

média synchronisé

flux audio ou vidéo synchronisé avec un autre format pour présenter de l'information et/ou comportant des composants temporels interactifs, à moins que le média soit un média de remplacement pour un texte clairement identifié comme tel

pré-enregistré

information qui n'est pas diffusée en direct

vidéo

la technologie des images ou photos en mouvement ou en séquence

Note : une vidéo peut être constituée d'images fixes ou animées ou des deux.

Seulement audio (en direct) :
Comprendre le CS 1.2.9

1.2.9 Seulement audio (en direct) : fournir une version de remplacement pour un média temporel donnant une information équivalente pour un contenu seulement audio en direct. (niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de rendre l'information fournie par de l'audio en direct, telle que de la vidéo conférence, les discours en direct et les radios diffusées sur Internet, accessible grâce à l'utilisation de texte de remplacement. Un service de sous-titre en direct permettra à de l'audio en direct d'être accessible aux personnes sourdes, ayant des limitations auditives ou qui, autrement, ne pourraient entendre la partie audio. De tels services ont recours à un opérateur humain qualifié qui écoute ce qui se dit et utilise un clavier spécifique pour taper le texte avec juste un peu de délai. Ils sont capables de saisir un évènement en direct avec un haut degré de fidélité ainsi que d'insérer des remarques sur n'importe quelle partie audio non verbale nécessaire à la compréhension de l'évènement. Une transcription est parfois possible si l'audio en direct suit un scénario prédéfini ; mais un service de sous-titrage en direct est préférable car il se déroule au même rythme que l'audio et peut s'adapter à tout écart par rapport au scénario.

Utiliser des opérateurs non qualifiés ou fournir une transcription qui diffère nettement de ce qui se produit réellement, ne pourra pas être considéré comme satisfaisant à ce critère de succès.

Exemples pour le critère de succès 1.2.9

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.2.9 - Seulement audio (en direct)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.2.9

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Utiliser des métadonnées pour associer les transcriptions textuelles avec le contenu seulement audio (lien à venir)

    Exemple : fournir, dans les métadonnées, des URI pointant vers plusieurs transcriptions textuelles d'un fichier audio (en français, en anglais et en flamand)

Échecs fréquents pour le CS 1.2.9

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.2.8.

(Aucun échec n'est actuellement documenté)

Mots clés

en direct

information captée depuis un événement du monde réel et transmise à un récepteur sans autre délai que celui de la diffusion

Note 1 : le délai de diffusion est un court délai souvent automatisé, utilisé par exemple pour permettre aux diffuseurs de mettre en liste d'attente ou de censurer le flux sonore (ou vidéo), mais insuffisant pour permettre un montage significatif.

Note 2 : si l'information est totalement générée par ordinateur il ne s'agit pas d'information en direct.

seulement audio

une présentation temporelle qui contient seulement de l'audio (sans vidéo ni interaction)

version de remplacement pour un média temporel

document renfermant dans un ordre correct une description des contenus visuels et sonores d'un média temporel et fournissant un moyen de réaliser les effets de toute interaction temporelle

Note : un scénario utilisé pour créer le contenu d'un média synchronisé serait conforme à cette définition seulement s'il a été corrigé afin de représenter fidèlement la version finale du média synchronisé après édition.

Adaptable :
Comprendre la règle 1.3

Règle 1.3 : créer un contenu qui puisse être présenté de différentes manières sans perte d'information ni de structure (par exemple avec une mise en page simplifiée).

Objectif de la règle 1.3

L'objectif de cette règle est d'assurer que toutes les informations sont disponibles sous une forme qui peut être perçue par tous les utilisateurs, par exemple, parlée à haute voix, ou présentée dans une mise en page visuelle simplifiée. Si toutes les informations sont disponibles dans une forme qui peut être déterminée par un logiciel, elles peuvent alors être présentées aux utilisateurs de différentes façons (visuelle, audible, tactile, etc.) Si l'information est incorporée dans une présentation particulière de telle sorte que la structure et l'information ne peuvent être déterminées par le programme informatique d'une technologie d'assistance, alors cette information ne peut être rendue dans d'autres formats selon les besoins de l'utilisateur.

Les critères de succès qui découlent de cette règle cherchent tous à faire en sorte que les différents types d'informations qui sont encodées dans la présentation soient également disponibles afin qu'ils puissent être présentés selon d'autres modalités.

  • Structure : la manière dont les parties d'une page Web sont organisées entre elles et la manière dont un groupe de pages Web est organisé.

  • Présentation : rendu du contenu sous une forme perceptible par l'utilisateur.

Information et relations :
Comprendre le CS 1.3.1

1.3.1 Information et relations : l'information, la structure, et les relations véhiculées par la présentation peuvent être déterminées par un programme informatique ou sont disponibles sous forme de texte. (Niveau A)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que l'information et les relations qui sont impliquées par la mise en forme visuelle ou auditive sont conservées lors de la présentation sous d'autres formats. Par exemple, le format de présentation change lorsque le contenu est lu par un lecteur d'écran ou lorsque la feuille de style de l'utilisateur est substituée à la feuille de style fournie par l'auteur.

Les utilisateurs voyants perçoivent la structure à travers divers indices visuels — les en-têtes de section sont souvent dans une taille de police plus grande, en caractères gras et séparés du paragraphe par des lignes blanches ; les éléments de liste sont précédés par une puce et peut-être en retrait ; les paragraphes sont séparés par une ligne blanche ; les éléments partageant une caractéristique commune sont organisés en lignes et en colonnes dans des tableaux ; des champs de formulaires peuvent être positionnés par groupes partageant des étiquettes textuelles ; une couleur de fond différente peut être utilisée pour indiquer que plusieurs points sont liés les uns aux autres ; les mots qui ont une fonction particulière sont indiqués par un changement de la famille de police et/ou par des caractères gras, italiques ou soulignés et ainsi de suite.

Des signaux sonores peuvent aussi être utilisés. Par exemple, un carillon pourrait indiquer le début d'une nouvelle section, un changement de ton de la voix ou du débit de lecture pourrait faire ressortir de l'information importante ou indiquer le texte d'une citation, etc.

Lorsque de telles relations sont perceptibles à un ensemble d'utilisateurs, ces relations peuvent être rendues perceptibles à tous. Une méthode permettant de déterminer si oui ou non l'information a été correctement donnée à tous les utilisateurs est d'accéder à la même information dans une série de modalités différentes.

Si des liens vers des articles du glossaire sont implémentés en utilisant des éléments d'ancrage (ou l'élément de lien approprié pour la technologie utilisée) et si ces liens sont identifiés en utilisant une police différente, un utilisateur d'un lecteur d'écran va entendre que l'élément est un lien quand le terme du glossaire sera rencontré, même s'il ne peut pas recevoir l'information sur le changement de la police. Un catalogue en ligne peut indiquer les prix en utilisant une plus grande police rouge. Un lecteur d'écran ou une personne qui ne peut pas percevoir le rouge ont toujours l'information sur le prix tant qu'il est précédé du symbole monétaire.

Certaines technologies ne donnent pas le moyen de déterminer par un programme informatique certains types d'information et de relations. Dans ce cas, il devrait y avoir une description textuelle de l'information et des relations. Par exemple, « tous les champs obligatoires sont signalés par un astérisque (*) ». La description du texte devrait être à proximité de l'information qui est décrite (si la page est linéarisée), comme dans l'élément parent ou dans l'élément adjacent.

Il peut aussi y avoir des cas où il faut porter un jugement sur les informations qui doivent figurer dans le texte et ce qui aurait besoin d'être directement associé, et il peut alors être plus approprié de dupliquer des informations (par exemple, dans un tableau HTML, fournir le résumé tant dans le paragraphe précédant le tableau que dans l'attribut summary du tableau lui-même). Toutefois, dans la mesure du possible, il est nécessaire que les informations puissent être déterminées par un programme informatique plutôt que de fournir une description textuelle précédant le tableau.

Note : il n'est pas nécessaire que les valeurs de la couleur soient déterminables par un programme informatique. L'information véhiculée par de la couleur ne peut pas être présentée de façon adéquate simplement en donnant la valeur. Par conséquent, le critère de succès 1.4.1 traite du cas spécifique de la couleur, plutôt que le critère de succès 1.3.1.

Avantages spécifiques du critère de succès 1.3.1 :

  • Ce critère de succès aide les personnes ayant différentes limitations fonctionnelles en permettant aux agents utilisateurs d'adapter le contenu en fonction des besoins de chaque utilisateur.

  • Les utilisateurs aveugles (et qui utilisent un lecteur d'écran) en bénéficient lorsque les informations transmises par la couleur sont également disponibles en texte (y compris les équivalents textuels des images où la couleur est utilisée pour transmettre l'information).

  • Les utilisateurs sourds-aveugles et qui utilisent un afficheur braille éphémère peuvent être incapables d'accéder à l'information dépendante de la couleur.

Exemples du critère de succès 1.3.1

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.3.1 - Information et relations

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : la technologie offre une structure sémantique permettant de rendre l'information et les relations véhiculées par la présentation déterminables par un programme informatique :
  1. G115 : Utiliser les éléments sémantiques pour baliser la structure (en anglais) ET H49 : Utiliser les éléments sémantiques pour baliser le texte accentué ou spécial (en anglais) (HTML)

  2. G117 : Utiliser du texte pour véhiculer l'information donnée par les variations dans la présentation du texte (en anglais)

  3. G140 : Séparer l'information et la structure de la présentation afin de permettre des présentations différentes (en anglais)

  4. Rendre l'information et les relations véhiculées par la présentation déterminables par un programme informatique en utilisant les techniques suivantes :

Situation B : la technologie en cours d'utilisation ne fournit pas la structure sémantique permettant de rendre l'information et les relations véhiculées par la présentation déterminables par un programme informatique :
  1. G117 : Utiliser du texte pour véhiculer l'information donnée par les variations dans la présentation du texte (en anglais)

  2. FLASH8 : Ajouter un nom de groupe à la propriété name accessible d'un élément de formulaire (en anglais) (Flash)

  3. Rendre l'information et les relations véhiculées par la présentation déterminables par un programme informatique ou disponibles en texte en utilisant les techniques suivantes :

Techniques supplémentaires (recommandées) pour 1.3.1

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Échecs fréquents pour le CS 1.3.1

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.3.1.

Mots clés

déterminé (déterminable) par un programme informatique

déterminé par un programme à partir de données fournies par l'auteur d'une manière qui permet aux agents utilisateurs, y compris les technologies d'assistance, d'extraire et de présenter cette information aux utilisateurs sous différentes formes

Exemple 1 : déterminé dans un langage de balisage à partir d'éléments et d'attributs auxquels on accède grâce aux technologies d'assistance couramment disponibles.

Exemple 2 : déterminé grâce à des structures de données spécifiques d'une technologie pour un langage non-balisé et exposée aux technologies d'assistance via une API d'accessibilité aux technologies d'assistance couramment disponibles.

présentation

rendu du contenu sous une forme perceptible par l'utilisateur

relations

associations significatives entre des parties distinctes du contenu

structure
  1. La manière dont les parties d'une page Web sont organisées entre elles ; et

  2. La manière dont un groupe de pages Web est organisé

Ordre séquentiel logique :
Comprendre le CS 1.3.2

1.3.2 Ordre séquentiel logique : lorsque l'ordre de présentation du contenu affecte sa signification, un ordre de lecture correct peut être déterminé par un programme informatique. (Niveau A)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de permettre à un agent utilisateur de fournir une présentation alternative du contenu tout en préservant l'ordre de lecture nécessaire pour comprendre le sens. Il est important qu'il soit possible de déterminer par programmation au moins une séquence du contenu qui a du sens. Un contenu qui ne satisfait pas à ce critère de succès peut perturber ou désorienter les utilisateurs lorsque la technologie d'assistance lit le contenu dans un ordre fautif ou lorsque les feuilles de styles alternatives ou d'autres changements de format sont appliqués.

Une séquence a un sens si l'ordre du contenu dans la séquence ne peut être changé sans affecter sa signification. Par exemple, si une page contient deux articles indépendants, l'ordre relatif des articles peut ne pas affecter leur signification, tant qu'ils ne sont pas entrelacés. Dans une telle situation, les articles eux-mêmes peuvent avoir un ordre séquentiel logique, mais le conteneur qui contient les articles peut quant à lui ne pas avoir un ordre séquentiel logique.

La sémantique de certains éléments détermine si oui ou non leur contenu constitue un ordre séquentiel logique. Par exemple, en HTML, le texte forme toujours un ordre séquentiel logique. Les tableaux et les listes ordonnées constituent des ordres séquentiels logiques, mais pas les listes non ordonnées.

L'ordre du contenu dans une séquence n'est pas toujours significatif. Par exemple, l'ordre relatif de la partie principale d'une page Web et d'une section de navigation n'affecte pas leur signification. Ils pourraient se produire dans n'importe quel ordre dans la séquence de lecture déterminée par programmation. Comme autre exemple, un article de magazine contient plusieurs encadrés latéraux. L'ordre de l'article et des encadrés n'affecte pas leur signification. Dans de tels cas, il existe plusieurs ordres différents de lecture d'une page Web qui peuvent satisfaire le critère de succès.

Avantages spécifiques du critère de succès 1.3.2 :

  • Ce critère de succès peut aider les personnes qui comptent sur les technologies d'assistance qui lisent le contenu à haute voix. La signification évidente tirée de la mise en ordre de l'information de la présentation par défaut sera la même quand le contenu sera présenté sous forme orale.

Exemples pour le critère de succès 1.3.2

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 1.3.2 - Ordre séquentiel logique

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques supplémentaires (recommandées) pour 1.3.2

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Utiliser un alignement à gauche pour les langues qui s'écrivent de gauche à droite et un alignement à droite pour les langues qui s'écrivent de droite à gauche (lien à venir)

  • Fournir un lien permettant de linéariser la présentation (lien à venir)

  • Fournir une fonction de bascule entre des feuilles de style qui affectent l'ordre de présentation (lien à venir)

Mots clés

déterminé (déterminable) par un programme informatique

déterminé par un programme à partir de données fournies par l'auteur d'une manière qui permet aux agents utilisateurs, y compris les technologies d'assistance, d'extraire et de présenter cette information aux utilisateurs sous différentes formes

Exemple 1 : déterminé dans un langage de balisage à partir d'éléments et d'attributs auxquels on accède grâce aux technologies d'assistance couramment disponibles.

Exemple 2 : déterminé grâce à des structures de données spécifiques d'une technologie pour un langage non-balisé et exposée aux technologies d'assistance via une API d'accessibilité aux technologies d'assistance couramment disponibles.

ordre de lecture correct

tout ordre séquentiel où les mots et les paragraphes sont présentés dans un ordre qui ne modifie pas la signification du contenu

Caractéristiques sensorielles :
Comprendre le CS 1.3.3

1.3.3 Caractéristiques sensorielles : les instructions données pour la compréhension et l'utilisation du contenu ne doivent pas reposer uniquement sur les caractéristiques sensorielles des éléments comme la forme, la taille, l'emplacement visuel, l'orientation ou le son. (Niveau A)

Note : pour les exigences liées à la couleur, se référer à la Règle 1.4.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que tous les utilisateurs peuvent accéder aux instructions données pour l'utilisation du contenu, même quand ils ne peuvent pas percevoir la forme ou la taille ou utiliser l'information sur la position spatiale ou l'orientation. Une partie du contenu repose sur la connaissance de la forme ou de la position des objets qui ne sont pas disponibles à partir de la structure du contenu (par exemple « bouton rond » ou « bouton à droite »). Certains utilisateurs ayant des limitations fonctionnelles ne sont pas capables de percevoir la forme ou la position en raison de la nature des technologies d'assistance qu'ils utilisent. Ce critère de succès exige que des informations supplémentaires soient fournies pour clarifier tout ce qui est tributaire de ce genre d'information.

Fournir des informations en utilisant la forme ou la position, constitue toutefois une méthode efficace pour de nombreux utilisateurs, y compris ceux ayant des limitations cognitives. Cette disposition ne doit pas décourager d'utiliser ces types d'indices pour autant que les informations sont également fournies par d'autres moyens.

Dans certaines langues, il est communément admis que « plus haut » se réfère au contenu qui précède ce point et que « plus bas » se réfère à du contenu se situant après ce point. Dans ces langues, si le contenu auquel on réfère se situe à l'endroit approprié dans l'ordre de lecture et que les références sont sans ambiguïté, des déclarations comme « choisir un des liens ci-dessous » ou « tout ce qui précède » seraient conformes à ce critère de succès.

Avantages spécifiques du critère de succès 1.3.3 :

  • Les personnes aveugles et les personnes qui ont une basse vision peuvent ne pas être en mesure de comprendre l'information si elle est véhiculée par la forme ou la position. Fournir des informations supplémentaires autres que la forme ou la position leur permettra de comprendre l'information véhiculée seulement par la forme ou la position.

Exemples pour le critère de succès 1.3.3

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 1.3.3 - Caractéristiques sensorielles

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques supplémentaires (recommandées) pour 1.3.3

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Utiliser une image avec un équivalent textuel pour les symboles graphiques au lieu d'un glyphe Unicode avec l'apparence souhaitée mais une signification différente (lien à venir)

Distinguable :
Comprendre la règle 1.4

Règle 1.4 : faciliter la perception visuelle et auditive du contenu par l'utilisateur, notamment en séparant le premier plan de l'arrière-plan.

Objectif de la règle 1.4

Alors que certaines règles portent sur la mise à disposition de l'information sous des formats de présentation de remplacement, cette règle consiste à rendre la présentation par défaut aussi facile à percevoir que possible par les personnes en situation de handicap. L'objectif principal est de rendre plus facile pour les utilisateurs la séparation des informations de premier plan de l'arrière-plan. Pour les présentations visuelles cela implique de s'assurer que les informations présentées par-dessus un arrière-plan contrastent suffisamment avec celui-ci. Pour les présentations audio cela implique de s'assurer que les sons de premier plan sont suffisamment plus forts que les sons en arrière-plan. Les personnes ayant des limitations visuelles ou celles ayant des limitations auditives ont beaucoup plus de difficultés à dissocier les informations de premier plan de celles en arrière-plan.

Techniques recommandées pour la règle 1.4 (sans rattachement à un critère de succès spécifique)

Les techniques spécifiques pour satisfaire à chaque critère de succès de cette règle sont listées dans les sections Comprendre de chaque critère de succès (énumérés ci-dessous). Cependant, si des techniques permettant de traiter cette règle ne se rapportent à aucun critère de succès, elles sont listées ici. Ces techniques ne sont pas requises ou suffisantes pour satisfaire à un critère de succès, mais peuvent rendre certains types de contenus Web plus accessibles à un plus grand nombre de personnes.

  • Utiliser des polices lisibles (lien à venir)

  • S'assurer que le texte présenté sous forme d'image est d'au moins 14 points et offre un bon contraste (lien à venir)

  • Fournir un mécanisme de surlignement bien visible pour les liens et les éléments de contrôle lorsqu'ils reçoivent le focus au clavier (lien à venir)

Utilisation de la couleur :
Comprendre le CS 1.4.1

1.4.1 Utilisation de la couleur : la couleur n'est pas utilisée comme la seule façon de véhiculer de l'information, d'indiquer une action, de solliciter une réponse ou de distinguer un élément visuel. (Niveau A)

Note : ce critère de succès traite spécifiquement de la perception des couleurs. Les autres formes de perception sont traitées à la règle 1.3 comme l'accès à la couleur par programme informatique et les autres formes de codage de la présentation visuelle.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que tous les utilisateurs peuvent accéder à l'information qui est véhiculée par des différences de couleur, c'est-à-dire par l'utilisation de couleurs où chaque couleur est porteuse d'un sens qui lui est assigné. Si l'information est véhiculée par des différences de couleur dans une image (ou autres formats non textuels), la couleur peut ne pas être vue par des utilisateurs présentant des limitations dans la perception des couleurs. Dans ce cas, fournir l'information véhiculée par la couleur par un autre moyen visuel garantit la perception de l'information aux utilisateurs qui ne voient pas les couleurs.

La couleur est un atout important de la conception des contenus Web, elle permet de renforcer leur attrait esthétique, leur utilisabilité et leur accessibilité. Cependant, certains utilisateurs ont des difficultés à percevoir les couleurs. Les personnes malvoyantes ont souvent une vision limitée des couleurs et certains utilisateurs âgés ne voient pas correctement les couleurs. En outre, les personnes utilisant des écrans et des navigateurs en texte seul, limités en nombre de couleurs ou monochromes, seront incapables d'accéder à l'information présentée uniquement par la couleur.

Exemples d'informations portées par des différences de couleurs : « les champs obligatoires sont en rouge », « erreur signalée en rouge » et « les ventes de Mary sont en rouge, celles de Tom en bleu ». Les exemples d'indications d'une action sont notamment : l'utilisation de couleurs pour indiquer qu'un lien s'ouvrira dans une nouvelle fenêtre ou qu'une entrée de base de données a été mise à jour avec succès. Un exemple d'une invite sollicitant une réponse serait : l'utilisation du surlignement sur des champs de formulaire pour indiquer qu'un champ obligatoire n'a pas été renseigné.

Note : cela ne devrait en aucun cas décourager l'utilisation de couleurs sur une page, ou même de codes de couleurs si leur utilisation est redondante avec une autre indication visuelle.

Avantages spécifiques du critère de succès 1.4.1 :

  • Les utilisateurs malvoyants ont souvent une vision limitée des couleurs.

  • Certains utilisateurs âgés ne sont pas capables de voir correctement les couleurs.

  • Lorsque les informations véhiculées par les couleurs sont disponibles par d'autres moyens visuels, les utilisateurs qui ont des difficultés de perception des couleurs en tirent parti.

  • Les personnes utilisant des écrans en texte seul, en couleurs limitées ou monochromes, peuvent ne pas avoir accès aux informations dépendantes de couleurs.

  • Les utilisateurs qui ont des problèmes pour faire la différence entre les couleurs peuvent regarder ou écouter des indices textuels.

  • Les personnes qui utilisent des afficheurs braille ou d'autres interfaces tactiles peuvent détecter des indices textuelles au toucher.

Exemples pour le critère de succès 1.4.1

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.4.1 - Utilisation de la couleur

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.4.1

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Contrôle du son :
Comprendre le CS 1.4.2

1.4.2 Contrôle du son : si du son sur une page Web 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. (Niveau A)

Note : puisque tout contenu ne satisfaisant pas à ce critère de succès peut interférer avec la capacité de l'utilisateur à exploiter la page entière, tout le contenu présent dans la page Web (qu'il soit utilisé pour satisfaire à d'autres critères de succès ou non) doit satisfaire à ce critère de succès. Voir l'exigence de conformité 5 : Non-interférence.

Objectif de ce critère de succès

Les personnes qui utilisent un logiciel de lecture d'écran peuvent avoir des difficultés à entendre le contenu parlé si d'autres sons sont joués en même temps. Cette difficulté est aggravée lorsque la sortie son du contenu parlé du lecteur d'écran est basée sur une solution logicielle (comme la plupart le sont aujourd'hui) et est contrôlée par le même contrôle du volume que le son. Il est par conséquent important que l'utilisateur soit en mesure de désactiver l'arrière-plan sonore. Note : avoir le contrôle sur le volume inclut d'être en mesure de réduire le volume à zéro.

Note : le démarrage automatique d'un son à l'arrivée sur une page peut affecter la capacité d'un utilisateur de lecteur d'écran à trouver le mécanisme pour l'arrêter car il navigue en écoutant et le son démarré automatiquement peut interférer avec cette navigation. Par conséquent, nous déconseillons la pratique de démarrage automatique de sons (surtout s'ils durent plus de 3 secondes) et nous recommandons que le son soit lancé par une action initiée par l'utilisateur après avoir atteint la page plutôt que d'exiger que le son soit arrêté par une action de l'utilisateur après son arrivée sur la page.

Voir également Comprendre le critère de succès 1.4.7 Arrière-plan sonore de faible volume ou absent.

Avantages spécifiques du critère de succès 1.4.2 :

  • Les personnes qui utilisent les technologies de lecture d'écran peuvent entendre le lecteur d'écran sans qu'aucun autre son ne soit joué. Cela est particulièrement important pour ceux qui sont malentendants et pour ceux dont les lecteurs d'écran utilisent le volume du système (ils ne peuvent donc pas baisser le volume du système général et monter celui du lecteur d'écran).

  • Ce critère de succès bénéficie également aux personnes qui ont des difficultés à se concentrer sur le contenu visuel (y compris le texte) lorsqu'un son est joué.

Exemples pour le critère de succès 1.4.2

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 1.4.2 - Contrôle du son

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.4.2

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir des préférences s'appliquant à l'ensemble d'un site afin de désactiver le son en plus de fournir un élément de contrôle à proximité du début de la page Web qui permet d'arrêter le son qui joue automatiquement (lien à venir)

Échecs fréquents pour le CS 1.4.2

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.4.2.

Mots clés

mécanisme

processus ou technique pour obtenir un résultat

Note 1 : le mécanisme peut être explicitement fourni par le contenu ou dépendre de la plateforme ou de l'agent utilisateur, y compris les technologies d'assistance.

Note 2 : le mécanisme doit satisfaire à tous les critères de succès (d'un niveau donné) pour déclarer un niveau de conformité.

Contraste (minimum) :
Comprendre le CS 1.4.3

1.4.3 Contraste (minimum) : la présentation visuelle du texte et du texte sous forme d'image a un rapport de contraste d'au moins 4,5:1, sauf dans les cas suivants : (Niveau AA)

  • Texte agrandi : le texte agrandi et le texte agrandi sous forme d'image ont un rapport de contraste d'au moins 3:1;

  • Texte décoratif : aucune exigence de contraste pour le texte ou le texte sous forme d'image qui fait partie d'un composant d'interface utilisateur inactif, qui est purement décoratif, qui est invisible pour tous ou qui est une partie d'une image contenant un autre contenu significatif.

  • Logotypes : aucune exigence de contraste pour le texte faisant partie d'un logo ou d'un nom de marque.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de fournir un contraste suffisant entre le texte et son arrière-plan afin qu'il puisse être lu par des personnes avec une basse vision modérée (qui n'utilisent pas de technologies d'assistance améliorant les contrastes). Pour les personnes ne présentant pas de limitation de perception des couleurs, la teinte et la saturation ont peu ou pas d'effet sur la lisibilité comme cela a été démontré par la performance de lecture (Knoblauch et al., 1991). Les limitations de perception des couleurs peuvent quelque peu influer sur le contraste de luminosité. Par conséquent, dans la recommandation, le contraste est calculé de telle manière que la couleur ne soit pas un facteur clé pour que les personnes qui ont une limitation de perception des couleurs aient également un contraste satisfaisant entre le texte et l'arrière-plan.

Le texte qui est décoratif et qui ne transmet pas d'information n'est pas concerné. Par exemple, si des mots aléatoires étaient utilisés pour créer un arrière-plan et que les mots pouvaient être réarrangés ou remplacés sans changer leur sens, alors ils seraient décoratifs et ne seraient pas concernés par ce critère.

Un texte agrandi et avec des traits de caractères plus larges est plus facile à lire sur un contraste plus faible. L'exigence de contraste est donc plus faible pour un texte agrandi. Cela permet aux auteurs d'utiliser une gamme de choix de couleurs plus large pour les textes agrandis, ce qui est utile pour la conception de pages, en particulier pour les titres. Un texte en 18 points ou un texte en 14 points gras est jugé suffisamment grand pour exiger un plus faible rapport de contraste (voir les recommandations pour les grands caractères de la maison d'édition américaine pour les personnes aveugles et les recommandations pour les grands caractères de la bibliothèque du Congrès dans les ressources). « 18 points » et « gras » peuvent avoir des représentations différentes selon différentes polices cependant, sauf pour les polices très minces ou inhabituelles, cela devrait être suffisant. Comme il existe de nombreuses différentes polices, des mesures génériques sont utilisées et une note sur les caractères fantaisistes ou les polices fines est incluse.

Note : comme certains logiciels de traitement d'images ne gèrent pas les différentes densités de pixels (exemple 72 PPI ou 96 PPI), définir la taille des points des polices dans ces logiciels peut ne pas être fiable quand il s'agit de présenter du texte dans une taille spécifique. Lors de la création d'images avec du texte agrandi, les auteurs doivent s'assurer que le texte de l'image résultante est sensiblement équivalent à 1,2 et 1,5 em ou à 120% et 150% de la taille par défaut du corps de texte. Par exemple, pour une image à 72 PPI, un auteur aurait besoin d'utiliser des tailles de police approximativement de 19 pt et 24 pt pour présenter correctement des images avec du texte agrandi à un utilisateur.

Les exigences de contraste précédemment mentionnées pour le texte s'appliquent également au texte sous forme d'image (texte qui a été rendu en pixels puis stocké sous un format d'image) comme indiqué dans le critère de succès 1.4.3.

Cette exigence s'applique aux situations dans lesquelles du texte sous forme d'image est destiné à être compris comme du texte. Le texte décoratif, comme celui sur les panneaux de signalisation pouvant apparaître sur les photographies, n'est pas concerné. N'est également pas concerné le texte qui, pour une raison ou une autre, est conçu pour être invisible à tous les utilisateurs. Le texte stylisé, comme sur les logos d'entreprises, doit être traité selon sa fonction sur la page, selon qu'il nécessite ou non l'ajout d'un contenu dans le texte de remplacement. Les éléments de la charte graphique d'une organisation, autres que le logo et le logotype, ne sont pas compris dans l'exception.

Dans cette recommandation, il existe une exception pour ce « qui est une partie d'une image contenant un autre contenu visuel significatif ». Cette exception a pour but de distinguer les images qui ont du texte de celles qui en ont dans le but de remplacer du texte et d'obtenir une apparence particulière.

Note 1 : certaines personnes ayant des limitations cognitives ont besoin de combinaisons de couleurs ou de teintes avec un faible contraste, ainsi nous autorisons et nous encourageons les auteurs à fournir des mécanismes permettant d'ajuster les couleurs de premier-plan et d'arrière-plan du contenu. Certaines combinaisons qui pourraient être choisies peuvent avoir des niveaux de contrastes inférieurs à ceux précisés dans les critères de succès. Ce n'est pas une violation des critères de succès à condition qu'il y ait un mécanisme qui revienne aux valeurs par défaut exposées dans les critères de succès.

Note 2 : la taille des textes sous forme d'images ne se change pas aussi bien que du texte car ils ont tendance à pixeliser. Il est également plus difficile de changer les contrastes et les combinaisons de couleurs de premier plan et d'arrière-plan pour les textes sous forme d'images, ce qui est nécessaire pour certains utilisateurs. Par conséquent, nous suggérons d'utiliser autant que possible du texte, et dans le cas contraire, pensez à fournir une image de résolution plus élevée.

Bien que ce critère de succès ne s'applique qu'aux textes, des questions similaires se présentent pour des données présentées dans des tableaux ou des graphiques. Un bon contraste de couleurs devrait également être fourni pour les données présentées dans ces formats.

Voir également Comprendre le critère de succès 1.4.6 Contraste (amélioré) .

Justification des ratios choisis

Un rapport de contraste de 3:1 est le niveau minimum recommandé par [ISO-9241-3] et [ANSI-HFES-100-1988] pour du texte et une vision standards. Le rapport de 4,5:1 est utilisé dans cette recommandation pour tenir compte de la perte de contraste qui résulte d'une acuité visuelle modérée faible, des limitations de perception des couleurs congénitales ou acquises, ou de la perte de sensibilité aux contrastes qui accompagne en général le vieillissement.

Le raisonnement est basé sur a) une adoption du rapport de contraste de 3:1 comme rapport de contraste minimum acceptable pour les observateurs normaux dans la norme ANSI, et b) la constatation empirique que dans la population, l'acuité visuelle de 20/40 est associée à une perte de sensibilité aux contrastes de l'ordre de 1,5 [ARDITI-FAYE]. Un utilisateur avec 20/40 aurait besoin d'un rapport de contraste de 3 * 1,5 = 4,5 pour 1. À la suite de constatations empiriques analogues et en suivant la même logique, l'utilisateur avec une acuité visuelle de 20/80 aurait besoin d'un contraste de 7:1.

Les teintes sont perçues différemment par les utilisateurs présentant des limitations de perception des couleurs (congénitales comme acquises), il en résulte des couleurs et contrastes de luminosité relative différents par rapport aux utilisateurs qui voient normalement. À cause de cela, le contraste efficace et la lisibilité sont différents pour cette population. Toutefois, les limitations de perception des couleurs sont tellement diverses qu'une prescription générale efficace sur l'utilisation de paires de couleurs (pour les contrastes) basée sur des données quantitatives n'est pas réalisable. Exiger un bon contraste de luminosité s'adapte bien à cela en exigeant un contraste qui est indépendant de la perception de la couleur. Heureusement, la plupart des apports de la luminosité passe par des récepteurs de moyennes et longues ondes qui se recoupent en grande partie dans leurs réponses spectrales. Le résultat est que le contraste de luminosité relative peut généralement être calculé sans tenir compte d'une limitation de perception des couleurs, sauf pour l'utilisation de couleurs principalement composées de grandes longueurs d'ondes et opposées à des couleurs sombres (qui apparaissent généralement noires) pour les personnes atteintes de protanopie. (Nous fournissons pour cette raison une technique recommandée sur l'évitement du rouge sur fond noir). Pour plus d'information, voir [ARDITI-KNOBLAUCH] [ARDITI-KNOBLAUCH-1996] [ARDITI].

Le rapport de contraste de 4,5:1 a été choisi pour le niveau AA car il compensait la perte de sensibilité au contraste généralement vécue par les utilisateurs avec une perte de vision à peu près équivalente à 20/40. (20/40 correspond environ à 4,5:1.) On indique fréquemment que 20/40 correspond à l'acuité visuelle moyenne des personnes âgées d'environ 80 ans. [GITTINGS-FOZARD]

Le rapport de contraste de 7:1 a été choisi pour le niveau AAA, car il compensait la perte de sensibilité au contraste généralement vécue par les utilisateurs avec une perte de vision à peu près équivalente à 20/80. Les personnes ayant un degré de perte de vision supérieur utilisent généralement des technologies d'assistance pour accéder à leur contenu (et les technologies d'assistance disposent généralement d'un renforcement des contrastes, ainsi que de possibilités d'agrandissement intégrées). Le niveau 7:1 fournit donc généralement une compensation pour la perte de sensibilité au contraste rencontrée chez les utilisateurs avec une basse vision et qui n'utilisent pas de technologie d'assistance, et il fournit également un renforcement des contrastes pour les daltoniens.

Note : les méthodes de calculs dans [ISO-9241-3] et [ANSI-HFES-100-1988] sont pour le corps du texte. Un rapport de contraste moins exigeant est fourni pour du texte qui est beaucoup plus grand.

Notes sur la formule

La conversion des valeurs RGB non linéaires à linéaires est basée sur IEC/4WD 61966-2-1 [IEC-4WD] et sur « Un espace de couleur par défaut standard pour Internet - sRGB » [sRGB].

La formule (L1/L2) pour le contraste est basée sur les normes [ISO-9241-3] et [ANSI-HFES-100-1988].

Le standard ANSI/HFS 100-1988 demande à ce que l'impact de la lumière ambiante soit inclus dans le calcul de L1 et L2. La valeur 0,05 utilisée est basée sur l'affichage du signal lumineux général [IEC-4WD] et l'article [sRGB] de M. Stokes et al.

Ce critère de succès et ses définitions emploient les termes « rapport de contraste » et « luminosité relative » plutôt que « luminosité » pour refléter le fait que le contenu Web n'émet pas de lumière. Le rapport de contraste donne une mesure de la luminosité relative qui se traduirait à l'affichage. (Parce que c'est une proportion, sans dimension.)

Note 1 : se référer aux ressources liées pour obtenir une liste d'outils qui utilisent le rapport de contraste pour analyser le contraste de contenus Web.

Note 2 : voir également Comprendre le critère de succès 2.4.7 Visibilité du focus pour les techniques pour indiquer le focus du clavier.

Note 3 : il est parfois utile pour les auteurs de ne pas spécifier de couleurs pour certaines sections d'une page afin d'aider les utilisateurs qui ont besoin de voir le contenu dans des combinaisons de couleurs spécifiques à voir le contenu dans leur jeu de couleurs préféré. Pour plus d'informations, se référer à Comprendre le critère de succès 1.4.5 Texte sous forme d'image.

Avantages spécifiques du critère de succès 1.4.3 :

  • Les personnes ayant une basse vision ont souvent des difficultés à lire un texte qui n'est pas contrasté avec son arrière-plan. Cela peut être aggravé si la personne a une limitation de perception des couleurs qui diminue davantage le contraste. Fournir un rapport minimum de contraste de luminosité entre le texte et son arrière-plan peut rendre le texte plus lisible même si la personne ne voit pas toute la gamme de couleurs. Cela fonctionne également pour les rares personnes qui ne distinguent pas les couleurs.

Exemples pour le critère de succès 1.4.3

(Aucun exemple n'est actuellement documenté)

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.4.3 - Contraste (minimum)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : le texte est inférieur à 18 points s'il n'est pas en gras et le texte est inférieur à 14 points s'il est en gras
  1. G18 : S'assurer qu'un rapport de contraste d'au moins 4,5 pour 1 existe entre le texte (et le texte sous forme d'image) et l'arrière-plan du texte (en anglais)

  2. G148 : Ne pas spécifier de couleur d'arrière-plan ni de couleur de texte et ne pas utiliser une technologie qui change ces couleurs par défaut (en anglais)

  3. G174 : Fournir un élément d'interface ayant un rapport de contraste suffisant afin de permettre à l'utilisateur de basculer vers une présentation offrant un contraste suffisant (en anglais)

Situation B : le texte est au moins de 18 points s'il n'est pas en gras et au moins de 14 points s'il est en gras
  1. G145 : S'assurer qu'un rapport de contraste d'au moins 3 pour 1 existe entre le texte (et le texte sous forme d'image) et l'arrière-plan du texte (en anglais)

  2. G148 : Ne pas spécifier de couleur d'arrière-plan ni de couleur de texte et ne pas utiliser une technologie qui change ces couleurs par défaut (en anglais)

  3. G174 : Fournir un élément d'interface ayant un rapport de contraste suffisant afin de permettre à l'utilisateur de basculer vers une présentation offrant un contraste suffisant (en anglais)

Techniques (recommandées) supplémentaires pour 1.4.3

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • G156 : Utiliser une technologie qui permet de changer l'avant-plan et l'arrière-plan des blocs de texte dans des agents utilisateur communément disponibles (en anglais)

  • Utiliser un contraste supérieur pour un texte placé sur un motif d'arrière-plan (lien à venir)

  • Utiliser du texte Unicode et des feuilles de style plutôt que des textes sous forme d'images (lien à venir)

  • Utiliser un contraste supérieur pour les lignes d'un diagramme (lien à venir)

  • Utiliser un plus fort contraste pour une combinaison de rouge et de noir comme texte et arrière-plan (lien à venir)

  • Utiliser des couleurs où prédominent les composantes du milieu du spectre visible pour les tons clairs et les couleurs de chaque extrémité du spectre visible (longueurs d'onde bleues et rouges) pour les tons foncés.

  • Utiliser un arrière-plan de couleur pastel plutôt que blanc avec du texte noir afin de créer un contraste suffisant mais non extrême (lien à venir)

  • Créer des icônes qui utilisent des lignes de couleur qui satisfont au niveau de contraste prévu pour le texte (lien à venir)

  • Fournir un contraste suffisant dans les diagrammes et les graphes (lien à venir)

  • Utiliser un niveau de contraste de 3 pour 1 ou mieux comme présentation par défaut (lien à venir)

  • Fournir un contraste de couleurs suffisant pour un champ de texte vide (lien à venir)

Mots clés

(texte) agrandi

avec au minimum 18 points ou 14 points gras ou une taille de caractère équivalente pour les polices chinoises, japonaises ou coréennes (CJK)

Note 1 : les polices avec des traits extraordinairement fins ou des aspects et des caractéristiques inhabituels qui réduisent la reconnaissance de la forme des lettres sont plus difficiles à lire, spécialement à des niveaux de contrastes bas.

Note 2 : la taille de caractère est la taille lorsque le contenu est affiché. Cela n'inclut pas le redimensionnement qui pourrait être fait par l'utilisateur.

Note 3 : la taille réelle des caractères qu'un utilisateur voit est dépendante à la fois de la définition de la taille faite par l'auteur, du périphérique de restitution de l'utilisateur ou du paramétrage de l'agent utilisateur. Pour la majorité des polices de corps de texte, 14 et 18 points est sensiblement équivalent à 1,2 et 1,5 em ou à 120% et 150% de la taille par défaut du corps de texte (en considérant que la police de corps est à 100%), mais les auteurs seraient tenus de vérifier cela pour les polices particulières qui seraient utilisées. Quand les polices sont définies en unités relatives, la taille réelle du point est mesurée par l'agent utilisateur pour l'affichage. La taille d'un point doit être obtenue auprès de l'agent utilisateur ou calculée sur la même base de mesure que celle de l'agent utilisateur, lors de l'évaluation de ce critère de succès. Les utilisateurs qui ont une basse vision auront à choisir les paramètres appropriés.

Note 4 : lors de l'utilisation de texte sans spécification de taille de caractère, la taille la plus petite utilisée dans les principaux navigateurs pour le texte dont la taille n'est pas spécifiée serait considérée comme une taille raisonnable pour la police. Si un titre de niveau 1 est restitué en 14pt gras ou plus sur les principaux navigateurs, alors il est raisonnable de considérer qu'il s'agit de texte agrandi. Le redimensionnement relatif peut être calculé de manière identique à partir de la taille par défaut.

Note 5 : la taille 18 ou 14 points pour les textes en alphabet latin est définie à partir de la taille minimum pour les grands caractères (14pt) et de la taille standard plus grande (18pt). Pour les autres polices telles que les langues CJK, les tailles « équivalentes » seraient la taille de grand caractère minimum utilisée pour ces langues et la taille de grands caractères plus grande suivante.

composant d'interface utilisateur

partie du contenu qui est perçue par les utilisateurs comme un élément de contrôle unique pour une fonction distincte

Note 1 : plusieurs composants d'interface utilisateur peuvent être implémentés au sein d'un seul programme. La notion de composant n'est pas liée ici aux techniques de programmation, mais plutôt à ce que les utilisateurs perçoivent comme des éléments de contrôle distincts.

Note 2 : les composants d'interface utilisateur incluent les éléments de formulaire et les liens aussi bien que des composants générés par scripts.

Exemple : un microprogramme (applet) dispose d'un « élément de contrôle » permettant de se déplacer dans le contenu ligne par ligne, page par page ou au hasard. Puisque chacune de ces fonctions devrait avoir un nom et fonctionner indépendamment, elles constitueraient chacune un « composant d'interface utilisateur ».

purement décoratif

utilisé seulement dans un but esthétique, ne fournissant aucune information et n'ayant aucune fonctionnalité

Note : un texte est purement décoratif si les mots peuvent être réarrangés ou remplacés sans changer leur raison d'être.

Exemple : la page de couverture d'un dictionnaire présente un arrière-plan estompé et constitué de mots choisis au hasard.

rapport de contraste

(L1 + 0,05) / (L2 + 0,05), où

Note 1 : le rapport de contraste peut varier de 1 à 21 (communément écrit 1:1, 1 pour 1, à 21:1, 21 pour 1).

Note 2 : étant donné que les auteurs ne contrôlent pas la configuration de l'utilisateur concernant le rendu du texte (par exemple le lissage de police ou l'anti-crénelage), le rapport de contraste du texte peut être évalué en désactivant l'anti-crénelage.

Note 3 : en ce qui concerne les critères de succès 1.4.3 et 1.4.6, le contraste est mesuré en tenant compte de l'arrière-plan sur lequel le texte est normalement affiché. Si aucune couleur d'arrière-plan n'est spécifiée, il est considéré comme blanc.

Note 4 : la couleur d'arrière-plan est la couleur spécifiée du contenu sur lequel le texte est normalement affiché. Il est considéré comme une erreur de ne pas définir une couleur d'arrière-plan lorsque la couleur du texte est spécifiée, parce que la couleur d'arrière-plan de l'utilisateur est inconnue et ne peut donc pas être évaluée pour vérifier si le contraste est suffisant. Pour la même raison, il est aussi considéré comme une erreur de ne pas définir la couleur du texte lorsqu'une couleur d'arrière-plan est spécifiée.

Note 5 : lorsqu'il y a une bordure autour de la lettre, la bordure peut augmenter le contraste et serait utilisée dans le calcul du contraste entre la lettre et son arrière-plan. La couleur d'une bordure étroite autour de la lettre serait utilisée à la place de la lettre. Une bordure large autour de la lettre qui remplit l'espace dans lequel se découpe le détail de la lettre agit comme un halo et serait considérée comme un arrière-plan.

Note 6 : la conformité aux WCAG devrait être évaluée pour les paires de couleurs spécifiées dans le contenu qu'un auteur s'attendrait à voir apparaître de façon adjacente dans une présentation habituelle. Les auteurs n'ont pas besoin de prendre en considération les présentations inhabituelles comme les changements de couleurs faits par l'agent utilisateur sauf si ces changements sont provoqués par le code de l'auteur.

texte

séquence de caractères pouvant être déterminée par un programme informatique, et exprimant quelque chose dans une langue donnée

texte sous forme d'image

texte qui est restitué sous une forme non textuelle (par exemple une image) dans le but de permettre un effet visuel particulier

Note : cela n'inclut pas le texte qui est une partie d'une image qui contient d'autres contenus visuels signifiants.

Exemple : le nom d'une personne sur un badge dans une photographie.

Redimensionnement du texte :
Comprendre le CS 1.4.4

1.4.4 Redimensionnement du texte : à l'exception des sous-titres et du texte sous forme d'image, le texte peut être redimensionné jusqu'à 200 pour cent sans l'aide d'une technologie d'assistance et sans perte de contenu ou de fonctionnalité. (Niveau AA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que les textes rendus visuellement, y compris les textes des éléments de contrôle (les caractères qui ont été affichés de sorte qu'ils puissent être lus [à l'opposé des caractères qui sont encore sous forme de données comme les caractères définis en ASCII]) puissent être redimensionnés avec succès afin qu'ils puissent être lus directement par les personnes ayant une limitation visuelle légère, sans nécessiter l'utilisation de technologies d'assistance comme un agrandisseur d'écran. Les utilisateurs peuvent bénéficier du redimensionnement de tous les contenus sur la page Web mais le redimensionnement du texte est plus crucial.

Le redimensionnement du contenu est en premier lieu la responsabilité de l'agent utilisateur. Les agents utilisateurs qui satisfont le point de contrôle 4.1 des UAAG 1.0 (en anglais) permettent aux utilisateurs de configurer la taille des textes. La responsabilité de l'auteur est de créer un contenu Web qui n'empêche pas l'agent utilisateur de redimensionner le contenu de manière efficace. Les auteurs peuvent satisfaire à ce critère de succès en vérifiant que le contenu n'interfère pas avec la fonction de redimensionnement du texte de l'agent utilisateur, y compris pour les textes des éléments de contrôle, ou en fournissant une fonction pour le redimensionnement du texte ou pour le changement de présentation. Un exemple de support direct peut être un script côté serveur qui peut être utilisé pour attribuer des feuilles de style différentes.

L'auteur ne peut pas compter sur l'agent utilisateur pour satisfaire à ce critère de succès pour le contenu HTML si les utilisateurs n'ont pas accès à un agent utilisateur avec une fonction de zoom. Par exemple, s'ils travaillent dans un environnement qui nécessite de travailler avec IE 6 ou Firefox.

Si l'auteur utilise une technologie dont les agents utilisateurs ne fournissent pas de fonction de zoom, l'auteur est responsable de fournir ce type de fonctionnalité directement ou en fournissant du contenu qui est compatible avec le type de fonctionnalités fournies par l'agent utilisateur. Si l'agent utilisateur ne fournit pas de fonctionnalités de zoom mais permet à l'utilisateur de changer la taille du texte, l'auteur est chargé de s'assurer que le contenu reste utilisable lorsque le texte est redimensionné.

Certains composants de l'interface utilisateur qui fonctionnent comme une étiquette et nécessitent une activation par l'utilisateur pour accéder à du contenu ne sont pas assez larges pour accueillir le contenu de l'étiquette. Par exemple, dans les applications de messagerie Web, la colonne objet peut ne pas être assez large pour accueillir tous les en-têtes d'objets possibles, mais l'activation de l'en-tête de l'objet amène l'utilisateur à l'intégralité du message comportant l'en-tête complet. Dans des feuilles de calculs sur le Web, le contenu d'une cellule qui est trop long pour être affiché dans une colonne peut être tronqué, et l'intégralité du contenu de la cellule est disponible pour l'utilisateur lorsque la cellule reçoit le focus. Le contenu d'un composant d'interface utilisateur peut également devenir trop large dans les interfaces où l'utilisateur peut redimensionner la largeur d'une colonne. Dans ce type de composants d'interface utilisateur, le retour à la ligne n'est pas requis ; la troncature est acceptable si l'intégralité du contenu du composant est disponible au focus ou après une activation de l'utilisateur et si une indication précisant que l'information peut être consultée est fournie à l'utilisateur d'une autre manière que par le simple fait que le contenu soit tronqué.

Le contenu satisfait au critère de succès s'il peut être agrandi jusqu'à 200%, ce qui représente jusqu'à deux fois la largeur et la hauteur. Les auteurs peuvent prendre en charge le redimensionnement au-delà de cette limite, cependant, comme le redimensionnement devient plus extrême, les mises en pages adaptées peuvent introduire des problèmes d'utilisabilité. Par exemple, les mots peuvent être trop larges pour tenir horizontalement dans l'espace qui leur est alloué, les obligeant alors à être tronqués ; les contraintes de mise en page peuvent provoquer des chevauchements du texte avec d'autres contenus lorsque le texte est agrandi ; ou une phrase peut se retrouver avec seulement un mot par ligne, provoquant alors l'affichage d'une phrase en une colonne de texte qui est difficile à lire.

Le groupe de travail estime que 200% est un compromis raisonnable qui peut prendre en charge un large éventail de graphismes et de mises en page, et cela complète les plus anciens agrandisseurs d'écran qui proposent un grossissement minimum de 200%. Au-delà de 200%, le zoom (qui redimensionne le texte, les images et les éléments de mise en page et qui crée une large surface pouvant nécessiter l'utilisation d'un défilement horizontal et vertical) peut être plus efficace que le redimensionnement du texte. Les technologies d'assistance dédiées au zoom devraient généralement être utilisées dans une telle situation et peuvent fournir une meilleure accessibilité que les tentatives de l'auteur pour fournir cette fonctionnalité directement à l'utilisateur.

Note : les textes sous forme d'images ne s'adaptent pas aussi bien que du texte car ils ont tendance à pixeliser, et par conséquent nous suggérons d'utiliser autant que possible du texte. Il est également plus difficile de changer le contraste entre le premier plan et l'arrière-plan et les combinaisons de couleurs des textes sous forme d'images, ce qui est nécessaire pour certains utilisateurs.

Voir également Comprendre le critère de succès 1.4.8 Présentation visuelle.

Avantages spécifiques du critère de succès 1.4.4 :

  • Ce critère de succès aide les personnes qui ont une basse vision en leur permettant d'augmenter la taille du texte dans le contenu pour qu'elles puissent le lire.

Exemples pour le critère de succès 1.4.4

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.4.4 - Redimensionnement du texte

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.4.4

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Mots clés

sous-titres

visuel synchronisé ou équivalent textuel pour l'information audio avec ou sans parole nécessaire à la compréhension du contenu d'un média

Note 1 : les sous-titres (en anglais captions) sont similaires à ceux qui sont utilisés seulement pour les dialogues (en anglais subtitles) sauf que les sous-titres ne communiquent pas seulement le contenu des dialogues parlés mais aussi des équivalents pour les informations audio autres que le dialogue et nécessaires à la compréhension du contenu du programme, y compris les effets sonores, la musique, les rires, l'identification et le positionnement des interlocuteurs.

Note 2 : les sous-titres codés sont de la même espèce mais peuvent être activés ou désactivés dans certains lecteurs multimédia.

Note 3 : les sous-titres visibles sont des sous-titres qui ne peuvent être désactivés. Par exemple, si les sous-titres sont un équivalent visuel en texte sous forme d'image intégré à la vidéo.

Note 4 : les sous-titres ne devraient pas masquer l'information pertinente de la vidéo, même partiellement.

Note 5 : 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.

Note 6 : l'audio-description peut aussi être sous-titrée, mais n'a pas besoin de l'être, étant donné qu'il s'agit d'une description d'information qui est déjà présentée visuellement.

technologie d'assistance (tel qu'utilisé dans ce document)

matériel ou logiciel qui agit comme agent utilisateur ou simultanément avec un agent utilisateur usuel afin de fournir des fonctionnalités répondant aux besoins des utilisateurs ayant des limitations fonctionnelles, fonctionnalités qui vont au-delà de celles qui sont offertes par les agents utilisateurs usuels

Note 1 : les fonctionnalités fournies par les technologies d'assistance comprennent des présentations de remplacement (par exemple de la synthèse vocale ou du contenu agrandi), des méthodes de saisie alternatives (par exemple la voix), des mécanismes de navigation ou d'orientation supplémentaires et des transformations de contenu (par exemple pour rendre un tableau plus accessible).

Note 2 : les technologies d'assistance communiquent souvent les données et les messages aux agents utilisateurs usuels en utilisant et en surveillant le fonctionnement d'une API (interface de programmation).

Note 3 : la distinction entre agents utilisateurs usuels et technologies d'assistance n'est pas absolue. Plusieurs agents utilisateurs usuels comportent des fonctions d'assistance aux utilisateurs ayant des limitations fonctionnelles. La principale différence est que ces agents utilisateurs usuels visent un public large et diversifié qui comprend des personnes avec et sans limitations fonctionnelles. Les technologies d'assistance visent des populations plus restreintes d'utilisateurs ayant des limitations fonctionnelles particulières. L'assistance fournie par une technologie d'assistance est plus spécifique et appropriée aux besoins des utilisateurs visés. Un agent utilisateur usuel peut comporter des fonctionnalités importantes pour les technologies d'assistance comme l'extraction du contenu Web à partir d'objets de programmation ou l'analyse syntaxique du balisage par paquets identifiables.

Exemple : les technologies d'assistance qui sont importantes dans le contexte du présent document comprennent les technologies suivantes :

  • les agrandisseurs d'écran et les autres assistants de lecture visuelle qui sont utilisés par les personnes ayant des limitations de la vision, de la perception ou d'accès physique à l'imprimé pour modifier la police de caractères, la taille, l'espacement, la couleur, la synchronisation avec la synthèse vocale, etc. dans le but d'améliorer la lisibilité visuelle du rendu des textes et des images ;

  • les lecteurs d'écran qui sont utilisés par les personnes aveugles pour lire l'information textuelle en synthèse vocale ou en braille ;

  • les logiciels de conversion du texte en parole qui sont utilisés par certaines personnes ayant des limitations cognitives, des limitations du langage et des difficultés d'apprentissage pour convertir le texte en synthèse vocale ;

  • les logiciels de reconnaissance vocale qui peuvent être utilisés par les personnes ayant certaines limitations motrices ;

  • des claviers de remplacement qui sont utilisés par des personnes ayant certaines limitations motrices pour simuler le clavier (y compris des claviers de remplacement qui utilisent des pointeurs de tête, des commutateurs simples, des dispositifs d'aspiration/expiration et d'autres dispositifs spéciaux d'aide à la saisie.) ;

  • des dispositifs de pointage adaptés qui sont utilisés par des personnes ayant certaines limitations motrices pour simuler le pointeur de la souris et l'activation des boutons.

texte

séquence de caractères pouvant être déterminée par un programme informatique et exprimant quelque chose dans une langue donnée

texte sous forme d'image

texte qui est restitué sous une forme non textuelle (par exemple une image) dans le but de permettre un effet visuel particulier

Note : cela n'inclut pas le texte qui est une partie d'une image qui contient d'autres contenus visuels signifiants.

Exemple : le nom d'une personne sur un badge dans une photographie.

Texte sous forme d'image :
Comprendre le CS 1.4.5

1.4.5 Texte sous forme d'image : si les technologies utilisées peuvent réaliser la présentation visuelle, du texte est utilisé pour véhiculer l'information plutôt que du texte sous forme d'image sauf dans les cas suivants : (Niveau AA)

  • Personnalisable : le texte sous forme d'image peut être personnalisé visuellement selon les exigences de l'utilisateur ;

  • Essentielle : une présentation spécifique du texte est essentielle à l'information véhiculée.

Note : les logotypes sont considérés comme essentiels (le texte qui fait partie d'un logo ou d'un nom de marque).

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'encourager les auteurs qui utilisent des technologies capables de réaliser des présentations visuelles spécifiques de permettre aux personnes d'ajuster la présentation du texte lorsqu'elles ont besoin d'une présentation spécifique du texte. Cela comprend les personnes qui ont un besoin spécifique concernant une taille de police, une couleur d'avant-plan et d'arrière-plan, une famille de polices de caractères, un espacement entre les lignes ou un alignement du texte.

Si un auteur peut utiliser du texte pour obtenir le même rendu visuel, il ou elle doit présenter les informations sous forme de texte plutôt que d'utiliser une image. Si pour une raison quelconque, l'auteur ne peut pas adapter le texte pour obtenir le même rendu, si le rendu ne peut pas être présenté de manière fiable par les agents utilisateurs couramment disponibles, ou si l'utilisation d'une technologie dans le but de répondre à ce critère devait nuire au respect d'autres critères comme le 1.4.4, alors du texte sous forme d'image peut être utilisé. Cela inclut les cas où une présentation spécifique du texte est essentielle à l'information devant être véhiculée, comme les échantillons de types, les logotypes, la marque, etc. Du texte sous forme d'image peut également être utilisé dans le but de se servir d'une police de caractères particulière qui n'est pas largement déployée, ou que l'auteur n'a pas le droit de distribuer, ou pour s'assurer que le texte ne sera pas crénelé sur tous les agents utilisateurs.

Du texte sous forme d'image peut également être utilisé lorsqu'il est possible pour les utilisateurs de personnaliser le texte sous forme d'image pour qu'il réponde à leurs exigences.

Les techniques pour satisfaire ce critère de succès sont les mêmes que celles du critère 1.4.9, excepté qu'elles n'ont besoin d'être appliquées que si les technologies utilisées par l'auteur peuvent réaliser la présentation visuelle. Pour le critère de succès 1.4.9, les techniques suffisantes seraient seulement appliquées lorsque l'utilisateur peut personnaliser le rendu final.

Voir également Comprendre le critère de succès 1.4.9 Texte sous forme d'image (sans exception).

Avantages spécifiques du critère de succès 1.4.5 :

  • Les personnes ayant une basse vision (qui peuvent avoir des difficultés à lire le texte avec la famille de police de caractères, la taille et/ou la couleur définies par l'auteur).

  • Les personnes ayant un dysfonctionnement du système visuel (qui peuvent avoir des difficultés à lire le texte avec l'espacement entre les lignes et/ou l'alignement définis par l'auteur).

  • Les personnes ayant des troubles cognitifs qui affectent la lecture.

Exemples pour le critère de succès 1.4.5

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.4.5 - Texte sous forme d'image

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.4.5

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Techniques générales pour le contenu non textuel
  1. Identifier un contenu non textuel informatif (lien à venir)

Techniques CSS
  1. C12 : Utiliser les pourcentages pour les tailles de caractères (en anglais) (CSS

  2. C13 : Utiliser les taille de caractères nommées (en anglais) (CSS)

  3. C14 : Utiliser les unités en em pour les tailles de caractères (en anglais) (CSS)

  4. C8 : Utiliser la propriété CSS letter-spacing pour contrôler l'espacement dans un mot (en anglais) (CSS)

  5. C6 : Positionner le contenu selon le balisage structurel (en anglais) (CSS)

  6. Éviter d'appliquer des styles de texte aux caractères dans un mot (lien à venir)

Échecs fréquents pour le CS 1.4.5

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.4.3.

(Aucun échec n'est actuellement documenté)

Mots clés

essentiel(le)

élément qui changerait fondamentalement les informations ou les fonctionnalités du contenu s'il était supprimé et informations et fonctionnalités qui ne pourraient être restituées autrement d'une manière conforme

personnalisé visuellement

la police, la taille, la couleur et le fond sont paramétrables

texte

séquence de caractères pouvant être déterminée par un programme informatique, et exprimant quelque chose dans une langue donnée

texte sous forme d'image

texte qui est restitué sous une forme non textuelle (par exemple une image) dans le but de permettre un effet visuel spécifique

Note : cela n'inclut pas le texte qui est une partie d'une image qui contient d'autres contenus visuels signifiants.

Exemple : le nom d'une personne sur un badge dans une photographie.

Contraste (amélioré) :
Comprendre le CS 1.4.6

1.4.6Contraste (amélioré) : la présentation visuelle du texte et du texte sous forme d'image a un rapport de contraste d'au moins 7:1, sauf dans les cas suivants : (Niveau AAA)

  • Texte agrandi : le texte agrandi et le texte agrandi sous forme d'image ont un rapport de contraste d'au moins 4,5:1;

  • Texte décoratif : aucune exigence de contraste pour le texte ou le texte sous forme d'image qui fait partie d'un composant d'interface utilisateur inactif, qui est purement décoratif, qui est invisible pour tous ou qui est une partie d'une image contenant un autre contenu visuel significatif.

  • Logotypes : aucune exigence de contraste pour le texte faisant partie d'un logo ou d'un nom de marque.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de fournir un contraste suffisant entre le texte et son arrière-plan afin qu'il puisse être lu par des personnes avec une basse vision modérée (qui n'utilisent pas de technologies d'assistance améliorant les contrastes). Pour les personnes ne présentant pas de limitation de perception des couleurs, la teinte et la saturation ont peu ou pas d'effet sur la lisibilité comme cela a été démontré par la performance de lecture (Knoblauch et al., 1991). Les limitations de perception des couleurs peuvent quelque peu influer le contraste de luminosité. Par conséquent, dans la recommandation, le contraste est calculé de telle manière que la couleur ne soit pas un facteur clé pour que les personnes qui ont une limitation de perception des couleurs aient également un contraste satisfaisant entre le texte et l'arrière-plan.

Le texte qui est décoratif et qui ne transmet pas d'information n'est pas concerné. Par exemple, si des mots aléatoires étaient utilisés pour créer un arrière-plan et que les mots pouvaient être réarrangés ou remplacés sans changer leur sens, alors ils seraient décoratifs et ne seraient pas concernés par ce critère.

Un texte agrandi et avec des traits de caractères plus larges est plus facile à lire sur un contraste plus faible. L'exigence de contraste est donc plus faible pour un texte agrandi. Cela permet aux auteurs d'utiliser une gamme de choix de couleurs plus large pour les textes agrandis, ce qui est utile pour la conception de pages, en particulier pour les titres. Un texte en 18 points ou un texte en 14 points gras est jugé suffisamment grand pour exiger un plus faible rapport de contraste (voir les recommandations pour les grands caractères de la maison d'édition américaine pour les personnes aveugles et les recommandations pour les grands caractères de la bibliothèque du Congrès dans les ressources). « 18 points » et « gras » peuvent avoir des représentations différentes selon différentes polices cependant, sauf pour les polices très minces ou inhabituelles, cela devrait être suffisant. Comme il existe de nombreuses polices différentes, des mesures génériques sont utilisées et une note sur les caractères fantaisistes ou les polices fines est incluse.

Note 1 : lorsque les polices ont des systèmes anti-crénage qui leur sont appliqués pour leur donner un aspect plus lisse, elles peuvent devenir plus foncées ou plus claires. Le contraste peut ainsi être réduit. Des fûts plus épais réduiront cet effet (les polices de caractères fines pourront avoir des fûts plus minces sur toute leur longueur, et non uniquement aux extrémités). Il est recommandé d'utiliser des polices plus larges et de tester leur lisibilité dans les agents utilisateurs en activant le lissage des polices.

Note 2 : comme certains logiciels de traitement d'images ne gèrent pas les différentes densités de pixels ((exemple 72 PPI ou 96 PPI), définir la taille des points des polices dans ces logiciels peut ne pas être fiable quand il s'agit de présenter du texte dans une taille spécifique. Lors de la création d'images avec du texte agrandi, les auteurs doivent s'assurer que le texte de l'image résultante est sensiblement équivalent à 1,2 et 1,5 em ou à 120% et 150% de la taille par défaut du corps de texte. Par exemple, pour une image à 72 PPI, un auteur aurait besoin d'utiliser des tailles de police approximativement de 19 pt et 24 pt pour présenter correctement des images avec du texte agrandi à un utilisateur.

Les exigences de contraste précédemment mentionnées pour le texte s'appliquent également au texte sous forme d'image (texte qui a été rendu en pixels puis stocké sous un format d'image) comme indiqué dans le critère de succès 1.4.5.

Cette exigence s'applique aux situations dans lesquelles du texte sous forme d'image est destiné à être compris comme du texte. Le texte décoratif, comme celui sur les panneaux de signalisation pouvant apparaître sur les photographies, n'est pas concerné. N'est également pas concerné le texte qui, pour une raison ou une autre, est conçu pour être invisible à tous les utilisateurs. Le texte stylisé, comme sur les logos d'entreprises, doit être traité selon sa fonction sur la page, selon qu'il nécessite ou non l'ajout d'un contenu dans le texte de remplacement. Les éléments de la charte graphique d'une organisation, autres que le logo et le logotype, ne sont pas compris dans l'exception.

Dans cette recommandation, il existe une exception pour ce « qui est une partie d'une image contenant un autre contenu significatif ». Cette exception a pour but de distinguer les images qui ont du texte de celles qui en ont dans le but de remplacer du texte et d'obtenir une apparence particulière.

Bien que ce critère de succès ne s'applique qu'aux textes, des questions similaires se présentent pour des données présentées dans des tableaux ou des graphiques. Un bon contraste de couleurs devrait également être fourni pour les données présentées dans ces formats.

Justification des ratios choisis

Un rapport de contraste de 3:1 est le niveau minimum recommandé par [ISO-9241-3] et [ANSI-HFES-100-1988] pour du texte et une vision standards. Le rapport de 4,5:1 est utilisé dans le critère de succès 1.4.3 pour tenir compte de la perte de contraste qui résulte d'une acuité visuelle modérément faible, des limitations de perception des couleurs congénitales ou acquises, ou de la perte de sensibilité aux contrastes qui accompagne en général le vieillissement.

Le raisonnement est basé sur a) une adoption du rapport de contraste de 3:1 comme rapport de contraste minimum acceptable pour les observateurs normaux dans la norme ANSI, et b) la constatation empirique que dans la population, l'acuité visuelle de 20/40 est associée à une perte de sensibilité aux contrastes de l'ordre de 1,5 [ARDITI-FAYE]. Un utilisateur avec 20/40 aurait besoin d'un rapport de contraste de 3 * 1,5 = 4,5 pour 1. À la suite de constatations empiriques analogues et en suivant la même logique, l'utilisateur avec une acuité visuelle de 20/80 aurait besoin d'un contraste de 7:1.

Les teintes sont perçues différemment par les utilisateurs présentant des limitations de perception des couleurs (congénitales comme acquises), il en résulte des couleurs et contrastes de luminosité relative différents par rapport aux utilisateurs qui voient normalement. À cause de cela, le contraste efficace et la lisibilité sont différents pour cette population. Toutefois, les limitations de perception des couleurs sont tellement diverses qu'une prescription générale efficace sur l'utilisation de paires de couleurs (pour les contrastes) basée sur des données quantitatives n'est pas réalisable. Exiger un bon contraste de luminosité s'adapte bien à cela en exigeant un contraste qui est indépendant de la perception de la couleur. Heureusement, la plupart des apports de la luminosité passe par des récepteurs de moyennes et longues ondes qui se recoupent en grande partie dans leurs réponses spectrales. Le résultat est que le contraste de luminosité relative peut généralement être calculé sans tenir compte d'une limitation de perception des couleurs, sauf pour l'utilisation de couleurs principalement composées de grandes longueurs d'ondes et opposées à des couleurs sombres (qui apparaissent généralement noires) pour les personnes atteintes de protanopie. (Nous fournissons pour cette raison une technique recommandée sur l'évitement du rouge sur fond noir). Pour plus d'information, voir [ARDITI-KNOBLAUCH] [ARDITI-KNOBLAUCH-1996] [ARDITI].

Le rapport de contraste de 4,5:1 a été choisi pour le niveau AA car il compensait la perte de sensibilité au contraste généralement vécue par les utilisateurs avec une perte de vision à peu près équivalente à 20/40. (20/40 correspond environ à 4,5:1.) Fréquemment, il est rapporté que 20/40 correspond à l'acuité visuelle moyenne des personnes âgées d'environ 80 ans. [GITTINGS-FOZARD]

Le rapport de contraste de 7:1 a été choisi pour le niveau AAA, car il compensait la perte de sensibilité au contraste généralement vécue par les utilisateurs avec une perte de vision à peu près équivalente à 20/80. Les personnes ayant un degré de perte de vision supérieur utilisent généralement des technologies d'assistance pour accéder à leur contenu (et les technologies d'assistance disposent généralement d'un renforcement des contrastes, ainsi que des possibilités d'agrandissement intégrées). Le niveau 7:1 fournit donc généralement une compensation pour la perte de sensibilité au contraste rencontrée chez les utilisateurs avec une basse vision et qui n'utilisent pas de technologie d'assistance et il fournit également un renforcement des contrastes pour les daltoniens.

Note : les méthodes de calculs dans [ISO-9241-3] et [ANSI-HFES-100-1988] sont pour le corps du texte. Un rapport de contraste moins exigeant est fourni pour du texte qui est beaucoup plus grand.

Notes sur la formule

La conversion des valeurs RGB non linéaires à linéaires est basée sur IEC/4WD 61966-2-1 [IEC-4WD] et sur « Un espace de couleur par défaut standard pour Internet - sRGB » [sRGB].

La formule (L1/L2) pour le contraste est basée sur les normes [ISO-9241-3] et [ANSI-HFES-100-1988].

Le standard ANSI/HFS 100-1988 demande à ce que l'impact de la lumière ambiante soit inclus dans le calcul de L1 et L2. La valeur 0,05 utilisée est basée sur l'affichage du signal lumineux général [IEC-4WD] et l'article [sRGB] de M. Stokes et al.

Ce critère de succès et ses définitions emploient les termes « rapport de contraste » et « luminosité relative » plutôt que « luminosité » pour refléter le fait que le contenu Web n'émet pas de lumière. Le rapport de contraste donne une mesure de la luminosité relative qui se traduirait à l'affichage. (Parce que c'est une proportion, sans dimension.)

Note 1 : se référer aux ressources liées pour obtenir une liste d'outils qui utilisent le rapport de contraste pour analyser le contraste de contenus Web.

Note 2 : voir égalementComprendre le critère de succès 2.4.7 Visibilité du focus pour les techniques pour indiquer le focus du clavier.

Avantages spécifiques du critère de succès 1.4.6 :

  • Les personnes ayant une basse vision ont souvent des difficultés à lire un texte qui n'est pas contrasté avec son arrière-plan. Cela peut être aggravé si la personne a une limitation de perception des couleurs qui diminue davantage le contraste. Fournir un rapport minimum de contraste de luminosité entre le texte et son arrière-plan peut rendre le texte plus lisible même si la personne ne voit pas toute la gamme de couleurs. Cela fonctionne également pour les rares personnes qui ne distinguent pas les couleurs.

Exemples pour le critère de succès 1.4.6

(Aucun exemple n'est actuellement documenté)

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.4.6 - Contraste (amélioré)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : le texte est inférieur à 18 points s'il n'est pas en gras et le texte est inférieur à 14 points s'il est en gras
  1. G17 : S'assurer qu'un rapport de contraste d'au moins 7 pour 1 existe entre le texte (et le texte sous forme d'image) et l'arrière-plan du texte (en anglais)

  2. G148 : Ne pas spécifier de couleur d'arrière-plan ni de couleur de texte et ne pas utiliser une technologie qui change ces couleurs par défaut (en anglais)

  3. G174 : Fournir un élément d'interface ayant un rapport de contraste suffisant afin de permettre à l'utilisateur de basculer vers une présentation offrant un contraste suffisant (en anglais)

Situation B : le texte est au moins de 18 points s'il n'est pas en gras et au moins de 14 points s'il est en gras
  1. G18 : S'assurer qu'un rapport de contraste d'au moins 4,5 pour 1 existe entre le texte (et le texte sous forme d'image) et l'arrière-plan du texte (en anglais)

  2. G148 : Ne pas spécifier de couleur d'arrière-plan ni de couleur de texte et ne pas utiliser une technologie qui change ces couleurs par défaut (en anglais)

  3. G174 : Fournir un élément d'interface ayant un rapport de contraste suffisant afin de permettre à l'utilisateur de basculer vers une présentation offrant un contraste suffisant (en anglais)

Techniques (recommandées) supplémentaires pour 1.4.6

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • G156 : Utiliser une technologie qui permet de changer l'avant-plan et l'arrière-plan des blocs de texte dans des agents utilisateur communément disponibles (en anglais)

  • Utiliser un contraste supérieur pour un texte placé sur un motif d'arrière-plan (lien à venir)

  • Utiliser du texte Unicode et des feuilles de style plutôt que des textes sous forme d'images (lien à venir)

  • Utiliser un contraste supérieur pour les lignes d'un diagramme (lien à venir)

  • Utiliser un plus fort contraste pour une combinaison de rouge et de noir comme texte et arrière-plan

  • Utiliser des couleurs où prédominent les composantes du milieu du spectre visible pour les tons clairs et les couleurs de chaque extrêmité du spectre visible (longueurs d'onde bleues et rouges) pour les tons foncés.

  • Utiliser un arrière-plan de couleur pastel plutôt que blanc avec du texte noir afin de créer un contraste suffisant mais non extrême (lien à venir)

  • Créer des icônes qui utilisent des lignes de couleur qui satisfont au niveau de contraste prévu pour le texte (lien à venir)

  • Fournir un contraste suffisant dans les diagrammes et les graphes (lien à venir)

  • Utiliser un niveau de contraste de 3 pour 1 ou mieux comme présentation par défaut (lien à venir)

  • Fournir un contraste de couleurs suffisant pour un champ de texte vide (lien à venir)

Mots clés

(texte) agrandi

avec au minimum 18 points ou 14 points gras ou une taille de caractère équivalente pour les polices chinoises, japonaises ou coréennes (CJK)

Note 1 : les polices avec des traits extraordinairement fins ou des aspects et des caractéristiques inhabituels qui réduisent la reconnaissance de la forme des lettres sont plus difficiles à lire, spécialement à des niveaux de contrastes bas.

Note 2 : la taille de caractère est la taille lorsque le contenu est affiché. Cela n'inclut pas le redimensionnement qui pourrait être fait par l'utilisateur.

Note 3 : la taille réelle des caractères qu'un utilisateur voit est dépendante à la fois de la définition de la taille faite par l'auteur, du périphérique de restitution de l'utilisateur ou du paramétrage de l'agent utilisateur. Pour la majorité des polices de corps de texte, 14 et 18 points est sensiblement équivalent à 1,2 et 1,5 em ou à 120% et 150% de la taille par défaut du corps de texte (en considérant que la police de corps est à 100%), mais les auteurs seraient tenus de vérifier cela pour les polices particulières qui seraient utilisées. Quand les polices sont définies en unités relatives, la taille réelle du point est mesurée par l'agent utilisateur pour l'affichage. La taille d'un point doit être obtenue auprès de l'agent utilisateur ou calculée sur la même base de mesure que celle de l'agent utilisateur, lors de l'évaluation de ce critère de succès. Les utilisateurs qui ont une basse vision auront à choisir les paramètres appropriés.

Note 4 : lors de l'utilisation de texte sans spécification de taille de caractère, la taille la plus petite utilisée dans les principaux navigateurs pour le texte dont la taille n'est pas spécifiée serait considérée comme une taille raisonnable pour la police. Si un titre de niveau 1 est restitué en 14pt gras ou plus sur les principaux navigateurs, alors il est raisonnable de considérer qu'il s'agit de texte agrandi. Le redimensionnement relatif peut être calculé de manière identique à partir de la taille par défaut.

Note 5 : la taille 18 ou 14 points pour les textes en alphabet latin est définie à partir de la taille minimum pour les grands caractères (14pt) et de la taille standard plus grande (18pt). Pour les autres polices telles que les langues CJK, les tailles « équivalentes » seraient la taille de grand caractère minimum utilisée pour ces langues et la taille de grands caractères plus grande suivante.

composant d'interface utilisateur

partie du contenu qui est perçue par les utilisateurs comme un élément de contrôle unique pour une fonction distincte

Note 1 : plusieurs composants d'interface utilisateur peuvent être implémentés au sein d'un seul programme. La notion de composant n'est pas liée ici aux techniques de programmation, mais plutôt à ce que les utilisateurs perçoivent comme des éléments de contrôle distincts.

Note 2 : les composants d'interface utilisateur incluent les éléments de formulaire et les liens aussi bien que des composants générés par scripts.

Exemple : un microprogramme (applet) dispose d'un « élément de contrôle » permettant de se déplacer dans le contenu ligne par ligne, page par page ou au hasard. Puisque chacune de ces fonctions devrait avoir un nom et fonctionner indépendamment, elles constitueraient chacune un « composant d'interface utilisateur ».

purement décoratif

utilisé seulement dans un but esthétique, ne fournissant aucune information et n'ayant aucune fonctionnalité

Note : un texte est purement décoratif si les mots peuvent être réarrangés ou remplacés sans changer leur raison d'être.

Exemple : la page de couverture d'un dictionnaire présente un arrière-plan estompé et constitué de mots choisis au hasard.

rapport de contraste

(L1 + 0,05) / (L2 + 0,05), où

Note 1 : le rapport de contraste peut varier de 1 à 21 (communément écrit 1:1, 1 pour 1, à 21:1, 21 pour 1).

Note 2 : étant donné que les auteurs ne contrôlent pas la configuration de l'utilisateur concernant le rendu du texte (par exemple le lissage de police ou l'anti-crénelage), le rapport de contraste du texte peut être évalué en désactivant l'anti-crénelage.

Note 3 : en ce qui concerne les critères de succès 1.4.3 et 1.4.6, le contraste est mesuré en tenant compte de l'arrière-plan sur lequel le texte est normalement affiché. Si aucune couleur d'arrière-plan n'est spécifiée, il est considéré comme blanc.

Note 4 : la couleur d'arrière-plan est la couleur spécifiée du contenu sur lequel le texte est normalement affiché. Il est considéré comme une erreur de ne pas définir une couleur d'arrière-plan lorsque la couleur du texte est spécifiée, parce que la couleur d'arrière-plan de l'utilisateur est inconnue et ne peut donc pas être évaluée pour vérifier si le contraste est suffisant. Pour la même raison, il est aussi considéré comme une erreur de ne pas définir la couleur du texte lorsqu'une couleur d'arrière-plan est spécifiée.

Note 5 : lorsqu'il y a une bordure autour de la lettre, la bordure peut augmenter le contraste et serait utilisée dans le calcul du contraste entre la lettre et son arrière-plan. La couleur d'une bordure étroite autour de la lettre serait utilisée à la place de la lettre. Une bordure large autour de la lettre qui remplit l'espace dans lequel se découpe le détail de la lettre agit comme un halo et serait considérée comme un arrière-plan.

Note 6 : la conformité aux WCAG devrait être évaluée pour les paires de couleurs spécifiées dans le contenu qu'un auteur s'attendrait à voir apparaître de façon adjacente dans une présentation habituelle. Les auteurs n'ont pas besoin de prendre en considération les présentations inhabituelles comme les changements de couleurs faits par l'agent utilisateur sauf si ces changements sont provoqués par le code de l'auteur.

texte

séquence de caractères pouvant être déterminée par un programme informatique, et exprimant quelque chose dans une langue donnée

texte sous forme d'image

texte qui est restitué sous une forme non textuelle (par exemple une image) dans le but de permettre un effet visuel particulier

Note : cela n'inclut pas le texte qui est une partie d'une image qui contient d'autres contenus visuels signifiants.

Exemple : le nom d'une personne sur un badge dans une photographie.

Arrière-plan sonore de faible volume ou absent :
Comprendre le CS 1.4.7

1.4.7 Arrière-plan sonore de faible volume ou absent : pour un contenu seulement audio pré-enregistré qui (1) contient principalement de la parole au premier plan, (2) n'est pas un CAPTCHA ou un logo sonore et (3) qui n'est pas une vocalisation dont l'intention est principalement d'être musicale comme une chanson ou un rap, au moins l'une des conditions suivantes est vraie : (Niveau AAA)

  • Sans arrière-plan : le contenu audio ne contient pas d'arrière-plan sonore.

  • Désactivation : l'arrière-plan sonore peut être désactivé.

  • 20 dB : l'arrière-plan sonore est au moins 20 décibels plus faible que le contenu parlé au premier plan sauf pour certains effets sonores occasionnels durant seulement une ou deux secondes.

    Note : par la définition du « décibel », le volume de l'arrière-plan sonore correspondant à cette exigence est approximativement quatre fois plus faible que le contenu parlé au premier plan.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que tous les sons qui ne sont pas de la parole soient suffisamment faibles pour que l'utilisateur qui est malentendant puisse séparer les paroles des fonds sonores ou d'autres contenus parlés de premier plan.

La valeur de 20 dB a été choisie d'après Large area assistive listening systems (ALS): Review and recommendation (analyse et recommandations pour les systèmes d'assistance auditive, applicables aux lieux de grandes dimensions) [LAALS] et In-the-ear measurements of interference in hearing aids from digital wireless telephones (Mesures intra-auriculaires des interférences dans les aides auditives, provoquées par les téléphones numériques sans fil) ([HEARING-AID-INT]

Avantages spécifiques du critère de succès 1.4.7 :

  • Les personnes qui sont malentendantes ont souvent de grandes difficultés à séparer la parole de l'arrière-plan sonore.

Exemples pour le critère de succès 1.4.7

(Aucun exemple n'est actuellement documenté)

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.4.7 - Arrière-plan sonore de faible volume ou absent

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.4.7

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir à l'utilisateur une façon d'ajuster indépendemment les niveaux sonores du premier plan et de l'arrière-plan (lien à venir)

  • Fournir une piste sonore pour un média syncrhonisé incluant des sons d'arrière-plan qui sont au moins 20 décibels plus faibles que la parole (lien à venir)

Échecs fréquents pour le CS 1.4.7

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.4.7.

(Aucun échec n'est actuellement documenté)

Mots clés

CAPTCHA

sigle de « Completely Automated Public Turing test to tell Computers and Humans Apart » (test public de Turing entièrement automatique ayant pour but de distinguer les humains des ordinateurs)

Note 1 : les tests de type CAPTCHA demandent souvent à l'utilisateur de taper un texte présenté dans une image ou un extrait audio déformés.

Note 2 : un test de Turing est tout système de tests conçu pour distinguer un humain d'un ordinateur. Il est nommé en l'honneur du célèbre informaticien Alan Turing. Ce terme a été popularisé par les chercheurs de l'Université Carnegie Mellon. [CAPTCHA]

pré-enregistré

information qui n'est pas diffusée en direct

seulement audio

une présentation temporelle qui contient seulement de l'audio (sans vidéo ni interaction)

Présentation visuelle :
Comprendre le CS 1.4.8

1.4.8 Présentation visuelle : pour la présentation visuelle des blocs de texte, un mécanisme est disponible permettant de réaliser ce qui suit : (Niveau AAA)

  1. Les couleurs de premier plan et d'arrière-plan peuvent être choisies par l'utilisateur.

  2. La largeur n'excède pas 80 caractères ou glyphes (40 si CJK).

  3. Le texte n'est pas justifié (aligné simultanément à droite et à gauche).

  4. L'espacement entre les lignes (interlignage) est d'une valeur d'au moins 1,5 dans les paragraphes et l'espacement entre les paragraphes est au moins 1,5 fois plus grand que la valeur de l'interligne.

  5. La taille du texte peut être redimensionnée jusqu'à 200 pour cent sans l'aide d'une technologie d'assistance et sans que l'utilisateur soit obligé de faire défiler le texte horizontalement pour lire une ligne complète dans une fenêtre plein écran.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que le texte rendu visuellement est présenté de telle manière qu'il puisse être perçu sans que sa mise en forme n'interfère avec sa lisibilité. Les personnes ayant des limitations cognitives, de troubles du langage et de l'apprentissage ainsi que certains utilisateurs avec une basse vision ne peuvent pas percevoir le texte et/ou peuvent perdre le fil de la lecture si le texte est présenté d'une manière qui leur est difficile à lire.

Les personnes ayant certaines limitations visuelles ou cognitives doivent être en mesure de sélectionner la couleur du texte et la couleur de l'arrière-plan. Elles choisissent parfois des combinaisons qui semblent peu intuitives pour quelqu'un n'ayant pas ces limitations. Parfois, ces combinaisons ont de très faibles contrastes. Parfois, seules des combinaisons de couleurs très spécifiques leurs sont adaptées. Le contrôle de la couleur et d'autres aspects de la présentation du texte influent de manière très différente sur leur compréhension.

De longues lignes de textes peuvent devenir un obstacle important pour les personnes ayant des difficultés de lecture ou avec une limitation visuelle. Elles ont du mal à se situer dans le texte et à suivre le flux de texte. Il est plus facile pour elles de continuer sur la ligne suivante dans un bloc lorsqu'elles disposent d'un bloc de texte étroit. Les lignes ne devraient pas dépasser 80 caractères ou glyphes (40 si CJK), où les glyphes sont l'unité d'écriture dans les systèmes d'écriture pour du texte. Des études ont montré que les caractères chinois, japonais et coréens (CJK) sont approximativement deux fois plus larges que les caractères non-CJK lorsque les deux types de caractères sont affichés avec des caractéristiques permettant d'atteindre la même lisibilité, ainsi la longueur maximale d'une ligne pour les caractères CJK est la moitié de celle des caractères non-CJK.

Les personnes ayant une limitation cognitive trouvent difficile de suivre un texte où les lignes sont rapprochées. Leur proposer plus d'espace entre les lignes et les paragraphes leur permet de mieux suivre la ligne suivante et de reconnaître quand elles ont atteint la fin d'un paragraphe. Le mieux est qu'il y ait plusieurs options possibles, par exemple, un espacement d'une valeur de un et demi et un double espace entre les lignes. Par espacement d'une valeur de un et demi on entend que le haut d'une ligne soit situé à 150% du haut de la ligne située en-dessous, ce qui est le cas lorsque le texte possède un « interligne simple » (l'espacement par défaut dans une police de caractères). L'espacement entre les paragraphes est au moins 1,5 fois plus grand que la valeur de l'interligne, on entend par cela que le haut de la dernière ligne d'un paragraphe soit situé à 250% du haut de la première ligne du paragraphe suivant (c'est-à-dire qu'il y a une ligne vide de séparation entre les deux paragraphes qui est de 150% par rapport à l'espace de la ligne de séparation seule).

Les personnes ayant certaines limitations cognitives ont des problèmes de lecture du texte lorsque celui-ci est à la fois justifié à gauche et à droite. L'espacement inégal entre les mots d'un texte justifié peut provoquer des « rivières » d'espaces blancs qui courent jusqu'au bas de la page rendant la lecture difficile et dans certains cas impossible. La justification du texte peut également entraîner le rapprochement de mots de sorte qu'il devienne difficile pour elles de situer les limites des mots.

La disposition pour le redimensionnement garantit que le texte rendu visuellement (les caractères qui ont été affichés de sorte qu'ils puissent être lus [à l'opposé des caractères qui sont encore sous forme de données comme les caractères définis en ASCII]) puisse être redimensionné sans exiger que wrapping l'utilisateur fasse défiler le contenu à gauche et à droite pour le voir entièrement. Lorsque le contenu a été écrit pour que cela soit possible, le contenu est dit redistribuable. Cela permet aux personnes malvoyantes et à celles ayant une limitation cognitive d'augmenter la taille du texte sans pour autant être désorientées.

Le redimensionnement du contenu relève en premier lieu de la responsabilité de l'agent utilisateur. Les agents utilisateurs qui satisfont le point de contrôle 4.1 des UAAG 1.0 permettent aux utilisateurs de configurer la taille des textes. La responsabilité de l'auteur est de créer un contenu Web qui n'empêche pas l'agent utilisateur de redimensionner le contenu de manière efficace et qui permet de recomposer le contenu au sein de la largeur courante de la fenêtre. Voir Comprendre le critère de succès 1.4.4 Redimensionnement du texte pour des discussions supplémentaires sur le redimensionnement du texte.

L'exigence à propos du défilement horizontal n'est pas destinée à être appliquée aux appareils à petit écran où les longs mots peuvent être affichés sur une seule ligne et vont nécessiter que les utilisateurs fassent défiler le contenu horizontalement. Pour l'application de cette exigence, les auteurs doivent s'assurer que le contenu répond à cette exigence à l'affichage sur les écrans d'ordinateurs de bureau ou portable de taille courante dont l'espace de restitution est maximisé. Du fait que les gens gardent leurs ordinateurs pendant plusieurs années, il est conseillé de ne pas se baser sur les dernières résolutions d'écrans des ordinateurs de bureau ou portable, mais de prendre en considération la plus représentative des résolutions d'écrans durant une période de plusieurs années précédant cette évaluation.

La césure des mots devrait toujours être possible tant que les mots ne sont pas plus longs qu'un seul mot qui ne dépasse pas la moitié de la largeur d'un plein écran. Les très longues URI peuvent glisser sur le côté sur des écrans agrandis mais elles ne seront pas considérées comme un texte « à lire » et ne seraient donc pas en violation de cette disposition.

Cette disposition ne signifie pas qu'un utilisateur n'ait jamais besoin d'utiliser le défilement horizontal. Cela signifie seulement qu'il n'aurait pas besoin d'utiliser le défilement horizontal en avant et en arrière pour lire une ligne de texte. Par exemple, si une page se composait de deux colonnes de texte de même taille, cette disposition serait automatiquement satisfaite. L'agrandissement de la page conserverait la première colonne à l'écran et l'utilisateur aurait juste besoin de faire défiler la page verticalement pour la lire. Pour lire la seconde colonne, il ferait défiler la page horizontalement vers la droite, la colonne de droite tiendrait alors entièrement à l'écran et la lecture se ferait sans utiliser le défilement horizontal.

Avantages spécifiques du critère de succès 1.4.8 :

Ce critère de succès aide les utilisateurs ayant une basse vision en les laissant voir le texte sans éléments de présentation distrayants. Il leur permet de configurer le texte de manière à ce qu'il soit plus facile pour eux de le voir en leur permettant de contrôler la couleur et la taille des blocs de texte.

Ce critère de succès aide les personnes ayant une limitation cognitive, un trouble du langage ou de l'apprentissage à percevoir le texte et à se retrouver dans les blocs de texte.

  • Les personnes ayant certaines limitations cognitives peuvent mieux lire le texte lorsqu'elles peuvent sélectionner leurs propres combinaisons de couleurs d'avant-plan et d'arrière-plan.

  • Les personnes ayant certaines limitations cognitives peuvent se retrouver plus facilement quand les blocs de texte sont étroits et quand ils peuvent configurer la quantité d'espace entre les lignes et les paragraphes.

  • Les personnes ayant certaines limitations cognitives peuvent plus facilement lire du texte lorsque les espaces entre les mots sont réguliers.

Exemples pour le critère de succès 1.4.8

Les images suivantes montrent des exemples d'un espacement simple entre les lignes, d'un espacement d'une valeur de un et demi et d'un espacement double d'un texte dans un paragraphe.

Exemple d'un espacement simple du texte. (pas d'espace entre chaque ligne du texte)Exemple d'un espacement d'une valeur de un et demi. (un espace est égal à la moitié de la hauteur d'une ligne de texte)Exemple d'un espacement double du texte. (entre chaque ligne, un espace est égal à la hauteur d'une ligne de texte)

Des exemples de glyphes incluent « A », « → » (un symbole de flèche), et « さ » (un caractère japonais).

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.4.8 - Présentation visuelle

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : étant donné que ce critère de succès est en plusieurs parties, vous devez satisfaire à l'un des éléments numérotés pour chacune des exigences ci-dessous.

Première exigence : techniques pour veiller à ce que les couleurs de premier plan et d'arrière-plan puissent être sélectionnées par l'utilisateur
  1. C23 : Spécifier les couleurs de texte et d'arrière-plan en CSS pour les contenus secondaires comme les bannières, les fonctionnalités et la navigation, sans spécifier les couleurs de texte et d'arrière-plan du contenu principal (en anglais) (CSS) OU

  2. C25 : Spécifier les bordures et la mise en page en CSS pour délimiter les zones de la page Web, sans spécifier les couleurs de texte et d'arrière-plan (en anglais) (CSS) OU

  3. G156 : Utiliser une technologie qui permet de changer l'avant-plan et l'arrière-plan des blocs de texte dans des agents utilisateur communément disponibles (en anglais) OU

  4. G148 : Ne pas spécifier de couleur d'arrière-plan ni de couleur de texte et ne pas utiliser une technologie qui change ces couleurs par défaut (en anglais) OU

  5. G175 : Fournir un outil de sélection multi-couleurs sur la page pour l'avant-plan et l'arrière-plan (en anglais)

Deuxième exigence : techniques pour assurer que la largeur ne soit pas supérieure à 80 caractères ou glyphes (40 si CJK)
  1. H87 : Ne pas interférer avec la redistribution du texte par l'agent utilisateur quand la fenêtre de visualisation est rétrécie (en anglais) (HTML) OU

  2. C20 : Utiliser des mesures relatives pour fixer la largeur des colonnes de sorte que les lignes puissent avoir une moyenne de 80 caractères ou moins en redimensionnant le navigateur (en anglais) (CSS)

Troisième exigence : techniques pour assurer que le texte ne soit pas justifié (aligné simultanément à droite et à gauche)
  1. C19 : Spécifier l'alignement soit à gauche, soit à droite en CSS (en anglais) (CSS) OU

  2. G172 : Fournir un mécanisme pour enlever la justification du texte (en anglais) OU

  3. G169 : Aligner le texte d'un seul côté (en anglais)

Quatrième exigence : techniques pour assurer que l'espacement entre les lignes (interlignage) soit d'une valeur d'au moins 1,5 dans les paragraphes et l'espacement entre les paragraphes soit au moins 1,5 fois plus grand que la valeur de l'interligne
  1. G188 : Fournir un bouton sur la page pour augmenter l'espace entre les lignes et entre les paragraphes (en anglais)OU

  2. C21 : Spécifier l'espacement entre les lignes en CSS (en anglais) (CSS)

Cinquième exigence : techniques pour assurer que la taille du texte puisse être redimensionnée jusqu'à 200 pour cent sans l'aide d'une technologie d'assistance et sans que l'utilisateur soit obligé de faire défiler le texte horizontalement pour lire une ligne complète dans une fenêtre plein écran
  1. Ne pas interférer avec la redistribution du texte par l'agent utilisateur quand la fenêtre de visualisation est rétrécie (Général, lien à venir) OU

  2. G146 : Utiliser une mise en page fluide (en anglais) ET utiliser pour le contenu des unités de mesure qui sont relatives par rapport à d'autres unités de mesure en utilisant au moins l'une des techniques suivantes :

  3. C26 : Fournir, dans le contenu, des choix pour basculer à une mise en page qui n'exige pas que l'utilisateur fasse défiler horizontalement pour lire une ligne de texte (en anglais) (CSS)

Techniques (recommandées) supplémentaires pour 1.4.8

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Utiliser un effet de survol pour surligner un paragraphe, un élément de liste, ou une cellule de tableau (HTML, CSS) (lien à venir)

  • Présenter le texte avec une police sans empattement ou fournir un mécanisme qui permet une telle présentation (CSS) (lien à venir)

  • Utiliser une liste verticale (à puce ou numérotée) plutôt qu'une liste linéaire (lien à venir)

  • Utiliser les majuscules et les minuscules conformément aux conventions de la langue du texte (lien à venir)

  • Fournir du texte agrandi par défaut (lien à venir)

  • Éviter l'utilisation de texte dans des images matricielles (lien à venir)

  • Éviter de redimensionner des polices à une taille plus petite que la taille par défaut de l'agent utilisateur (lien à venir)

  • Créer un espacement suffisant entre les lignes et entre les colonnes (lien à venir)

  • Éviter le texte centré (lien à venir)

  • Éviter les passages de texte en italique (lien à venir)

  • Éviter la surutilisation de styles différents sur une même page dans les sites (lien à venir)

  • Rendre les liens visuellement distincts (lien à venir)

  • Fournir des puces extensibles (lien à venir)

  • Permettre d'afficher ou de masquer les puces (lien à venir)

  • Placer un cadratin ou deux espaces après les phrases (lien à venir)

Mots clés

blocs de texte

plus d'une phrase de texte

dans une fenêtre plein écran

sur les écrans d'ordinateur de bureau ou portable de taille courante dont l'espace de restitution est maximisé

Note : du fait que les gens gardent leurs ordinateurs pendant plusieurs années, il est conseillé de ne pas se baser sur les dernières résolutions d'écrans des ordinateurs de bureau ou portable, mais de prendre en considération la plus représentative des résolutions d'écrans durant une période de plusieurs années précédant cette évaluation.

mécanisme

processus ou technique pour obtenir un résultat

Note 1 : le mécanisme peut être explicitement fourni par le contenu ou dépendre de la plateforme ou de l'agent utilisateur, y compris les technologies d'assistance.

Note 2 : le mécanisme doit satisfaire à tous les critères de succès (d'un niveau donné) pour déclarer un niveau de conformité.

Texte sous forme d'image (sans exception) :
Comprendre le CS 1.4.9

1.4.9 Texte sous forme d'image (sans exception) : le texte sous forme d'image est utilisé seulement pour du texte purement décoratif ou lorsqu'une présentation spécifique du texte est essentielle à l'information véhiculée. (Niveau AAA)

Note : les logotypes (le texte qui fait partie d'un logo ou d'un nom de marque) sont considérés comme essentiels.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de permettre aux personnes qui ont besoin d'une présentation visuelle particulière du texte d'être en mesure d'ajuster la présentation du texte selon le besoin. Cela comprend les personnes qui ont un besoin particulier concernant une taille de police, une couleur d'avant-plan et d'arrière-plan, une famille de police de caractères, un espacement entre les lignes ou un alignement du texte.

Cela implique d'implémenter le texte d'une manière qui permet à sa présentation d'être modifiée ou de fournir un mécanisme par lequel les utilisateurs peuvent sélectionner une présentation de remplacement. Utiliser du texte sous forme d'image est un exemple d'implémentation qui ne permet pas aux utilisateurs de modifier la présentation du texte qui y est affiché.

Dans certaines situations, une présentation spécifique du texte est essentielle à l'information véhiculée. Cela signifie que l'information serait perdue sans une présentation visuelle spécifique. Dans ce cas, la mise en œuvre du texte d'une manière qui permet à sa présentation d'être modifiée n'est pas requise. Cela comprend le texte qui illustre un aspect visuel spécifique du texte, comme une famille de police spécifique, ou du texte qui véhicule une identité, comme du texte au sein d'un logo d'entreprise.

Le texte qui est de la décoration ne nécessite pas de mise en œuvre du texte d'une manière qui permet à sa présentation d'être modifiée.

Avantages spécifiques du critère de succès 1.4.9 :

  • Les personnes ayant une basse vision (qui peuvent avoir des difficultés à lire le texte avec la famille de police de caractères, la taille et/ou la couleur définies par l'auteur).

  • Les personnes ayant un dysfonctionnement du système visuel (qui peuvent avoir des difficultés à lire le texte avec l'espacement entre les lignes et/ou l'alignement définis par l'auteur).

  • Les personnes ayant des troubles cognitifs qui affectent la lecture.

Exemples pour le critère de succès 1.4.9

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 1.4.9 – Texte sous forme d'image (sans exception)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 1.4.9

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Techniques générales pour le contenu non textuel
  • Utiliser des scripts côté serveur pour modifier la taille des textes sous forme d'images (lien à venir)

Techniques CSS

Échecs fréquents pour le CS 1.4.9

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.4.3.

(Aucun échec n'est actuellement documenté)

Mots clés

essentiel(le)

élément qui changerait fondamentalement les informations ou les fonctionnalités du contenu s'il était supprimé et informations et fonctionnalités qui ne pourraient être restituées autrement d'une manière conforme

purement décoratif

utilisé seulement dans un but esthétique, ne fournissant aucune information et n'ayant aucune fonctionnalité

Note : un texte est purement décoratif si les mots peuvent être réarrangés ou remplacés sans changer leur raison d'être.

Exemple : la page de couverture d'un dictionnaire présente un arrière-plan estompé et constitué de mots choisis au hasard.

texte

séquence de caractères pouvant être déterminée par un programme informatique, et exprimant quelque chose dans une langue donnée

texte sous forme d'image

texte qui est restitué sous une forme non textuelle (par exemple une image) dans le but de permettre un effet visuel particulier

Note : cela n'inclut pas le texte qui est une partie d'une image qui contient d'autres contenus visuels signifiants.

Exemple : le nom d'une personne sur un badge dans une photographie.

Accessible au clavier :
Comprendre la règle 2.1

Règle 2.1 : rendre toutes les fonctionnalités accessibles au clavier.

Objectif de la règle 2.1

Si toute fonctionnalité peut être réalisée en utilisant le clavier, elle peut être accomplie par les utilisateurs de clavier, par commande vocale (créant une saisie au clavier), par la souris (via l'utilisation d'un clavier virtuel), par une large gamme de technologies d'assistance qui simulent des commandes clavier en sortie. Aucune autre forme de saisie n'est aussi souple ou aussi universellement adoptée et utilisée par les personnes ayant différentes limitations fonctionnelles, tant que l'interaction au clavier ne dépend pas de la durée.

Notez que le fait de fournir un mode de saisie universel au clavier ne signifie pas que les autres modes de saisie ne doivent pas être pris en charge. Une saisie optimisée par commande vocale, une saisie optimisée par souris/pointeur etc. est également bonne. L'important est de fournir aussi une saisie et un contrôle au clavier.

D'origine, certains appareils n'ont pas de clavier, par exemple, les assistants personnels numériques (pda) ou les téléphones portables. Toutefois, si ces appareils ont la possibilité de naviguer sur internet, ils offrent des moyens de générer du texte ou des « commandes ». Cette règle utilise le terme « interface clavier » pour tenir compte du fait que le contenu web doit être contrôlé à l'aide de commandes qui peuvent venir d'un clavier, d'un émulateur de clavier, ou d'autres équipements ou logiciels pouvant générer une saisie au clavier ou du texte.

Techniques recommandées pour la règle 2.1 (sans rattachement à un critère de succès spécifique)

Les techniques spécifiques pour satisfaire à chaque critère de succès de cette règle sont listées dans les sections Comprendre de chaque critère de succès (énumérés ci-dessous). Cependant, si des techniques permettant de traiter cette règle ne se rapportent à aucun critère de succès, elles sont listées ici. Ces techniques ne sont pas requises ou suffisantes pour satisfaire à un critère de succès, mais peuvent rendre certains types de contenus Web plus accessibles à un plus grand nombre de personnes.

  • Toutes les techniques recommandées pour cette règle sont liées à des critères de succès spécifiques et sont listées ci-après.

Clavier :
Comprendre le CS 2.1.1

2.1.1 Clavier : toutes les fonctionnalités sont utilisables à l'aide d'une interface clavier sans exiger un rythme de frappe propre à l'utilisateur, sauf lorsque la fonction sous-jacente nécessite une saisie qui dépend du tracé du mouvement effectué par l'utilisateur et pas seulement des points de départ et d'arrivée de ce tracé. (Niveau A)

Note 1 : cette exception ne concerne que la fonction sous-jacente et non la technique de saisie. Par exemple, lorsqu'on utilise l'écriture manuscrite pour saisir du texte, la technique de saisie (l'écriture manuscrite) nécessite une saisie qui dépend d'un tracé, mais la fonction sous-jacente (la saisie de texte) ne le requiert pas.

Note 2 : cela n'interdit pas et ne devrait pas décourager l'utilisation de la souris ou de toute autre méthode de saisie en plus de l'utilisation du clavier.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de garantir, partout où cela est possible, que le contenu peut être manipulé à l'aide d'un clavier ou d'une interface clavier (un clavier alternatif peut donc être utilisé). À l'aide d'un clavier ou d'un clavier alternatif, le contenu peut être manipulé par des personnes qui n'ont pas de vision (qui ne peuvent utiliser de périphériques comme les souris nécessitant une coordination de l’œil et de la main) ainsi que par les personnes qui doivent se servir de claviers alternatifs ou de périphériques de saisie qui agissent comme des émulateurs de clavier. Les émulateurs de clavier incluent les logiciels de saisie par commande vocale, les logiciels de commande par le souffle, les claviers virtuels, les logiciels reposant sur le balayage et de nombreuses technologies d'assistance et claviers alternatifs. Les personnes malvoyantes peuvent aussi avoir des difficultés à suivre un pointeur et trouver plus facile (ou n'avoir que cette possibilité) d'utiliser un logiciel si elles peuvent le contrôler à l'aide d'un clavier.

Des exemples de « rythme de frappe propre à l'utilisateur » incluent les situations dans lesquelles un utilisateur serait amené à répéter ou exécuter plusieurs commandes dans un court laps de temps ou dans lesquelles une touche doit être maintenue enfoncée pendant une période prolongée avant que la commande ne soit prise en compte.

La phrase « sauf lorsque la fonction sous-jacente nécessite une saisie qui dépend du tracé du mouvement effectué par l'utilisateur et pas seulement des points de départ et d'arrivée » a été ajoutée pour distinguer ces éléments qui ne peuvent raisonnablement être contrôlés au clavier.

La plupart des actions réalisables à l'aide d'un périphérique de pointage peuvent également l'être au clavier (par exemple, cliquer, sélectionner, déplacer, redimensionner). Il existe cependant un petit ensemble de commandes effectuées à l'aide d'un périphérique de pointage qui ne peuvent être faites au clavier de quelque manière connue que ce soit sans requérir un nombre démesuré de commandes. Dessiner à main levée, faire du coloriage, faire voler un hélicoptère par dessus des obstacles sont autant de fonctions nécessitant une saisie qui dépend du tracé du mouvement. Tracer des lignes droites, des formes géométriques courantes, redimensionner des fenêtres et déplacer des objets à un endroit (dès lors que le tracé vers cet endroit n'est pas significatif), ne nécessitent pas de saisie qui dépend du tracé du mouvement.

L'utilisation de MouseKeys ne satisferait pas à ce critère de succès car il ne s'agit pas d'un équivalent du clavier du point de vue de l'application ; c'est un équivalent de la souris (du point de vue applicatif, c'est une souris).

Il est admis que le développement de fonctionnalités de saisie utilisateur prend en compte le fait que les fonctionnalités d'accessibilité par le clavier du système d'exploitation peuvent être utilisées. Par exemple, les touches de modification peuvent se trouver verrouillées. Dans un tel environnement, le contenu fonctionne toujours, n'envoie pas d'évènements qui entreraient en conflit avec les touches de modification verrouillées et produiraient des résultats indésirables.

Avantages spécifiques du critère de succès 2.1.1 :

  • Les personnes aveugles (qui ne peuvent utiliser de périphériques comme les souris qui nécessitent une coordination de l’œil et de la main)

  • Les personnes malvoyantes (qui peuvent avoir du mal à trouver ou à suivre le symbole du pointeur sur l'écran)

  • Certaines personnes ayant des tremblements de la main trouvent l'utilisation de la souris très difficile et se servent donc habituellement d'un clavier

Exemples pour le critère de succès 2.1.1

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 2.1.1 - Clavier

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 2.1.1

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Utiliser les attributs XHTML role, state et value si des éléments statiques réutilisés ont des composants interactifs (lien à venir) ET SCR29 : Ajouter des actions au clavier accessibles à des éléments HTML statiques (en anglais) (programmation par script)

  • Fournir des raccourcis clavier pour les liens et contrôles de formulaire importants (lien à venir)

  • Utiliser des combinaisons uniques de lettres pour débuter chaque élément d'une liste (lien à venir).

  • Choisir le déclencheur d'événement le plus abstrait (lien à venir) (Programmation par script)

  • Utiliser l'événement onactivate (lien à venir) (programmation par script)

  • Éviter l'utilisation à d'autres fins des commandes au clavier communément utilisées par les agents utilisateurs (lien à venir)

Mots clés

fonctionnalité

processus et résultats atteignables par une action de l'utilisateur

interface clavier

interface utilisée par un logiciel pour obtenir une saisie au clavier

Note 1 : une interface clavier permet aux utilisateurs de fournir aux programmes une saisie au clavier même si la technologie native ne comporte pas de clavier.

Exemple : un assistant numérique personnel (PDA) à écran tactile possède une interface clavier intégrée à son système d'exploitation et un connecteur pour des claviers externes. Les applications dans le PDA peuvent utiliser l'interface pour obtenir une saisie au clavier externe ou par d'autres applications qui simulent une sortie clavier comme les interpréteurs d'écriture manuscrite ou les applications de transcription vocale en texte avec des fonctionnalités « d'émulation clavier ».

Note 2 : l'utilisation d'une application (ou de parties d'une application) à travers un pointeur souris dirigé au clavier, comme MouseKeys, ne constitue pas une opération réalisée au travers d'une interface clavier car l'utilisation du programme passe par l'interface de pointage et non pas par l'interface clavier.

Pas de piège au clavier :
Comprendre le CS 2.1.2

2.1.2 Pas de piège au clavier : si le focus du clavier peut être positionné sur un élément de la page à 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. (Niveau A)

Note : puisque tout contenu ne satisfaisant pas à ce critère de succès peut interférer avec la capacité de l'utilisateur à exploiter la page entière, tout le contenu présent dans la page Web (qu'il soit utilisé pour satisfaire à d'autres critères de succès ou non) doit satisfaire à ce critère de succès. Voir l' exigence de conformité 5 : non-interférence.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de garantir que ce contenu ne « piège » pas le focus du clavier à l'intérieur d'une sous-section du contenu de la page web. C'est un problème fréquent lorsque l'on combine plusieurs formats sur une page et que ceux-ci sont restitués à l'aide d'extensions ou d'applications embarquées.

Il arrive parfois que la fonctionnalité d'une page web restreigne le focus à une sous-section du contenu, jusqu'à ce que l'utilisateur comprenne comment se sortir de cette situation et « débloque » le focus.

Avantages spécifiques du critère de succès 2.1.2 :

  • Les personnes qui se servent d'un clavier ou d'une interface clavier pour exploiter le web, dont les personnes aveugles et les personnes ayant des limitations physiques.

Exemples pour le critère de succès 2.1.2

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 2.1.2 - Pas de piège au clavier

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 2.1.2

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

(Aucune technique recommandée n'est actuellement documentée)

Échecs fréquents pour le CS 2.1.2

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 2.1.2.

Mots clés

interface clavier

interface utilisée par un logiciel pour obtenir une saisie au clavier

Note 1 : une interface clavier permet aux utilisateurs de fournir aux programmes une saisie au clavier même si la technologie native ne comporte pas de clavier.

Exemple : un assistant numérique personnel (PDA) à écran tactile possède une interface clavier intégrée à son système d'exploitation et un connecteur pour des claviers externes. Les applications dans le PDA peuvent utiliser l'interface pour obtenir une saisie au clavier externe ou par d'autres applications qui simulent une sortie clavier comme les interpréteurs d'écriture manuscrite ou les applications de transcription vocale en texte avec des fonctionnalités « d'émulation clavier ».

Note 2 : l'utilisation d'une application (ou de parties d'une application) à travers un pointeur souris dirigé au clavier, comme MouseKeys, ne constitue pas une opération réalisée au travers d'une interface clavier car l'utilisation du programme passe par l'interface de pointage et non pas par l'interface clavier.

Clavier (pas d'exception) :
Comprendre le CS 2.1.3

2.1.3 Clavier (pas d'exception) : toutes les fonctionnalités du contenu sont utilisables à l'aide d'une interface clavier sans exiger un rythme de frappe propre à l'utilisateur. (Niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de garantir que tout contenu est utilisable au clavier. Il est identique au critère de succès 2.1.1, sauf qu'aucune exception n'est admise. Cela ne signifie pas que le contenu dont la fonction sous-jacente nécessite une saisie qui dépend du tracé du mouvement effectué par l'utilisateur et pas seulement des points de départ et d'arrivée de ce tracé (à l'exclusion des exigences du 2.1.1) doit être rendu accessible par le clavier. Cela signifie plutôt qu'un contenu qui utilise une telle saisie, dépendante du rythme, n'est pas conforme à ce critère de succès et ne peut donc satisfaire à la règle 2.1 au niveau AAA.

Exemples pour le critère de succès 2.1.3

(Aucun exemple n'est actuellement documenté)

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 2.1.3 - Clavier (pas d'exception)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

  1. Il n'existe pas de techniques supplémentaires pour ce critère de succès. Suivez les techniques pour le critère de succès 2.1.1. Si cela n'est pas possible, à cause d'une exigence concernant un mode de saisie dépendant de la durée, il n'est alors pas possible de satisfaire à ce critère de succès de niveau AAA.

Mots clés

Fonctionnalité

processus et résultats atteignables par une action de l'utilisateur

interface clavier

interface utilisée par un logiciel pour obtenir une saisie au clavier

Note 1 : une interface clavier permet aux utilisateurs de fournir aux programmes une saisie au clavier même si la technologie native ne comporte pas de clavier.

Exemple : un assistant numérique personnel (PDA) à écran tactile possède une interface clavier intégrée à son système d'exploitation et un connecteur pour des claviers externes. Les applications dans le PDA peuvent utiliser l'interface pour obtenir une saisie au clavier externe ou par d'autres applications qui simulent une sortie clavier comme les interpréteurs d'écriture manuscrite ou les applications de transcription vocale en texte avec des fonctionnalités « d'émulation clavier ».

Note 2 : l'utilisation d'une application (ou de parties d'une application) à travers un pointeur souris dirigé au clavier, comme MouseKeys, ne constitue pas une opération réalisée au travers d'une interface clavier car l'utilisation du programme passe par l'interface de pointage et non pas par l'interface clavier.

Délai suffisant :
Comprendre la règle 2.2

Règle 2.2 : laisser à l'utilisateur suffisamment de temps pour lire et utiliser le contenu.

Objectif de la règle 2.2

Beaucoup d'utilisateurs en situation de handicap ont besoin de plus de temps que la majorité des utilisateurs pour accomplir des tâches : cela peut leur demander plus de temps pour réagir physiquement, cela peut leur demander plus de temps pour lire, ils peuvent avoir une faible vision qui leur demande plus de temps pour trouver les choses ou les lire, ou ils peuvent être amenés à accéder au contenu via des technologies d'assistance qui nécessitent plus de temps. Cette règle insiste sur le fait de garantir que les utilisateurs soient en mesure d'accomplir les tâches exigées par le contenu, selon leur propre temps de réaction. Les premières approches consistent à éliminer les contraintes de temps ou à laisser aux utilisateurs suffisamment de temps supplémentaire pour leur permettre d'exécuter leurs tâches. Des exceptions sont admises pour les cas où cela n'est pas possible.

Techniques recommandées pour la règle 2.2 (sans rattachement à un critère de succès spécifique)

Les techniques spécifiques pour satisfaire à chaque critère de succès de cette règle sont listées dans les sections Comprendre de chaque critère de succès (énumérés ci-dessous). Cependant, si des techniques permettant de traiter cette règle ne se rapportent à aucun critère de succès, elles sont listées ici. Ces techniques ne sont pas requises ou suffisantes pour satisfaire à un critère de succès, mais peuvent rendre certains types de contenus Web plus accessibles à un plus grand nombre de personnes.

  • Toutes les techniques recommandées pour cette règle sont liées à des critères de succès spécifiques et sont listées ci-après.

Réglage du délai :
Comprendre le CS 2.2.1

2.2.1 Réglage du délai : pour chaque limite de temps fixée par le contenu, au moins l'un des points suivants est vrai : (Niveau A)

  • 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 : 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 devrait être considéré conjointement avec le critère de succès 3.2.1, qui pose des limites aux changements de contenu ou de contexte résultant d'une action de l'utilisateur.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de garantir, partout où cela est possible, qu'une durée adéquate pour interagir avec le contenu web est accordée aux utilisateurs en situation de handicap. Les personnes ayant des limitations telles que la cécité, la malvoyance, la diminution de la dextérité, et des limitations cognitives, peuvent avoir besoin de plus de temps pour lire du contenu ou exécuter des fonctions comme le remplissage de formulaires en ligne. Si des fonctions Web sont soumises à une durée, il sera difficile pour certains utilisateurs d'exécuter l'action requise avant que la limite de temps n'expire. Ce qui peut leur rendre le service inaccessible. Le fait de concevoir des fonctions qui ne dépendent pas de la durée aidera les personnes en situation de handicap à réussir l'exécution de ces fonctions. Le fait de fournir des options qui permettent de désactiver les limites de temps, de personnaliser l'étendue des durées limites, ou de demander du temps supplémentaire avant l'expiration d'une durée, est une aide pour les utilisateurs qui ont besoin de plus de temps que celui imparti pour accomplir pleinement des tâches. Ces options sont énumérées dans l'ordre le plus pratique pour l'utilisateur. Désactiver les limites de temps est mieux que de personnaliser la durée limite, qui est à son tour mieux que de demander du temps supplémentaire avant que n'expire la durée limite.

Tout processus qui se déroule après une certaine durée, sans avoir été initié par l'utilisateur, ou de manière périodique, est considéré comme une limite de temps. Cela comprend les mises à jour partielles ou complètes du contenu (par exemple, le rafraîchissement d'une page), des modifications dans le contenu, ou l'expiration d'un délai offert à l'utilisateur pour réagir à une demande de saisie.

Cela inclut également du contenu qui avance ou se met à jour à un rythme supérieur à celui auquel l'utilisateur est capable de le lire et/ou le comprendre. En d'autres termes, du contenu animé, en mouvement ou défilant constitue une limite de temps par rapport à la capacité de l'utilisateur à lire du contenu.

Toutefois, dans certains cas, il n'est pas possible de modifier la limite de temps (par exemple pour une enchère ou autre évènement en temps réel), et des exceptions sont alors mentionnées pour ces cas.

Notes concernant les limites de temps côté serveur

Dans les cas où le délai n'est pas une exigence intrinsèque mais où le fait de donner à l'utilisateur le contrôle sur la durée invaliderait les résultats, un tiers peut gérer les limites de temps pour l'utilisateur (en accordant, par exemple, le double du temps pour un test).

Voir aussi Comprendre le Critère de succès 2.2.3 Pas de délai.

Avantages spécifiques du Critère de succès 2.2.1 :

  • Les personnes ayant des limitations physiques ont souvent besoin de plus de temps pour réagir, écrire ou réaliser une activité. Les personnes malvoyantes ont besoin de plus de temps pour localiser les choses à l'écran et lire. les personnes aveugles et utilisant un lecteur d'écran peuvent avoir besoin de plus de temps pour comprendre la disposition de l'écran, trouver des informations et manipuler des éléments de contrôle. Les personnes ayant des limitations cognitives ou de langage ont besoin de plus de temps pour lire et comprendre. les personnes sourdes qui communiquent avec la langue des signes ont besoin de plus de temps pour lire un texte écrit (qui peut être pour certaines, une seconde langue).

  • Dans le cas où un interprète en langue des signes est en train de transcrire un contenu audio, le contrôle sur les limites de temps est également important.

  • Les personnes ayant des difficultés de lecture, des limitations cognitives et des difficultés d'apprentissage, qui ont besoin de plus de temps pour lire et comprendre l'information, peuvent avoir du temps supplémentaire pour lire l'information en mettant en pause le contenu.

Exemples pour le critère de succès 2.2.1

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 2.2.1 - Réglage du délai

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : s'il y a des limites de durée de session :
  1. G133 : Proposer une case à cocher sur la première page d'un formulaire multipages permettant à l'utilisateur de demander une limite du temps de session plus longue ou un temps de session sans limite (en anglais)

  2. G198 : Fournir à l'utilisateur une façon de désactiver la limite de temps (en anglais)

Situation B : lorsqu'une limite de temps est gérée par un script dans la page :
  1. G198 : Fournir à l'utilisateur une façon de désactiver la limite de temps (en anglais)

  2. G180 : Fournir à l'utilisateur une façon de fixer la limite de temps à 10 fois la durée par défaut (en anglais)

  3. SCR16 : Fournir un script qui avertit l'utilisateur que le délai va expirer (programmation par script) ET SCR1 : Permettre à l'utilisateur de prolonger le délai par défaut (en anglais) (programmation par script)

  4. FLASH19 : Fournir un script qui avertit l'utilisateur qu'une limite de temps arrive à échéance et fournir un moyen de retarder celle-ci (en anglais) (Flash)

  5. FLASH24 : Permettre à l'utilisateur d'étendre la limite de temps par défaut (en anglais) (Flash)

Situation C : lorsque la lecture est limitée par une durée :
  1. G4 : Permettre de mettre le contenu en pause et de redémarrer là où il a été mis en pause (en anglais)

  2. G198 : Fournir à l'utilisateur une façon de désactiver la limite de temps (en anglais)

  3. SCR33 : Utiliser un script pour faire défiler le contenu et fournir un mécanisme pour le mettre en pause (en anglais) (programmation par script)

  4. SCR36 : Fournir un mécanisme permettant à l'utilisateur d'afficher le texte en mouvement, défilant ou mis à jour automatiquement dans une fenêtre ou une zone statique (en anglais) (programmation par script)

Techniques (recommandées) supplémentaires pour 2.2.1

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Utiliser un script pour interroger le serveur et notifier l'utilisateur qu'un délai est programmé (lien à venir) (Programmation par script)

  • Utiliser des sons pour attirer l'attention de l'utilisateur (lien à venir)

Mots clés

essentiel(le)

élément qui changerait fondamentalement les informations ou les fonctionnalités du contenu s'il était supprimé et informations et fonctionnalités qui ne pourraient être restituées autrement d'une manière conforme

Mettre en pause, arrêter, masquer :
Comprendre le CS 2.2.2

2.2.2 Mettre en pause, arrêter, masquer : pour toute information en mouvement, clignotante, défilante ou mise à jour automatiquement, tous les points suivants sont vrais : (Niveau A)

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

Note 2 : puisque tout contenu ne satisfaisant pas à ce critère de succès peut interférer avec la capacité de l'utilisateur à exploiter la page entière, tout le contenu présent dans la page Web (qu'il soit utilisé pour satisfaire à d'autres critères de succès ou non) doit satisfaire à ce critère de succès. Lire Exigence de conformité 5 : Non-interférence.

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.

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'éviter que l'utilisateur ne soit distrait pendant qu'il interagit avec la page web.

« En mouvement, clignotante et défilante » fait référence à du contenu dans lequel le contenu visible est porteur de sens grâce au mouvement. Les images animées, les présentations sous forme de média synchronisés, les animations, les jeux en temps réel et les bandeaux des cours de la bourse font partie des exemples classiques. « Mise à jour automatique » fait référence à du contenu qui se met à jour ou disparaît selon un intervalle de temps prédéfini. La mise à jour automatique de contenu comprend l'audio, les informations météo qui sont mises à jour automatiquement, les actualités, les mises à jour des cours de la bourse et les présentations et messages défilant automatiquement. Les exigences concernant les contenus en mouvement, clignotants et défilants et les contenus avec mise à jour automatique sont les mêmes, exception faite des cas suivants :

Du contenu en mouvement ou qui se met à jour automatiquement peut être une barrière pour quiconque a des difficultés à lire rapidement un texte statique, également pour quiconque a du mal à suivre des objets en mouvement. Cela peut aussi poser des problèmes pour les lecteurs d'écran.

Du contenu en mouvement peut aussi perturber sérieusement certaines personnes. Certains groupes, en particulier ceux qui ont des troubles de l'attention, sont distraits par un contenu qui clignote et ont du mal à se concentrer sur les autres parties de la page Web. La limite des cinq secondes a été choisie car elle est suffisamment longue pour capter l'attention de l'utilisateur, mais pas au point qu'un utilisateur n'ait à attendre de ne plus être distrait pour utiliser la page, le cas échéant.

Un contenu mis en pause peut soit se poursuivre en temps réel, soit continuer la présentation à partir du point où l'utilisateur l'a laissée.

  1. Mettre en pause le contenu et le continuer à l'endroit où l'utilisateur l'a laissé est la meilleure solution pour les utilisateurs qui veulent mettre en pause pour lire le contenu et est celle qui fonctionne le mieux lorsque le contenu ne dépend pas d'un évènement ou d'un état en temps réel.

    Note : voir Comprendre le critère de succès 2.2.1 Réglage du délai pour les exigences supplémentaires concernant les limites de durée liées à la lecture.

  2. Mettre en pause et passer à l'affichage courant (lorsque la pause est relâchée) est la meilleure solution si l'information est de type temps réel ou porte sur un état. Par exemple, un radar météo, un cours de la bourse, une caméra pour le trafic routier, un compteur d'enchères risqueraient de présenter des informations trompeuses si la mise en pause provoquait l'affichage d'informations périmées au redémarrage du contenu.

    Note : le fait de masquer le contenu aurait le même effet que le fait de mettre en pause puis de passer à l'affichage actuel (au relâchement de la pause).

Note : les termes « clignotement » et « flashs » peuvent parfois faire référence au même contenu.

  • « Le clignotement » fait référence à du contenu posant des problèmes de perte de concentration. Le clignotement peut être permis tant qu'il reste de courte durée et s'arrête (ou peut être arrêté).

  • « Flashant » fait référence à du contenu pouvant déclencher des crises (s'il dépasse le nombre de 3 flashs par secondes et est relativement grand et lumineux). Cela ne peut être autorisé, même pour une seconde, sous peine de provoquer une crise. Et le fait de permettre la désactivation des flashs ne peut pas non plus être autorisé dans la mesure où la crise peut survenir avant que l'utilisateur n'ait le temps d'arrêter le flash.

  • Généralement, les clignotements ne sont pas supérieurs à 3 par seconde ou plus, mais cela peut arriver. Si des clignotements sont supérieurs à 3 par seconde, ils sont aussi considérés comme un flash.

Avantages spécifiques du critère de succès 2.2.2 :

  • Fournir du contenu qui s'arrête de clignoter après cinq secondes ou fournir un mécanisme qui permette aux utilisateurs d'arrêter le clignotement du contenu, permet aux personnes ayant certaines limitations d'interagir avec la page web.

  • L'une des utilisations du clignotement de contenu consiste à attirer l'attention du visiteur sur ce contenu. Bien que ce soit une technique efficace pour les utilisateurs voyants, cela peut être un problème pour certains utilisateurs s'il est persistant. Pour certains groupes de personnes, dont celles ayant un faible niveau d'alphabétisation, des limitations de lecture et des limitations intellectuelles, et les personnes ayant des troubles de l'attention, un contenu clignotant peut leur rendre difficile, voire impossible, l'interaction avec le reste de la page web.

Exemples pour le critère de succès 2.2.2

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 2.2.2 - Mettre en pause, arrêter, masquer

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 2.2.2

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir un mécanisme pour arrêter tous les contenus qui clignotent dans une page Web (lien à venir)

  • Fournir à l'utilisateur un moyen d'arrêter un contenu en mouvement même s'il s'arrêtent automatiquement en moins de 5 secondes (lien à venir)

Mots clés

clignotement

alternance entre deux états visuels d'une façon qui veut attirer l'attention

Note : voir aussi flash. Il est possible que quelque chose soit suffisamment gros et clignote de façon suffisamment lumineuse à la fréquence appropriée pour être aussi considéré comme un flash.

essentiel(le)

élément qui changerait fondamentalement les informations ou les fonctionnalités du contenu s'il était supprimé et informations et fonctionnalités qui ne pourraient être restituées autrement d'une manière conforme

mis en pause

arrêté par une action de l'utilisateur et relancé seulement sur demande de l'utilisateur

Pas de délai d'exécution :
Comprendre le CS 2.2.3

2.2.3 Pas de délai d'exécution : le temps n'est pas un facteur essentiel dans le déroulement de l'événement ou de l'activité, à l'exception des médias synchronisés non interactifs et des événements en temps réel. (Niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de minimiser le nombre d'occurrences d'un contenu qui nécessite une interaction soumise à une durée. Cela permet aux personnes aveugles, malvoyantes, ayant des limitations cognitives, ou des limitations motrices d'interagir avec le contenu. Cela diffère du critère de succès de niveau A pour lequel la seule exception concerne les événements en temps réel.

Note : un contenu vidéo seulement, comme la langue des signes, est traitée dans la règle 1.1.

Avantages spécifiques du critère de succès 2.2.3 :

  • Les personnes ayant des limitations physiques ont souvent besoin de plus de temps pour réagir, pour écrire et réaliser des activités. Les personnes malvoyantes ont besoin de plus de temps pour localiser les choses à l'écran et pour lire. Les personnes aveugles qui utilisent un lecteur d'écran peuvent avoir besoin de plus de temps pour comprendre la mise en forme des écrans, pour trouver une information et pour utiliser des contrôles. Les personnes qui ont des limitations cognitives ou de langage ont besoin de plus de temps pour lire et pour comprendre. Les personnes sourdes qui communiquent en langue des signes peuvent avoir besoin de plus de temps pour lire l'information écrite (ce qui, pour certaines d'entre elles constitue une seconde langue).

  • Dans les cas où un interprète en langue des signes traduit du contenu audio à un utilisateur sourd, le contrôle de la durée est également important.

Exemples pour le critère de succès 2.2.3

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 2.2.3 - Pas de délai d'exécution

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 2.2.3

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

(Aucune technique n'est actuellement documentée)

Échecs fréquents pour le CS 2.2.3

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 2.2.3.

(Aucun échec n'est actuellement documenté)

Mots clés

essentiel(le)

élément qui changerait fondamentalement les informations ou les fonctionnalités du contenu s'il était supprimé et informations et fonctionnalités qui ne pourraient être restituées autrement d'une manière conforme

événement en temps réel

événement qui a) se produit en même temps que la visualisation et b) n'est pas entièrement généré par le contenu

Exemple 1 : une diffusion Web d'une représentation en direct (qui se produit en même temps que la visualisation et qui n'est pas pré-enregistrée).

Exemple 2 : des enchères en ligne avec des gens qui enchérissent (avec une visualisation en direct).

Exemple 3 : des humains interagissant dans un monde virtuel grâce à des avatars (qui ne sont pas entièrement générés par le contenu et qui se produisent en même temps que la visualisation).

média synchronisé

flux audio ou vidéo synchronisé avec un autre format pour présenter de l'information et/ou comportant des composants temporels interactifs, à moins que le média soit un média de remplacement pour un texte clairement identifié comme tel

Interruptions :
Comprendre le CS 2.2.4

2.2.4 Interruptions : les interruptions peuvent être reportées ou supprimées par l'utilisateur, à l'exception des interruptions impliquant une urgence. (Niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de permettre à l'utilisateur de désactiver les mises à jour faites par l'auteur ou le serveur, à l'exception des urgences. Les urgences peuvent comprendre les messages d'alerte d'urgence civiles ou tout autre message prévenant d'un danger pour la santé, la sécurité ou la propriété, dont la perte de données, la perte de connexion etcetera.

Cela permet un accès pour les personnes ayant des limitations cognitives ou des troubles de l'attention afin qu'elles puissent se concentrer sur le contenu. Cela permet aussi aux personnes aveugles ou malvoyantes de ne pas « perdre de vue » le contenu qu'elles sont en train de lire.

Avantages spécifiques du critère de succès 2.2.4 :

  • Les personnes ayant des troubles de l'attention peuvent se concentrer sur le contenu sans être distraites.

  • Les personnes malvoyantes ou qui utilisent un lecteur d'écran ne subiront pas une mise à jour du contenu pendant qu'elles sont en train de le consulter, ce qui peut provoquer de la discontinuité et de l'incompréhension si elles commencent à lire un sujet puis finissent avec un autre.

Exemples pour le critère de succès 2.2.4

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 2.2.4 - Interruptions

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 2.2.4

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

(Aucune technique n'est actuellement documentée)

Mots clés

urgence

un événement ou une situation soudaine et imprévue qui exige une action immédiate afin de préserver la santé, la sécurité ou la propriété

Nouvelle authentification :
Comprendre le CS 2.2.5

2.2.5 Nouvelle authentification : quand une session authentifiée expire, l'utilisateur peut poursuivre son activité sans perte de données après une nouvelle authentification. (Niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de permettre à tous les utilisateurs de terminer des transactions authentifiées qui ont une durée maximum d'inactivité ou d'autres facteurs qui provoqueraient la déconnexion de l'utilisateur en plein milieu de sa transaction.

Pour des raisons de sécurité, de nombreux sites implémentent une durée maximum d'authentification après une certaine période d'inactivité. Ces durées maximum peuvent poser des problèmes pour des personnes en situation de handicap car cela peut leur demander plus de temps pour accomplir une activité.

D'autres sites vont déconnecter la personne si celle-ci s'identifie sur le site à partir d'un autre ordinateur ou si d'autres activités se produisent, conduisant le site à s'interroger sur le fait que cette personne est toujours la personne légitime qui s'est initialement authentifiée. Lorsque les utilisateurs sont déconnectés en plein milieu d'une transaction - il est important qu'ils aient la possibilité de s'authentifier de nouveau et de poursuivre la transaction sans perdre aucune des données déjà entrées.

Avantages spécifiques du critère de succès 2.2.5 :

  • Ce critère de succès est un avantage pour les personnes qui ont besoin de temps supplémentaire pour accomplir une activité. Les personnes ayant des limitations cognitives peuvent lire lentement et peuvent avoir besoin de temps supplémentaire pour lire et répondre à un questionnaire. Les utilisateurs qui interagissent via un lecteur d'écran peuvent avoir besoin de temps supplémentaire pour naviguer dans un formulaire complexe et le remplir. Une personne ayant une limitation motrice et qui navigue à l'aide d'un périphérique de saisie alternatif peut avoir besoin de temps supplémentaire pour naviguer ou remplir des données dans un formulaire.

  • Dans les cas où un interprète en langue des signes traduit à un utilisateur sourd du contenu audio, le contrôle de la limite de temps est également important.

Exemples pour le critère de succès 2.2.5

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 2.2.5 - Nouvelle authentification

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

  1. Fournir des options pour poursuivre sans perte de données, en utilisant l'une des techniques suivantes :

Note : se référer aux Techniques pour satisfaire au critère de succès 2.2.1 au sujet des techniques permettant de fournir des notifications de limites de temps.

Techniques (recommandées) supplémentaires pour 2.2.5

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

(Aucune technique n'est actuellement documentée)

Crises :
Comprendre la règle 2.3

Règle 2.3 : ne pas concevoir de contenu susceptible de provoquer des crises.

Objectif de la règle 2.3

Les personnes ayant des troubles pouvant provoquer des crises peuvent avoir une crise déclenchée par du contenu visuel flashant. La plupart des gens ne sont pas conscients qu'ils sont atteints de ce trouble jusqu'à ce qu'il apparaisse. En 1997, un dessin animé à la télévision au Japon a provoqué l'envoi de 700 enfants à l'hôpital dont 500 qui avaient eu des crises [EPFND]. Les mises en garde ne fonctionnent pas bien car, souvent, on ne les remarque pas, en particulier, les enfants qui peuvent en fait être incapables de les lire.

L'objectif de cette règle est de faire en sorte que le contenu marqué comme conforme aux WCAG 2.0 évite les types de flash qui pourraient causer des crises lorsqu'ils sont vus même pendant une seconde ou deux.

Techniques recommandées pour la règle 2.3 (sans rattachement à un critère de succès spécifique)

Les techniques spécifiques pour satisfaire à chaque critère de succès de cette règle sont listées dans les sections Comprendre de chaque critère de succès (énumérés ci-dessous). Cependant, si des techniques permettant de traiter cette règle ne se rapportent à aucun critère de succès, elles sont listées ici. Ces techniques ne sont pas requises ou suffisantes pour satisfaire à un critère de succès, mais peuvent rendre certains types de contenus Web plus accessibles à un plus grand nombre de personnes.

  • S'assurer que le contenu ne dépasse pas le seuil prévu pour les motifs spatiaux (lien à venir)

Pas plus de trois flashs ou sous le seuil critique :
Comprendre le CS 2.3.1

2.3.1 Pas plus de trois flashs ou sous le seuil critique : une page Web doit être exempte 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. (Niveau A)

Note : puisque tout contenu ne satisfaisant pas à ce critère de succès peut interférer avec la capacité de l'utilisateur à exploiter la page entière, tout le contenu présent dans la page Web (qu'il soit utilisé pour satisfaire à d'autres critères de succès ou non) doit satisfaire à ce critère de succès. Voir l'exigence de conformité 5 : Non-interférence.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de permettre à l'utilisateur d'accéder au contenu complet d'un site sans causer des crises dûes à la photosensibilité.

Les personnes sujettes à des crises causées par la photosensibilité peuvent avoir une crise causée par du contenu qui flashe à certaines fréquences pour plus de quelques flashs. Les personnes sont même plus sensibles au flash rouge qu'à d'autres couleurs, ainsi un test spécifique est proposé pour un flash de rouge saturé. Ces règles se basent sur des règles en vigueur dans l'industrie de la télévision adaptées aux écrans d'ordinateurs, devant lesquels le contenu est visionné à une distance plus courte (avec un angle de vision plus grand).

Le flash peut être causé par l'affichage, par l'ordinateur restituant le contenu ou par le contenu restitué. L'auteur ne peut pas contrôler les deux premiers. Ils peuvent être réglés par la conception et la vitesse de l'affichage et de l'ordinateur. L'objectif de ce critère est d'assurer que le scintillement qui dépasse le seuil de flash n'est pas causé par le contenu lui-même. Par exemple, le contenu pourrait inclure un clip vidéo ou une image animée d'une série de flashs stroboscopiques ou des gros plans d'explosions à tir rapide.

Ce critère de succès remplace un critère beaucoup plus restrictif des WCAG 1.0 qui ne permettait aucun flash (même d'un seul pixel) dans une large gamme de fréquence (3 à 50 Hz). Ce critère de succès est basé sur les spécifications existantes utilisées au Royaume-Uni et ailleurs pour la diffusion de la télévision et qui ont été adaptées à la visualisation sur un écran d'ordinateur. L'écran 1024 x 768 est utilisé comme la résolution d'écran de référence pour l'évaluation. Le bloc de pixel 341 x 256 représente un espace de restitution de 10 degrés à une distance habituelle de visualisation. (Le champ de 10 degrés est issu des spécifications originales et représente la partie de vision centrale de l'oeil où les gens sont plus sujets à des stimuli à la lumière.)

La zone combinée de flashs qui se produisent simultanément et de façon contiguë signifie la zone totale qui flashe en même temps. Elle est calculée en additionnant la zone contiguë qui flashe simultanément dans un angle de vision de 10 degrés.

Note : les termes « clignotement » et « flash » peuvent parfois se référer au même contenu.

  • Le « clignotement » fait référence au contenu qui entraîne un problème de distraction. Le clignotement peut être permis pour une courte période dans la mesure où il s'arrête (ou peut être arrêté)

  • Le « flash » fait référence au contenu qui peut déclencher une crise (s'il y en a plus de trois par seconde et s'ils sont assez larges et lumineux). Cela ne peut pas être permis, même pour une seconde, sinon il pourrait provoquer une crise. Et le fait d'arrêter le flash n'est pas non plus une option, puisque la crise peut se déclarer avant que la plupart des utilisateurs n'aient le temps d'arrêter le flash.

  • Le clignotement ne se produit généralement pas à une vitesse de trois ou plus par seconde, mais cela est possible. Si le clignotement est plus rapide que 3 par seconde, il serait aussi considéré comme un flash.

Avantages spécifiques du critère de succès 2.3.1 :

  • Les personnes sujettes à des crises en visualisant du contenu flashant pourront voir tout le contenu d'un site sans avoir de crise et sans avoir à perdre toute l'expérience du contenu en étant limitées aux équivalents textuels. Cela comprend les personnes ayant une épilepsie photosensible ainsi que d'autres troubles provoquant des crises photosensibles.

Exemples pour le critère de succès 2.3.1

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 2.3.1 - Pas plus de trois flashs ou sous le seuil critique

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 2.3.1

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Réduire le contraste pour tout contenu flashant (lien à venir)

  • Éviter les rouges entièrement saturés pour tout contenu flashant (lien à venir)

  • Réduire le nombre de flashs même si le seuil critique n'est pas dépassé (lien à venir)

  • Fournir un mécanisme pour supprimer tout contenu flashant avant qu'il débute (lien à venir)

  • Ralentir un contenu en direct pour éviter des flashs rapides (comme avec une ampoule de flash) (lien à venir)

  • Figer une image momentanément si 3 flashs par seconde sont détectés (lien à venir)

  • Réduire le niveau de contraste si 3 flashs par seconde sont détectés (lien à venir)

  • Permettre à l'utilisateur de définir une fréquence de flash maximum (lien à venir)

Échecs fréquents pour le CS 2.3.1

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 2.3.1.

(Aucun échec n'est actuellement documenté)

Mots clés

flash

alternance de luminosité relative qui peut causer des crises chez certaines personnes si leur taille est suffisamment importante dans une gamme de fréquences spécifiques

Note 1 : voir seuil de flash générique et seuil de flash rouge pour plus d'informations sur les types de flashs qui ne sont pas autorisés.

Note 2 : voir aussi clignotement.

Page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

seuil de flash générique et seuil de flash rouge

un flash ou une séquence d'images changeant rapidement est en dessous du seuil de flash (c'est-à-dire que le contenu est conforme) si l'une des conditions suivantes est satisfaite :

  1. il n'y a pas plus de trois flashs génériques et pas plus de trois flashs rouges par seconde ; ou

  2. la surface d'affichage combinée des flashs simultanés ne représente pas plus de 0,006 stéradian dans chaque champ visuel de 10 degrés sur l'écran (soit 25% de chaque champ visuel de 10 degrés sur l'écran) à une distance habituelle de visualisation

où :

  • un flash générique est défini comme une alternance de luminosité relative de 10% ou plus par rapport à la luminosité relative maximum, où la luminosité relative de l'image la plus sombre est en dessous de 0,80 et où « une alternance » est définie comme étant une augmentation suivie d'une diminution ou une diminution suivie d'une augmentation, et

  • un flash rouge est défini comme toute alternance de transition impliquant un rouge saturé.

Exception : Le flash qui suit un modèle précis et équilibré comme du bruit blanc ou un modèle de damier alterné avec des « carrés » dont les côtés font moins de 0,1 degré (du champ visuel à une distance habituelle de visualisation) ne dépasse pas le seuil de flash.

Note 1 : pour les logiciels ou le contenu Web, un rectangle de 341 x 256 pixels n'importe où sur la surface d'affichage de l'écran, quand la résolution est à 1024 x 768 pixels, fournit une bonne estimation de ce que représente 10 degrés du champ visuel sur l'écran pour un écran et une distance habituelle de visualisation (par exemple des écrans de 38 à 43 centimètres (15 à 17 pouces) à une distance de 55 à 65 centimètres (22-26 pouces)). (Un affichage à une résolution supérieure du même contenu produirait des images plus petites et plus sûres, c'est pourquoi des résolutions inférieures sont utilisées pour définir le seuil.)

Note 2 : une transition est le changement, dans un temps donné, de luminosité relative (ou de luminosité relative ou de couleur pour le flash rouge) entre les pics et les creux adjacents dans un ensemble de mesures de luminosité relative (ou de luminosité relative ou de couleur pour le flash rouge)

Note 3 : la définition couramment utilisée dans le domaine pour « deux transitions opposées de rouge saturé » est : pour chacun ou tous les états impliqués dans chacune des transitions, R/(R+ G + B) >= 0,8, et le changement dans la valeur de (R-G-B)x320 est > 20 (les valeurs négatives de (R-G-B)x320 sont considérées comme nulles) pour chacune des transitions. Les valeurs R, G, B se classent entre 0 et 1 tel que spécifié dans la définition de « luminosité relative ». [HARDING-BINNIE]

Note 4 : des outils sont disponibles pour effectuer l'analyse depuis des captures vidéos. Cependant, aucun outil n'est nécessaire pour évaluer cette condition si le flash est inférieur ou égal à 3 flashs par seconde. Le contenu est automatiquement conforme (voir #1 et #2 ci-dessus).

Trois flashs :
Comprendre le CS 2.3.2

2.3.2 Trois flashs : une page Web doit être exempte de tout élément qui flashe plus de trois fois dans n'importe quel intervalle d'une seconde. (Niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de réduire davantage les risques de crises. Les crises ne peuvent pas être complètement éliminées puisque certaines personnes y sont si sensibles. Cependant, si l'on élimine toute série de trois flash par seconde sur n'importe quelle zone de l'écran, les risques pour une personne susceptible d'avoir une crise sont beaucoup plus réduits que lorsque l'on se conforme aux mesures qui sont ordinairement en vigueur aujourd'hui dans les normes au niveau international, comme nous le faisons au niveau A.

Tandis que le critère de succès 2.3.1 permet le flash s'il est assez sombre ou s'il a une surface assez petite, le critère de succès 2.3.2 ne permet pas un flash supérieur à 3 par seconde, sans tenir compte de l'intensité ou de la taille. Par conséquent, même un seul pixel flashant serait une violation du critère. L'objectif est de se protéger contre un flash plus grand qu'un seul pixel, mais puisqu'un nombre inconnu de configurations à un agrandissement ou un contraste élevé peut être appliqué, l'interdiction concerne tout flash.

Note : dans certains cas, ce que nous indiquons comme « clignotement » et ce que nous indiquons comme « flash » peut se recouper légèrement. Nous utilisons des termes différents pour les deux car le « clignotement » entraîne un problème de distraction qui peut être autorisé pendant une courte durée tant qu'il s'arrête (ou peut être arrêté) tandis que le « flash » est un facteur de crise et ne peut pas être autorisé sans provoquer une crise. La crise pourrait se produire avant que la plupart des utilisateurs ne puissent les désactiver. « Le clignotement » fait donc référence à des changements répétitifs lents qui pourraient distraire. « Le flash » fait référence à des changements pouvant provoquer une crise s'ils étaient assez vifs ou s'ils persistaient assez longtemps. Le clignotement ne se produit généralement pas à une vitesse égale ou supérieure à trois par seconde, si bien que le terme de clignotement et celui de flash ne se recoupent pas. Néanmoins, le clignotement peut se produire plus rapidement que trois par seconde, c'est pourquoi il peut y avoir amalgame. Voir Comprendre le critère de succès 2.2.2 mettre en pause, arrêter, masquer pour plus d'information sur le clignotement.

Avantages spécifiques du critère de succès 2.3.2 :

  • Les personnes sujettes à des crises lorsqu'elles visualisent du contenu flashant pourront voir tout le contenu d'un site sans avoir une crise et sans avoir à perdre toute l'expérience du contenu en étant limitées aux équivalents textuels. Cela comprend les personnes sujettes à l'épilepsie photosensible ainsi que d'autres troubles provoquant des crises photosensibles.

Exemples pour le critère de succès 2.3.2

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 2.3.2 - trois flashs

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 2.3.2

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Réduire le contraste pour tout contenu flashant (lien à venir)

  • Éviter les rouges entièrement saturés pour tout contenu flashant (lien à venir)

  • Réduire le nombre de flashs même si le seuil critique n'est pas dépassé (lien à venir)

  • Ralentir un contenu en direct pour éviter des flashs rapides (comme avec une ampoule de flash) (lien à venir)

  • Figer une image momentanément si 3 flashs par seconde sont détectés (lien à venir)

  • Réduire le niveau de contraste si 3 flashs par seconde sont détectés (lien à venir)

Échecs fréquents pour le CS 2.3.2

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 2.3.2.

(Aucun échec n'est actuellement documenté)

Mots clés

flash

alternance de luminosité relative qui peut causer des crises chez certaines personnes si leur taille est suffisamment importante dans une gamme de fréquences spécifiques

Note 1 : voir seuil de flash générique et seuil de flash rouge pour plus d'informations sur les types de flashs qui ne sont pas autorisés.

Note 2 : voir aussi clignotement.

Page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Example 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Example 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

Navigable :
Comprendre la règle 2.4

Règle 2.4 : fournir à l'utilisateur des éléments d'orientation pour naviguer, trouver le contenu et se situer dans le site.

Objectif de la Règle 2.4

L'objectif de cette règle est d'aider les utilisateurs à trouver le contenu dont ils ont besoin et leur permettre de savoir où ils se situent. Ces tâches sont souvent plus difficiles pour les personnes ayant des limitations. Pour effectuer une recherche, naviguer ou s'orienter, il est important que l'utilisateur sache quelle est sa position courante. Les informations sur les destinations possibles doivent être disponibles afin de pouvoir naviguer. Les lecteurs d'écran convertissent le contenu en voix de synthèse qui, du fait que ce soit une restitution audio, doit être présenté de façon linéaire. Certains critères de succès de cette règle expliquent quelles sont les dispositions à prendre pour que les utilisateurs de lecteurs d'écran réussissent à naviguer dans le contenu. D'autres permettent aux utilisateurs de repérer plus facilement les barres de navigation et les en-têtes de page et d'éviter ces contenus répétitifs. Des fonctions ou des comportements inhabituels d'interfaces peuvent perturber les personnes ayant des limitations cognitives.

Comme expliqué dans le glossaire des arguments de la conception web (en anglais), la navigation a deux fonctions principales :

  • Indiquer à l'utilisateur où il se trouve.

  • Permettre à l'utilisateur d'aller autre part.

Cette règle est en lien étroit avec la Règle 1.3, qui garantit que toute structure du contenu peut être perçue, ce qui est aussi un élément clé pour la navigation. Les en-têtes constituent des mécanismes particulièrement importants pour aider les utilisateurs à s'orienter et à naviguer dans le contenu. De nombreux utilisateurs de technologies d'assistance se servent des en-têtes appropriés pour survoler les informations et localiser facilement les différentes sections. Le fait de satisfaire le critère de succès 1.3.1 concernant les en-têtes résout certains aspects de la règle 2.4.

Techniques recommandées pour la Règle 2.4 (sans rattachement à un critère de succès spécifique)

Les techniques spécifiques pour satisfaire à chaque critère de succès de cette règle sont listées dans les sections Comprendre de chaque critère de succès (énumérés ci-dessous). Cependant, si des techniques permettant de traiter cette règle ne se rapportent à aucun critère de succès, elles sont listées ici. Ces techniques ne sont pas requises ou suffisantes pour satisfaire à un critère de succès, mais peuvent rendre certains types de contenus Web plus accessibles à un plus grand nombre de personnes.

  • Limiter le nombre de liens par page (lien à venir)

  • Fournir un mécanisme pour naviguer vers les différentes sections du contenu d'une page Web (lien à venir)

  • Rendre les liens visuellement distincts (lien à venir)

  • Mettre en surbrillance les termes d'une recherche (lien à venir)


Contourner des blocs :
Comprendre le CS 2.4.1

2.4.1 Contourner des blocs : un mécanisme permet de contourner les blocs de contenu qui sont répétés sur plusieurs pages Web. (Niveau A)

L'objectif de ce critère de succès est de permettre aux personnes qui naviguent séquentiellement à travers le contenu d'accéder plus directement au contenu principal de la page. Le contenu des pages Web et des applications apparaît souvent sur d'autres pages ou d'autres écrans. Parmi les exemples non exhaustifs de blocs répétitifs, il y a les liens de navigation, les images d'en-tête, et les cadres publicitaires. Les petites sections répétitives comme les mots uniques, les phrases ou de simples liens ne sont pas considérées comme des blocs dans le cadre de cette disposition.

Cela fait contraste avec la possibilité pour un utilisateur voyant d'ignorer les éléments répétitifs soit en se focalisant sur la partie centrale de l'écran (où apparaît généralement le contenu principal) ou la possibilité qu'a un utilisateur de souris de sélectionner un lien par un simple clic de souris plutôt que de parcourir chacun des liens ou contrôles de formulaire qui précèdent l'élément souhaité.

Il n'est pas dans l'objectif de ce critère de succès de demander aux auteurs de fournir des méthodes redondantes par rapport aux fonctionnalités offertes par l'agent utilisateur. La plupart des navigateurs Web fournissent à l'utilisateur des commandes clavier pour placer le focus en haut de la page, donc si un ensemble de liens de navigation est présent en bas de page, le fait de fournir un lien « Aller à » n'est pas forcément nécessaire.

Note 1 : bien que ce critère de succès traite des blocs de contenu qui sont répétés sur plusieurs pages, nous encourageons fortement à structurer chaque page dans le code source selon le critère de succès 1.3.1.

  • Lorsque ce critère de succès n'est pas satisfait, il peut être difficile pour certaines personnes en situation de handicap d'atteindre rapidement et facilement le contenu principal d'une page web.

  • Les utilisateurs de lecteurs d'écran qui visitent plusieurs pages d'un même site peuvent éviter de réentendre, sur chaque page, les images d'en-tête et des dizaines de liens de navigation, avant que ne soit lu le contenu principal.

  • Les personnes qui n'utilisent que le clavier ou une interface clavier peuvent atteindre le contenu avec un minimum de commandes. Dans le cas contraire, elles peuvent avoir à activer des dizaines de commandes avant d'atteindre un lien dans la zone principale du contenu. Pour certains utilisateurs, cela peut prendre beaucoup de temps et causer des douleurs physiques sévères.

  • Les personnes utilisant un agrandisseur d'écran n'ont pas à chercher à travers les mêmes en-têtes ou autres blocs d'informations pour trouver où commence le contenu lorsqu'elles arrivent sur une nouvelle page.

  • Les personnes ayant des limitations cognitives ainsi que celles qui utilisent des lecteurs d'écran peuvent en bénéficier si les liens sont groupés sous forme de listes.

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir des raccourcis clavier pour les liens et les éléments de contrôles de formulaire qui sont importants (lien à venir)

  • Fournir des liens d'évitement pour améliorer la navigation à l'intérieur d'une page (lien à venir)

  • Fournir des raccourcis clavier (lien à venir)

  • Utiliser des technologies compatibles avec l'accessibilité afin de permettre une navigation structurée avec les agents utilisateurs et les technologies d'assistance (lien à venir)

  • C6 : Positionner le contenu selon le balisage structurel (en anglais) (CSS)

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 2.4.1.

(Aucun échec n'est actuellement documenté)

mécanisme

processus ou technique pour obtenir un résultat

Note 1 : le mécanisme peut être explicitement fourni par le contenu ou dépendre de la plateforme ou de l'agent utilisateur, y compris les technologies d'assistance.

Note 2 : le mécanisme doit satisfaire à tous les critères de succès (d'un niveau donné) pour déclarer un niveau de conformité.

page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

Titre de page :
Comprendre le CS 2.4.2

2.4.2 Titre de page : les pages Web présentent un titre qui décrit leur sujet ou leur but. (Niveau A)

L'objectif de ce critère de succès est d'aider les utilisateurs à trouver du contenu et à se situer dans ce contenu en garantissant que chaque page Web possède un titre descriptif. Les titres permettent d'identifier la position actuelle sans que les utilisateurs n'aient à lire ou à interpréter le contenu de la page. Lorsque les titres apparaissent dans le plan du site ou la liste des résultats d'une recherche, les utilisateurs peuvent plus rapidement identifier les contenus dont ils ont besoin. Les agents utilisateur rendent le titre de la page facilement disponible à l'utilisateur pour identifier le contenu de la page. Par exemple, un agent utilisateur peut afficher le titre sur la barre de titre de la fenêtre ou comme nom de l'onglet contenant la page.

  • Ce critère bénéficie à tous les utilisateurs en leur permettant d'identifier rapidement et facilement si l'information contenue dans la page Web est pertinente par rapport à leurs besoins.

  • Les personnes ayant des limitations visuelles en bénéficient car elles sont capables de différencier les contenus lorsque plusieurs pages sont ouvertes.

  • Les personnes ayant des limitations cognitives, une mémoire à court terme limitée et des difficultés de lecture en bénéficient également car elles ont la possibilité d'identifier le contenu grâce à son titre.

  • Ce critère bénéficie aussi aux personnes ayant de sévères problèmes de mobilité pour qui le mode opératoire pour naviguer entre les pages repose sur l'audio.

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

  1. G88 : Donner un titre descriptif aux pages Web (en anglais) ET Associer un titre aux pages web en utilisant l'une des techniques suivantes :

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 2.4.2.

page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

Parcours du focus :
Comprendre le CS 2.4.3

2.4.3 Parcours du focus : si une page Web peut être parcourue 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é. (Niveau A)

L'objectif de ce critère de succès est de garantir que lorsque les utilisateurs naviguent séquentiellement dans du contenu, ils parcourent les informations de sorte qu'elles soient cohérentes avec la signification du contenu et qu'elles soient manipulables au clavier. Cela atténue la confusion en permettant aux utilisateurs de se constituer une image mentale cohérente du contenu. Il peut y avoir différents agencements pour refléter des relations logiques dans le contenu. Par exemple, dans un tableau, le déplacement d'une rangée à la fois ou d'une colonne à la fois parmi les composants représentent tous deux des relations logiques dans le contenu. N'importe lequel de ces agencements peut satisfaire ce critère de succès.

La manière dont l'ordre de navigation séquentielle est déterminé dans un contenu, est définie par la technologie du contenu. Par exemple, du simple HTML définit une navigation séquentielle via la notion d'ordre de tabulation. Le HTML dynamique peut modifier la séquence de navigation en utilisant des scripts en plus de l'attribut tabindex pour permettre la prise de focus par davantage d'éléments. Si aucun script ou tabindex n'est utilisé, l'ordre de navigation est l'ordre dans lequel les composants apparaissent dans le flux du contenu. (Voir la spécification html 4.01, 17.11, « donner le focus à un élément »).

Un exemple de navigation au clavier qui n'est pas une navigation séquentielle dont il est question dans ce critère de succès consiste à utiliser les touches fléchées pour parcourir une arborescence. L'utilisateur peut se servir des flèches vers le haut et vers le bas pour passer d'un nœud à l'autre de l'arbre. L'appui sur la flèche vers la droite déplie le nœud, ensuite l'appui sur la flèche vers le bas permet de se déplacer aux nouveaux nœuds ouverts. Cette séquence de navigation suit la séquence attendue pour un contrôle d'arborescence - lorsque des éléments supplémentaires sont ouverts ou refermés, ils sont ajoutés ou supprimés de la séquence de navigation.

Le parcours du focus peut ne pas être identique à l'ordre de lecture déterminé par un programme informatique (voir le critère de succès 1.3.2) dès lors que l'utilisateur peut comprendre et manipuler la page web. Puisqu'il peut y avoir plusieurs ordres de lecture logiques possibles du contenu, le parcours du focus peut correspondre à n'importe lequel d'entre eux. Cependant, lorsque l'ordre d'une présentation spécifique est différent de l'ordre de lecture déterminé par un programme informatique, ceux qui utilisent l'une de ces présentations peuvent trouver la page web difficile à comprendre ou à manipuler. Les auteurs doivent prêter attention à tous ces utilisateurs lorsqu'ils conçoivent leurs pages web.

Par exemple, l'utilisateur d'un lecteur d'écran interagit selon l'ordre de lecture déterminé par un programme informatique, tandis qu'un utilisateur voyant se servant du clavier interagit selon la présentation visuelle de la page. Il faut faire attention à ce que le parcours du focus ait un sens pour ces deux ensembles d'utilisateurs et que ni l'un ni l'autre n'ait l'impression qu'il se balade au hasard.

Ces techniques bénéficient aux utilisateurs du clavier qui naviguent séquentiellement dans les documents et s'attendent à ce que le parcours du focus soit cohérent avec l'ordre de lecture séquentiel.

  • Les personnes ayant des limitations physiques et qui s'appuient sur l'accès au clavier pour manipuler une page, bénéficient d'un parcours du focus logique et utilisable.

  • Les personnes ayant des limitations fonctionnelles qui rendent la lecture difficile peuvent être désorientées si l'appui sur la touche tabulation place le focus à un endroit inattendu. Elles bénéficient d'un parcours du focus logique.

  • Les personnes ayant des limitations visuelles peuvent être désorientées si l'appui sur la touche tabulation place le focus à un endroit inattendu ou lorsqu'elles ne parviennent pas à trouver le contenu qui entoure un élément interactif.

  • Pour une personne utilisant un logiciel d'agrandissement avec un fort taux de grossissement, seule une petite portion de la page peut être visible. Cet utilisateur peut interpréter de façon erronée le contexte d'un champ si le parcours du focus n'est pas logique.

  1. La manière dont l'ordre de navigation séquentielle est déterminé dans un contenu, est définie par la technologie du contenu. Par exemple, du simple HTML définit une navigation séquentielle via la notion d'ordre de tabulation. Le HTML dynamique peut modifier la séquence de navigation en utilisant des scripts en plus de l'attribut tabindex pour permettre la prise de focus par davantage d'éléments. Dans ce cas, la navigation doit suivre les relations et les séquences du contenu. Si aucun script ou tabindex n'est utilisé, l'ordre de navigation est l'ordre dans lequel les composants apparaissent dans le flux du contenu (Voir la spécification html 4.01, 17.11, « donner le focus à un élément »).

  2. Utiliser les flèches vers le haut et vers le bas pour circuler dans une arborescence. L'utilisateur peut se servir des flèches vers le haut et vers le bas pour passer d'un nœud à l'autre de l'arbre. L'appui sur la flèche vers la droite déploie le nœud, ensuite l'appui sur la flèche vers le bas permet de se déplacer aux nouveaux nœuds ouverts. Cette séquence de navigation suit la séquence attendue pour un contrôle d'arborescence - lorsque des éléments supplémentaires sont ouverts ou refermés, ils sont ajoutés ou supprimés de la séquence de navigation.

  3. Une page web implémente des boîtes de dialogue non modales via un script. Lorsque le bouton de déclenchement est activé, une boîte de dialogue s'ouvre. Les éléments interactifs du dialogue sont ajoutés au parcours du focus, immédiatement après le bouton. Lorsque le dialogue s'ouvre, le parcours du focus va du bouton aux éléments du dialogue, puis à l'élément interactif suivant le bouton. Lorsque le dialogue est fermé, le parcours du focus va du bouton à l'élément suivant.

  4. Une page web implémente des boîtes de dialogue modales via un script. Lorsque le bouton de déclenchement est activé, la boîte de dialogue s'ouvre et le focus est placé sur le premier élément interactif du dialogue. Tant que la boîte de dialogue reste ouverte, le focus est restreint aux éléments de la boîte de dialogue. Lorsque la boîte de dialogue disparaît, le focus revient sur le bouton ou sur l'élément suivant le bouton.

  5. Une page html est conçue de sorte que la navigation de gauche soit située après le contenu principal dans le code html, et stylée par CSS de façon à apparaître sur la gauche de la page. Cela afin de permettre au focus de se placer d'abord sur le contenu principal sans avoir à utiliser l'attribut tabIndex ou du javascript.

    Note : bien que cet exemple passe ce critère de succès, ce ne sera pas nécessairement vrai pour tous les positionnements par CSS. D'autres exemples de positionnements plus complexes peuvent ou non préserver la signification et l'opérabilité.

  6. L'exemple suivant ne satisfait pas le critère de succès :

    Le site d'une entreprise contient un formulaire destiné à recueillir des données marketing et permet à l'utilisateur de s'inscrire à plusieurs lettres d'informations publiées par l'entreprise. La section du formulaire destinée à recueillir les données marketing comporte des champs tels que nom, nom de rue, ville, état ou province, et code postal. Une autre section du formulaire comporte plusieurs cases à cocher afin que l'utilisateur puisse indiquer quelle lettre d'information il souhaite recevoir. Cependant, l'ordre de tabulation du formulaire passe d'un champ à l'autre des différentes sections, de sorte que le focus passe du champ nom à une case à cocher, puis au champ nom de rue, puis à une autre case à cocher.

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir un mécanisme de surlignement bien visible pour les liens et les éléments de contrôle lorsqu'ils reçoivent le focus au clavier (lien à venir)

  • Créer des ordres de présentation alternatifs (lien à venir)

page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

parcouru de façon séquentielle

parcouru dans l'ordre défini par le déplacement du focus (d'un élément à l'autre) en utilisant une interface clavier

Fonction du lien (selon le contexte) :
Comprendre le CS 2.4.4

2.4.4 Fonction du lien (selon le contexte) : la fonction de chaque lien est déterminée par le texte du lien seul ou par le texte du lien associé à un contexte du lien déterminé par un programme informatique, sauf si la fonction du lien est ambiguë pour tout utilisateur. (Niveau A)

L'objectif de ce critère de succès est d'aider les utilisateurs à comprendre la fonction de chaque lien et à décider s'ils veulent le suivre. Dès que cela est possible, fournir un texte de lien qui identifie la fonction du lien sans que l'on ait besoin de contexte supplémentaire. La technologie d'assistance est capable de fournir aux utilisateurs une liste des liens présents sur la page web. Les textes de lien, lorsqu'ils sont aussi explicites que possible, aident les utilisateurs qui veulent faire un choix à partir de cette liste de liens. Des textes de lien explicites aident également les utilisateurs qui souhaitent passer de lien en lien avec la touche tab. Des textes de lien explicites aident les utilisateurs à choisir les liens à suivre sans avoir recours à une stratégie complexe pour comprendre la page.

Dans certains cas, les auteurs peuvent vouloir donner une partie de la description du lien par un texte qui lui soit logiquement rattaché, qui fournit le contexte du lien. Dans ce cas, l'utilisateur doit être en mesure de comprendre la fonction du lien sans avoir à déplacer le focus du lien. En d'autres termes, il doit pouvoir arriver sur le lien et en savoir plus sur le lien sans avoir à en bouger. Cela peut se faire en mettant la description du lien dans la même phrase, paragraphe, élément de liste, l'en-tête qui précède immédiatement le lien, ou la cellule de tableau servant de lien ou la cellule d'en-tête de tableau servant de lien dans un tableau de données, car elle est directement associée au lien lui-même.

Cette mise en contexte est plus utile lorsqu'elle précède le lien. (Par exemple, si vous devez utiliser des textes de lien ambigus, il vaut mieux les placer à la fin de la phrase qui en décrit la destination, plutôt que de mettre l'intitulé ambigu au début de la phrase). Si la description suit le lien, il peut y avoir confusion ou difficulté pour les utilisateurs de lecteurs d'écran qui lisent la page dans l'ordre (de haut en bas).

Les liens ayant la même destination doivent avoir les mêmes descriptions (selon le critère de succès 3.2.4), mais les liens ayant des fonctions et des destinations différentes doivent avoir des descriptions différentes.

Le critère de succès comporte une exception concernant les liens pour lesquels la fonction du lien ne peut être déterminée d'après les informations présentes sur la page. Dans ce cas, la personne ayant une limitation fonctionnelle n'est pas désavantagée ; il n'existe pas de contexte supplémentaire permettant de comprendre la fonction du lien. Cependant, quel que soit le nombre de contextes disponibles sur la page web pouvant être utilisés pour l'interpréter, la fonction du lien doit être rendue disponible dans le texte du lien ou associée au lien par un programme informatique pour satisfaire le critère de succès.

Note : il peut y avoir des situations où la fonction du lien est supposée inconnue ou masquée. Par exemple, un jeu peut avoir des liens identifiés par porte 1, porte 2, porte 3. Ces textes de liens seraient suffisants car la fonction du lien est de créer du suspens pour tous les utilisateurs.

Voir également Comprendre le critère de succès 2.4.9 Fonction du lien (lien uniquement).

  • Ce critère de succès aide les personnes ayant des difficultés de mouvement en leur permettant de passer les pages dont le contenu ne les intéresse pas, en évitant les commandes nécessaires pour visiter le contenu référencé puis revenir au contenu actuel.

  • Les personnes ayant des limitations cognitives ne seront pas perturbées par une navigation superflue vers et depuis du contenu qui ne les intéresse pas.

  • Les personnes ayant des limitations visuelles seront capables de déterminer la fonction du lien en explorant son contexte.

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

  1. G91 : Fournir un intitulé de lien qui décrit la fonction du lien (en anglais)

  2. H30 : Fournir un intitulé de lien qui décrit la fonction du lien pour un élément anchor (en anglais) (HTML)

  3. H24 : Fournir un équivalent textuel pour l'élément area d'une image à zones cliquables (en anglais) (HTML)

  4. FLASH27 : Fournir des étiquettes de boutons qui en décrivent la fonction (en anglais) (Flash)

  5. Permettre à l'utilisateur de choisir entre un texte de lien court ou long en utilisant l'une des techniques suivantes :

  6. G53 : Identifier la fonction d'un lien en combinant l'intitulé du lien avec le texte de la phrase qui contient ce lien (en anglais)

  7. Fournir des descriptions supplémentaires sur la fonction du lien en utilisant l'une des techniques suivantes :

  8. Identifier la fonction d'un lien en utilisant le texte du lien combiné à un contexte de lien déterminé par un programme informatique, en utilisant l'une des techniques suivantes :

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques recommandées suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

ambigu pour tout utilisateur

l'intention ne peut être déterminée à partir du lien et de toute l'information de la page Web présentée à l'utilisateur en même temps que ce lien. (c'est-à-dire qu'un lecteur sans limitations fonctionnelles ne connaîtrait pas la fonction d'un lien avant de l'activer)

Exemple : le mot goyave dans la phrase suivante utilisé comme lien : « L'une des exportations importantes est la goyave ». Ce lien pourrait conduire à une définition de la goyave, à un graphe présentant une liste des quantités de goyave exportées ou à une photo de gens récoltant la goyave. Jusqu'à ce que le lien soit activé, tout utilisateur est dans l'incertitude et une personne handicapée n'est donc pas désavantagée.

contexte du lien déterminé par un programme informatique

information supplémentaire qui peut être déterminée par un programme informatique à partir des relations avec un lien, combinée avec le texte du lien et présentée aux utilisateurs sous différentes formes

Exemple : en HTML, l'information qui est déterminée par un programme informatique à partir d'un lien en français, y compris le texte qui est dans le même paragraphe, la même liste ou la même cellule de tableau que le lien, ou une cellule d'en-tête de tableau associée avec la cellule contenant le lien.

Note : puisque les lecteurs d'écran interprètent la ponctuation, ils peuvent aussi fournir le contexte de la phrase en cours, lorsque le focus est sur le lien contenu dans cette phrase.

fonction du lien

nature d'un résultat obtenu par l'activation d'un lien

Accès multiples :
Comprendre le CS 2.4.5

2.4.5 Accès multiples : une page Web peut être située par plus d'un moyen dans un ensemble de pages Web sauf si cette page est le résultat ou une étape d'un processus. (Niveau AA)

L'objectif de ce critère de succès est de faire en sorte que les utilisateurs puissent localiser du contenu par le moyen qui leur convient le mieux. Des utilisateurs peuvent trouver une technique plus facile ou plus compréhensible à utiliser qu'une autre.

Même les petits sites doivent fournir aux utilisateurs un moyen de s'orienter. Pour un site de trois ou quatre pages dont toutes les pages sont liées à la page d'accueil, il peut être suffisant de fournir un lien depuis et vers la page d'accueil si les liens de la page d'accueil peuvent aussi servir de plan du site.

  • Fournir la possibilité de naviguer sur un site de plus d'une manière peut aider les personnes à trouver plus rapidement l'information. Les utilisateurs ayant une limitation visuelle peuvent trouver plus commode de naviguer vers une partie adéquate d'un site en utilisant la recherche plutôt que de faire défiler une grande barre de navigation avec un logiciel d'agrandissement ou un lecteur d'écran. Les personnes ayant des limitations cognitives peuvent préférer une table des matières ou un plan du site qui offre un aperçu du site plutôt que de lire et de passer à travers plusieurs pages. Certains utilisateurs peuvent préférer parcourir le site de manière séquentielle en se déplaçant d'une page à l'autre pour mieux en comprendre les concepts et la disposition.

  • Des personnes ayant des limitations cognitives peuvent trouver plus facile d'utiliser les fonctions de recherche plutôt qu'un schéma de navigation hiérarchique difficile à comprendre.

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 2.4.5.

(Aucun échec n'est actuellement documenté)

ensemble de pages Web

groupe de pages Web partageant un objectif commun et créées par le même auteur, groupe ou organisation

Note : différentes versions linguistiques seraient considérées comme des ensembles de pages Web distincts.

page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

processus

séries d'actions de l'utilisateur dont l'enchaînement est nécessaire à l'accomplissement d'une tâche

Exemple 1 : utilisation réussie par l'utilisateur, sur un site de vente, d'un enchaînement de pages Web permettant de voir différents produits, des prix et des offres, de sélectionner des produits, de soumettre une commande, de fournir les informations d'envoi et de paiement.

Exemple 2 : une page permettant de créer un compte utilisateur nécessitant l'accomplissement d'un test de Turing avant de pouvoir accéder à cette page de formulaire de création de compte.

En-têtes et étiquettes :
Comprendre le CS 2.4.6

2.4.6 En-têtes et étiquettes : les en-têtes et les étiquettes décrivent le sujet ou le but. (Niveau AA)

L'objectif de ce critère de succès est d'aider les utilisateurs à comprendre quelles sont les informations contenues dans les pages Web et la façon dont ces informations sont organisées. Lorsque les en-têtes sont clairs et descriptifs, les utilisateurs trouvent plus facilement l'information qu'ils recherchent et peuvent plus facilement comprendre les relations entre les différentes parties du contenu. Des étiquettes descriptives aident les utilisateurs à identifier des composants spécifiques dans un contenu.

Il n'est pas nécessaire que les étiquettes et en-têtes soient longs. Un mot ou même une seule lettre peut suffire si elle offre un point d'entrée approprié pour trouver du contenu ou naviguer dedans.

  • Les en-têtes descriptifs sont particulièrement utiles pour les personnes qui ont des limitations qui rendent la lecture lente ou pour les personnes ayant une mémoire à court terme limitée. Ces personnes en bénéficient lorsque les titres de sections permettent de deviner ce que contient chaque section.

  • Les personnes qui ont des difficultés à utiliser leurs mains ou pour qui cela est douloureux, bénéficient de techniques qui leur réduisent le nombre de commandes nécessaires pour atteindre le contenu dont elles ont besoin.

  • Ce critère de succès bénéficie aux personnes qui utilisent un lecteur d'écran en garantissant que les étiquettes et les en-têtes sont explicites lorsqu'ils sont lus hors contexte, par exemple, dans une table des matières, ou lorsqu'ils passent d'un en-tête à l'autre dans une page.

    Ce critère de succès peut également aider les personnes malvoyantes qui ne peuvent voir qu'un petit nombre de mots à la fois.

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

  1. G130 : Fournir des en-têtes de section descriptifs (en anglais)

  2. G131 : Fournir des étiquettes descriptives (en anglais)

Note : les en-têtes et les étiquettes doivent pouvoir être déterminés par un programme informatique, selon le Critère de succès 1.3.1 .

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Utiliser des en-têtes de sections uniques dans une page web (lien à venir)

  • Débuter les en-têtes de section par une information distinctive (lien à venir)

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.2.1.

(Aucun échec n'est actuellement documenté)

étiquette

texte ou autre composant avec un équivalent textuel qui est restitué à l'utilisateur pour permettre d'identifier un composant dans un contenu Web

Note 1 : une étiquette est présentée à tous les utilisateurs alors que le nom peut être masqué et seulement restitué par une technologie d'assistance. Dans de nombreux cas (mais pas tous) le nom et l'étiquette sont identiques.

Note 2 : le terme étiquette n'est pas limité à l'élément label en HTML.

Visibilité du focus :
Comprendre le CS 2.4.7

2.4.7 Visibilité du focus : toute interface utilisable au clavier comporte un mode de fonctionnement où le focus est visible. (Niveau AA)

L'objectif de ce critère de succès est de garantir qu'il existe au moins un mode de fonctionnement où l'indicateur du focus clavier est repérable visuellement.

  • Ce critère de succès est une aide pour quiconque utilise le clavier pour manipuler la page, en lui permettant à tout instant de déterminer visuellement sur quel composant les commandes clavier vont prendre effet.

  • Les personnes ayant des difficultés d'attention, une mémoire à court terme ou ayant des difficultés à exécuter un processus en bénéficient car elles ont la possibilité de trouver où se situe le focus.

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Surligner un lien ou un élément de contrôle lorsque la souris le survole (lien à venir)

  • Fournir un mécanisme de surlignement bien visible pour les liens et les éléments de contrôle lorsqu'ils reçoivent le focus au clavier (lien à venir)

Localisation :
Comprendre le CS 2.4.8

2.4.8 Localisation : l'utilisateur dispose d'informations pour se situer dans un ensemble de pages Web. (Niveau AAA)

L'objectif de ce critère de succès est de fournir à l'utilisateur un moyen de se situer dans un ensemble de pages web, un site Web, ou une application Web et de trouver l'information.

  • Ce critère de succès est utile pour les personnes ayant de courtes périodes d'attention qui peuvent se perdre en suivant une longue série d'étapes de navigation à travers les pages Web. Il est également utile lorsqu'un utilisateur suit un lien direct vers une page située en profondeur dans un ensemble de pages Web et doit naviguer à travers le site Web pour comprendre le contenu de cette page ou pour trouver davantage d'informations associées.

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir un lien vers la page d'accueil ou la page principale (lien à venir)

  • Fournir une version facile à lire de l'information à propos de l'organisation d'un ensemble de pages Web (lien à venir)

  • Fournir une version en langue des signes à propos de l'organisation d'un ensemble de pages Web (lien à venir)

  • Fournir un résumé facile à lire au début de chaque section du contenu (lien à venir)

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 2.4.8.

(Aucun échec n'est actuellement documenté)

ensemble de pages Web

groupe de pages Web partageant un objectif commun et créées par le même auteur, groupe ou organisation

Note : différentes versions linguistiques seraient considérées comme des ensembles de pages Web distincts.

Fonction du lien (lien uniquement) :
Comprendre le CS 2.4.9

2.4.9 Fonction du lien (lien uniquement) : un mécanisme permet de déterminer la fonction de chaque lien par le texte du lien uniquement, sauf si la fonction du lien est ambiguë pour tout utilisateur. (Niveau AAA)

L'objectif de ce critère de succès est d'aider les utilisateurs à comprendre la fonction de chaque lien du contenu, afin qu'ils puissent décider s'ils veulent le suivre. Une bonne pratique consiste à ce que les liens ayant la même destination aient la même description, mais que les liens ayant des fonctions et des destinations différentes aient des descriptions différentes (Voir aussi le critère de succès 3.2.4 qui exige de la cohérence dans l'identification de composants ayant la même fonctionnalité). Puisque la fonction du lien peut être identifiée par le texte du lien, les liens peuvent être compris hors de leur contexte, lorsque, par exemple, l'agent utilisateur donne une liste de tous les liens d'une page.

Ce critère de succès comporte une exception concernant les liens pour lesquels la fonction du lien ne peut être déterminée d'après les informations présentes sur la page. Dans ce cas, la personne en situation de handicap n'est pas désavantagée ; il n'existe pas de contexte supplémentaire permettant de comprendre la fonction du lien. Cependant, quel que soit le nombre de contextes disponibles sur la page Web pouvant être utilisés pour l'interpréter, la fonction du lien doit être rendue disponible dans le texte du lien pour satisfaire le critère de succès.

Le terme « mécanisme » est utilisé pour permettre aux auteurs soit de rendre tous leurs liens intégralement compréhensibles hors contexte par défaut, soit de fournir un moyen pour y parvenir par ce mécanisme. Cela a été mis en place car, sur certaines pages, le fait de rendre tous les liens explicites par eux-mêmes rend les pages plus faciles d'utilisation pour certains utilisateurs et plus difficiles pour d'autres. Le fait de laisser la liberté de rendre les liens explicites (par eux-mêmes) ou non, donne la possibilité aux utilisateurs en situation de handicap d'utiliser la page selon le format qui convient le mieux à leurs besoins.

Par exemple : une page contenant 100 titres de livres avec des liens pour télécharger les livres au format HTML, PDF, DOC, TXT, MP3 ou AAC, s'afficherait en principe avec les titres de livres comme liens, suivis des mots « en HTML ». Puis la phrase « également disponible en » suivie d'une série de liens courts dont le texte serait « HTML », « PDF », « DOC », « TXT », « MP3 », et « AAC ». Au niveau 3, certains utilisateurs peuvent choisir de visualiser la page de cette manière - car ils trouveraient la page plus difficile à comprendre ou plus lente à utiliser si le titre intégral du livre était inclus dans chacun des liens. D'autres peuvent choisir de visualiser la page avec le titre intégral inclus dans chacun des liens, de sorte que chaque lien soit compréhensible par lui-même. Le premier et le second groupe peuvent tous deux inclure des utilisateurs ayant des limitations visuelles ou cognitives qui emploient différentes techniques de navigation ou qui ont différents degrés de sévérité concernant leurs limitations.

  • Ce critère de succès aide les personnes ayant des difficultés de mouvement en leur permettant de passer les pages dont le contenu ne les intéresse pas, d'éviter les commandes nécessaires pour visiter le contenu référencé puis revenir au contenu actuel.

  • Les personnes ayant des limitations cognitives ne seront pas perturbées par une navigation superflue vers et depuis du contenu qui ne les intéresse pas.

  • Les personnes ayant une limitation visuelle auront l'avantage de ne pas perdre le fil du contenu lorsqu'elles reviennent à la page d'origine. La liste des liens offerte par le lecteur d'écran s'avère plus pratique pour trouver une information puisque les cibles des liens sont décrites.

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

ambigu pour tout utilisateur

l'intention ne peut être déterminée à partir du lien et de toute l'information de la page Web présentée à l'utilisateur en même temps que ce lien. (c'est-à-dire qu'un lecteur sans limitations fonctionnelles ne connaîtrait pas la fonction d'un lien avant de l'activer)

Exemple : le mot goyave dans la phrase suivante utilisé comme lien : « L'une des exportations importantes est la goyave ». Ce lien pourrait conduire à une définition de la goyave, à un graphe présentant une liste des quantités de goyave exportées ou à une photo de gens récoltant la goyave. Jusqu'à ce que le lien soit activé, tout utilisateur est dans l'incertitude et une personne handicapée n'est donc pas désavantagée.

mécanisme

processus ou technique pour obtenir un résultat

Note 1 : le mécanisme peut être explicitement fourni par le contenu ou dépendre de la plateforme ou de l'agent utilisateur, y compris les technologies d'assistance.

Note 2 : le mécanisme doit satisfaire à tous les critères de succès (d'un niveau donné) pour déclarer un niveau de conformité.

En-têtes de section :
Comprendre le CS 2.4.10

2.4.10 En-têtes de section : les en-têtes de section sont utilisés pour organiser le contenu. (Niveau AAA)

Note 1 : « en-tête » est utilisé dans le sens général et comprend les titres et autres moyens de structurer les différents types de contenus.

Note 2 : ce critère de succès concerne les contenus de sections et non les composants d'interface utilisateur. Les composants d'interface utilisateur sont traités par le critère de succès 4.1.2.

L'objectif de ce critère de succès est de fournir des en-têtes pour les sections d'une page Web, lorsque la page est organisée en sections. Par exemple, les longs documents sont souvent divisés en plusieurs chapitres, les chapitres ont des sous-parties et les sous-parties sont divisées en plusieurs sections, les sections en paragraphes etc. Lorsqu'il existe de telles sections, elles doivent comporter un en-tête permettant de les présenter. Cela indique clairement l'organisation du contenu, facilite la navigation à travers le contenu, et fournit des repères mentaux qui aident à la compréhension du contenu. D'autres éléments de la page peuvent venir en complément des en-têtes pour améliorer la présentation (exemple les traits horizontaux et les boîtes), mais la présentation visuelle ne suffit pas à identifier les sections d'un document.

Cette disposition est incluse au niveau AAA car elle ne peut pas être appliquée à tous les types de contenu et il n'est pas toujours possible d'insérer des en-têtes. Par exemple, lorsqu'on publie sur le Web un document préexistant, les en-têtes qui n'ont pas été inclus par l'auteur dans le document original ne peuvent être insérés. Ou une longue lettre traite souvent de différents sujets, mais le fait de mettre des en-têtes dans une lettre paraîtrait très étrange. Toutefois, lorsqu'un document peut être partagé en sections à l'aide d'en-têtes, cela en facilite à la fois la compréhension et la navigation.

  • Les personnes aveugles sauront qu'elles se déplacent d'une section à l'autre d'une page Web et connaîtront le but de chaque section.

  • Les personnes ayant certaines difficultés d'apprentissage auront la possibilité d'utiliser les en-têtes pour comprendre plus facilement l'organisation générale du contenu de la page.

  • Les personnes qui naviguent à l'aide du clavier pourront déplacer le focus d'en-tête en en-tête, ce qui leur permet de trouver rapidement le contenu qui les intéresse.

  • Dans les pages où une partie du contenu se met à jour, les en-têtes peuvent être utilisés pour accéder rapidement au contenu mis à jour.

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Utiliser la propriété live pour les régions actives (lien à venir) (ARIA)

  • Fournir un mécanisme pour naviguer vers les différentes sections du contenu d'une page Web (lien à venir)

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 2.4.10.

(Aucun échec n'est actuellement documenté)

composant d'interface utilisateur

partie du contenu qui est perçue par les utilisateurs comme un élément de contrôle unique pour une fonction distincte

Note 1 : plusieurs composants d'interface utilisateur peuvent être implémentés au sein d'un seul programme. La notion de composant n'est pas liée ici aux techniques de programmation, mais plutôt à ce que les utilisateurs perçoivent comme des éléments de contrôle distincts.

Note 2 : les composants d'interface utilisateur incluent les éléments de formulaire et les liens aussi bien que des composants générés par scripts.

Exemple : un microprogramme (applet) dispose d'un « élément de contrôle » permettant de se déplacer dans le contenu ligne par ligne, page par page ou au hasard. Puisque chacune de ces fonctions devrait avoir un nom et fonctionner indépendamment, elles constitueraient chacune un « composant d'interface utilisateur ».

section

une portion autonome de contenu écrit qui traite d'un ou plusieurs sujets ou idées liés entre eux

Note : une section peut consister en un ou plusieurs paragraphes et inclure des graphiques, des tableaux, des listes et des sous-sections.

Lisible :
Comprendre la règle 3.1

Règle 3.1 : rendre le contenu textuel lisible et compréhensible.

Objectif de la règle 3.1

L'objectif de cette règle est de permettre à l'utilisateur et aux technologies d'assistance de lire le contenu textuel et de faire en sorte que les informations nécessaires à sa compréhension soient disponibles.

Les personnes en situation de handicap ont de multiples façons différentes d'appréhender du texte. Pour certaines, la perception est visuelle ; pour certaines elle est sonore ; pour certaines elle est tactile ; pour d'autres encore elle est à la fois visuelle et sonore. Certains utilisateurs rencontrent une grande difficulté à reconnaître les mots écrits bien qu'ils comprennent des documents extrêmement complexes et sophistiqués lorsque le texte est lu à haute voix ou lorsque des processus et des idées clés sont illustrés visuellement ou interprétés en langue des signes. Pour certains utilisateurs, il est difficile de déchiffrer la signification d'un mot ou d'une expression à partir du contexte, en particulier lorsque le mot ou l'expression est utilisé de façon inhabituelle ou lorsqu'une signification spécialisée lui a été attribuée ; pour ces utilisateurs, la capacité de lire et de comprendre peut dépendre de la disponibilité de définitions spécifiques ou des formes étendues des acronymes ou des abréviations. Les agents utilisateurs, y compris les applications vocales et graphiques, peuvent être incapables de présenter le texte correctement à moins que la langue et la direction du texte soient identifiées ; tandis que ces problèmes peuvent être mineurs pour la plupart des utilisateurs, ils peuvent constituer d'@?normes barrières pour les utilisateurs en situation de handicap. Dans les cas où la signification ne peut pas être déterminée sans des informations sur la prononciation (par exemple, certains caractères Kanji japonais), les informations sur la prononciation doivent être également disponibles

Techniques recommandées pour la règle 3.1 (sans rattachement à un critère de succès spécifique)

Les techniques spécifiques pour satisfaire à chaque critère de succès de cette règle sont listées dans les sections Comprendre de chaque critère de succès (énumérés ci-dessous). Cependant, si des techniques permettant de traiter cette règle ne se rapportent à aucun critère de succès, elles sont listées ici. Ces techniques ne sont pas requises ou suffisantes pour satisfaire à un critère de succès, mais peuvent rendre certains types de contenus Web plus accessibles à un plus grand nombre de personnes.

  • Définir les attentes à propos d'un contenu de la page provenant d'une source non contrôlée (lien à venir)

  • Fournir une interprétation en langue des signes pour tout le contenu (lien à venir)

  • Utiliser la langue la plus claire et la plus simple appropriée au contenu (lien à venir)

  • Éviter le texte centré (lien à venir)

  • Éviter le texte qui est justifié (aligné à gauche et à droite) d'une façon qui crée de faibles espaces entre les mots ou les caractères (lien à venir)

  • Utiliser un alignement à gauche pour les langues qui s'écrivent de gauche à droite et un alignement à droite pour les langues qui s'écrivent de droite à gauche (lien à venir)

  • Limiter la largeur des colonnes de texte (lien à venir)

  • Éviter les passages de texte en italique (lien à venir)

  • Éviter la surutilisation de styles différents sur une même page dans les sites (lien à venir)

  • Rendre les liens visuellement distincts (lien à venir)

  • Utiliser des images, des illustrations, de la vidéo, de l'audio ou des symboles pour clarifier la compréhension (lien à venir)

  • Fournir des exemples pratiques pour clarifier le contenu (lien à venir)

  • Utiliser un arrière-plan de couleur pastel clair plutôt que blanc avec du texte noir (lien à venir)

  • Éviter d'utiliser des contrôles d'interface uniques qui ne sont pas nécessaires (lien à venir)

  • Utiliser les majuscules et les minuscules conformément aux conventions de la langue du texte (lien à venir)

  • Éviter les mots étrangers non usuels (lien à venir)

  • Fournir des versions en langue des signes de l'information, des idées et des processus qui doivent être compris pour être en mesure d'utiliser le contenu (lien à venir)

  • Faire référence à tout emplacement dans une page Web à l'aide d'un lien vers cet emplacement (lien à venir)

  • Faire en sorte que les références à un en-tête ou à un titre incluent tout le texte du titre (lien à venir)

  • Fournir une version facile à lire de l'information de base à propos d'un ensemble de pages Web, incluant l'information à propos de la façon de contacter le webmestre (lien à venir)

  • Fournir une version en langue des signes de l'information de base à propos d'un ensemble de pages Web, incluant l'information sur la façon de contacter le webmestre (lien à venir)

Langue de la page :
Comprendre le CS 3.1.1

3.1.1 Langue de la page : la langue par défaut de chaque page Web peut être déterminée par un programme informatique. (Niveau A)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de faire en sorte que les développeurs de contenus Web fournissent des informations dans la page Web nécessaires aux agents utilisateurs pour restituer correctement le texte et autre contenu linguistique. Les technologies d'assistance ainsi que les agents utilisateurs conventionnels peuvent restituer le texte plus fidèlement si la langue de la page Web est identifiée. Les lecteurs d'écran peuvent charger les règles de prononciation correctes. Les navigateurs graphiques peuvent afficher correctement les caractères et les scripts. Les lecteurs multimédia peuvent afficher correctement les sous-titres. Par conséquent, les utilisateurs en situation de handicap pourront mieux comprendre le contenu.

La langue par défaut de la page Web est la langue par défaut avec laquelle le texte est traité, comme l'explique le document Bonnes pratiques pour l'internationalisation : spécifier une langue dans du contenu XHTML & HTML (en anglais). Lorsqu'une page Web utilise plusieurs langues, la langue par défaut du traitement du texte est la langue qui est la plus utilisée. (Si plusieurs langues sont utilisées de façon égale, la première langue utilisée devrait être choisie comme langue par défaut.)

Note : pour les sites multilingues visant le niveau A de conformité, le groupe de travail encourage fortement les développeurs à appliquer également le critère de succès 3.1.2 même s'il s'agit d'un critère de succès de niveau AA.

Avantages spécifiques du critère de succès 3.1.1 :

Ce critère de succès aide :

  • les personnes qui utilisent des lecteurs d'écran ou d'autres technologies qui convertissent le texte en voix de synthèse ;

  • les personnes qui éprouvent des difficultés à lire avec fluidité et précision des documents écrits, comme le fait de reconnaître les caractères et les alphabets ou décoder les mots ;

  • les personnes avec certaines limitations cognitives, des troubles du langage et de l'apprentissage, utilisant des logiciels de synthèse vocale

  • les personnes ayant besoin de sous-titres pour les média synchronisés.

Exemples pour le critère de succès 3.1.1

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 3.1.1 - Langue de la page

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 3.1.1

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Échecs fréquents pour le CS 3.1.1

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.1.1.

(Aucun échec n'est actuellement documenté)

Mots clés

déterminé (déterminable) par un programme informatique

déterminé par un programme à partir de données fournies par l'auteur d'une manière qui permet aux agents utilisateurs, y compris les technologies d'assistance, d'extraire et de présenter cette information aux utilisateurs sous différentes formes

Exemple 1 : déterminé dans un langage de balisage à partir d'éléments et d'attributs auxquels on accède grâce aux technologies d'assistance couramment disponibles.

Exemple 2 : déterminé grâce à des structures de données spécifiques d'une technologie pour un langage non-balisé et exposée aux technologies d'assistance via une API d'accessibilité aux technologies d'assistance couramment disponibles.

langue

langue qui est parlée, écrite ou signée (à l'aide des signes visuels ou tactiles) pour communiquer avec les humains

Note : voir aussi langue des signes.

Page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

Langue d'un passage :
Comprendre le CS 3.1.2

3.1.2 Langue d'un passage : la langue de chaque passage ou expression du contenu peut être déterminée par un programme informatique sauf pour un nom propre, pour un terme technique, pour un mot dont la langue est indéterminée ou pour un mot ou une expression faisant partie du langage courant de la langue utilisée dans le contexte immédiat. (Niveau AA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'assurer que les agents utilisateurs puissent restituer correctement le contenu écrit dans plusieurs langues. Cela permet aux agents utilisateurs et aux technologies d'assistance de présenter le contenu selon les règles de présentation et de prononciation de cette langue. Cela s'applique aux navigateurs graphiques, ainsi qu'aux lecteurs d'écran, aux afficheurs braille et autres navigateurs vocaux.

Les technologies d'assistance ainsi que les agents utilisateurs courants peuvent restituer le texte plus fidèlement si la langue de chaque passage de texte est identifiée. Les lecteurs d'écrans peuvent utiliser les règles de prononciation de la langue du texte. Les navigateurs graphiques peuvent afficher les caractères et les scripts de façon appropriée. Cela est particulièrement important lorsqu'on alterne entre une langue qui se lit de gauche à droite et une langue qui se lit de droite à gauche, ou lorsque le texte est restitué dans une langue utilisant un alphabet différent. Les utilisateurs en situation de handicap qui connaissent toutes les langues utilisées sur la page Web seront plus en mesure de comprendre le contenu si chaque passage est restitué de façon appropriée.

Si aucune autre langue n'a été spécifiée pour une expression ou un passage de texte, la langue de cette expression ou de ce passage est la langue par défaut de la page Web (voir le critère de succès 3.1.1). Donc, la langue de tout le contenu dans des documents en une seule langue peut être déterminée par un programme informatique.

Des mots ou des expressions isolés dans une langue peuvent faire partie intégrante d'une autre langue. Par exemple, « parking » est un mot anglais qui a été adopté en français, figure dans les dictionnaires francophones, et est prononcé correctement par les lecteurs d'écran français. Ainsi, le passage d'un texte en français peut contenir le mot « parking » sans spécifier que sa langue est l'anglais et peut quand même satisfaire ce critère de succès. Souvent, quand la langue d'un texte change pour un seul mot, ce mot est devenu partie intégrante de la langue utilisée dans le contexte immédiat. Parce qu'ils sont si usuels dans certaines langues, les mots « isolés » devraient être considérés comme faisant partie de la langue utilisée dans le contexte immédiat à moins qu'il soit évident qu'un changement de langue était voulu. S'il y a un doute sur l'intention d'un changement de langue, vérifier si le mot serait prononcé de la même façon (sauf pour l'accent ou l'intonation) dans la langue du contexte immédiat.

La plupart des professions nécessitent l'utilisation fréquente de termes techniques pouvant provenir d'une langue étrangère. De tels termes ne sont généralement pas traduits dans toutes les langues. La nature universelle des termes techniques facilite également la communication entre les professionnels.

Parmi les exemples courants de termes techniques il y a : Homo sapiens, Alpha Centauri, hertz et habeas corpus.

Il est important d'identifier les changements de langue pour de multiples raisons :

Avantages spécifiques du critère de succès 3.1.2 :

Ce critère de succès aide :

  • les personnes utilisant des lecteurs d'écran ou d'autres technologies qui convertissent le texte en voix de synthèse ;

  • les personnes éprouvant des difficultés à lire avec fluidité et précision des documents écrits, comme le fait de reconnaître les caractères et les alphabets, décoder les mots, et comprendre des mots et des expressions ;

  • les personnes avec certaines limitations cognitives, des troubles du langage et de l'apprentissage, utilisant des logiciels de synthèse vocale ;

  • les personnes ayant besoin de sous-titres pour reconnaître les changements de langue dans la piste sonore du contenu d'un média synchronisé.

Exemples du critère de succès 3.1.2

  1. Une expression allemande dans une phrase en français.

    Dans la phrase, « Il soutint que la DDR (République Démocratique Allemande) était juste un « Treppenwitz der Weltgeschichte », l'expression allemande « Treppenwitz der Weltgeschichte » est marquée comme étant de l'Allemand. En fonction du langage de balisage, le Français peut être soit marqué comme la langue de l'ensemble du document sauf là où autre chose est spécifié, ou marqué au niveau du paragraphe. Lorsqu'un lecteur d'écran rencontre l'expression allemande, il change les règles de prononciation du Français vers l'Allemand afin de prononcer le mot correctement.

  2. Liens en langue alternative

    Une page Web en HTML contient des liens vers des versions de la page dans d'autres langues (par exemple Deutsch, English, Nederlands, Castellano, etc.). Le texte de chaque lien est le nom de la langue, dans cette langue. La langue de chaque lien est indiquée via un attribut lang.

  3. « podcast » utilisé dans une phrase en français.

    Parce que « podcast » fait partie du langage courant de la langue utilisée dans le contexte immédiat, l'extrait suivant « À l'occasion de l'exposition “ Énergie Éternelle. 1500 ans d'art indien ”, le Palais des Beaux-Arts de Bruxelles a lancé son premier podcast. Vous pouvez télécharger ce podcast au format M4A et MP3 » aucune indication de changement de langue n'est nécessaire.

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 3.1.2 - Langue d'un passage

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 3.1.2

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Rendre les passages de texte dans une autre langue visuellement distincts (lien à venir)

  • Donner le nom de toute langue d'un passage ou d'une expression en langue étrangère (lien à venir)

  • Fournir des balises de langue pour les noms propres afin de permettre une prononciation correcte par les lecteurs d'écran (lien à venir)

Échecs fréquents pour le CS 3.1.2

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.1.2.

(Aucun échec n'est actuellement documenté)

Mots clés

déterminé (déterminable) par un programme informatique

déterminé par un programme à partir de données fournies par l'auteur d'une manière qui permet aux agents utilisateurs, y compris les technologies d'assistance, d'extraire et de présenter cette information aux utilisateurs sous différentes formes

Exemple 1 : déterminé dans un langage de balisage à partir d'éléments et d'attributs auxquels on accède grâce aux technologies d'assistance couramment disponibles.

Exemple 2 : déterminé grâce à des structures de données spécifiques d'une technologie pour un langage non-balisé et exposée aux technologies d'assistance via une API d'accessibilité aux technologies d'assistance couramment disponibles.

langue

langue qui est parlée, écrite ou signée (à l'aide des signes visuels ou tactiles) pour communiquer avec les humains

Note voir aussi langue des signes.

Mots rares :
Comprendre le CS 3.1.3

3.1.3 Mots rares : un mécanisme est disponible pour identifier la définition spécifique des mots ou expressions utilisés de manière inhabituelle ou de façon limitée, y compris les expressions idiomatiques et le jargon. (Niveau AAA)

Objectif de ce critère de succès

Certaines limitations fonctionnelles rendent difficile la compréhension de l'usage de mots non littéraux et l'utilisation de mots spécialisés. Certaines limitations fonctionnelles rendent difficile la compréhension du langage figuré ou d'utilisations spécialisées. Il est vital pour ces publics de fournir de tels mécanismes. Afin de satisfaire à ce critère de succès, de l'information spécialisée à l'intention des lecteurs non spécialistes est encouragée, même si l'on déclare seulement le niveau de conformité simple A ou double-A.

Avantages spécifiques pour le critère de succès 3.1.3 :

Ce critère de succès peut aider les personnes ayant des limitations cognitives, des troubles du langage et de l'apprentissage qui :

  • ont des difficultés à décoder les mots

  • ont des difficultés à comprendre les mots et les expressions

  • ont des difficultés à utiliser le contexte aidant la compréhension

Il pourrait aussi aider les personnes avec des limitations visuelles qui :

  • perdent le contexte lorsqu'elles agrandissent avec un logiciel de grossissement

Exemples pour le critère de succès 3.1.3

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Note : l'ajout du nom d'un produit ou d'un vendeur dans la liste ci-dessous ne constitue pas une approbation par le groupe de travail des Règles pour l'accessibilité des contenus Web ou l'initiative pour l'accessibilité du Web (>WAI du Consortium W3c. Cette liste est simplement fournie pour des raisons de commodité et pour donner aux utilisateurs une idée des ressources disponibles

Techniques et échecs pour le critère de succès 3.1.3 - Mots rares

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : si le mot ou l'expression a une signification unique dans la page Web :
  1. G101 : Fournir la définition d'un mot ou d'une expression utilisés de manière inhabituelle ou de façon limitée (en anglais) pour la première occurrence du mot ou de l'expression dans une page Web en utilisant l'une des techniques suivantes :

  2. G101 : Fournir la définition d'un mot ou d'une expression utilisés de manière inhabituelle ou de façon limitée (en anglais) pour chaque occurrence du mot ou de l'expression dans une page Web en utilisant l'une des techniques suivantes :

Situation B : si le mot ou l'expression a différentes significations dans la même page Web :
  1. G101 : Fournir la définition d'un mot ou d'une expression utilisés de manière inhabituelle ou de façon limitée (en anglais) pour chaque occurrence du mot ou de l'expression dans une page Web en utilisant l'une des techniques suivantes :

Techniques (recommandées) supplémentaires pour 3.1.3

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Utiliser un balisage et un formatage visuel pour aider les utilisateurs à reconnaître les mots qui ont une signification spéciale (lien à venir)

  • Fournir une fonction de recherche à reconnaissance vocale de façon à ce que les utilisateurs qui ont de la difficulté à taper ou à épeler puissent prononcer le mot dont ils recherchent la définition (lien à venir)

  • Fournir un dictionnaire en langue des signes pour aider les utilisateurs qui sont sourds à trouver les définitions nécessaires (lien à venir)

  • Fournir un mécanisme permettant de trouver la définition de tous les mots d'un contenu textuel (lien à venir)

  • Fournir un mécanisme pour déterminer la signification de chaque mot ou expression d'un contenu textuel (lien à venir)

  • Éviter les mots étrangers non usuels (lien à venir)

  • Utiliser une série de dictionnaires en cascade pour donner les significations (lien à venir)

Échecs fréquents pour le CS 3.1.3

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.1.3.

(Aucun échec n'est actuellement documenté)

Mots clés

expression idiomatique

phrase dont le sens ne peut être déduit du sens des mots qui la composent et dont les mots spécifiques ne peuvent être changés sans en perdre le sens

Note : les expressions idiomatiques ne peuvent être traduites littéralement sans perdre leur sens (culturel ou linguistique).

Exemple 1 : en anglais, « spilling the beans » signifie « révéler un secret ». Cependant, « knocking over the beans » ou « spilling the vegetables » ne signifie pas la même chose.

Exemple 2 : en japonais, la phrase « さじを投げる » se traduit littéralement par « il jette une cuillère » mais cela signifie qu'il n'y a rien qu'il puisse faire et que finalement il abandonne.

Exemple 3 : en néerlandais, « Hij ging met de kippen op stok » se traduit littéralement par « il est allé rôtir avec les poulets » mais cela signifie qu'il est allé au lit tôt.

jargon

termes utilisés par les personnes d'une façon particulière dans un domaine particulier

Exemple : les termes « touches rémanentes » sont du jargon du domaine des technologies d'assistance.

mécanisme

processus ou technique pour obtenir un résultat

Note 1 : le mécanisme peut être explicitement fourni par le contenu ou dépendre de la plateforme ou de l'agent utilisateur, y compris les technologies d'assistance.

Note 2 : le mécanisme doit satisfaire à tous les critères de succès (d'un niveau donné) pour déclarer un niveau de conformité.

utilisé de manière inhabituelle ou de façon limitée

mots employés de telle manière qu'ils obligent les utilisateurs à savoir exactement quelle définition appliquer afin de comprendre correctement le contenu

Example : le terme « mémoire » possède une signification différente dans une conversation universitaire de celle qu'il peut avoir dans un article consacré au stockage informatique, mais la définition pertinente peut être déduite du contexte. À l'inverse, le mot « texte » est utilisé de manière très spécifique dans les WCAG 2.0, à tel point qu'une définition figure dans le glossaire.

Abréviations :
Comprendre le CS 3.1.4

3.1.4 Abréviations : un mécanisme est disponible pour identifier la forme complète ou la signification d'une abréviation. (Niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de faire en sorte que l'utilisateur puisse accéder à la forme complète des abréviations.

Avantages spécifiques du critère de succès 3.1.4 :

Ce critère de succès peut aider les personnes qui :

  • ont des difficultés à décoder les mots ;

  • dépendent de logiciels de grossissement (le grossissement peut réduire les indices contextuels) ;

  • ont une mémoire limitée 

  • ont des difficultés à utiliser le contexte pour aider à la compréhension.

Les abréviations peuvent troubler certains lecteurs de différentes façons :

  • certaines abréviations ne ressemblent pas à des mots ordinaires et ne peuvent pas être prononcées selon les règles usuelles de la langue. Par exemple, le mot anglais « room » est abrégé « rm, » ce qui ne correspond à aucun mot ou phonème anglais. L'utilisateur doit savoir que « rm » est une abréviation du mot « room » pour le dire correctement.

  • Parfois la même abréviation a différentes significations dans différents contextes. Par exemple, dans la phrase anglaise « Dr. Johnson habite à Boswell Dr., » le premier « Dr. » est l'abréviation de « docteur » et la seconde occurrence est l'abréviation du mot « Drive » (un mot qui veut dire « rue » en anglais). L'utilisateur doit être capable de comprendre le contexte afin de connaître la signification des abréviations.

  • Certains acronymes sont l'épellation de noms communs mais ils sont utilisés dans différentes situations. Par exemple, « JAWS » est l'acronyme d'un lecteur d'écran dont le nom complet est « Job Access with Speech. » C'est aussi un nom anglais commun se référant à la partie de la bouche qui porte les dents. L'acronyme est utilisé différemment du mot courant.

  • Certains acronymes s'entendent comme des mots courants mais ils s'épellent différemment. Par exemple, l'acronyme de Synchronized Multimedia Integration Language, S M I L, se prononce comme le mot anglais « smile. »

Cela aiderait aussi les personnes ayant une limitation visuelle qui :

  • perdent le contexte lorsqu'elles agrandissent le texte avec un logiciel de grossissement

Exemples pour le critère de succès 3.1.4

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 3.1.4 - abréviations

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : si l'abréviation n'a qu'une signification dans la page Web :
  1. G102 : Fournir la forme complète ou la signification d'une abréviation (en anglais) pour la première occurrence de l'abréviation dans une page Web en utilisant l'une des techniques suivantes :

  2. G102 : Fournir la forme complète ou la signification d'une abréviation (en anglais) pour toutes les occurrences de l'abréviation dans une page Web en utilisant l'une des techniques suivantes :

Situation B : si l'abréviation a différentes significations dans la même page Web :
  1. G102 : Fournir la forme complète ou la signification d'une abréviation (en anglais) pour toutes les occurrences des abréviations dans une page Web en utilisant l'une des techniques suivantes :

Techniques (recommandées) supplémentaires pour 3.1.4

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Utiliser des abréviations uniques dans une page Web (lien à venir)

  • Utiliser un formatage visuel pour aider les utilisateurs à reconnaître les abréviations (lien à venir)

  • Donner accès à un dictionnaire parlant pour soutenir les utilisateurs qui pourraient avoir de la difficulté à décoder des définitions écrites (lien à venir)

  • Fournir une fonction de recherche à reconnaissance vocale de façon à ce que les utilisateurs qui ont de la difficulté à taper ou à épeler puissent prononcer le mot dont ils recherchent la définition (lien à venir)

Échecs fréquents pour le CS 3.1.4

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.1.4

(Aucun échec n'est actuellement documenté)

Mots clés

abréviation

forme abrégée d'un mot, d'une expression ou d'un nom lorsque l'abréviation ne fait pas encore partie de la langue courante

Note 1 : cela comprend les sigles et les acronymes formés à partir des initiales des mots où :

  1. les sigles sont une forme abrégée d'un nom ou d'une expression constituée des lettres initiales des mots ou des syllabes contenues dans ce nom ou cette expression

    Note 1 : ne sont pas définies dans toutes les langues.

    Exemple 1 : SNCF est le sigle de la Société nationale des chemins de fer français.

    Exemple 2 : ESP est le sigle, en anglais, de extrasensory perception, la perception extrasensorielle.

  2. les acronymes sont des abréviations formées à partir des premières lettres ou des parties d'autres mots (dans un nom ou une expression) et qui peuvent être prononcés comme un mot.

    Exemple : ONU est un acronyme constitué des premières lettres de Organisation des Nations unies.

Note 2 : quelques sociétés ont adopté ce qui constituait un sigle ou un acronyme comme nom de leur société. Dans un tel cas, le nouveau nom de la société est constitué des lettres (par exemple, Ecma) et le mot n'est plus alors considéré comme une abréviation.

mécanisme

processus ou technique pour obtenir un résultat

Note 1 : le mécanisme peut être explicitement fourni par le contenu ou dépendre de la plateforme ou de l'agent utilisateur, y compris les technologies d'assistance.

Note 2 : le mécanisme doit satisfaire à tous les critères de succès (d'un niveau donné) pour déclarer un niveau de conformité.

Niveau de lecture :
Comprendre le CS 3.1.5

3.1.5 Niveau de lecture : lorsqu'un texte nécessite une capacité de lecture plus avancée que le premier cycle de l'enseignement secondaire après la suppression des noms propres et des titres, un contenu additionnel, ou une version qui ne requiert pas de capacité de lecture supérieure au premier cycle de l'enseignement secondaire est disponible. (Niveau AAA)

Objectif de ce critère de succès

Le contenu devrait être écrit aussi clairement et simplement que possible. L'objectif de ce critère de succès est :

Ce critère de succès aide les personnes ayant des difficultés de lecture tout en permettant aussi aux auteurs de publier du contenu Web difficile ou complexe. La difficulté du texte est décrite selon le niveau d'éducation requis pour lire le texte. Le niveau d'éducation est défini par la norme de Classification internationale type de l'éducation de l'[UNESCO], qui a été créée pour permettre la comparaison au niveau international des systèmes d'éducation.

Le texte difficile ou complexe peut être approprié pour la plupart des membres du public visé (c'est-à-dire la plupart des gens pour qui le contenu a été créé). Mais il y a des personnes avec des limitations fonctionnelles, y compris des difficultés de lecture, même parmi les utilisateurs ayant une éducation élevée qui ont des connaissances spécialisées de la matière. Il est possible d'aider ces utilisateurs en rendant le texte plus lisible. Si le texte ne peut être rendu plus lisible, alors un contenu additionnel est nécessaire. Le contenu additionnel est requis lorsque le texte exige une capacité de lecture supérieure au niveau du premier cycle de l'enseignement secondaire —c'est-à-dire, supérieur à neuf ans d'école. Un tel texte constitue un obstacle sévère pour les personnes ayant des difficultés de lecture et il est considéré comme difficile même pour les personnes sans limitations fonctionnelles qui ont suivi un cycle d'enseignement secondaire élevé.

Les difficultés de lecture comme la dyslexie font qu'il est difficile de reconnaître les mots écrits ou imprimés et de les associer aux sons adéquats. Cela s'appelle « décoder » le texte. Afin que les gens puissent lire couramment, le décodage doit être automatique. Le fait de décoder le texte mot à mot consomme une grande partie de l'énergie mentale que la plupart des gens peuvent utiliser pour comprendre ce qu'ils lisent. Un texte qui utilise des mots courts, communs et des phrases courtes est plus facile à décoder et nécessite généralement une capacité de lecture moins élevée que le texte qui emploie de longues phrases et des mots longs ou peu familiers.

Le niveau d'éducation requis pour lire du contenu textuel (que l'on appelle aussi « lisibilité ») se mesure en analysant les passages de texte sélectionnés dans la page Web. Si la page Web inclut du texte écrit pour différents objectifs ou si des styles différents sont utilisés, les passages sélectionnés contiennent des échantillons des types de contenus de la page Web et des différents styles dans lesquels le contenu est écrit. (Dans beaucoup de cas, la page Web ne contient qu'une sorte de contenu textuel — par exemple une documentation technique, des mentions légales, des documents commerciaux, etc.—et tout le contenu utilise le même style.)

Les formateurs peuvent aussi mesurer le niveau d'éducation nécessaire pour la lecture du contenu textuel. Par exemple, des professeurs qualifiés peuvent évaluer le texte selon les normes d'éducation locales pour déterminer s'il nécessite une capacité de lecture supérieure à ce qui est attendu pour les élèves de dernière année du niveau secondaire.

Parce que les noms de personnes, les noms de villes ou autres noms propres ne peuvent pas être modifiés pour qu'ils soient plus courts et avec moins de syllabes, et parce que le faire ou faire juste référence à tout le monde à l'aide de pronoms peut rendre les phrases plus difficiles à comprendre, le critère de succès stipule que les noms propres peuvent être ignorés ou supprimés du texte avant d'évaluer si ce texte est conforme à l'exigence de capacité de lecture. Les titres font référence au nom des documents, des livres, des films etc. Les titres sont supprimés ou ignorés pour l'analyse car la modification des mots dans le titre peut rendre les titres plus faciles à lire mais empêcherait de comprendre le sujet auquel se rapporte le titre. Le contenu en serait plus difficile à lire et à comprendre. (par exemple un livre, une dissertation universitaire, un article, etc.). C'est pourquoi les titres sont aussi spécifiquement exemptés.

Lorsqu'une page Web contient plusieurs langues, le résultat de lisibilité doit être calculé pour chaque langue constituant au moins 5% du contenu et qui est utilisée dans des phrases complètes ou dans des paragraphes (pas uniquement pour des mots ou expressions isolés). La lisibilité globale de la page doit être jugée selon la langue qui obtient les plus mauvais résultats de lisibilité.

La lisibilité du contenu peut aussi être déterminée en appliquant une formule de lisibilité au passage sélectionné. Beaucoup (mais pas toutes) les formules de lisibilité fondent leurs calculs sur des passages de 100 mots. De telles formules ont été développées pour beaucoup de langues. Le nombre de mots du passage est compté et la longueur des mots est déterminée en comptant soit le nombre de syllabes soit le nombre de caractères. La plupart des formules de lisibilité comptent aussi le nombre et la longueur des phrases. La longueur moyenne des mots et des phrases du contenu est ensuite utilisée pour calculer un score de lisibilité. (Certaines langues, comme le japonais, peuvent contenir des scripts multiples dans le même passage. Les formules de lisibilité pour ces langues peuvent utiliser le nombre et la longueur de tels « tests » pour leurs calculs.) Le résultat peut être présenté sous forme de nombre (par exemple sur une échelle de 0 à 100) comme une graduation des niveaux. Ces résultats peuvent ensuite être interprétés en utilisant les niveaux d'éducation décrits dans la norme de Classification internationale type de l'éducation. Des formules de lisibilité sont au moins disponibles pour certaines langues en utilisant le correcteur orthographique des logiciels courants lorsqu'on indique dans les options de cet outil que l'on souhaite obtenir les statistiques une fois que l'outil a terminé de vérifier les documents.

Niveaux d'éducation
Niveau primaire premier cycle de l'enseignement secondaire deuxième cycle de l'enseignement secondaire Niveau supérieur
Les six premières années d'école 7-9 années d'école 10-12 années d'école Plus de 12 années d'école

Adapté à partir de la norme de Classification internationale type de l'éducation [UNESCO]

Note : selon l'initiative Open Society Mental Health Initiative, le concept Facile à Lire ne peut pas être universel et il ne sera pas possible d'écrire un texte convenant aux capacités de lecture de toutes les personnes ayant des problèmes de lecture, d'écriture et de compréhension. L'utilisation de la langue la plus simple et la plus claire possible est hautement souhaitable mais le groupe de travail des WCAG n'a pas pu trouver de moyen pour tester si cela a été accompli. L'utilisation d'un niveau de lecture est le moyen d'introduire la possibilité de test dans un critère de succès qui encourage une rédaction claire. Un contenu additionnel peut être une technique puissante pour les personnes ayant certaines limitations cognitives.

Avantages spécifiques du critère de succès 3.1.5 :

Ce critère de succès peut aider les personnes qui :

  • ont de la difficulté à comprendre et interpréter une langue écrite (par exemple des articles, des instructions, ou journaux imprimés ou en braille), afin d'obtenir des connaissances générales ou de l'information spécifique

Exemples pour le critère de succès 3.1.5

  1. Un journal scientifique incluant des résumés lisibles d'articles de recherche complexes

    Un journal scientifique inclut des articles écrits dans un langage très technique destinés à des spécialistes du domaine. La page de table des matières du journal contient un résumé dans une langue simple de chaque article. Les résumés sont destinés à un public général ayant un niveau de huit ans d'école. Les métadonnées du journal utilisent la spécification Dublin Core pour identifier le niveau d'éducation du public concerné par ces articles comme « supérieur, » et le niveau d'éducation du public concerné par les résumés comme « premier cycle de l'enseignement secondaire. »

  2. Informations médicales pour les membres du public.

    Une école de médecine gère un site Web expliquant les découvertes médicales et scientifiques récentes. Les articles du site sont écrits pour des gens sans formation médicale. Chaque article utilise la spécification des métadonnées Dublin Core pour identifier le niveau d'éducation du public concerné comme « premier cycle de l'enseignement secondaire » et comprend le résultat de lisibilité Flesch Reading Ease pour l'article. Un lien sur chaque page affiche le niveau d'éducation et autres métadonnées. Aucun contenu additionnel n'est requis parce que les lecteurs ayant le niveau d'études du premier cycle de l'enseignement secondaire peuvent lire les articles.

  3. Une application d'enseignement à distance e-learning

    Un cours en ligne sur l'histoire culturelle espagnole contient un module sur l'architecture mauresque. Le module contient du texte écrit pour des élèves ayant différentes capacités de lecture. Des photographies et des dessins de bâtiments illustrent les concepts et les styles architecturaux. Des représentations graphiques sont utilisées pour illustrer des relations complexes, et une version sonore utilisant une synthèse vocale est disponible. Les métadonnées de chaque version décrivent le niveau scolaire du contenu et incluent un résultat de lisibilité reposant sur des formules développées pour du texte en langue espagnole. L'application d'enseignement utilise ces métadonnées et des métadonnées sur les étudiants afin de fournir des versions de contenu pédagogique qui correspondent aux besoins de chaque élève.

  4. Des informations scientifiques exigeant une capacité de lecture du niveau du premier cycle de l'enseignement secondaire.

    Le texte ci-dessous (au total 134 mots) nécessite une capacité de lecture du niveau 4,2 aux États-Unis selon la formule Flesch-Kincaid. Aux États-Unis, le niveau 4,2 est le niveau primaire.

    L'objectif de la science est de tester — et de regarder de près. Certains scientifiques utilisent des microscopes pour regarder de près. Nous allons utiliser un simple morceau de papier.

    Voici ce que vous devez faire : imprimez cette page et découpez le carré pour fabriquer une « fenêtre » de 2,5 centimètres de côté (1 pouce carré). (Avant de couper il est plus facile de plier la page en deux.)

    Choisissez quelque chose d'intéressant : un tronc d'arbre, une feuille, une fleur, la surface du sol, ou une pelletée de terre.

    Placez votre fenêtre sur l'objet et regardez-le de près. Prenez votre temps — ce n'est pas une course.

    Pour vous aider à voir plus de détails, dessinez ce que vous voyez à l'intérieur de votre carré.

    Maintenant réfléchissons à ce que vous avez trouvé.

    (Source : Howard Hughes Medical Institute http://www.hhmi.org/coolscience/forkids/inchsquare/ (en anglais))

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 3.1.5 - niveau de lecture

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

  1. G86 : Fournir un résumé du texte qui exige une capacité de lecture inférieure au deuxième cycle de l'enseignement secondaire (en anglais)

  2. G103 : Fournir des illustrations visuelles, des images et des symboles pour aider à expliquer les idées, les événements et les processus (en anglais)

  3. G79 : Fournir une version parlée du texte (en anglais)

  4. G153 : Rendre le texte plus facile à lire (en anglais)

  5. G160 : Fournir une version en langue des signes des informations, des idées et des processus qui doivent être compris pour utiliser le contenu (en anglais)

Note : divers sites peuvent traiter ce critère de succès de différentes façons. Une version audio du contenu peut être utile à certains utilisateurs. Pour des personnes sourdes, une version de la page en langue des signes peut être plus facile à comprendre qu'une version écrite puisque la langue des signes peut être leur première langue. Certains sites peuvent décider d'effectuer ces combinaisons ou d'autres. Aucune technique n'aidera tous les utilisateurs qui ont des difficultés. Ainsi différentes techniques sont proposées ici comme techniques suffisantes pour les auteurs qui tentent de rendre leurs sites plus accessibles. Toute technique numérotée ou toute combinaison ci-dessus peut être utilisée par un site particulier et sera considérée comme suffisante par le groupe de travail.

Techniques (recommandées) supplémentaires pour 3.1.5

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir du texte qui exige des capacités de lecture inférieures au premier cycle de l'enseignement secondaire pour les pages de navigation et de destination (lien à venir)

  • Fournir du texte qui exige des capacités de lecture du premier cycle de l'enseignement secondaire pour les pages intérieures (lien à venir)

  • Inclure des résumés de contenu dans les métadonnées (lien à venir)

  • Utiliser la langue la plus claire et la plus simple appropriée au contenu (lien à venir)

  • Utiliser RDF pour associer du contenu additionnel avec le contenu d'origine (lien à venir)

  • Fournir une image claire et représentative sur la page d'accueil du site (lien à venir)

  • Marquer de façon claire, par l'utilisation d'un texte ou d'une icône, les contenus qui ont été optimisés pour une lecture facile (lien à venir)

  • Utiliser des phrases qui ne contiennent pas de mots redondants, c'est-à-dire des mots qui ne changent pas la signification de la phrase (lien à venir)

  • Utiliser des phrases qui ne contiennent pas plus de deux conjonctions (lien à venir)

  • Utiliser des phrases qui ne sont pas plus longues que celles utilisées de façon usuelle pour l'enseignement secondaire (Note : en anglais, il s'agit de 25 mots) (lien à venir)

  • Utiliser des phrases qui ne contiennent pas d'expressions ou de mots complexes qui pourraient être remplacés par des mots plus courants sans changer la signification de la phrase (lien à venir)

  • Fournir des résumés pour différentes sections du texte (lien à venir)

  • Utiliser des métadonnées pour associer des versions équivalentes appropriées à différents niveaux de lecture (lien à venir)

  • Utiliser l'élément d'accessibilité du Dublin Core pour associer du contenu additionnel sous forme textuelle, graphique ou orale (lien à venir)

  • Utiliser l'élément d'accessibilité ISO AfA pour associer du contenu additionnel sous forme textuelle, graphique ou orale (lien à venir)

  • Utiliser l'élément d'accessibilité IMS pour associer du contenu additionnel sous forme textuelle, graphique ou orale (lien à venir)

  • Rendre les métadonnées visibles par les humains (en anglais) (lien à venir)

    • EXEMPLE : fournir, dans les métadonnées, des URI qui conduisent à une transcription textuelle d'un niveau de lecture préprimaire et primaire d'un article sur une nouvelle découverte scientifique rédigé pour un niveau de lecture supérieur.

  • Proposer une complexité progressive pour les contenus du site et de la page (lien à venir)

Échecs fréquents pour le CS 3.1.5

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.1.5.

(Aucun échec n'est actuellement documenté)

Mots clés

contenu additionnel

contenu additionnel illustrant ou clarifiant le contenu primaire

Exemple 1 : la version audio d'une page Web.

Exemple 2 : l'illustration d'un processus complexe.

Exemple 3 : un paragraphe résumant les principales conclusions et recommandations d'un rapport de recherche.

premier cycle de l'enseignement secondaire

les deux ou trois années de scolarité qui commencent après six ans environ d'enseignement primaire et qui se terminent après neuf ans environ de scolarisation depuis le début de l'enseignement primaire

Note : cette définition se fonde sur la norme de Classification internationale type de l'éducation de l'[UNESCO].

Prononciation :
Comprendre le CS 3.1.6

3.1.6 Prononciation : un mécanisme permet d'identifier la prononciation spécifique des mots dont la signification est ambiguë dans le contexte si leur prononciation n'est pas connue. (Niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'aider les personnes aveugles, malvoyantes et les personnes ayant des difficultés de lecture à comprendre le contenu dans les cas où la signification dépend de la prononciation. Souvent des mots ou des caractères ont des significations différentes, chacun ayant sa propre prononciation. La signification de tels mots ou caractères peut être habituellement déterminée selon le contexte de la phrase. Cependant, dans le cas de phrases plus complexes ou ambigües, ou dans certaines langues, la signification du mot ne peut pas être facilement déterminée ou pas du tout déterminée sans connaître la prononciation. Lorsque la phrase est lue à haute voix et que le lecteur d'écran lit le mot en utilisant la mauvaise prononciation, il peut être même plus difficile à comprendre que lorsqu'il est lu visuellement. Lorsque les mots sont ambigus ou indéterminés à moins que la prononciation soit connue, alors il est nécessaire de fournir un moyen de déterminer la prononciation.

Dans la langue anglaise, par exemple, les hétéronymes sont des mots qui s'épellent de la même façon mais qui ont des prononciations et significations différentes, comme le mot anglais desert (en français déserter) (abandonner) et le mot desert (en français désert) (région aride). Si la prononciation adéquate peut être déterminée à partir du contexte de la phrase, alors rien n'est requis. Si elle ne le peut pas, alors un mécanisme pour déterminer la prononciation adéquate sera requis. De plus, dans certaines langues certains caractères peuvent être prononcés de différentes façons. En japonais, par exemple, des caractères comme les caractères Han (Kanji) ont des prononciations multiples. Les lecteurs d'écran pourront prononcer les caractères de façon incorrecte sans l'information sur la prononciation. Lorsqu'il est lu de façon incorrecte, le contenu sera incompréhensible pour les utilisateurs.

Avantages spécifiques du critère de succès 3.1.6 :

Ce critère de succès pourra aider les personnes qui :

  • ont de la difficulté à décoder les mots

  • ont de la difficulté à se servir du contexte pour les aider à comprendre

  • utilisent des technologies qui lisent les mots à haute voix

Exemples pour le critère de succès 3.1.6

Note : pour le japonais l'élément ruby est utilisé pour indiquer la « lecture » plutôt que la « prononciation. »

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 3.1.6 - prononciation

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 3.1.6

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir une prononciation dans un fichier sonore, de façon à ce que les utilisateurs puissent écouter la prononciation du mot (lien à venir)

  • Fournir un mécanisme pour rechercher la prononciation de tout mot étranger dans un contenu textuel (lien à venir)

  • Fournir un mécanisme pour déterminer la prononciation de chaque mot ou expression d'un contenu textuel (lien à venir)

Échecs fréquents pour le CS 3.1.6

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.1.6.

(Aucun échec n'est actuellement documenté)

Mots clés

mécanisme

processus ou technique pour obtenir un résultat

Note 1 : le mécanisme peut être explicitement fourni par le contenu ou dépendre de la plateforme ou de l'agent utilisateur, y compris les technologies d'assistance.

Note 2 : le mécanisme doit satisfaire à tous les critères de succès (d'un niveau donné) pour déclarer un niveau de conformité.

Prévisible :
Comprendre la règle 3.2

Règle 3.2 : faire en sorte que les pages apparaissent et fonctionnent de manière prévisible.

Objectif de la règle 3.2

L'objectif de cette règle est d'aider les utilisateurs en situation de handicap en leur présentant dans les pages Web des contenus dans un ordre prévisible et en faisant en sorte que les comportements des composants interactifs ou fonctionnels soient aussi prévisibles. Il est difficile pour certains utilisateurs d'avoir une vue d'ensemble d'une page Web : les lecteurs d'écrans restituent les contenus dans un flux de synthèse vocale à une seule dimension, ce qui rend difficile la compréhension des relations dans l'espace. Les utilisateurs avec des limitations cognitives peuvent être perturbés si des composants apparaissent à différents endroits dans différentes pages.

Par exemple, les utilisateurs se servant d'agrandisseurs d'écrans voient uniquement une partie de l'écran à chaque instant ; une présentation cohérente leur rend l'identification de la barre de navigation ou des autres composants plus facile. Placer des composants qui se répètent dans le même ordre relatif dans un ensemble de pages Web permet aux utilisateurs ayant des difficultés de lecture de se diriger directement vers une zone de l'écran plutôt que de passer du temps supplémentaire à décoder le texte de chaque lien. Les utilisateurs avec des capacités manuelles réduites peuvent déterminer plus facilement comment effectuer leurs tâches à l'aide d'un minimum de frappes au clavier.

Techniques recommandées pour la règle 3.2 (sans rattachement à un critère de succès spécifique)

Les techniques spécifiques pour satisfaire à chaque critère de succès de cette règle sont listées dans les sections Comprendre de chaque critère de succès (énumérés ci-dessous). Cependant, si des techniques permettant de traiter cette règle ne se rapportent à aucun critère de succès, elles sont listées ici. Ces techniques ne sont pas requises ou suffisantes pour satisfaire à un critère de succès, mais peuvent rendre certains types de contenus Web plus accessibles à un plus grand nombre de personnes.

  • Placer les étiquettes de façon à maximiser la prévisibilité des relations


Critère de succès pour cette règle :

Au Focus :
Comprendre le CS3.2.1

3.2.1 Au Focus : quand un composant reçoit le focus, il ne doit pas initier un changement de contexte. (Niveau A)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que le comportement des fonctionnalités est prévisible pour les utilisateurs au cours de leur navigation dans une page. Tout composant déclenchant un événement lorsqu'il reçoit le focus ne doit pas modifier le contexte. Les exemples de changements de contexte lorsqu'un composant reçoit le focus comprennent mais ne sont pas limités à :

Avantages spécifiques du critère de succès 3.2.1 :

  • Ce critère de succès aide les personnes ayant des limitations visuelles, des limitations cognitives ou motrices en diminuant les risques de changements de contexte inattendus.

Exemples pour le critère de succès 3.2.1

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 3.2.1 - Au Focus

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

  1. G107 : Utiliser activate au lieu de focus comme déclencheur pour un changement de contexte (en anglais)

Note : un changement de contenu n'est pas toujours un changement de contexte. Ce critère de succès est automatiquement atteint si les changements de contenus ne sont pas aussi des changements de contexte.

Techniques (recommandées) supplémentaires pour 3.2.1

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Mots clés

changement de contexte

changements majeurs dans le contenu d'une page Web qui, s'ils sont faits sans que l'utilisateur en soit conscient, peuvent désorienter l'utilisateur qui ne peut voir l'ensemble de la page en même temps.

Les changements de contexte comprennent les changements de :

  1. agent utilisateur ;

  2. espace de restitution ;

  3. focus ;

  4. contenu qui modifie la signification de la page Web.

Note : un changement dans le contenu comme le déploiement d'une arborescence, un menu dynamique ou un déplacement de tabulation ne change pas nécessairement le contexte à moins qu'il ne change aussi l'un des éléments énumérés ci-dessus (par exemple le focus).

Exemple : l'ouverture d'une nouvelle fenêtre, le déplacement du focus sur un composant différent, le déplacement vers une nouvelle page (y compris tout ce qui, pour l'utilisateur, aurait l'air d'un déplacement vers une autre page) ou la réorganisation significative du contenu d'une page sont autant d'exemples d'un changement de contexte.

À la saisie :
Comprendre le CS 3.2.2

3.2.2 À la saisie : le changement de paramètre d'un composant d'interface utilisateur ne doit pas initier de changement de contexte, à moins que l'utilisateur n'ait été avisé de ce comportement avant d'utiliser le composant. (Niveau A)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que la saisie de données ou la sélection d'un contrôle de formulaire ont des effets prévisibles. Changer la valeur de n'importe quel composant d'interface c'est changer l'état d'un contrôle qui persistera après la fin de l'interaction de l'utilisateur. Ainsi, cocher une case à cocher ou saisir un texte dans un champ change leur valeur, mais activer un lien ou un bouton ne la change pas. Les changements de contexte peuvent perturber des utilisateurs qui ne perçoivent pas aisément les changements ou qui sont distraits par ceux-ci. Les changements de contexte sont appropriés uniquement lorsqu'il est évident que ces changements vont avoir lieu après une action de l'utilisateur .

Note : ce critère de succès couvre les changements de contexte dus aux changements de valeur d'un contrôle. Le fait de cliquer sur un lien ou un onglet dans un tab control active le contrôle mais ne change pas la valeur de ce contrôle.

Avantages spécifiques du critère de succès 3.2.2 :

  • Ce critère de succès aide les utilisateurs en situation de handicap en rendant les contenus interactifs plus prévisibles. Les changements de contexte non prévus peuvent être suffisamment déstabilisants pour les utilisateurs ayant une limitation visuelle ou cognitive, qu'ils ne sont plus en mesure d'utiliser le contenu.

  • Les personnes qui ne sont pas capables de détecter les changements de contexte ont plus de chances d'être désorientées au cours de leur navigation dans le site. Par exemple :

    • Les personnes aveugles ou malvoyantes peuvent avoir des difficultés pour percevoir un changement de contexte visuel, comme l'ouverture d'une nouvelle fenêtre (popup). Dans ce cas, prévenir à l'avance les utilisateurs des changements, limite le risque de confusion quand l'utilisateur découvre que le bouton retour ne réagit plus comme attendu.

  • Des personnes malvoyantes, avec des difficultés de lecture ou des limitations intellectuelles, et d'autres personnes ayant des difficultés à identifier les repères visuels peuvent bénéficier de repères supplémentaires afin de détecter les changements de contexte.

Exemples pour le critère de succès 3.2.2

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 3.2.2 - À la saisie

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 3.2.2

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Mots clés

changement de contexte

changements majeurs dans le contenu d'une page Web qui, s'ils sont faits sans que l'utilisateur en soit conscient, peuvent désorienter l'utilisateur qui ne peut voir l'ensemble de la page en même temps

Les changements de contexte comprennent les changements de :

  1. agent utilisateur ;
  2. espace de restitution  ;
  3. focus ;
  4. contenu qui modifie la signification de la page Web.

Note : un changement de contenu n'est pas toujours un changement de contexte. Un changement dans le contenu comme le déploiement d'une arborescence, un menu dynamique ou un déplacement de tabulation ne change pas nécessairement le contexte à moins qu'il ne change aussi l'un des éléments énumérés ci-dessus (par exemple le focus).

Exemple : l'ouverture d'une nouvelle fenêtre, le déplacement du focus sur un composant différent, le déplacement vers une nouvelle page (y compris tout ce qui, pour l'utilisateur, aurait l'air d'un déplacement vers une autre page) ou la réorganisation significative du contenu d'une page sont autant d'exemples d'un changement de contexte.

composant d'interface utilisateur

partie du contenu qui est perçue par les utilisateurs comme un élément de contrôle unique pour une fonction distincte

Note 1 : plusieurs composants d'interface utilisateur peuvent être implémentés au sein d'un seul programme. La notion de composant n'est pas liée ici aux techniques de programmation, mais plutôt à ce que les utilisateurs perçoivent comme des éléments de contrôle distincts.

Note 2 : les composants d'interface utilisateur incluent les éléments de formulaire et les liens aussi bien que des composants générés par scripts.

Exemple : un microprogramme (applet) dispose d'un « élément de contrôle » permettant de se déplacer dans le contenu ligne par ligne, page par page ou au hasard. Puisque chacune de ces fonctions devrait avoir un nom et fonctionner indépendamment, elles constitueraient chacune un « composant d'interface utilisateur ».

Navigation cohérente :
Comprendre le CS 3.2.3

3.2.3 Navigation cohérente : dans un ensemble de pages Web les mécanismes de navigation qui se répètent sur plusieurs pages Web se présentent dans le même ordre relatif chaque fois qu'ils sont répétés, à moins qu'un changement soit initié par l'utilisateur. (Niveau AA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'encourager l'utilisation d'une présentation et d'une mise en page cohérentes pour les utilisateurs qui interagissent avec un contenu répété dans un ensemble de pages et qui ont besoin de localiser une information ou fonctionnalité plus d'une fois. Les personnes malvoyantes, qui utilisent un agrandisseur d'écran pour en afficher une petite portion, utilisent souvent des repères visuels ou les limites de la page pour repérer un contenu répété. Présenter un contenu répété dans le même ordre est aussi bénéfique pour les utilisateurs visuels qui utilisent leur mémoire spatiale ou des indices visuels dans la présentation pour localiser le contenu répété.

Il est important de noter que l'utilisation du terme « même ordre » dans cette section ne signifie pas que les sous-menus de navigation ne peuvent pas être utilisés ou que les blocs de la navigation secondaire ou de la structure de page ne peuvent pas non plus être utilisés. Au contraire, ce critère de succès a pour objectif d'aider les utilisateurs, qui interagissent avec du contenu répété dans les pages Web, à pouvoir prévoir l'emplacement du contenu qu'ils recherchent et à le retrouver plus rapidement lorsqu'ils le trouvent à nouveau.

Les utilisateurs peuvent initier un changement de l'ordre en utilisant un agent utilisateur adapté ou par réglage de préférences, de manière à ce que l'information soit présentée dans un sens qui est le plus pratique pour eux.

Avantages spécifiques du critère de succès 3.2.3 :

  • S'assurer que les composants répétés apparaissent dans le même ordre sur chaque page d'un site, aide les utilisateurs à être plus à l'aise pour être en mesure de prévoir où ils peuvent trouver les éléments sur chaque page. Cela aide les utilisateurs ayant des limitations cognitives, les utilisateurs ayant une limitation visuelle, les utilisateurs avec une limitation intellectuelle, mais aussi les personnes aveugles.

Exemples pour le critère de succès 3.2.3

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 3.2.3 - Navigation cohérente

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 3.2.3

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Utiliser des gabarits pour assurer la cohérence à travers plusieurs pages Web (lien à venir)

  • Créer une présentation, un positionnement, une superposition et un alignement (lien à venir)

Échecs fréquents pour le CS 3.2.3

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.2.3.

Mots clés

ensemble de pages Web

groupe de pages Web partageant un objectif commun et créées par le même auteur, groupe ou organisation

Note : différentes versions linguistiques seraient considérées comme des ensembles de pages Web distincts.

même ordre relatif

même position relativement aux autres éléments

Note : plusieurs éléments sont considérés être dans le même ordre relatif même si d'autres éléments sont insérés ou retirés de l'ordre original. Par exemple, des menus de navigation extensibles peuvent intégrer un niveau de détail additionnel, une section de navigation secondaire peut être insérée dans l'ordre de lecture.

page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX ( Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

Identification cohérente :
Comprendre le CS 3.2.4

3.2.4 Identification cohérente : dans un ensemble de pages Web les composants qui ont la même fonctionnalité sont identifiés de la même façon. (Niveau AA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer d'une identification cohérente des composants fonctionnels qui apparaissent répétitivement dans un ensemble de pages Web. Les personnes se servant de lecteurs d'écran ont pour stratégie lors de leur utilisation d'un site Web de s'appuyer fortement sur leurs connaissances des fonctions apparaissant sur les différentes pages Web. Si des fonctions identiques ont des étiquettes différentes sur les différentes pages Web, alors le site sera beaucoup plus difficile à utiliser. Cela peut être également perturbant et augmenter la charge cognitive pour les personnes ayant des limitations cognitives. Par conséquent, un étiquetage cohérent sera utile.

Cette cohérence est étendue aux équivalents textuels. Si des icônes ou autres éléments non textuels ont la même fonctionnalité, alors leurs équivalents textuels devraient être cohérents.

Avantages spécifiques pour le critère de succès 3.2.4 :

  • Les personnes qui repèrent une fonctionnalité sur une page d'un site peuvent retrouver les fonctions désirées sur d'autres pages si elles sont présentes.

  • Quand un contenu non textuel est utilisé de manière cohérente pour identifier des composants avec la même fonctionnalité, les personnes ayant des difficultés pour lire du texte ou identifier les équivalents textuels peuvent alors interagir avec le Web sans dépendre des équivalents textuels.

  • Les personnes dépendant des équivalents textuels peuvent disposer de plus de situations prévisibles. Elles peuvent chercher un composant s'il possède une étiquette cohérente sur les différentes pages.

Exemples pour le critère de succès 3.2.4

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée

Techniques et échecs pour le critère de succès 3.2.4 - Identification cohérente

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

  1. G197 : Utiliser les étiquettes, les noms et les équivalents textuels de façon cohérente pour des contenus ayant la même fonctionnalité (en anglais)ET en suivant les techniques suffisantes pour le critère de succès 1.1.1 et les techniques suffisantes pour le critère de succès 4.1.2 pour fournir des étiquettes, des noms, et des équivalents textuels.

Note 1 : les équivalents textuels « cohérents » ne sont pas toujours « identiques ». Par exemple, vous pourriez avoir une flèche graphique en bas d'une page Web représentant un lien vers la prochaine page Web. L'équivalent textuel indiquerait par exemple « Aller à la page 4 ». Naturellement, il ne serait pas approprié de répéter ce même équivalent textuel sur la page suivante. Il serait plus approprié d'indiquer « Aller à la page 5 ». Bien que ces équivalents textuels ne seraient pas identiques, ils seraient cohérents et satisferaient ainsi ce critère.

Note 2 : un élément de contenu non textuel pourrait répondre à plusieurs fonctions. Dans de telles situations, différents équivalents textuels sont nécessaires et devraient être utilisés. Des exemples peuvent être classiquement trouvés avec l'utilisation d'icones comme des marques cochées ou en croix ou encore des panneaux de signalisation. Une marque « cochée » peut signifier « approuvé », « complété » ou « inclus » suivant la situation. Utiliser « marque cochée » comme équivalent textuel dans toutes les pages Web et situations n'apportera pas d'information sur la fonction de l'icône à l'utilisateur. Ainsi, différents équivalents textuels peuvent être utilisés quand un même contenu non textuel sert différentes fonctions.

Techniques (supplémentaires) recommandées pour le critère de succès 3.2.4

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • S'assurer que l'équivalent textuel exprime la fonction du composant et ce qu'il adviendra lorsque l'utilisateur l'activera (lien à venir)

  • Utiliser le même contenu non textuel pour une fonction donnée à chaque fois que cela sera possible (lien à venir)

Échecs fréquents pour le CS 3.2.4

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.2.4.

Mots clés

même fonctionnalité

produit le même résultat à l'utilisation

Exemple : un bouton « recherche » sur une page Web et un bouton « trouver » sur une autre peuvent tous les deux proposer un champ pour saisir un terme et lister les sujets présents dans le site et pertinents par rapport au terme soumis. Dans ce cas, ils offrent la même fonctionnalité mais ne sont pas nommés à l'identique.

page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

Changement à la demande  :
Comprendre le CS 3.2.5

3.2.5 Changement à la demande : un changement de contexte est initié uniquement sur demande de l'utilisateur ou un mécanisme est disponible pour désactiver un tel changement. (Niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'encourager la conception de contenus Web laissant aux utilisateurs un contrôle total sur les changements de contexte. Ce critère de succès vise à éliminer les confusions potentielles pouvant être causées par des changements de contexte non voulus, comme l'ouverture de nouvelles fenêtres, la soumission automatique de formulaires après sélection d'un élément dans une liste, etc. De tels changements de contexte non voulus peuvent causer des difficultés aux personnes ayant une limitation motrice, étant malvoyantes ou aveugles, et les personnes ayant des limitations cognitives.

Certains types de changements de contexte ne sont pas perturbants pour certains utilisateurs et sont mêmes bénéfiques pour d'autres utilisateurs. Par exemple, les utilisateurs d'« interrupteur unique » se fient aux changements de contexte animés par le système, et les préférences des utilisateurs malvoyants peuvent varier suivant la quantité de contenu vue à la fois et selon la quantité d'information de structure qu'ils peuvent retenir en mémoire de travail. Certains types de contenus, comme les diaporamas, nécessitent de pouvoir changer le contexte pour procurer l'expérience utilisateur voulue. Les contenus qui initient un changement de contexte automatique suivant les préférences de l'utilisateur, peuvent respecter ce critère de succès.

Note : cliquer sur un lien est un exemple d'action qui est « initié uniquement sur demande de l'utilisateur ».

Avantages spécifiques du critère de succès 3.2.5 :

  • Les personnes qui ne peuvent pas détecter les changements de contexte ou qui pourraient ne pas réaliser qu'un changement de contexte a eu lieu auront moins de chances d'être désorientées au cours de leur navigation dans un site. Par exemple :

    • Les personnes aveugles ou malvoyantes pourraient avoir des difficultés pour savoir quand un changement de contexte visuel a eu lieu, tel que l'ouverture d'une nouvelle fenêtre (popup). Dans cette situation, avertir à l'avance les utilisateurs des changements de contexte limite les risques de confusion lorsque ces utilisateurs découvrent que le bouton Retour ne se comporte plus comme prévu.

  • Certaines personnes malvoyantes, avec des difficultés de lecture et des limitations intellectuelles, et qui ont des difficultés à interpréter les repères visuels, pourraient tirer avantage de repères supplémentaires pour détecter les changements de contexte.

  • Les personnes avec des limitations cognitives ne sont pas perturbées si des redirections automatiques sont exécutées par le serveur Web, et non par le navigateur.

Exemples pour le critère de succès 3.2.5

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 3.2.5 - Changement à la demande

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : si la page Web permet des mises à jour automatiques :
  1. G76 : Fournir un mécanisme pour demander une mise à jour du contenu plutôt que de faire des mises à jour automatiquement (en anglais)

Situation B : si des redirections automatiques sont possibles :
  1. SVR1 : Implémenter les redirections automatiques côté serveur plutôt que côté client (en anglais) (Serveur)

  2. G110 : Utiliser une redirection instantanée côté client (en anglais) en utilisant l'une des techniques suivantes :

Situation C : si la page Web utilise une fenêtre (pop-up) :
  1. inclure les fenêtres pop-up en utilisant l'une des techniques suivantes :

Situation D : si un évènement onchange est utilisé sur un élément select :
  1. SCR19 : Utiliser un événement onchange sur un élément select sans causer de changement de contexte (en anglais) (programmation par script)

Techniques (recommandées) supplémentaires pour 3.2.5

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Mots clés

changement de contexte

changements majeurs dans le contenu d'une page Web qui, s'ils sont faits sans que l'utilisateur en soit conscient, peuvent désorienter l'utilisateur qui ne peut voir l'ensemble de la page en même temps

Les changements de contexte comprennent les changements de :

  1. agent utilisateur ;

  2. espace de restitution ;

  3. focus ;

  4. contenu qui modifie la signification de la page Web.

Note : un changement de contenu n'est pas toujours un changement de contexte. Un changement dans le contenu comme le déploiement d'une arborescence, un menu dynamique ou un déplacement de tabulation ne change pas nécessairement le contexte à moins qu'il ne change aussi l'un des éléments énumérés ci-dessus (par exemple le focus).

Exemple : l'ouverture d'une nouvelle fenêtre, le déplacement du focus sur un composant différent, le déplacement vers une nouvelle page (y compris tout ce qui, pour l'utilisateur, aurait l'air d'un déplacement vers une autre page) ou la réorganisation significative du contenu d'une page sont autant d'exemples d'un changement de contexte.

mécanisme

processus ou technique pour obtenir un résultat

Note 1 : le mécanisme peut être explicitement fourni par le contenu ou dépendre de la plateforme ou de l'agent utilisateur, y compris les technologies d'assistance.

Note 2 : le mécanisme doit satisfaire à tous les critères de succès (d'un niveau donné) pour déclarer un niveau de conformité.

Assistance à la saisie :
Comprendre la règle 3.3

Règle 3.3 : Aider l'utilisateur à éviter et à corriger les erreurs de saisie.

Objectif de la règle 3.3

Tout le monde commet des erreurs. Cependant, les personnes ayant des limitations fonctionnelles ont plus de difficultés à faire des saisies sans erreur. De plus, il peut être plus difficile pour elles de détecter qu'elles ont fait une erreur. Les méthodes habituelles pour prévenir d'une erreur ne sont pas évidentes pour elles à cause d'un champ de vision trop limité, une perception des couleurs limitée ou l'usage de technologies d'assistance. Cette règle cherche à réduire le nombre d'erreurs importantes ou irréversibles qui peuvent être commises, augmenter les possibilités que toutes les erreurs soient indiquées à l'utilisateur, et aider les utilisateurs à comprendre ce qu'ils doivent faire pour corriger une erreur.

Techniques recommandées pour la règle 3.3 (sans rattachement à un critère de succès spécifique)

Les techniques spécifiques pour satisfaire à chaque critère de succès de cette règle sont listées dans les sections Comprendre de chaque critère de succès (énumérés ci-dessous). Cependant, si des techniques permettant de traiter cette règle ne se rapportent à aucun critère de succès, elles sont listées ici. Ces techniques ne sont pas requises ou suffisantes pour satisfaire à un critère de succès, mais peuvent rendre certains types de contenus Web plus accessibles à un plus grand nombre de personnes.

  • Cacher les champs de formulaires optionnels (lien à venir)

Identification des erreurs :
Comprendre le CS 3.3.1

3.3.1 Identification des erreurs : si une erreur de saisie est détectée automatiquement, l'élément en erreur est identifié et l'erreur est décrite à l'utilisateur sous forme de texte. (Niveau A)

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que les utilisateurs sont avertis qu'une erreur s'est produite et qu'ils peuvent déterminer la nature de l'erreur. Le message d'erreur devra être aussi précis que possible. Dans le cas d'un échec d'envoi d'un formulaire, afficher de nouveau le formulaire en indiquant les champs erronés est insuffisant pour certains utilisateurs pour leur indiquer qu'une erreur s'est produite. Les utilisateurs de lecteurs d'écrans par exemple, n'auront pas connaissance de l'erreur tant qu'ils ne seront pas parvenus jusqu'à l'indicateur. Ils peuvent ainsi abandonner complètement le formulaire avant même de rencontrer l'indicateur d'erreur, en pensant tout simplement que la page n'est pas fonctionnelle.

L'identification et la description d'une erreur peuvent être combinées avec des informations programmées que les agents utilisateurs ou les technologies d'assistance peuvent utiliser pour identifier une erreur et fournir des informations concernant cette erreur à l'utilisateur. Par exemple, certaines technologies peuvent indiquer que la saisie de l'utilisateur ne doit pas dépasser une longueur spécifique, ou bien qu'un champ du formulaire est obligatoire. Actuellement, peu de technologies supportent ce genre d'informations programmées, mais le critère de succès ne les requiert pas, ni ne les interdit.

Il est parfaitement envisageable d'indiquer des erreurs d'une autre façon, comme par exemple à l'aide d'une image, d'une couleur spécifique, etc.., en plus de la description textuelle.

Voir aussi Comprendre le critère de succès 3.3.3 Suggestion après une erreur.

Avantages spécifiques du critère de succès 3.3.1 :

  • Fournir des informations concernant des erreurs de saisie dans un texte permet aux utilisateurs aveugles ou daltoniens de comprendre qu'une erreur a été commise.

  • Ce critère de succès peut aider les personnes ayant des limitations cognitives, de langage, ainsi que celles ayant des difficultés d'apprentissage qui ont des difficultés à comprendre la signification des informations présentées sous forme d'icône, ou par d'autres repères visuels.

Exemples pour le critère de succès 3.3.1

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 3.3.1 - Identification des erreurs

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : si un formulaire contient des champs dont les informations utilisateurs sont obligatoires.
  1. G83 : Fournir une description textuelle pour identifier un champ obligatoire qui n'a pas été rempli (en anglais)

  2. SCR18 : Fournir une alerte de validation côté client (en anglais) (programmation par script)

Situation B : si une information fournie par l'utilisateur requiert d'être dans un format de données spécifique ou contenir certaines valeurs.
  1. G84 : Fournir une description textuelle lorsque l'utilisateur fournit une information qui n'est pas dans la liste des valeurs permises (en anglais)

  2. G85 : Fournir une description textuelle quand la saisie de l'utilisateur n'entre pas dans les formats ou les valeurs requises (en anglais)

  3. SCR18 : Fournir une alerte de validation côté client (en anglais) (programmation par script)

  4. SCR32 : Fournir une validation côté client et ajouter un texte décrivant l'erreur via le DOM (en anglais) (programmation par script)

  5. FLASH12 : Fournir une validation côté client et ajouter le texte des erreurs via la description accessible (en anglais) (Flash)

Techniques (recommandées) supplémentaires pour 3.3.1

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Échecs fréquents pour le CS 3.3.1

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.3.1.

(Aucun échec n'est actuellement documenté)

Mots clés

erreur de saisie

information fournie par l'utilisateur qui n'est pas acceptée

Note : cela inclut :

  1. L'information qui est demandée par la page web mais oubliée par l'utilisateur

  2. L'information qui est fournie par l'utilisateur mais qui ne correspond pas au format ou aux valeurs des données attendus.

Étiquettes ou instructions :
Comprendre le CS 3.3.2

3.3.2 Étiquettes ou instructions : des étiquettes sont présentées ou des instructions sont fournies quand un contenu requiert une saisie utilisateur. (Niveau A)

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'aider les utilisateurs à éviter les erreurs quand une saisie est nécessaire. Pour aider à éviter ces erreurs, il est nécessaire de présenter une bonne interface utilisateur qui fournit des instructions et des indications simples qui permettent d'entrer des informations. Certains utilisateurs en situation de handicap auront plus de chances de commettre des erreurs que les utilisateurs n'ayant pas de handicap ou bien le rattrapage d'erreurs leur sera plus difficile, ce qui fait de l'évitement d'erreur une stratégie importante pour les utilisateurs en situation de handicap. Les personnes ayant des limitations fonctionnelles comptent sur des formulaires et des procédures bien documentés pour interagir avec une page. Les utilisateurs aveugles doivent connaître exactement quelle information doit être saisie dans les champs d'un formulaire et quels sont les choix disponibles. Des instructions simples visuellement rattachées aux champs de formulaires peuvent aider les utilisateurs ayant des limitations cognitives ou ceux accédant à une page en utilisant un agrandisseur d'écran.

L'objectif de ce critère de succès n'est pas de surcharger la page d'informations pas forcément nécessaires, mais de donner des instructions et des indications importantes qui seront profitables aux personnes en situation de handicap. Trop d'informations ou d'instructions peuvent être aussi rédhibitoires que si elles étaient insuffisantes. Le but est d'être sûr que suffisamment d'informations sont fournies à l'utilisateur afin qu'il termine son action sans une trop grande confusion ou sans devoir trop naviguer.

Avantages spécifiques du critère de succès 3.3.2 :

  • Les éléments de type label associés à des éléments de saisie permettent de s'assurer que l'information concernant le champ de saisie est lue par les lecteurs d'écran quand le champ de saisie reçoit le focus.

  • Les étiquettes des champs proches des champs associés aident les utilisateurs d'agrandisseurs d'écrans car le champ et l'étiquette sont plus facilement visibles dans la zone grossie de la page.

  • Fournir des exemples de formats de données attendus aide les utilisateurs ayant une limitation cognitive, des difficultés de langage ou d'apprentissage à saisir les informations correctement.

  • Identifier clairement des champs obligatoires évite aux personnes utilisant uniquement le clavier d'envoyer un formulaire incomplet et d'avoir à parcourir de nouveau l'intégralité du formulaire pour retrouver le champ incomplet et fournir l'information manquante.

Exemples pour le critère de succès 3.3.2

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 3.3.2 - Étiquettes ou instructions

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

  1. G131 : Fournir des étiquettes descriptives (en anglais) ET l'un des éléments suivants :

  2. H44 : Utiliser l'élément label pour associer les étiquettes avec les champs de formulaire (en anglais) (HTML)

  3. FLASH32 : Utiliser l'étiquetage automatique pour associer les étiquettes textuelles aux éléments de formulaire. (en anglais) (Flash)

  4. FLASH29 : Définir la propriété label pour les éléments de formulaire (en anglais) (Flash)

  5. FLASH25 : Donner une étiquette à un élément de formulaire en spécifiant sa propriété name (en anglais) (Flash)

  6. H71 : Fournir une description des groupes de champs à l'aide des éléments fieldset et legend (en anglais) (HTML)

  7. FLASH8 : Ajouter un nom de groupe à la propriété name accessible d'un élément de formulaire. (en anglais) (Flash)

  8. H65 : Utiliser l'attribut title pour identifier un champ de formulaire quand l'élément label ne peut pas être utilisé (en anglais) (HTML)

  9. G167 : Utiliser un bouton adjacent pour identifier visuellement la fonction d'un champ (en anglais)

Note : les techniques à la fin de la liste ci-dessus doivent être considérées « en dernier ressort » et utilisées uniquement quand les autres techniques ne peuvent pas être implémentées dans la page. Les techniques précédentes sont préférables car elles améliorent l'accessibilité pour un plus grand nombre d'utilisateurs.

Techniques supplémentaires (recommandées) pour 3.3.2

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

Échecs fréquents pour le CS 3.3.2

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.3.2.

Mots clés

étiquette

texte ou autre composant avec un équivalent textuel qui est restitué à l'utilisateur pour permettre d'identifier un composant dans un contenu Web

Note 1 : une étiquette est présentée à tous les utilisateurs alors que le nom peut être masqué et seulement restitué par une technologie d'assistance. Dans de nombreux cas (mais pas tous) le nom et l'étiquette sont identiques.

Note 2 : le terme étiquette n'est pas limité à l'élément label en HTML.

Suggestion après une erreur :
Comprendre le CS 3.3.3

3.3.3 Suggestion après une erreur : si une erreur de saisie est automatiquement détectée et que des suggestions de corrections sont connues, ces suggestions sont alors proposées à l'utilisateur à moins que cela puisse compromettre la sécurité ou la finalité du contenu. (Niveau AA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'assurer que les utilisateurs obtiennent les suggestions appropriées pour corriger une erreur de saisie quand cela est possible.

Le critère de succès 3.3.1 fournit des notifications d'erreurs. Cependant, les personnes ayant des limitations cognitives peuvent rencontrer des difficultés pour corriger les erreurs. Les personnes ayant des limitations visuelles pourront ne pas être capables de comprendre ce qu'il faut faire pour corriger une erreur. Dans le cas d'un échec de l'envoi d'un formulaire, les utilisateurs sont susceptibles d'abandonner le formulaire parce que, bien qu'ils soient informés qu'une erreur s'est produite, ils peuvent ne pas être sûrs de la manière de la corriger, même s'ils sont alertés qu'elle s'est produite.

L'auteur du contenu doit pouvoir fournir une description de l'erreur, ou l'agent utilisateur doit pouvoir fournir la description d'une erreur basée sur une technologie spécifique, ou sur une information déterminée par un programme informatique.

Avantages spécifiques du critère de succès 3.3.3 :

  • Fournir une information sur la manière de corriger les erreurs de saisie permet aux utilisateurs ayant des difficultés d'apprentissage à remplir un formulaire avec succès. Les utilisateurs aveugles ou ayant une vision limitée comprennent plus facilement la nature de l'erreur de saisie et comment la corriger. Les personnes ayant des difficultés de mouvement peuvent réduire le nombre de fois où elles doivent changer une valeur à saisir.

Exemples pour le critère de succès 3.3.3

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 3.3.3 - Suggestion après une erreur

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Note : dans certains cas, plus d'une de ces situations s'applique. Par exemple, quand un champ obligatoire requiert que la donnée soit dans un format spécifique.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : si un champ obligatoire ne contient aucune information :
  1. G83 : Fournir une description textuelle pour identifier un champ obligatoire qui n'a pas été rempli (en anglais)

Situation B : si un champ doit être dans un format de données spécifique :
  1. G85 : Fournir une description textuelle quand la saisie de l'utilisateur n'entre pas dans les formats ou les valeurs requises (en anglais)

  2. G177 : Fournir un texte de correction suggérée (en anglais)

  3. SCR18 : Fournir une alerte de validation côté client (en anglais) (programmation par script)

  4. SCR32 : Fournir une validation côté client et ajouter un texte décrivant l'erreur via le DOM (en anglais) (programmation par script)

  5. FLASH12 : Fournir une validation côté client et ajouter le texte des erreurs via la description accessible (en anglais) (Flash)

Situation C : l'information saisie par l'utilisateur est requise parmi une liste limitée de valeurs :
  1. G84 : Fournir une description textuelle lorsque l'utilisateur fournit une information qui n'est pas dans la liste des valeurs permises (en anglais)

  2. G177 : Fournir un texte de correction suggérée (en anglais)

  3. SCR18 : Fournir une alerte de validation côté client (en anglais) (programmation par script)

  4. SCR32 : Fournir une validation côté client et ajouter un texte décrivant l'erreur via le DOM (en anglais) (programmation par script)

  5. FLASH12 : Fournir une validation côté client et ajouter le texte des erreurs via la description accessible (en anglais) (Flash)

Techniques (recommandées) supplémentaires pour 3.3.3

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • G139 : Créer un mécanisme permettant à l'utilisateur d'aller directement aux erreurs. (en anglais)

  • Rendre les messages d'erreurs faciles à comprendre et à distinguer du reste du texte de la page Web (lien à venir)

  • Valider l'envoi du formulaire sur le serveur (lien à venir)

  • Lorsque les informations obligatoires n'ont pas été fournies, ajouter des descriptions ou des exemples d'informations correctes en plus de l'identification du champ obligatoire (lien à venir)

  • Répéter et accentuer les suggestions pour la correction de chaque erreur de saisie dans le contexte de son champ de formulaire (lien à venir)

  • Donner à l'utilisateur un moyen d'aller de chaque élément dans une liste de suggestions vers son champ de formulaire correspondant (lien à venir)

  • Proposer une aide contextuelle supplémentaire pour le champ de formulaire qui doit être modifié (lien à venir)

  • Accepter la saisie de données dans des formats variés (lien à venir)

  • G199 : Fournir un retour de réussite lorsque les données ont été envoyées avec succès (en anglais)

Techniques permettant de proposer des suggestions à l'utilisateur. (recommandées)
  • Fournir une description textuelle contenant des informations sur le nombre d'erreurs de saisie, des suggestions de corrections pour chaque élément, et des instructions sur la façon de procéder (lien à venir)

  • Fournir une description textuelle contenant des suggestions de correction qui doit être le premier élément (ou l'un des premiers éléments) du contenu, ou mettre en évidence ces informations dans le contenu (lien à venir)

  • Afficher les erreurs et suggestions dans le contexte du formulaire original (par exemple, réafficher un formulaire dans lequel les erreurs de saisie et les suggestions de correction sont surlignées et affichées dans le contexte du formulaire original) (lien à venir)

Techniques HTML (recommandées)
  • Fournir « des exemples corrects » de données et de formats de données en tant que texte initial dans les champs de formulaires obligatoires (lien à venir)

  • Proposer des liens vers un texte suggérant une correction « à proximité » des champs de formulaire, ou fournir le texte suggérant la correction lui-même directement sur la page Web « à côté des » champs de formulaire (lien à venir)

Techniques de programmation par script côté client (recommandées)
Techniques WAI-ARIA (recommandées)

Échecs fréquents pour le CS 3.3.3

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.3.3.

(Aucun échec n'est actuellement documenté)

Mots clés

erreur de saisie

information fournie par l'utilisateur qui n'est pas acceptée

Note : cela inclut :

  1. L'information qui est demandée par la page web mais oubliée par l'utilisateur

  2. L'information qui est fournie par l'utilisateur mais qui ne correspond pas au format ou aux valeurs des données attendus.

Prévention des erreurs (juridiques, financières, de données) :
Comprendre le CS 3.3.4

3.3.4 Prévention des erreurs (juridiques, financières, de données) : pour les pages Web 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 : (Niveau AA)

  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.

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'éviter aux utilisateurs en situation de handicap de graves conséquences résultant d'une erreur lorsqu'elles accomplissent une action irréversible. Par exemple, l'achat de billets d'avion non remboursables ou la soumission d'un ordre d'achat d'action à un compte de courtage, sont des transactions financières ayant d'importantes conséquences. Si l'utilisateur a fait une erreur sur la date du voyage, il ou elle peut se retrouver avec un billet non échangeable, ne correspondant pas au bon jour. Si l'utilisateur a fait une erreur sur le nombre d'actions à acheter, il ou elle peut se retrouver avec un nombre supérieur d'actions à celui désir@?. Ces deux types d'erreurs impliquent des transactions qui se déroulent dans l'instant et ne peuvent être modifiées après coup, et peuvent s'avérer très coûteuses. De même, il peut s'agir d'une erreur irrécupérable si les utilisateurs modifient ou effacent de façon non intentionnelle des données stockées dans une base de données à laquelle ils auront besoin d'accéder ultérieurement, tel que leur profil de voyage sur un site de services de voyages. Les données liées à un test font partie de cette recommandation car, pour que les tests soient valides, les utilisateurs ne sont pas autorisés à modifier leurs réponses une fois soumises ; les utilisateurs doivent donc avoir la possibilité de s'assurer que leur envoi est correct.

Les utilisateurs en situation de handicap peuvent avoir plus de probabilité de faire des erreurs. Les utilisateurs ayant des difficultés de lecture peuvent inverser les chiffres et les lettres, et ceux ayant une limitation motrice peuvent appuyer sur des touches par erreur. Fournir la possibilité d'annuler des actions permet aux utilisateurs de corriger des erreurs pouvant entraîner de graves conséquences. Fournir la possibilité de relire et corriger des informations donne à l'utilisateur l'occasion de détecter une erreur, avant d'effectuer une action ayant de graves conséquences.

Des données contrôlables par l'utilisateur sont des données destinées à être consultées par les utilisateurs (Ex. nom et adresse pour le compte utilisateur). Cela ne se réfère pas aux éléments comme les journaux de connexions (logs) Internet ou les données de supervision des moteurs de recherche.

Avantages spécifiques du critère de succès 3.3.4 :

  • Le fait de fournir des garde-fous pour éviter des conséquences graves résultant d'erreurs, aide les utilisateurs ayant tout type de limitations fonctionnelles et étant plus susceptibles de faire des erreurs.

Exemples pour le critère de succès 3.3.4

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 3.3.4 - Prévention des erreurs (juridiques, financières, de données)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées

Techniques (recommandées) supplémentaires pour 3.3.4

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations

Échecs fréquents pour le CS 3.3.4

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.3.4.

(Aucun échec n'est actuellement documenté)

Mots clés

contrôlable par l'utilisateur

données auxquelles les utilisateurs ont accès

Note : cela ne concerne pas les journaux de connexions (logs) Internet et les données de supervision des moteurs de recherche.

Exemple : les champs nom et adresse d'un compte utilisateur.

engagements juridiques

transactions par lesquelles la personne contracte une obligation ou reçoit un bénéfice de nature juridique

Exemple : un contrat de mariage, un échange d'actions (financier et juridique), un legs, un prêt, une adoption, un enrôlement dans l'armée, un contrat de tout type, etc.

erreur de saisie

information fournie par l'utilisateur qui n'est pas acceptée

Note : cela inclut :

  1. L'information qui est demandée par la page Web mais oubliée par l'utilisateur.

  2. L'information qui est fournie par l'utilisateur mais qui ne correspond pas au format ou aux valeurs des données attendus.

mécanisme

processus ou technique pour obtenir un résultat

Note 1 : le mécanisme peut être explicitement fourni par le contenu ou dépendre de la plateforme ou de l'agent utilisateur, y compris les technologies d'assistance.

Note 2 : le mécanisme doit satisfaire à tous les critères de succès (d'un niveau donné) pour déclarer un niveau de conformité.

page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

Aide :
Comprendre le CS 3.3.5

3.3.5 Aide : une aide contextuelle est disponible. (Niveau AAA)

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'éviter aux utilisateurs de faire des erreurs. Certains utilisateurs en situation de handicap ont plus de probabilité de faire des erreurs que les utilisateurs n'étant pas en situation de handicap. En se servant d'une aide contextuelle, les utilisateurs apprennent à effectuer une opération sans perdre de vue ce qu'ils sont en train de faire.

L'aide contextuelle n'est nécessaire que lorsque l'étiquette ne suffit pas pour décrire complètement la fonctionnalité. L'existence de l'aide contextuelle doit apparaître de façon évidente pour les utilisateurs, et ils doivent pouvoir l'obtenir chaque fois qu'ils en ont besoin.

L'auteur du contenu peut fournir le texte de l'aide, ou l'agent utilisateur peut fournir le texte d'aide en s'appuyant sur des informations liées à une technologie, déterminées par un programme informatique.

Avantages spécifiques du critère de succès 3.3.5 :

  • L'assistance à la saisie de texte apporte une aide aux personnes qui ont des difficultés d'écriture et les personnes ayant des difficultés de lecture ou des limitations intellectuelles, qui ont souvent du mal à écrire du texte dans des formulaires ou tout autre endroit nécessitant la saisie de texte.

  • De plus, ce type d'assistance aide les personnes vieillissantes et qui ont les mêmes difficultés pour saisir du texte et/ou manipuler la souris.

Exemples pour le critère de succès 3.3.5

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 3.3.5 - Aide

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : lorsqu'un formulaire nécessite la saisie de texte :
  1. G71 : Fournir un lien d'aide sur chaque page Web (en anglais)

  2. G193 : Fournir de l'aide via un avatar dans la page Web (en anglais)

  3. G194 : Fournir une vérification de l'orthographe et des suggestions pour un champ texte (en anglais)

  4. G184 : Fournir des instructions textuelles au début d'un formulaire ou d'un ensemble de champs pour décrire les données requises (en anglais)

Situation B : lorsqu'un formulaire nécessite la saisie de texte dans un format de données précis :
  1. G89 : Fournir de l'information sur le format des données attendu et des exemples (en anglais)

  2. G184 : Fournir des instructions textuelles au début d'un formulaire ou d'un ensemble de champs pour décrire les données requises (en anglais)

Techniques (recommandées) supplémentaires pour 3.3.5

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations

Échecs fréquents pour le CS 3.3.5

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 3.3.5.

(Aucun échec n'est actuellement documenté)

Mots clés

aide contextuelle

texte d'aide qui fournit des informations relatives à la fonction actuellement utilisée

Note : des étiquettes claires peuvent jouer le rôle d'aide contextuelle.

Prévention des erreurs (toutes) :
Comprendre le CS 3.3.6

3.3.6 Prévention des erreurs (toutes) : pour des pages Web demandant à l'utilisateur de soumettre des informations, au moins l'une des conditions suivantes est vraie : (Niveau AAA)

  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.

Objectif de ce critère de succès

L'objectif de ce critère de succès est d'aider les utilisateurs en situation de handicap à se prémunir des conséquences qui résulteraient d'une erreur lors de l'envoi de données d'un formulaire. Ce critère renforce le critère de succès 3.3.4 dans la mesure où il s'applique à tout formulaire demandant l'envoi d'informations de la part des utilisateurs.

Les utilisateurs en situation de handicap ont plus de probabilité de faire des erreurs et peuvent avoir plus de mal à détecter ou à rectifier des erreurs. Les personnes ayant des difficultés de lecture peuvent inverser les chiffres et les lettres, et celles ayant une limitation motrice peuvent appuyer sur des touches par erreur. Le fait de fournir la possibilité d'annuler des actions permet aux utilisateurs de corriger une erreur. Le fait de fournir la possibilité de relire et de corriger des informations donne aux utilisateurs l'occasion de détecter une erreur avant d'effectuer une action.

Avantages spécifiques du critère de succès 3.3.6 :

  • Le fait de fournir des garde-fous pour éviter des conséquences résultant d'erreurs, aide les utilisateurs ayant tout type de limitations fonctionnelles et étant plus susceptibles de faire des erreurs.

Exemples pour le critère de succès 3.3.6

(Aucun exemple n'est actuellement documenté)

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 3.3.6 - Prévention des erreurs (toutes)

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées

Techniques suffisantes

  1. Suivre les techniques suffisantes pour le critère de succès 3.3.4 pour tout formulaire demandant à l'utilisateur l'envoi d'informations.

Mots clés

erreur de saisie

information fournie par l'utilisateur qui n'est pas acceptée

Note : cela inclut :

  1. L'information qui est demandée par la page Web mais oubliée par l'utilisateur.

  2. L'information qui est fournie par l'utilisateur mais qui ne correspond pas au format ou aux valeurs des données attendus.

mécanisme

processus ou technique pour obtenir un résultat

Note 1 : le mécanisme peut être explicitement fourni par le contenu ou dépendre de la plateforme ou de l'agent utilisateur, y compris les technologies d'assistance.

Note 2 : le mécanisme doit satisfaire à tous les critères de succès (d'un niveau donné) pour déclarer un niveau de conformité.

page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achat face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

Compatible :
Comprendre la règle 4.1

Règle 4.1 : optimiser la compatibilité avec les agents utilisateurs actuels et futurs, y compris les technologies d'assistance.

Objectif de la règle 4.1

L'objectif de cette règle est d'assurer la compatibilité avec les agents utilisateurs actuels et futurs, particulièrement les technologies d'assistance (TA). Cela est réalisé à la fois en 1) s'assurant que les auteurs ne font rien qui puisse bloquer les TA (par exemple du balisage mal formé) ou mettre en échec les TA (par exemple en utilisant du code ou du balisage non conventionnel) et 2) fournissant les informations dans le contenu d'une manière standard de telle sorte que les technologies d'assistance puissent les reconnaître et interagir avec elles. Puisque les technologies changent rapidement, et que les développeurs de TA ont beaucoup de mal à suivre l'évolution rapide des technologies, il est important que le contenu suive les conventions et soit compatible avec les APIs de telle sorte que les TA travaillent plus facilement avec les nouvelles technologies et leurs évolutions.

Techniques recommandées pour la règle 4.1 (sans rattachement à un critère de succès spécifique)

Les techniques spécifiques pour satisfaire à chaque critère de succès de cette règle sont listées dans les sections comprendre de chaque critère de succès (énumérés ci-dessous). Cependant, si des techniques permettant de traiter cette règle ne se rapportent à aucun critère de succès, elles sont listées ici. Ces techniques ne sont pas requises ou suffisantes pour satisfaire à un critère de succès, mais peuvent rendre certains types de contenus Web plus accessibles à un plus grand nombre de personnes.

  • Éviter les éléments dépréciés dans les technologies du W3C (lien à venir)

  • Ne pas afficher de contenu dépendant de technologies qui ne sont pas compatibles avec l'accessibilité si la technologie est désactivée ou n'est pas supportée.

Analyse syntaxique :
Comprendre le CS 4.1.1

4.1.1 Analyse syntaxique : à moins que les spécifications ne le permettent, dans un contenu implémenté via un langage de balisage, 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. (Niveau A)

Note : 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.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que les agents utilisateurs, y compris les technologies d'assistance, peuvent analyser et interpréter correctement le contenu. Si le contenu ne peut être analysé via une structure de données, des agents utilisateurs différents pourraient le présenter différemment ou être totalement incapables de l'analyser. Certains agents utilisateurs utilisent « des techniques de réparation » pour restituer le contenu mal codé.

Puisque les techniques de réparation varient selon les agents utilisateurs, les auteurs ne peuvent savoir comment le contenu sera précisément analysé via une structure de données ou s'il sera restitué correctement par les agents utilisateurs spécialisés, y compris les technologies d'assistance, à moins que le contenu soit créé selon les règles formelles définies par la grammaire de la technologie. Dans les langages de balisage, les erreurs de syntaxe d'éléments et d'attributs et le manquement à fournir des balises de début et de fin correctement imbriquées, peuvent conduire à des erreurs qui empêchent les agents utilisateurs d'analyser le contenu de manière fiable. Par conséquent, le critère de succès exige que le contenu puisse être analysé en utilisant uniquement les règles formelles de la grammaire.

Note : la notion de « bien formé » est proche de ce qui est requis ici. Toutefois, les exigences de l'exactitude de l'analyse varient entre les langages de balisage, et la plupart des langages non basés sur XML ne définissent pas explicitement ces exigences. Par conséquent, il était nécessaire d'être plus explicite dans le critère de succès afin qu'il puisse être applicable de manière générale aux langages de balisage. Parce que le terme « bien formé » est défini uniquement pour XML, et (parce que les balises de fin sont parfois optionnelles), que le HTML valide ne nécessite pas de code bien formé, le terme n'est pas utilisé dans ce critère de succès.

Avantages spécifiques du critère de succès 4.1.1 :

  • Veiller à ce que le code des pages Web dispose de balises de début et de fin et qu'elles soient imbriquées selon les spécifications, permet de s'assurer que les technologies d'assistance peuvent analyser le contenu avec précision et sans erreur.

Exemples pour le critère de succès 4.1.1

(Aucun exemple n'est actuellement documenté)

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

(Aucune ressource n'est actuellement documentée)

Techniques et échecs pour le critère de succès 4.1.1 - analyse syntaxique

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques (recommandées) supplémentaires pour 4.1.1

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

(Aucune technique n'est actuellement documentée)

Nom, rôle et valeur :
Comprendre le CS 4.1.2

4.1.2 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. (Niveau A)

Note : ce critère de succès s'adresse d'abord aux auteurs qui développent ou programment leurs propres composants d'interface utilisateur. Toutefois, les contrôles HTML standards se conforment déjà à ce critère de succès lorsqu'ils sont utilisés conformément à la spécification.

Objectif de ce critère de succès

L'objectif de ce critère de succès est de s'assurer que les technologies d'assistance (TA) peuvent recueillir des informations sur l’activation (ou le paramétrage) et tenir à jour l'état des contrôles des interfaces utilisateur du contenu.

Lorsque les contrôles standards de technologies accessibles sont utilisés, ce processus est simplifié. Si les éléments d'interface utilisateur sont utilisés conformément aux spécifications, les conditions de ce critère seront remplies. (voir les exemples du critère de succès 4.1.2 ci-dessous)

Cependant, si des contrôles personnalisés ou des éléments d’interface sont créés ou programmés (en code ou via un script) afin d’avoir un rôle et/ou une fonction différents de l'usage habituel, des mesures supplémentaires doivent être prises pour s'assurer que les contrôles fournissent des informations essentielles aux technologies d'assistance et permettent d'être contrôlés par les technologies d'assistance.

Un état particulièrement important d'un contrôle d'interface utilisateur est de savoir s'il a le focus ou non. L'état de prise de focus d'un contrôle peut être déterminé par programmation, et des notifications sur les changements de focus sont envoyées aux agents utilisateurs et à la technologie d’assistance. D'autres exemples de l'état du contrôle de l'interface utilisateur sont de savoir si une case à cocher ou un bouton radio ont été sélectionnés, ou si une arborescence ou une liste dépliable est développée ou réduite.

Note : le critère de succès 4.1.2 requiert un nom déterminable par programmation pour tous les composants d'interface utilisateur. Les noms peuvent être visibles ou invisibles. Parfois, le nom doit être visible, dans ce cas, il est identifié comme une étiquette. Se référer à la définition d'un nom et d’une étiquette dans le glossaire pour plus d'informations.

Avantages spécifiques du critère de succès 4.1.2 :

  • Fournir des informations sur le rôle, le nom et la valeur de tous les composants d’interface utilisateur permet de garantir la compatibilité avec les technologies d’assistance, telles que les lecteurs ou agrandisseurs d’écran et les logiciels de reconnaissance vocale utilisés par les personnes en situation de handicap.

Exemples pour le critère de succès 4.1.2

Ressources liées

Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.

Techniques et échecs pour le critère de succès 4.1.2 - nom, rôle, valeur

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.

Techniques suffisantes

Consignes : choisissez parmi les situations suivantes celle qui correspond à votre contenu. Chaque situation comprend des techniques ou des combinaisons de techniques qui sont connues et documentées comme suffisantes par rapport à cette situation.

Situation A : si vous utilisez un composant d'interface utilisateur standard dans un langage de balisage (par exemple, HTML) :
  1. G108 : Utiliser les caractéristiques des balises pour présenter le nom et le rôle, permettre de configurer directement les propriétés modifiables par l'utilisateur et informer des changements (en anglais) en utilisant les techniques spécifiques à une technologie ci-dessous :

Situation B : si vous utilisez un script ou un code pour ré-insérer un composant d’interface utilisateur standard via un langage de balisage :
  1. Exposer les noms et les rôles, permettant aux propriétés réglables par l'utilisateur d'être paramétrées directement, et fournir la notification des changements en utilisant l'une des techniques ci-dessous :

Situation C : si vous utilisez un composant d'interface utilisateur standard via une technologie de programmation :
  1. G135 : Utiliser les fonctionnalités de l'API d'accessibilité d'une technologie pour exposer les noms et les rôles, pour permettre à l'utilisateur de configurer directement les propriétés configurables et pour notifier les changements (en anglais)

Situation D : si vous créez votre propre composant d'interface utilisateur dans un langage de programmation :
  1. G10 : Créer des composants à l'aide d'une technologie compatible avec les fonctionnalités de l'API d'accessibilité de la plateforme sur laquelle l'agent utilisateur sera utilisé pour exposer les noms et les rôles, pour permettre à l'utilisateur de configurer directement les propriétés configurables et pour notifier les changements (en anglais)

Techniques (recommandées) supplémentaires pour 4.1.2

Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.

  • Fournir des étiquettes pour tous les éléments de formulaires qui n'ont pas d'étiquettes implicites (lien à venir)

Échecs fréquents pour le CS 4.1.2

Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 1.4.2.

Mots clés

agent utilisateur

tout logiciel qui récupère et présente le contenu Web aux utilisateurs

Exemple : les navigateurs Web, les lecteurs de média, les modules d'extensions et les autres programmes — dont les technologies d'assistance — qui aident à récupérer, restituer et interagir avec le contenu Web.

composant d'interface utilisateur

partie du contenu qui est perçue par les utilisateurs comme un élément de contrôle unique pour une fonction distincte

Note 1 : plusieurs composants d'interface utilisateur peuvent être implémentés au sein d'un seul programme. La notion de composant n'est pas liée ici aux techniques de programmation, mais plutôt à ce que les utilisateurs perçoivent comme des éléments de contrôle distincts.

Note 2 : les composants d'interface utilisateur incluent les éléments de formulaire et les liens aussi bien que des composants générés par scripts.

Exemple : un microprogramme (applet) dispose d'un « élément de contrôle » permettant de se déplacer dans le contenu ligne par ligne, page par page ou au hasard. Puisque chacune de ces fonctions devrait avoir un nom et fonctionner indépendamment, elles constitueraient chacune un « composant d'interface utilisateur ».

défini par programmation

défini par un logiciel utilisant des méthodes qui fonctionnent avec les agents utilisateur, y compris les technologies d'assistance

déterminé (déterminable) par un programme informatique

déterminé par un programme à partir de données fournies par l'auteur d'une manière qui permet aux agents utilisateurs, y compris les technologies d'assistance, d'extraire et de présenter cette information aux utilisateurs sous différentes formes

Exemple 1 : déterminé dans un langage de balisage à partir d'éléments et d'attributs auxquels on accède grâce aux technologies d'assistance couramment disponibles.

Exemple 2 : déterminé grâce à des structures de données spécifiques d'une technologie pour un langage non-balisé et exposée aux technologies d'assistance via une API d'accessibilité aux technologies d'assistance couramment disponibles.

nom

texte grâce auquel un logiciel peut identifier pour l'utilisateur un composant du contenu Web

Note 1 : le nom peut être caché et présenté seulement aux technologies d'assistance, alors qu'une étiquette est présentée à tous les utilisateurs. Dans de nombreux cas (mais pas dans tous), l'étiquette et le nom sont identiques.

Note 2 : celui-ci n'a pas de lien avec l'attribut HTML name.

rôle

texte ou nombre par lequel un logiciel peut identifier la fonction d'un composant dans du contenu Web

Exemple : un nombre qui indique si une image sert d'hyperlien, de bouton de commande ou de case à cocher

technologie d'assistance (tel qu'utilisé dans ce document)

matériel ou logiciel qui agit comme agent utilisateur, ou simultanément avec un agent utilisateur usuel afin de fournir des fonctionnalités répondant aux besoins des utilisateurs ayant des limitations fonctionnelles, fonctionnalités qui vont au-delà de celles qui sont offertes par les agents utilisateurs usuels

Note 1 : les fonctionnalités fournies par les technologies d'assistance comprennent des présentations de remplacement (par exemple de la synthèse vocale ou du contenu agrandi), des méthodes de saisie alternatives (par exemple la voix), des mécanismes de navigation ou d'orientation supplémentaires et des transformations de contenu (par exemple pour rendre un tableau plus accessible).

Note 2 : les technologies d'assistance communiquent souvent les données et les messages aux agents utilisateurs usuels en utilisant et en surveillant le fonctionnement d'une API (interface de programmation).

Note 3 : la distinction entre agents utilisateurs usuels et technologies d'assistance n'est pas absolue. Plusieurs agents utilisateurs usuels comportent des fonctions d'assistance aux utilisateurs ayant des limitations fonctionnelles. La principale différence est que ces agents utilisateurs usuels visent un public large et diversifié qui comprend des personnes avec et sans limitations fonctionnelles. Les technologies d'assistance visent des populations plus restreintes d'utilisateurs ayant des limitations fonctionnelles particulières. L'assistance fournie par une technologie d'assistance est plus spécifique et appropriée aux besoins des utilisateurs visés. Un agent utilisateur usuel peut comporter des fonctionnalités importantes pour les technologies d'assistance comme l'extraction du contenu Web à partir d'objets de programmation ou l'analyse syntaxique du balisage par paquets identifiables.

Exemple : les technologies d'assistance qui sont importantes dans le contexte du présent document comprennent les technologies suivantes :

  • les agrandisseurs d'écran et les autres assistants de lecture visuelle qui sont utilisés par les personnes ayant des limitations de la vision, de la perception ou d'accès physique à l'imprimé pour modifier la police de caractères, la taille, l'espacement, la couleur, la synchronisation avec la synthèse vocale, etc. dans le but d'améliorer la lisibilité visuelle du rendu des textes et des images ;

  • les lecteurs d'écran qui sont utilisés par les personnes aveugles pour lire l'information textuelle en synthèse vocale ou en braille ;

  • les logiciels de conversion du texte en parole qui sont utilisés par certaines personnes ayant des limitations cognitives, des limitations du langage et des difficultés d'apprentissage pour convertir le texte en synthèse vocale ;

  • les logiciels de reconnaissance vocale qui peuvent être utilisés par les personnes ayant certaines limitations motrices ;

  • des claviers de remplacement qui sont utilisés par des personnes ayant certaines limitations motrices pour simuler le clavier (y compris des claviers de remplacement qui utilisent des pointeurs de tête, des commutateurs simples, des dispositifs d'aspiration/expiration et d'autres dispositifs spéciaux d'aide à la saisie.) ;

  • des dispositifs de pointage adaptés qui sont utilisés par des personnes ayant certaines limitations motrices pour simuler le pointeur de la souris et l'activation des boutons.

Comprendre la conformité

Tous les critères de succès des WCAG 2.0 sont écrits comme des critères testables permettant de déterminer objectivement si le contenu les satisfait. Tester les critères de succès impliquerait une combinaison de tests automatisés et d'évaluation humaine. Le contenu doit être testé par ceux qui comprennent comment les personnes ayant différents types de limitations utilisent le Web.

Tester et testable réfèrent, dans ce contexte, à des tests fonctionnels, c'est-à-dire vérifier que le contenu fonctionne comme prévu, ou dans ce cas, qu'il satisfait les critères de succès. Bien que le contenu satisfasse à tous les critères de succès, le contenu n'est pas toujours utilisable par des personnes ayant une grande variété de limitations. Par conséquent, les tests d'utilisabilité sont recommandés, en plus des tests fonctionnels requis. Les tests d'utilisabilité ont pour but de déterminer à quel point les gens peuvent utiliser le contenu selon sa fonction. Il est recommandé que des utilisateurs en situation de handicap soient inclus dans des groupes de test lors de la réalisation des tests d'utilisabilité.

Que signifie la conformité ?

La conformité à un standard signifie que les « exigences » de ce standard sont rencontrées ou satisfaites. Dans les WCAG 2.0 les « exigences » sont les critères de succès. Pour vous conformer aux WCAG 2.0, vous devez satisfaire les critères de succès, c'est-à-dire qu'il n'y ait aucun contenu qui viole les critères de succès.

Note : cela signifie que s'il n'y a aucun contenu auquel s'applique un critère de succès, ce critère de succès est satisfait.

La plupart des standards ont un seul niveau de conformité. Afin de tenir compte des différentes situations qui peuvent exiger ou permettre des niveaux plus élevés d'accessibilité, les WCAG 2.0 comportent trois niveaux de conformité et, par conséquent, trois niveaux de critères de succès.

Comprendre les exigences de conformité

Il y a cinq conditions à remplir pour que le contenu soit classé comme « conforme » aux WCAG 2.0. Cette section fournit de brèves notes concernant ces exigences. Cette section sera développée au fil du temps pour répondre aux questions qui pourraient se poser ou pour fournir de nouveaux exemples des façons de satisfaire aux différentes exigences de conformité.

Comprendre l'exigence 1

1. Niveau de conformité : l'un des niveaux de conformité suivants est atteint entièrement.

  • Niveau A : pour une conformité de niveau A (le niveau minimal de conformité), la page Web satisfait à tous les critères de succès de niveau A ou une version de remplacement conforme est fournie.

  • Niveau AA : pour une conformité de niveau AA, la page Web remplit tous les critères de succès de niveau A et AA ou une version de remplacement conforme au niveau AA est fournie.

  • Niveau AAA : pour une conformité de niveau AAA, la page Web remplit tous les critères de succès de niveau A, AA et AAA ou une version de remplacement conforme au niveau AAA est fournie.

Note 1 : bien que la conformité se définisse par paliers, les auteurs sont invités à mentionner (dans leur déclaration) tous les critères de succès satisfaits au-delà du niveau de conformité atteint.

Note 2 : il n'est pas recommandé de se fixer le niveau AAA comme objectif à l'échelle de sites entiers car il n'est pas possible de satisfaire à tous les critères de succès du niveau AAA pour certains contenus.

La première exigence traite des niveaux de conformité. Elle dit essentiellement que toutes les informations sur une page sont conformes ou comportent une version de remplacement conforme qui est disponible à partir de la page. L'exigence explique aussi qu'aucune conformité n'est possible sans au moins satisfaire à tous les critères de succès de niveau A.

La note fait ressortir que les auteurs sont encouragés à aller au-delà de la conformité à un niveau particulier et à compléter et rapporter s'ils le désirent, tout progrès vers des niveaux plus élevés de conformité.

Voir aussi Comprendre « version de remplacement conforme » qui inclut des techniques pour fournir une version de remplacement conforme.

Comprendre l'exigence 2

2. Pages complètes : la conformité (et le niveau de conformité) s'entend uniquement pour des pages Web complètes et ne peut être atteinte si une partie de la page Web est exclue.

Note 1 : dans le but de déterminer la conformité, les versions de remplacement à une partie du contenu de la page sont considérées comme une partie de la page quand les versions de remplacement peuvent être obtenues directement depuis la page, comme par exemple, une description longue ou la présentation de remplacement d'une vidéo.

Note 2 : les auteurs de pages Web qui ne peuvent être considérées comme conformes en raison d'un contenu qui n'est pas sous le contrôle de l'auteur peuvent envisager d'utiliser une déclaration de conformité partielle.

Cette disposition exige simplement que la page entière soit conforme. Des déclarations sur « une partie d'une page conforme » ne peuvent pas être faites.

Parfois, des informations supplémentaires pourront être disponibles à partir d'une autre page d'informations sur une page. L'attribut longdesc en HTML est un exemple. Avec un longdesc, une longue description d'un graphique peut être présentée sur une page distincte où l'utilisateur peut se déplacer à partir de la page présentant le graphique. Il est donc clair qu'un tel contenu est considéré comme faisant partie de la page Web, de sorte que l'exigence 2 est satisfaite pour l'ensemble combiné des pages Web considérées comme une seule page Web. Des versions de remplacement peuvent également être fournies sur la même page. Par exemple, créer un équivalent d'un contrôle de l'interface utilisateur.

Note 1 : en raison de l'exigence de conformité 5, une page entière peut être conforme, même si certaines parties d'une page utilisent des technologies qui ne sont pas compatibles avec l'accessibilité tant que ces parties n'interfèrent pas avec le reste de la page et que toutes les informations et les fonctionnalités sont disponibles ailleurs sur la même page ou à partir de cette page.

Note 2 : il est possible d'inclure des contenus non conformes. Voir Comprendre l'exigence de conformité 5.

Comprendre l'exigence 3

3. Processus complets : quand une page Web fait partie d'un ensemble représentant un processus (comme une succession d'étapes devant être complétées afin d'accomplir une activité), toutes les pages Web du processus sont conformes au moins au niveau spécifié. (La conformité à un certain niveau est impossible s'il existe une page de ce processus qui n'atteint pas au moins ce niveau.)

Exemple : une boutique en ligne présente une série de pages permettant de sélectionner et d'acheter des produits. Toutes les pages de la séquence depuis le début jusqu'à la fin (le paiement) sont conformes afin que toute page faisant partie du processus soit conforme.

Cette disposition empêche une page Web qui fait partie d'un processus plus large d'être considérée comme conforme si le processus dans son ensemble ne l'est pas. Cela permettrait d'éviter qu'un site de commerce soit classé comme conforme si le passage à la caisse ou d'autres fonctionnalités du site qui font partie des processus de vente ou d'achat ne sont pas conformes.

Comprendre l'exigence 4

4. L'usage des technologies selon des méthodes exclusivement compatibles avec l'accessibilité : la satisfaction à un critère de succès ne dépend que des méthodes d'utilisation des technologies qui sont compatibles avec l'accessibilité. Toute information ou fonctionnalité proposée d'une manière non compatible avec l'accessibilité est également disponible sous une forme compatible avec l'accessibilité. (Voir Comprendre la compatibilité avec l'accessibilité.)

Cette exigence de conformité est expliquée plus bas dans Comprendre la compatibilité avec l'accessibilité.

Comprendre l'exigence 5

5. Non-interférence : si des technologies sont employées de manière non compatible avec l'accessibilité ou non conforme, alors elles n'empêchent pas les utilisateurs d'accéder au reste de la page. En outre, la page Web dans sa globalité continue de répondre aux exigences de conformité dans chacun des cas suivants :

  1. quand toute technologie non dépendante est activée dans l'agent utilisateur,

  2. quand toute technologie non dépendante est désactivée dans l'agent utilisateur et

  3. quand toute technologie non dépendante n'est pas reconnue par l'agent utilisateur

De plus, les critères de succès suivants s'appliquent à tout le contenu de la page, y compris au contenu dont on ne dépend pas autrement pour atteindre la conformité, car un échec à les satisfaire pourrait perturber toute utilisation de la page :

  • 1.4.2 - Contrôle du son,

  • 2.1.2 - Pas de piège au clavier,

  • 2.3.1 - Pas plus de trois flashs ou sous le seuil critique et

  • 2.2.2 - Mettre en pause, arrêter, masquer.

Cela dit essentiellement que les technologies qui ne sont pas compatibles avec l'accessibilité peuvent être utilisées tant que toutes les informations sont également disponibles en utilisant les technologies qui sont compatibles avec l'accessibilité et tant que la non-compatibilité avec l'accessibilité de certains contenus n'interfère pas.

Les technologies qui ne sont pas compatibles avec l'accessibilité peuvent être utilisées, ou des technologies qui sont compatibles avec l'accessibilité peuvent être utilisées d'une manière non conforme, tant que toutes les informations sont aussi disponibles en utilisant les technologies qui sont compatibles avec l'accessibilité, d'une manière qui est conforme, et tant que la non compatibilité avec l'accessibilité de certains contenus n'interfère pas.

Il y a quatre dispositions qui traitent notamment des questions d'interférence avec l'utilisation de la page. Ces quatre dispositions sont incluses dans une note ici. Une note sur chacune de ces dispositions indique en effet que ces critères de succès doivent être respectés pour tous les contenus y compris le contenu créé en utilisant des technologies qui ne sont pas compatibles avec l'accessibilité.

Exemple : une page Web intègre une nouvelle technologie graphique interactive appelée « ZAP ». Bien que « ZAP » soit compatible avec l'accessibilité, l'information qui est présentée dans « ZAP » est également présentée sur la page en HTML, ainsi l'utilisation de dépend pas de « ZAP ». Ainsi donc, cette page satisferait l'exigence de conformité 1. Toutefois, si l'utilisateur tente de se déplacer avec la touche tabulation dans le contenu ZAP, le focus entrera dans l'objet ZAP et y restera coincé. Une fois dans l'objet, il n'y a rien que l'utilisateur puisse faire pour en retirer le focus. Ainsi les utilisateurs du clavier ne peuvent pas utiliser la moitié inférieure de la page. Le contenu ZAP flashe aussi vivement et continuellement à des fréquences variées sans s'arrêter. Ainsi, les personnes ayant un déficit d'attention sont distraites et celles ayant des troubles épileptiques photosensibles peuvent avoir des convulsions. La conformité à l'exigence 5 empêche de telles situations de se produire sur une page conforme.

Comprendre les déclarations de conformité

Il n'est pas nécessaire de faire une déclaration de conformité en vue de se conformer. Si une déclaration est faite cependant, les règles doivent être suivies.

Parfois, quelqu'un peut vouloir faire une déclaration seulement pour un contenu qui a été ajouté après une certaine date. Ou bien quelqu'un peut vouloir déclarer la conformité aux WCAG 1.0 pour le contenu jusqu'à une certaine date et la conformité aux WCAG 2.0 pour le contenu qui a été créé ou modifié après cette date. Les WCAG 2.0 n'interdisent aucune de ces pratiques tant qu'il ressort clairement quelles pages sont déclarées conformes à quelle version des WCAG.

Note 1 : quand on parle de technologies dont « dépend » l'utilisation du contenu, on parle des technologies Web (HTML, CSS, JavaScript, etc.), et non des agents utilisateurs (navigateurs, technologies d'assistance, etc.).

Note 2 : les déclarations de conformité ne sont généralement pas situées sur chaque page Web dans le périmètre de conformité.

Informations sur les mesures supplémentaires prises qui vont au-delà des critères de succès

Un des composants optionnels d'une revendication de conformité est « l'information sur les mesures supplémentaires prises qui vont au-delà des critères de succès pour améliorer l'accessibilité. » Cela peut inclure des critères de succès supplémentaires qui ont été satisfaits, les techniques recommandées qui ont été mises en œuvre, des informations sur tous les protocoles additionnels utilisés pour faciliter l'accès pour les personnes en situation de handicap ou ayant des besoins particuliers, etc. Toute information qui serait utile pour une meilleure compréhension de l'accessibilité des pages peut être incluse.

L'utilisation des métadonnées pour faire une déclaration de conformité

La façon la plus utile de rattacher les déclarations de conformité au contenu serait de le faire sous une forme standard lisible par machine. Lorsque cette pratique est généralisée, des moteurs de recherche ou des agents utilisateurs spéciaux seront en mesure d'utiliser cette information pour trouver et offrir un contenu qui est plus accessible ou les agents utilisateurs pourront s'ajuster au contenu. Il existe un certain nombre d'options de déclarations basées sur les métadonnées qui sont en cours de développement et les auteurs et les développeurs d'outils sont encouragés à les utiliser.

En outre, les métadonnées peuvent être utilisées pour faire rapport de la conformité aux différents critères de succès, une fois que le niveau A de conformité a été atteint.

Il existe également des formats de rapport programmés (EARL) Evaluation and Report Language (EARL) qui sont en cours d'élaboration et qui pourraient fournir des formats lisibles par machine pour des renseignements détaillés sur la conformité. Lorsque les formats de rapport seront formalisés et le soutien développé, ils seront documentés ici.

Exemples de déclarations de conformité

Exemples des composantes exigées pour une déclaration de conformité

Exemple 1 : le 20 septembre 2009, toutes les pages Web à http://www.example.com sont conformes aux Règles pour l'accessibilité des contenus Web 2.0 à http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Conformité de niveau A.

  • L'ensemble documenté des technologies compatibles avec l'accessibilité dont dépend l'utilisation du contenu faisant l'objet de cette déclaration est un sous-ensemble de l'ISA- AsCTset#1-2008 à http://ISA.example.gov/AsCTsets/AS2-2008.

Exemple 2 : (en utilisant une expression régulière) Le 12 août 2009, les pages correspondant au modèle http://www.example.com/ (marketing | Ventes | contact) / .* sont conformes aux Règles pour l'accessibilité des contenus Web 2.0 à http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Conformité de niveau AA.

  • Les technologies dont dépend l'utilisation de ce contenu sont : XHTML 1.0 Transitional, CSS 2.0 et JavaScript 1.2.

Exemple 3 : (en utilisant la logique booléenne) Le 6 janvier 2009, http://example.com/ ET NON (http://example.com/archive/ OU http://example.com/publications/archive/) est conforme aux Règles pour l'accessibilité des contenus Web 2.0 à http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Conformité de niveau AA.

  • L'ensemble documenté des technologies compatibles avec l'accessibilité dont dépend l'utilisation du contenu faisant l'objet de cette déclaration inclut XHTML 1.0 et SMIL de ISA- AsCTset#1-2008 à http://ISA.example.gov/AsCTsets/AS2-2008

Exemples de déclaration de conformité contenant des composants optionnels

Exemple 1 : le 5 mai 2009, la page « G7 : Une introduction » à http://telcor.example.com/nav/G7/intro.html est conforme aux Règles pour l'accessibilité des contenus Web 2.0 à http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Conformité de niveau AA.

  • Les critères de succès supplémentaires suivants ont également été satisfaits : 1.1.2, 1.2.5, et 1.4.3.

  • L'ensemble documenté des technologies compatibles avec l'accessibilité utilisées pour cette déclaration est AsCTset#1-2006 à http://UDLabs.org/AsCTset#1-2006.html.

  • Les technologies dont dépend l'utilisation de ce contenu sont : XHTML 1.0 (Strict), et Real Video.

  • Les technologies qui sont « utilisées mais dont ne dépend pas » l'utilisation du contenu sont : JavaScript 1.2, CSS2.

Exemple 2 : le 21 juin 2009, l'ensemble du contenu commençant par l'URI http://example.com/nav et http://example.com/docs est conforme aux Règles pour l'accessibilité des contenus Web 2.0 à http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Conformité de niveau AAA.

  • L'ensemble documenté des technologies compatibles avec l'accessibilité utilisées pour cette déclaration est SMITH- AsCTset#2-2008 à http://smithreports.example.com/AsCTsets/AS2-2008.

  • Les technologies dont dépend l'utilisation de ce contenu sont : XHTML 1.0 (Strict), CSS2, JavaScript 1.2, JPEG, PNG.

  • Les agents utilisateur, y compris les technologies d'assistance avec lesquels ce contenu a été testé, peuvent être trouvés à http://example.com/docs/WCAG20/test/technologies.html.

Exemple 3 : le 23 mars 2009, tous les contenus disponibles sur le serveur à http://www.wondercall.example.com sont conformes aux Règles pour l'accessibilité des contenus Web 2.0 à http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Conformité de niveau simple A.

  • La technologie dont « dépend » l'utilisation de ce contenu est : HTML 4.01.

  • Les technologies qui sont « utilisées mais dont ne dépend pas » l'utilisation du contenu sont : CSS2 et GIF.

  • Ce contenu a été testé avec les technologies d'assistance et les agents utilisateurs suivants : Firefox 1.5 sur Windows Vista avec le lecteur d'écran X 4.0, Firefox 1.5 sur Windows XP SP2 avec le lecteur d'écran X 3.5, IE 6.0 sur Windows 2000 SP4 avec le lecteur d'écran Y 5.0, IE 6.0 sur Windows 2000 SP4 avec le lecteur d'écran Z 2.0 et Firefox 1.5 sur Windows XP SP2 avec le lecteur d'écran X 4.0, Safari 2.0 avec OS X 10.4.

Techniques pour les déclarations de conformité

Techniques recommandées
  • Faire une déclaration de conformité aux WCAG 2.0 dans les éléments Dublin Core (lien à venir)

Comprendre les niveaux de conformité

Premièrement, il y a un certain nombre de conditions qui doivent être remplies pour qu'un critère de succès puisse être inclus. Il s'agit notamment de :

  1. Tous les critères de succès doivent représenter des enjeux d'accès importants pour les personnes avec des limitations fonctionnelles qui traitent des problèmes qui se situent au-delà des problèmes d'utilisabilité pouvant être rencontrés par tous les utilisateurs. En d'autres mots, l'enjeu de l'accès doit poser un problème proportionnellement plus important pour les personnes en situation de handicap que celui qu'il pose pour les personnes sans handicaps, afin d'être considéré comme un problème d'accessibilité (et d'être couvert par ces règles pour l'accessibilité).

  2. Tous les critères de succès doivent également être vérifiables. Cela est important car autrement il ne serait pas possible de déterminer si une page a satisfait ou non aux critères de succès. Les critères de succès peuvent être testés par une combinaison d'évaluation mécanique et humaine tant qu'il est possible de déterminer, avec un niveau de confiance élevé, si un critère de succès a été satisfait ou non.

Les critères de succès ont été affectés à l'un des trois niveaux de conformité par le groupe de travail après avoir pris en considération un large éventail de questions en interaction. Parmi les facteurs communs évalués lors de la fixation du niveau, on retrouvait :

  • si le critère de succès est essentiel (en d'autres termes, si le critère de succès n'est pas satisfait et que même la technologie d'assistance ne peut pas rendre le contenu accessible) ;

  • s'il est possible de satisfaire au critère de succès pour tous les sites Web et les types de contenus auxquels les critères de succès seraient applicables (par exemple différents sujets, des types de contenus, des types de technologies Web) ;

  • si le critère de succès exige un niveau de compétence qui pourrait raisonnablement être atteint par les créateurs de contenu (c'est-à-dire que les connaissances et les compétences pour satisfaire aux critères de succès pourraient être acquises dans une formation d'une semaine ou moins) ;

  • si le critère de succès impose des limites « à l'apparence et à la convivialité » ou à la fonction de la page Web (limites à la fonction, à la présentation, à la liberté d'expression, à la liberté de conception ou à l'esthétique que le critère de succès pourrait représenter pour les auteurs) ;

  • s'il n'existe pas de moyen de contournement dans le cas où les critères de succès ne sont pas satisfaits.

Comprendre la compatibilité avec l'accessibilité

Plusieurs des critères de succès traitent de l'accessibilité avec des technologies d'assistance ou avec les fonctions d'accessibilité propres aux agents utilisateurs ordinaires (par exemple, une option « afficher les sous-titres » dans un lecteur multimédia). Autrement dit, les critères de succès exigent que quelque chose soit fait dans le contenu Web qui permette aux technologies d'assistance de présenter avec succès les informations du contenu à l'utilisateur. Par exemple, une image sur laquelle vous devriez cliquer pour aller à un sujet particulier ne serait pas accessible à une personne qui serait aveugle, à moins que des équivalents textuels pour cette photo n'aient été fournis d'une façon que les agents utilisateurs y compris les technologies d'assistance puissent les trouver et les afficher. La clé ici est que l'équivalent textuel doit être inclus d'une façon que les agents utilisateurs, y compris les technologies d'assistance, peuvent comprendre et utiliser - d'une façon qui est « compatible avec l'accessibilité ».

Un autre exemple serait un contrôle personnalisé qui est inclus sur une page Web. Dans ce cas, un agent utilisateur standard ne serait pas normalement en mesure de présenter une version de remplacement à l'utilisateur. Toutefois, si l'information sur le contrôle, y compris son nom, son rôle, sa valeur, comment le configurer, etc. est fournie d'une façon que les technologies d'assistance peuvent comprendre et utiliser, alors les utilisateurs des technologies d'assistance seront en mesure d'utiliser ce contrôle.

Lorsque de nouvelles technologies sont introduites, deux conditions doivent être remplies pour que les personnes utilisant les technologies d'assistance soient en mesure d'y accéder. Premièrement, les technologies doivent être conçues de façon à ce que les agents utilisateurs, y compris les technologies d'assistance, aient accès à toute l'information dont ils ont besoin pour présenter le contenu à l'utilisateur. Deuxièmement, les agents utilisateurs et les technologies d'assistance peuvent avoir besoin d'être repensés ou modifiés pour être en mesure de fonctionner efficacement avec ces nouvelles technologies.

« Compatible avec l'accessibilité » signifie que ces deux conditions ont été remplies et que la technologie va fonctionner avec les agents utilisateurs et les technologies d'assistance.

Niveau de compatibilité requis pour la « compatibilité avec l'accessibilité »

Ce sujet pose la question de savoir combien et quelles technologies d'assistance doivent être compatibles avec une technologie Web pour que cette technologie Web soit considérée comme « compatible avec l'accessibilité ». Le groupe de travail des WCAG et le W3C ne précisent pas quelle technologie d'assistance ou combien de ces technologies doivent être compatibles avec une technologie Web afin que cette technologie Web soit classée comme compatible avec l'accessibilité. Il s'agit d'un sujet complexe et qui varie à la fois selon l'environnement et selon la langue. Il y a nécessité d'un dialogue avec l'extérieur, un dialogue international sur ce sujet. Voici quelques notes pour vous aider à comprendre et à explorer ce thème :

  1. La compatibilité avec l'accessibilité varie selon l'environnement

    • Dans une société où tous les employés sont équipés avec des agents utilisateurs particuliers et des technologies d'assistance, les technologies Web ont seulement besoin d'être compatibles avec ces agents utilisateurs et les technologies d'assistance plus anciennes.

    • Le contenu affiché sur le site Web public doit fonctionner avec un éventail plus large d'agents utilisateurs et de technologies d'assistance.

  2. La compatibilité avec l'accessibilité varie selon la langue (et le dialecte)

    • Il existe différents niveaux de compatibilité avec l'accessibilité pour les anciennes technologies d'assistance dans différentes langues et dans différents pays. Certains milieux ou pays peuvent fournir gratuitement les technologies d'assistance.

  3. Les nouvelles technologies ne seront pas compatibles avec les anciennes technologies d'assistance

    • De toute évidence, une nouvelle technologie ne peut pas être compatible avec toutes les anciennes technologies d'assistance, ainsi donc il n'est pas possible d'exiger qu'une technologie soit compatible avec toutes les technologies d'assistance.

  4. La compatibilité avec une seule ancienne technologie d'assistance n'est généralement pas suffisante

    • La compatibilité avec une seule technologie d'assistance (pour un type de limitation donné) ne serait généralement pas suffisante, surtout si la plupart des utilisateurs qui en ont besoin afin d'accéder au contenu n'ont pas cette technologie d'assistance et n'ont pas les moyens de se l'offrir. L'exception dans ce cas serait de diffuser l'information aux salariés de l'entreprise qui ont tous une technologie d'assistance (de ce type).

  5. Actuellement, les technologies d'assistance qui sont abordables pour le grand public sont souvent très pauvres

    • Créer un contenu qui ne peut pas être utilisé par le public ayant des limitations fonctionnelles en général doit être évité. Dans de nombreux cas, le coût des technologies d'assistance est trop élevé pour les utilisateurs qui en ont besoin. En outre, les capacités des technologies d'assistance gratuites ou à faible coût sont souvent si pauvres aujourd'hui que le contenu Web ne peut être restreint de façon réaliste à ce plus petit commun dénominateur (ou même moyen). Cela crée un dilemme très difficile qui doit être pris en compte.

Par conséquent, le groupe de travail s'est borné à définir ce qu'est la compatibilité et le jugement de comment, combien et quelle technologies d'assistance doivent être compatibles avec une technologie est renvoyé à la communauté et à des entités plus proches de chaque situation qui fixent des critères pour une organisation, pour l'achat, pour une communauté, etc.

Le Groupe de travail encourage davantage de discussions à ce sujet dans le forum général de la société parce que ce manque de technologies d'assistance robustes disponibles partout est un problème qui dessert les utilisateurs, les développeurs de technologies et les auteurs.

Définition technique de « compatible avec l'accessibilité »

Fondamentalement, une technologie Web sera « compatible avec l'accessibilité » lorsque les technologies d'assistance des utilisateurs fonctionneront avec les technologies Web et lorsque les fonctionnalités d'accessibilité des technologies courantes fonctionneront avec cette technologie. Plus précisément, pour être considérée comme une technologie compatible avec l'accessibilité, les conditions suivantes doivent être remplies pour cette technologie :

compatible avec l'accessibilité

compatible avec les technologies d'assistance des utilisateurs aussi bien qu'avec les fonctionnalités d'accessibilité des navigateurs et des autres agents utilisateurs

Pour qu'une technologie Web (ou une fonctionnalité d'une technologie) soit considérée comme compatible avec l'accessibilité, les conditions 1 et 2 doivent être toutes deux remplies pour une technologie Web (ou une fonctionnalité) :

  1. La manière dont la technologie Web est utilisée doit être compatible avec les technologies d'assistance des utilisateurs (TA). Cela signifie que la manière dont la technologie est utilisée a été testée pour l'interopérabilité avec la technologie d'assistance des utilisateurs dans la langue du contenu,

    ET

  2. La technologie Web doit avoir des agents utilisateurs compatibles avec l'accessibilité qui sont disponibles aux utilisateurs. Cela signifie qu'au moins l'une des quatre affirmations suivantes est vérifiée :

    1. la technologie est prise en charge en mode natif dans les agents utilisateurs largement distribués, qui sont aussi compatibles avec l'accessibilité (tels que HTML et CSS) ;

      OU

    2. la technologie est prise en charge dans un module d'extension largement distribué qui est aussi compatible avec l'accessibilité ;

      OU

    3. le contenu est disponible dans un environnement fermé, comme une université ou un réseau d'entreprise, où l'agent utilisateur requis par la technologie et utilisé par l'organisation est également compatible avec l'accessibilité ;

      OU

    4. L'agent ou les agents utilisateur(s) qui prennent en charge la technologie sont compatibles avec l'accessibilité et sont disponibles pour le téléchargement ou l'achat d'une manière qui :

      • ne coûte pas plus cher à une personne ayant une limitation fonctionnelle, qu'à une personne sans handicap et

      • est aussi facile à trouver et à obtenir pour une personne avec une limitation fonctionnelle que pour une personne sans handicap.

Note 1 : le groupe de travail des WCAG et le W3C ne précisent pas quelles technologies d'assistance ou le niveau de prise en charge qu'elles doivent avoir pour une utilisation particulière d'une technologie Web afin que cette technologie Web soit classée comme compatible avec l'accessibilité. (Voir Niveau de compatibilité requis pour la « compatibilité avec l'accessibilité ».)

Note 2 : les technologies Web peuvent être utilisées de manières qui ne sont pas compatibles avec l'accessibilité tant que l'utilisation du contenu n'en dépend pas et que la page dans son ensemble satisfait aux exigences de conformité, y compris l'exigence de conformité 4 : L'usage des technologies selon des méthodes exclusivement compatibles avec l'accessibilité et l'exigence de conformité 5 : Non-interférence.

Note 3 : quand une technologie Web est utilisée d'une manière qui est « compatible avec l'accessibilité », cela n'implique pas que l'ensemble de la technologie ou toutes les utilisations de cette technologie sont compatibles avec l'accessibilité. La plupart des technologies, notamment HTML, ne sont pas compatibles avec au moins l'une de leurs caractéristiques ou l'une de leurs utilisations. Les pages sont conformes aux WCAG si seulement les usages de la technologie qui sont compatibles avec l'accessibilité sont ceux dont on dépend pour répondre aux exigences des WCAG.

Note 4 : quand on cite les technologies Web qui ont plusieurs versions, la ou les version(s) compatibles devraient être précisées.

Note 5 : un moyen pour les auteurs de localiser les utilisations d'une technologie qui sont compatibles avec l'accessibilité serait de consulter les compilations des utilisations qui sont documentées comme compatibles avec l'accessibilité. (Voir Comprendre les usages des technologies Web qui sont compatibles avec l'accessibilité.) Les auteurs, les entreprises, les fournisseurs de technologie ou d'autres peuvent documenter les usages des technologies Web qui sont compatibles avec l'accessibilité. Toutefois, tous les usages des technologies documentés devront satisfaire à la définition de compatibilité avec l'accessibilité pour les technologies Web énoncée plus haut.

Comprendre les usages des technologies Web qui sont compatibles avec l'accessibilité

Les auteurs individuels ne seront généralement pas en mesure de faire tous les tests nécessaires pour déterminer lesquels des usages des technologies Web sont réellement compatibles avec les versions des technologies d'assistance et les agents utilisateurs. Les auteurs pourront donc compter sur des compilations publiques qui documentent quelles technologies d'assistance sont compatibles avec quelles façons d'utiliser les technologies Web. Par publique, nous ne voulons pas dire que la compilation et sa documentation sont nécessairement générées par un organisme public, mais seulement qu'ils sont à la disposition du public. N'importe qui peut créer des compilations publiques documentées des « usages des technologies Web et de leur compatibilité avec l'accessibilité ». Les gens peuvent créer des compilations et leur donner des noms auxquels les auteurs peuvent se référer. Tant qu'ils sont publiquement documentés, les auteurs ou les clients, etc. peuvent sélectionner facilement les usages qui répondent à leurs besoins. Les clients ou d'autres peuvent choisir les technologies qui correspondent à leur environnement ou leur langue à tout moment et préciser celles qui doivent être utilisées dans la création de leur contenu. Les auteurs sont fortement encouragés à utiliser des sources qui ont une réputation bien établie pour leur exactitude et leur utilité. Les développeurs de technologies sont fortement encouragés à fournir des informations sur la compatibilité avec l'accessibilité de leurs technologies. Le Groupe de travail prévoit qu'à long terme seuls les documents qui fourniront des informations précises et profiteront à la fois aux auteurs et aux utilisateurs pourront obtenir une reconnaissance du marché.

Les WCAG n'exigent pas qu'une compilation publique documentée soit utilisée ou que seulement les usages documentés des technologies par de telles compilations soient utilisés. Les compilations publiques documentées sont seulement décrites comme une méthode facilitant une appréciation critique mais un peu compliquée de ces aspects de la conformité par les auteurs qui ne sont pas eux-mêmes experts en matière de technologie d'assistance (ou qui n'ont tout simplement pas le temps de suivre les progrès des technologies usuelles et des technologies d'assistance et de leur compatibilité mutuelle).

Les auteurs, les sociétés ou d'autres personnes peuvent souhaiter créer et utiliser leurs propres compilations des usages des technologies compatibles avec l'accessibilité et cela est admis pour satisfaire aux WCAG. Les clients, les entreprises ou d'autres peuvent toutefois préciser que les usages des technologies sont tirés d'une compilation publique ou personnalisée. Voir Annexe B : documenter la compatibilité avec l'accessibilité pour l'utilisation d'une technologie Web.

Déclaration de compatibilité avec l'accessibilité

Voici des exemples de moyens par lesquels une déclaration de conformité pourrait documenter la compatibilité avec l'accessibilité :

  1. Cette déclaration de conformité satisfait à l'exigence de compatibilité avec l'accessibilité en se fondant sur des tests dans la ou les langue(s) du contenu avec les agents utilisateurs A, B et C, et les technologies d'assistance X, Y et Z. Cela signifie que nous avons réussi à satisfaire à tous les critères de succès pour le niveau A des WCAG 2.0 en utilisant ces produits.

  2. Cette déclaration de conformité satisfait à l'exigence de compatibilité avec l'accessibilité pour la ou les langue(s) du contenu en se fondant sur l'utilisation de techniques et de notes sur l'agent utilisateur documentées dans les Techniques pour les WCAG 2.0. Elle est également fondée sur la documentation sur la compatibilité avec l'accessibilité pour les technologies (dont dépend la conformité), qui est disponible dans « Documentation de l'organisation XYZ sur la compatibilité avec l'accessibilité ».

  3. Cette déclaration de conformité satisfait à l'exigence de compatibilité avec l'accessibilité pour la ou les langue(s) du contenu en se fondant sur l'utilisation de la technologie Z tel qu'indiqué dans « Techniques pour la compatibilité avec l'accessibilité de la technologie Z pour les WCAG 2.0 ».

  4. Cette déclaration de conformité satisfait à l'exigence de compatibilité avec l'accessibilité pour la langue du contenu en se fondant sur l'utilisation des règles pour l'accessibilité de la technologie A et de la technologie B. L'information sur la compatibilité avec les agents utilisateurs et les technologies d'assistance peut être trouvée dans « Exigences de compatibilité avec l'accessibilité du produit XYZ » qui sont documentées dans ces règles.

Comprendre « déterminable par un programme informatique »

Plusieurs critères de succès exigent que le contenu (ou certains aspects du contenu) puissent être « déterminés par un programme informatique ». Cela signifie que le contenu est conçu de telle façon que les agents utilisateurs, y compris les technologies d'assistance, puissent accéder à l'information.

Pour que le contenu créé avec des technologies Web (telles que HTML, CSS, PDF, GIF, MPEG, Flash, etc.) puisse être accessible aux personnes présentant différents types de limitations, il est essentiel que les technologies utilisées soient compatibles avec les fonctionnalités d'accessibilité des navigateurs et des autres agents utilisateurs, y compris les technologies d'assistance. Pour que quelque chose puisse satisfaire à un critère de succès qui l'oblige à être « déterminable par un programme informatique », il devra être mis en œuvre en utilisant une technologie qui est compatible avec les technologies d'assistance.

Un contenu qui peut être « déterminé par un programme informatique » peut être transformé (par les agents utilisateurs y compris les technologies d'assistance) dans différents formats sensoriels (par exemple visuel, auditif) ou styles de présentation selon les besoins de chaque utilisateur. Si les technologies d'assistance existantes ne peuvent pas le faire, alors l'information ne peut pas être considérée comme déterminable par un programme informatique.

Le terme a été créé afin de permettre au groupe de travail chargé d'identifier clairement les endroits où l'information devait être accessible aux technologies d'assistance (et autres agents utilisateurs agissant en qualité d'aide à l'accessibilité), sans préciser exactement comment ceci devait être fait. Cela est important en raison de la nature en évolution constante des technologies. Le terme permet aux règles d'accessibilité de déterminer ce qui doit être « déterminé par un programme informatique » afin de respecter les règles et de présenter dans des documents distincts (comment satisfaire à une règle, comprendre une règle et appliquer les techniques) qui peuvent mettre à jour au fil du temps la liste des techniques particulières qui fonctionneront et seront suffisantes à n'importe quel point dans le temps en fonction de l'agent utilisateur et de la compatibilité avec les technologies d'assistance.

« Compatibilité avec l'accessibilité » vs « déterminable par un programme informatique »

La « compatibilité avec l'accessibilité » se rapporte à la compatibilité avec les agents utilisateurs (incluant les technologies d'assistance) des usages particuliers des technologies Web. Les usages des technologies Web qui sont compatibles avec l'accessibilité fonctionneront avec les technologies d'assistance et les fonctionnalités d'accès des agents utilisateurs usuels (les navigateurs, les lecteurs, etc.).

« Déterminable par un programme informatique » se rapporte aux informations dans les contenus Web. Si les technologies qui sont compatibles avec l'accessibilité sont utilisées correctement, les technologies d'assistance et les agents utilisateurs pourront accéder aux informations dans le contenu (par exemple déterminer par un programme informatique les informations se trouvant dans le contenu) et les présenter à l'utilisateur.

Les deux concepts fonctionnent ensemble pour assurer que l'information puisse être présentée à l'utilisateur par les agents utilisateurs y compris les technologies d'assistance. Les auteurs ne doivent compter que sur les usages des technologies qui sont compatibles avec l'accessibilité - et les utiliser correctement pour que l'information soit déterminable par un programme informatique - et donc présentable, par les technologies d'assistance et les agents utilisateurs aux utilisateurs en situation de handicap.

Comprendre « version de remplacement conforme »

La première exigence de conformité permet d'inclure les pages non conformes dans le périmètre de conformité tant qu'elles ont une « version de remplacement conforme ». La version de remplacement conforme est définie comme suit :

version de remplacement conforme

version qui

  1. se conforme au niveau désigné, et

  2. fournit toutes les informations similaires et les mêmes fonctionnalités dans la même langue, et

  3. est aussi à jour que le contenu non conforme, et

  4. pour laquelle au moins l'une des affirmations suivantes est vraie :

    1. la version conforme peut être atteinte à partir de la page non conforme via un mécanisme compatible avec l'accessibilité, ou

    2. la version non conforme peut être atteinte seulement à partir de la version conforme, ou

    3. la version non conforme peut être atteinte seulement à partir d'une page conforme qui fournit aussi un mécanisme pour atteindre la version conforme.

Note 1 : dans cette définition, « peut être atteinte seulement » signifie qu'il y a un mécanisme, comme une redirection conditionnelle, qui empêche un utilisateur « d'atteindre » (de charger) la page non conforme à moins que l'utilisateur ne vienne justement de la version conforme de cette même page.

Note 2 : la version de remplacement n'a pas besoin d'être appariée page par page avec la version originale (par exemple la version de remplacement conforme peut se présenter en plusieurs pages).

Note 3 : si des versions sont proposées dans plusieurs langues, une version de remplacement conforme est donc requise pour chacune de ces langues.

Note 4 : des versions de remplacement peuvent aussi être fournies afin d'accommoder différents environnements technologiques ou différents groupes d'utilisateurs. Chaque version devrait être aussi conforme que possible. Une version devrait être entièrement conforme afin de satisfaire à l'exigence de conformité 1.

Note 5 : la version de remplacement conforme n'a pas besoin d'être située dans le périmètre de conformité ni même sur le même site Web tant qu'elle est aussi librement disponible que la version non conforme.

Note 6 : une version de remplacement ne devrait pas être confondue avec un contenu additionnel qui s'ajoute à la page originale pour en améliorer la compréhension.

Note 7 : permettre la configuration des préférences de l'utilisateur à l'intérieur du contenu afin de produire une version conforme est un mécanisme acceptable pour atteindre une autre version tant que la méthode utilisée pour configurer les préférences est compatible avec l'accessibilité.

Cela garantit que tous les renseignements et toutes les fonctionnalités qui se trouvent sur les pages intérieures du périmètre de conformité sont disponibles sur des pages Web conformes.

Pourquoi autoriser des versions de remplacement ?

Pourquoi les WCAG autorisent-elles des versions de remplacement conformes des pages Web à inclure dans les déclarations de conformité ? Pourquoi inclure des pages qui ne satisfont pas les critères de succès pour un niveau de conformité dans la déclaration du périmètre de conformité ?

  • Parfois, les pages utilisent des technologies qui ne sont pas encore compatibles avec l'accessibilité. Quand une nouvelle technologie apparaît, la compatibilité avec les technologies d'assistance peut être encore manquante, ou peut être disponible seulement pour certains groupes cibles. Aussi, les auteurs peuvent ne pas être en mesure de s'appuyer sur ou de dépendre de ces nouvelles technologies pour tous les utilisateurs. Toutefois, il peut y avoir d'autres avantages à utiliser les nouvelles technologies, par exemple, de meilleures performances, un plus large éventail de modalités disponibles, etc. L'exigence d'une version de remplacement permet aux auteurs d'inclure des pages dans leur site Web en offrant une page de remplacement accessible utilisant les technologies qui sont compatibles avec l'accessibilité. Les utilisateurs pour lesquels la nouvelle technologie est suffisamment compatible obtiennent les avantages de la nouvelle version. Les auteurs qui attendent le développement de la compatibilité avec l'accessibilité peuvent satisfaire aux critères de succès dès maintenant grâce à la page présentant la version de remplacement, et travailler avec l'autre page pour bâtir l'accès futur lorsque la compatibilité avec les technologies d'assistance (TA) sera disponible.

  • Pour diverses raisons, il peut être impossible de modifier certains contenus sur une page Web. Par exemple

    • Il peut être crucial d'inclure une copie visuelle exacte d'un document pour des raisons juridiques ou historiques ;

    • La page Web peut faire partie d'un site, mais le propriétaire du site peut ne pas avoir le droit de modifier le contenu de la page originale ;

    • La compagnie peut ne pas être légalement autorisée à supprimer ou modifier de quelque façon, quelque chose qui a déjà été affiché.

    • Un auteur peut ne pas avoir l'autorisation de modifier un document appartenant à un autre département, organisme ou société.

  • Parfois, la meilleure expérience pour les utilisateurs ayant certains types de limitation fonctionnelle est fournie en adaptant une page Web spécifique pour répondre à cette limitation. Dans une telle situation, il peut ne pas être possible ou pratique de faire une page Web adaptée à toutes les limitations en satisfaisant tous les critères de succès. L'exigence d'une version de remplacement permet d'inclure des pages spécialisées dans une déclaration de conformité tant qu'il y a une page présentant une version de remplacement entièrement conforme.

  • Beaucoup de sites qui sont commis à l'accessibilité ont de grandes quantités de documents patrimoniaux. Bien que l'information ait été mise à disposition dans des formats accessibles, il y aura des résistances institutionnelles significatives et des obstacles importants de procédure à la suppression massive de ces fichiers. Certaines organisations, en particulier les organismes gouvernementaux, donnent la priorité aux processus axés sur les imprimés traditionnels. Même si ces organismes sont adaptés à la publication sur le Web et reconnaissent la nécessité des formats accessibles, ils gardent encore une mentalité de papier et insistent souvent sur des formats conçus pour la copie papier comme « première » version (même pour des documents qui ne seront jamais « publiés » autrement qu'en version électronique). Bien que le groupe de travail estime que ces approches devraient être obsolètes il n'a pas le sentiment qu'elles pourraient être interdites, tant que des versions accessibles sont facilement disponibles.

Une préoccupation lors de l'autorisation de pages Web qui ne satisfont pas les critères de succès est que les personnes en situation de handicap qui rencontrent ces pages non conformes ne soient pas en mesure d'accéder à leur contenu, et ne soient pas capables de trouver la « version de remplacement conforme ». Un élément clé de la disposition concernant les versions de remplacement est donc la capacité à trouver la page conforme (la version de remplacement) de la page non conforme lorsque cette page est rencontrée. En conséquence, l'exigence de conformité qui permet les pages de remplacement exige aussi que les utilisateurs disposent d'une façon de trouver la version accessible parmi les autres versions.

Notez que le fait de fournir une version de remplacement est une option de repli pour la conformité aux WCAG et que la méthode préférée pour la conformité est de rendre l'ensemble du contenu directement accessible.

Techniques pour fournir une version de remplacement conforme

La chose la plus importante pour offrir une version de remplacement conforme est de fournir un mécanisme permettant de la trouver à partir de la version non conforme. Un certain nombre de méthodes différentes ont été recensées puisque certaines techniques particulières ne sont pas toujours possibles pour des technologies ou des situations spécifiques. Par exemple, si l'auteur a le contrôle du serveur, il y a des techniques puissantes qui permettront aux utilisateurs d'avoir toujours le choix à l'avance. Dans de nombreux cas cependant, l'auteur peut ne pas avoir le contrôle des services sur son serveur Web. Dans ces cas, d'autres techniques sont prévues. Un lien sur la page non conforme est une autre technique puissante, mais les liens hypertextes ne sont pas pris en charge par toutes les technologies non conformes.

Voici les techniques qui ont été identifiées à ce jour. Nous prévoyons que d'autres techniques seront également développées avec le temps et elles seront ajoutées ici à mesure qu'elles seront connues et que la compatibilité de ces approches avec les agents utilisateurs y compris les technologies d'assistance pourra être démontrée. Par exemple, un développeur d'une nouvelle technologie Web qui n'est pas compatible avec certaines technologies d'assistance pourrait intégrer une fonctionnalité qui permettrait à cette technologie de présenter automatiquement aux utilisateurs un lien vers une version de remplacement.

Techniques suffisantes pour fournir une version de remplacement conforme à une page Web

Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour fournir une version de remplacement conforme.

  1. G136 : Au début d'une page Web non conforme, fournir un lien pointant vers une version de remplacement conforme (en anglais)

  2. G190 : Pour un objet non conforme, fournir un lien adjacent ou associé vers une version de remplacement conforme (en anglais)

  3. C29 : Utiliser un changeur de style pour fournir une version de remplacement conforme (en anglais) (CSS)

  4. SVR2 : Utiliser .htaccess pour s'assurer que la seule façon d'accéder à un contenu non conforme est à partir du contenu conforme (en anglais) (SERVER)

  5. SVR3 : Utiliser un référent HTTP pour s'assurer que la seule façon d'accéder à un contenu non conforme est à partir du contenu conforme (en anglais) (SERVER)

  6. SVR4 : Permettre à l'utilisateur de configurer ses préférences pour la présentation des versions de remplacement conformes (en anglais) (SERVER)

Échecs fréquents identifiés par le groupe de travail
Techniques (recommandées) supplémentaires pour fournir une version de remplacement conforme à une page Web
  • Fournir des liens réciproques entre les versions conformes et non conformes (lien à venir)

  • Exclure les contenus non conformes des résultats de recherche (lien à venir)

  • Utiliser la négociation de contenu (lien à venir)

  • Ne pas afficher un contenu qui dépend des technologies qui ne sont pas compatibles avec l'accessibilité lorsque cette technologie est désactivée ou qu'elle n'est pas prise en charge (lien à venir)

  • Utiliser les métadonnées pour permettre de localiser la version de remplacement conforme à partir de l'URI d'une page non conforme (lien à venir)

Exemples de versions de remplacement conformes
  • Un site Intranet avec des versions multiples.

    Une grande entreprise craint que l'utilisation de nouvelles technologies Web sur un site intranet puisse limiter sa capacité à répondre aux besoins des divers bureaux qui ont des bases technologiques différentes et aux employés individuels qui utilisent une grande variété d'agents utilisateurs et de technologies d'assistance. Pour répondre à ces préoccupations, la société a créé une version de remplacement du contenu qui satisfait à tous les critères de succès de niveau A en utilisant un ensemble plus limité d'utilisations des technologies Web compatibles avec l'accessibilité. Les deux versions sont liées réciproquement.

  • Un site d'information assurant la rétrocompatibilité.

    Un site d'information couvre une grande variété de sujets et veut permettre aux visiteurs de trouver rapidement les sujets qu'ils recherchent. Pour ce faire, le site a mis en place un système de menu interactif qui est seulement pris en charge dans la version la plus récente de deux agents utilisateurs populaires. Pour s'assurer que les visiteurs qui n'utilisent pas ces agents utilisateurs spécifiques sont encore capables d'utiliser efficacement le site, un mécanisme de navigation qui ne dépend pas du système de menu interactif est présenté aux agents utilisateurs qui ne sont pas compatibles avec la nouvelle technologie.

Comprendre « page Web »

La définition de page Web est ;

page Web

une ressource autonome obtenue depuis un URI unique grâce au protocole HTTP, accompagnée de toutes les autres ressources utilisées dans la restitution ou conçues pour être restituées simultanément par un agent utilisateur

Note 1 : bien que toutes les « autres ressources » seraient restituées avec la ressource primaire, elles ne sont pas nécessairement restituées simultanément.

Note 2 : à des fins de conformité avec ces règles, une ressource doit être autonome à l'intérieur du périmètre de conformité pour être considérée comme une page Web.

Exemple 1 : une ressource Web incluant toutes les images et médias liés.

Exemple 2 : un programme Web de courrier électronique (Webmail) développé à l'aide d'AJAX (Asynchronous JavaScript and XML, JavaScript asynchrone et XML). Le programme réside intégralement à l'adresse http://exemple.com/mail, mais comprend une boîte de réception, un carnet d'adresses et un calendrier. Des liens et des boutons permettent d'afficher la boîte de réception, les contacts ou le calendrier, mais ne changent pas globalement l'URI de la page.

Exemple 3 : un site portail personnalisable, dans lequel les utilisateurs peuvent choisir le contenu à afficher à partir d'un ensemble de modules de contenu.

Exemple 4 : quand on saisit « http://shopping.exemple.com/ » dans son navigateur, on entre dans un environnement commercial animé et interactif dans lequel on se déplace visuellement dans une boutique, retirant les produits directement depuis les rayons pour les placer dans un panier d'achats face à soi. Cliquer sur un produit déclenche une démonstration avec la fiche technique juste à côté. Cela peut être un site Web à page unique ou simplement une page à l'intérieur d'un site Web.

Il est important de noter que, dans ce standard, le terme « page Web » va plus loin que la notion de page HTML statique. Le terme « page Web » est utilisé dans ces règles pour les rendre plus faciles à comprendre. Mais le terme a pris une signification plus large avec l'évolution des technologies pour englober un large éventail de technologies, dont beaucoup « ne ressemblent pas du tout à des pages ». Cela inclut les pages Web de plus en plus dynamiques qui apparaissent sur le Web, notamment les « pages » qui peuvent présenter une communauté virtuelle interactive complète. Par exemple, le terme « page Web » peut inclure une expérience immersive, interactive, proche du cinéma, pouvant être trouvée sur une seule URI.

Comprendre « équivalent textuel »

Un équivalent textuel est un texte qui est utilisé à la place du contenu non textuel pour ceux qui ne peuvent pas voir ce contenu non textuel. Un contenu non textuel peut inclure des choses telles que les tableaux, les graphiques, les applets, les fichiers audio, etc. Les gens qui ne peuvent pas voir par exemple, ne seraient pas en mesure de voir les informations présentées dans un tableau ou un graphique. Un équivalent textuel est donc prévu afin de permettre à l'utilisateur d'être en mesure de convertir l'information (le texte) en paroles. À l'avenir, avoir l'information en texte permettra aussi de traduire l'information en langue des signes, en images, ou dans une formulation simplifiée.

Pour que les personnes en situation de handicap soient en mesure d'utiliser ce texte - le texte doit être « déterminable par un programme informatique ». Cela signifie que le texte doit pouvoir être lu et utilisé par les technologies d'assistance (et les fonctionnalités d'accessibilité des navigateurs) que les personnes en situation de handicap utilisent.

Il doit aussi être possible pour les personnes utilisant les technologies d'assistance de trouver ces équivalents textuels quand ils rencontrent un contenu non textuel qu'ils ne peuvent pas utiliser. Pour ce faire, nous disons que le texte doit être « associé par programmation » avec le contenu non textuel. Cela signifie que l'utilisateur doit être en mesure d'utiliser sa technologie d'assistance pour trouver l'équivalent textuel (qu'il peut utiliser) quand il arrive à un contenu non textuel (qu'il ne peut pas utiliser).

Mots clés

conformité

satisfaire à toutes les exigences d'une norme ou d'un standard donné, d'une règle ou d'une spécification

processus

séries d'actions de l'utilisateur dont l'enchaînement est nécessaire à l'accomplissement d'une tâche

Exemple 1 : utilisation réussie par l'utilisateur, sur un site de vente, d'un enchaînement de pages Web permettant de voir différents produits, des prix et des offres, de sélectionner des produits, de soumettre une commande, de fournir les informations d'envoi et de paiement.

Exemple 2 : une page permettant de créer un compte utilisateur nécessitant l'accomplissement d'un test de Turing avant de pouvoir accéder à cette page de formulaire de création de compte.

dépendre (technologies)

le contenu ne serait pas conforme si cette technologie est inactivée ou si elle n'est pas compatible

satisfait à un critère de succès

le critère de succès ne se révèle pas « faux » lors de l'évaluation de la page

technologie Web

mécanisme pour encoder les instructions devant être restituées, jouées ou exécutées par les agents utilisateurs

Note 1 : tel qu'employés dans ces règles, l'expression « technologie Web » et le mot « technologie » (utilisé seul) désignent les technologies relatives aux contenus Web.

Note 2 : les technologies relatives aux contenus Web comprennent les langages de balisage, les formats de données ou les langages de programmation que les auteurs sont amenés à utiliser seuls ou combinés pour créer des expériences pour l'utilisateur final qui vont de pages Web statiques jusqu'à des présentations multimédia synchronisées, en passant par des applications Web dynamiques.

Exemple : on compte parmi les exemples les plus fréquents de technologies Web : HTML, CSS, SVG, PNG, PDF, Flash et JavaScript.


Annexe A Comment faire référence aux WCAG 2.0 dans d'autres documents

Veuillez noter que le texte suivant peut être inséré dans vos propres documents pour faire référence aux WCAG 2.0.

Références à titre d'information

Lorsque vous faites référence aux WCAG 2.0 à titre d'information, vous pouvez utiliser le format suivant :

Règles pour l'accessibilité des contenus Web version 2.0, recommandation XX mois année du W3C World Wide Web Consortium (http://www.w3.org/TR/200X/REC-WCAG20-20081211/, dernière version http://www.w3.org/TR/WCAG20/)


Lorsque vous faites référence aux WCAG 2.0 dans un autre standard à l'aide d'une formulation de type « devrait »

Lorsque vous faites référence aux WCAG 2.0 à l'aide d'une formulation de type « devrait » dans un standard (ou une recommandation dans un document légal), l'ensemble des WCAG 2.0 devrait alors être mentionné. Cela signifierait que les trois niveaux des WCAG 2.0 doivent être pris en compte, mais qu'aucun d'eux n'est obligatoire. Le format pour faire référence aux WCAG 2.0 dans une formulation de type « devrait » est donc :

Règles pour l'accessibilité des contenus Web version 2.0, recommandation XX mois année du W3C World Wide Web Consortium (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)


Faire référence aux WCAG 2.0 dans un autre standard avec la formulation « peut ou doit »

Lorsque vous citez les WCAG 2.0 comme étant obligatoires (ex. formulation de type peut ou doit dans un standard ou un document légal), la référence doit inclure les parties spécifiques des WCAG 2.0 que vous avez l'intention de rendre obligatoires. Lorsque vous faites référence aux WCAG 2.0 de cette manière, les règles suivantes s'appliquent :

  1. La conformité à n'importe quel niveau des WCAG 2.0 exige que tous les critères de succès de niveau A soient satisfaits. Il ne peut y avoir de références à la conformité aux WCAG 2.0 pour un sous-ensemble du niveau A.

  2. Au-delà du niveau A, la référence à « peut ou doit » peut inclure n'importe quel sous-ensemble sélectionné du niveau AA ou du niveau AAA. Par exemple, « Satisfaire tous les critères de succès du niveau A et [une liste de quelques critères de succès spécifiques du niveau AA et du niveau AAA] ».

  3. Si la conformité au niveau AA des WCAG 2.0 est spécifiée, alors tous les critères de succès de niveau A et de niveau AA doivent être satisfaits.

  4. Si la conformité au niveau AAA des WCAG 2.0 est spécifiée, alors tous les critères de succès de niveau A, de niveau AA et de niveau AAA doivent être satisfaits.

    Note 1 : il n'est pas recommandé d'exiger une politique générale de conformité au niveau AAA pour l'intégralité des sites car, pour certains contenus, il n'est pas possible de satisfaire à tous les critères de succès de niveau AAA.

    Note 2 : les ensembles de critères de succès définis dans les WCAG 2.0 sont interdépendants et chaque critère de succès s'appuie sur les définitions des autres, de sorte que cela peut ne pas être évident à la première lecture. Toute sélection d'un ensemble de critères de succès doit comprendre tous ceux du niveau A.


Exemples

Pour ne citer que les critères de succès de niveau A (conformité au niveau Simple A) :

Règles pour l'accessibilité des contenus Web version 2.0, recommandation XX mois année du W3C World Wide Web Consortium, critères de succès du niveau A. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)

Pour citer les critères de succès de niveau A et AA (conformité au niveau Double A) :

Règles pour l'accessibilité des contenus Web version 2.0, recommandation XX mois année du W3C World Wide Web Consortium, critères de succès du niveau A et AA. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)

Pour citer les critères de succès de niveau A et une sélection de critères de succès de niveau AA et AAA :

Règles pour l'accessibilité des contenus Web version 2.0, recommandation XX mois année du W3C World Wide Web Consortium, critères de succès du niveau A plus les critères de succès 1.x.x, 2.y.y ... 3.z.z. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)

Exemples de référence aux WCAG 2.0 dans une formulation de type « peut ou doit » :

Tout contenu Web disponible publiquement sur les sites Web peut être conforme aux Règles pour l'accessibilité des contenus Web version 2.0, recommandation XX mois année du W3C World Wide Web Consortium, critères de succès du niveau A plus les critères de succès 1.2.3, 2.4.5-6, 3.1.2. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)


Faire référence à du contenu provenant des documents d'accompagnement des WCAG

Les Techniques, qui sont énumérées dans Comprendre les WCAG 2.0 et décrites dans d'autres documents d'accompagnement, ne font pas partie de la recommandation normative des WCAG 2.0 et ne doivent pas être citées en utilisant les citations des WCAG 2.0 elles-mêmes. Les références aux Techniques dans les documents d'accompagnement doivent être citées séparément.

Les Techniques peuvent être citées d'après le document de la technique lui-même ou d'après le document maître des Techniques des WCAG 2.0. Par exemple, la technique « Utiliser l'attribut alt sur l'élément img » peut être citée comme

« Utiliser l'attribut alt sur l'élément img », note du W3C World Wide Web Consortium. (URI : {URI de la technique})

ou

W3C World Wide Web Consortium (200x) : WCAG 2.0 Techniques HTML (URI : {URI des Techniques HTML}).

Les techniques ne sont pas conçues pour être mentionnées comme « obligatoires » dans aucun standard ou document légal. Les standards et les documents légaux ne doivent rendre aucune technique spécifique obligatoire, même s'il peut être décidé de recommander une technique.


Annexe B Documenter la compatibilité avec l'accessibilité pour l'utilisation d'une technologie Web

La documentation de la compatibilité avec l'accessibilité pour l'utilisation d'une technologie Web fournit les informations nécessaires pour déterminer s'il est possible de répondre aux critères de succès des WCAG 2.0 pour un environnement particulier.

La documentation de la compatibilité avec l'accessibilité pour l'utilisation d'une technologie Web comprend les informations suivantes :

Les environnements cibles sont définis par les agents utilisateurs et les technologies d'assistance disponibles pour ses utilisateurs. La documentation de la compatibilité avec l'accessibilité implique une compréhension détaillée de la manière d'utiliser les fonctionnalités d'une technologie pour satisfaire aux critères de succès, et aussi des agents utilisateurs et des technologies d'assistance. Pour ces raisons, les vendeurs et développeurs des technologies Web et des agents utilisateurs sont encouragés à fournir ces informations à propos de la compatibilité de leurs produits avec l'accessibilité. De même, les développeurs et les vendeurs de technologies d'assistance sont encouragés à fournir ces informations à propos des façons d'utiliser les technologies Web qui sont compatibles avec leurs produits. Les auteurs n'auraient besoin de documenter les façons d'utiliser une technologie compatible avec l'accessibilité que si aucune documentation fiable n'est disponible par les vendeurs ou les groupes de testeurs pour ces utilisateurs.

Pour un environnement contrôlé comme le lieu de travail d'une entreprise, les agents utilisateurs et technologies d'assistance disponibles peuvent être un ensemble spécifique de versions d'agents utilisateurs sur un ensemble spécifique de plateformes. Afin de déterminer si l'utilisation d'une technologie Web est compatible avec l'accessibilité dans un environnement cible, un auteur vérifie que les agents utilisateurs et les technologies d'assistance disponibles sont dans l'ensemble des agents utilisateurs et des technologies d'assistance compatibles listés pour cette utilisation dans la documentation sur la compatibilité avec l'accessibilité.

Pour un environnement cible comme l'internet, les auteurs peuvent devoir considérer un plus large éventail d'agents utilisateurs y compris des versions plus anciennes, et sur une plus grande variété de plateformes.

Les environnements utilisant différentes langues sont des environnements cibles différents. Par exemple, les façons compatibles avec l'accessibilité d'utiliser des technologies pour un environnement en langue anglaise peuvent différer de celles pour un environnement en langue arabe, puisqu'il peut y avoir différents agents utilisateurs et technologies d'assistance compatibles avec ces langues.

La documentation comprend des informations spécifiques à une version à propos de toutes les technologies d'assistance et de tous les agents utilisateurs et de la façon dont ils interagissent les uns avec les autres. Si la compatibilité de ces agents utilisateurs est similaire, il sera simple pour un auteur de décider si une façon documentée d'utiliser une technologie est compatible avec l'accessibilité. Si les usages compatibles sont différents dans différentes versions, les auteurs peuvent uniquement dépendre des usages compatibles dans les versions disponibles pour leurs utilisateurs en déterminant la compatibilité avec l'accessibilité.

Si la façon d'utiliser une technologie ne dépend pas de la conformité, l'absence de compatibilité avec l'accessibilité pour cet usage n'empêche pas la conformité de la page Web. Ainsi, si l'usage non supporté n'a pas lieu dans le contenu, ou s'il existe une version conforme de ce contenu, la page Web reste conforme. Par exemple, le manque de compatibilité avec l'accessibilité de contrôles interactifs d'une technologie Web n'empêcherait pas l'utilisation de la technologie Web pour un contenu non interactif compatible avec l'accessibilité.

Annexe C Comprendre les métadonnées

Cette section traite des techniques de métadonnées qui peuvent être employées pour satisfaire aux critères de succès des WCAG 2.0. Pour plus d'informations sur les métadonnées, voir les ressources ci-dessous.

Au niveau le plus élémentaire, les métadonnées sont des données sur les données et sont utilisées à la fois pour décrire et retrouver des ressources.

Les métadonnées constituent un puissant outil pouvant être utilisé pour décrire des pages Web et des composants accessibles dans les pages Web, ainsi que pour associer entre elles des versions alternatives de contenus. À leur tour, ces descriptions permettent aux utilisateurs de localiser les informations particulières dont ils ont besoin ou qu'ils préfèrent.

Conjointement aux WCAG, les métadonnées peuvent avoir plusieurs rôles dont :

  1. Les métadonnées peuvent être employées pour associer des versions alternatives de pages Web conformes avec des pages Web qui ne le sont pas, afin de permettre aux utilisateurs de trouver la version alternative conforme lorsqu'ils arrivent sur une page non conforme qu'ils ne peuvent utiliser.

  2. Les métadonnées peuvent être utilisées pour localiser et également décrire des pages alternatives là où plusieurs versions d'une même page ont été développées, en particulier lorsque les pages alternatives ont été optimisées pour des personnes ayant différents types de limitations. L'utilisateur peut se servir des métadonnées à la fois pour localiser les versions alternatives et pour identifier les caractéristiques des versions alternatives afin de trouver celle qui correspond le mieux à ses besoins.

  3. En plus d'être utilisées pour l'intégralité des pages (comme indiqué ci-dessus aux points 1 et 2), les métadonnées peuvent être utilisées pour décrire des versions alternatives de sous-composants d'une page. Là encore, les métadonnées peuvent être utilisées pour localiser une version alternative d'un composant d'une page ainsi que pour obtenir des descriptions des versions alternatives (s'il en existe plusieurs) afin que l'utilisateur détermine celle qui convient le mieux à ses besoins.

Ressources sur les métadonnées

Les métadonnées descriptives fournissent souvent des valeurs provenant d'un vocabulaire défini et reconnu tel que le sujet de la ressource ou sa date de publication et sont interprétables par la machine - un logiciel capable de comprendre le schéma de métadonnées utilisé peut effectuer des tâches qui ne pourraient pas l'être autrement. Typiquement, un objet possédant des métadonnées, peut avoir une ou plusieurs de ces métadonnées descriptives.

Parmi les spécifications (schémas) de métadonnées connues on trouve :

Des outils sont disponibles pour fournir des descriptions de ressources, ou celles-ci peuvent être fournies manuellement. Plus les métadonnées peuvent être créées et collectées facilement, à la création de la ressource ou à sa publication, plus le processus est efficace et est en mesure de se dérouler.

Citons par exemple :

Parmi les implémentations de métadonnées pour l'accessibilité, citons :


Annexe D Références

ANSI-HFES-100-1988
ANSI/HFS 100-1988, American National Standard for Human Factors Engineering of Visual Display Terminal Workstations – standard national américain pour des postes de travail avec affichage visuel pour les ergonomes, Section 6, pp. 17-20.
ARDITI
Arditi, A. (2002). Effective color contrast: designing for people with partial sight and color deficiencies. New York, Arlene R. Gordon Research Institute, Lighthouse International. – Contraste de couleurs efficace : développer pour les personnes ayant une vision partielle et des limitations de perception des couleurs. Également consultable à l'adresse : http://www.lighthouse.org/color_contrast.htm.
ARDITI-FAYE
Arditi, A. et Faye, E. (2004). Monocular and binocular letter contrast sensitivity and letter acuity in a diverse ophthalmologic practice. – Sensibilité au contraste de lettres monoculaire et binoculaire et acuité des lettres dans une pratique ophtalmologique diverse : supplément de la revue Optometry and Vision Science, 81 (12S), 287.
ARDITI-KNOBLAUCH
Arditi, A. et Knoblauch, K. (1994). Choosing effective display colors for the partially-sighted. – Choisir des couleurs d'affichage efficaces pour les personnes ayant une malvoyance. Society for Information Display International Symposium Digest of Technical Papers, 25, 32-35.
ARDITI-KNOBLAUCH-1996
Arditi, A. et Knoblauch, K. (1996). Effective color contrast and low vision. – Contrastes de couleurs efficaces et malvoyance. Dans B. Rosenthal et R. Cole (Eds.) Functional Assessment of Low Vision. Évaluation fonctionnelle de la basse vision. St. Louis, Mosby, 129-135.
CAPTCHA
The CAPTCHA Project, Université Carnegie Mellon. Le projet est en ligne à l'adresse : http://www.captcha.net.
EPFND
Des experts publient des recommandations pour protéger le public de crises provoquées par la télévision / les jeux vidéos. Une copie de la norme est consultable à l'adresse : http://www.epilepsyfoundation.org/aboutus/pressroom/pr20050919.cfm.
GITTINGS-FOZARD
Gittings, NS et Fozard, JL (1986). Age related changes in visual acuity. – Changements d'acuité visuelle dus à l'âge. Experimental Gerontology, 21(4-5), 423-433.
HARDING-BINNIE
Harding G. F. A. et Binnie, C.D., Independent Analysis of the ITC Photosensitive Epilepsy Calibration Test Tape – Analyse indépendante pour tester l'épilepsie photosensible. 2002.
HEARING-AID-INT
Levitt, H., Kozma-Spytek, L., & Harkins, J. (2005). In-the-ear measurements of interference in hearing aids from digital wireless telephones. – Mesures intra-auriculaires des interférences dans les aides auditives, provoquées par les téléphones numériques sans fil. Séminaires sur l'audition, 26(2), 87.
IEC-4WD
IEC/4WD 61966-2-1: Colour Measurement and Management in Multimedia Systems and Equipment – Part 2.1: Default Colour Space – Mesure et gestion de la couleur dans des systèmes et équipements multimédia – partie 2.1 espace de couleur par défaut – sRGB. 5 mai 1998.
ISO-9241-3
ISO 9241-3, Exigences ergonomiques pour travail de bureau avec terminaux à écrans de visualisation (TEV) -- Partie 3 : Exigences relatives aux écrans de visualisation Amendement 1.
I18N-CHAR-ENC
« Tutoriel : Character sets & encodings in XHTML, HTML and CSS, » – Tables de caractères et encodages en XHTML, HTML et CSS. R. Ishida, ed., Ce tutoriel est consultable en anglais à l'adresse : http://www.w3.org/International/tutorials/tutorial-char-enc/.
KNOBLAUCH
Knoblauch, K., Arditi, A. et Szlyk, J. (1991). Effects of chromatic and luminance contrast on reading – Effets sur la lecture des contrastes cromatiques et de luminosité. Journal of the Optical Society of America A, 8, 428-439.
LAALS
Bakke, M. H., Levitt, H., Ross, M., & Erickson, F. (1999). Large area assistive listening systems (ALS): Review and recommendations – analyse et recommandations pour les systèmes d'assistance auditive, applicables aux lieux de grandes dimensions) (Rapport final. NARIC Accession Number: O16430). Jackson Heights, NY: école pour les sourds de Lexington Centre de recherche pour la réhabilitation des sourds Engineering Center on Hearing Enhancement.
sRGB
"A Standard Default Color Space for the Internet - sRGB," – Un espace de couleur par défaut standard pour l'Internet- sRGB, M. Stokes, M. Anderson, S. Chandrasekar, R. Motta, eds., Version 1.10, 5 novembre 1996. Une copie de cet article est consultable à l'adresse : http://www.w3.org/Graphics/Color/sRGB.html.
UNESCO
UNESCO Classification internationale type de l'éducation, 1997. Une copie de la norme est consultable à l'adresse : http://www.uis.unesco.org/ev_fr.php?ID=3813_201ID2=DO_TOPIC. .
WCAG20
"Web Content Accessibility Guidelines 2.0," B. Caldwell, M Cooper, L Guarino Reid, et G. Vanderheiden, eds., Recommandation W3 du 12 décembre 2008, http://www.w3.org/TR/2008/REC-WCAG20-20081211. La traduction française agréée des WCAG est consultable à l'adresse : http://www.w3.org/Translations/wcag20-fr. La version la plus récente des WCAG 2.0 est consultable à l'adresse : http://www.w3.org/TR/WCAG20/