Le présent document est une traduction du document de travail "Directives pour l'accessibilité aux contenus Web 2.0", ébauche du 19 novembre 2004, réalisé par le groupe de travail des directives pour l'accessibilité aux contenus Web du W3C. Cependant, il ne s'agit pas de la version officielle en français. Seul le document original en anglais a valeur de référence. On peut l'obtenir à : http://www.w3.org/TR/2004/WD-WCAG20-20041119/.
Nota Bene : Le document original est une ébauche de ce que seront les WCAG 2.0 et ne remplace pas encore les Directives pour l'accessibilité aux contenus Web 1.0 (WCAG 1.0) qui constitue à l'heure actuelle la seule référence en la matière.
Cette traduction a été réalisée sous la coordination d'Éric Gateau avec la collaboration de Laure Denoix, François Palaci et Catherine Roy.
Date de traduction : 30 janvier 2005
Adresse du présent document : http://www.webaccessibilite.net/traduction/WD-WCAG20-20041119-FR.html
Page d'accueil du site : Web accessibilité
Des erreurs ont pu survenir malgré le soin apporté à ce travail.
Copyright © 2004 W3C® (MIT, ERCIM, Keio), Tous droits réservés. Consulter la notice de copyright pour les productions du W3C.
Copyright © 2004 W3C® (MIT, ERCIM, Keio), Tous droits réservés. Les règles de responsabilité, de nom de marque et d'utilisation des documents du W3C s'appliquent.
Le World Wide Web Consortium (W3C) a publié en mai 1999 les Directives pour l'accessibilité aux contenus Web (WCAG 1.0). Cette ébauche de la version 2.0 est construite sur la base des WCAG 1.0. Elles ont le même but : expliquer comment rendre les contenus Web accessibles aux personnes handicapées et définir des niveaux à atteindre en matière d'accessibilité. En intégrant les commentaires reçus au sujet des WCAG 1.0, cette ébauche de la version 2.0 met l'accent sur les directives. Elle essaie de rendre applicables ces directives à une très grande variété de technologies et d'utiliser des termes compréhensibles par un public plus large.
Ce paragraphe décrit le statut de ce document au moment de sa publication. D'autres documents risquent de rendre le présent document obsolète. Vous pouvez trouver une liste des publications du W3C en vigueur et de la dernière version en cours de ce rapport technique dans l'index des rapports techniques du W3C à l'adresse http://www.w3.org/TR/.
Ce document est établi par le Web Content Accessibility Guidelines Working Group (WCAG WG) (groupe de travail des directives pour l'accessibilité des contenus Web) pour montrer comment les WCAG peuvent être plus généralisées (moins spécifiques au HTML). Cette ébauche n'a pas encore fait l'objet d'un consensus au sein du groupe de travail des WCAG et n'a pas non plus entamé son processus au sein du W3C. En aucun cas cette ébauche ne remplace les WCAG 1.0.
Pour voir une liste des discussions en cours au sujet de cette ébauche, merci de vous référer à la liste Issue Tracking for WCAG 2.0 Working Draft (liste des discussions au sujet de l'ébauche des WCAG 2.0). Le document "History of Changes to WCAG 2.0 Working Drafts (historique des changements dans les WCAG 2.0) est également disponible.
La publication d'une ébauche n'implique pas l'aval des membres du W3C. Il s'agit d'un document de travail qui peut à tout moment être mis à jour, obsolète ou remplacé par d'autres documents. Il n'est pas approprié de citer ce document comme étant autre chose qu'un travail en cours. Une liste des recommandations et autres documents techniques en vigueur du W3C est disponible : current W3C Recommendations and other technical documents.
Le groupe de travail accueille bien volontiers les commentaires sur ce document à l'adresse suivante public-comments-wcag20@w3.org. Les archives de cette liste de discussion sont disponibles publiquement. Les archives de la liste de discussion du groupe de travail WCAG sont également disponibles publiquement.
Ce document a été réalisé conformément aux pratiques courantes en matière de brevets (Current Patent Practice) du 24 janvier 2002, amendé par la procédure de transition de la politique de brevetabilité (Patent Policy Transition Procedure) du W3C. Le groupe de travail maintient une liste publique de divulgation de brevets concernant ce document ; cette page expose également les instructions relatives à la divulgation d'un brevet. Quiconque aurait connaissance de l'existence d'un brevet susceptible de contenir une ou plusieurs revendications essentielles concernant cette spécification devrait divulguer cette information, conformément au chapitre 6 de la politique de brevetabilité du W3C.
Le présent document a été produit dans le cadre de la Web Accessibility Initiative du W3C. Les objectifs du Groupe de Travail sur les Directives sont expliqués dans la charte du groupe de travail. Le groupe de travail des WCAG fait partie du WAI Activités techniques.
Ce document expose les principes de conception permettant de créer des contenus Web accessibles. Si l'on ne tient pas compte de ces principes, des personnes handicapées peuvent ne pas être capables d'accéder aux contenus ou ne l'être qu'avec de grandes difficultés. Lorsque ces principes sont mis en œuvre, ils rendent également les contenus Web accessibles à divers outils de consultation tels que des téléphones, des assistants personnels, des bornes et des équipements en réseau. Rendre accessible des contenus à divers outils de consultation les rend également accessibles à différents types d'utilisateurs.
Les principes de conception exposés dans ce document représentent des concepts généraux qui s'appliquent à tout contenu Web. Ils ne sont pas spécifiques au HTML, au XML ou à quelque autre technologie. Cette approche a été retenue pour que les principes de conception puissent s'appliquer à différentes situations et technologies, y compris celles qui n'existent pas encore.
Pour faciliter la compréhension des directives et aider les utilisateurs à ne se concentrer que sur les parties dont ils ont besoin, les directives sont présentées comme un jeu de documents étroitement liés. Les informations sur les directives comptent trois niveaux.
Le niveau supérieur s'intitule "Directives pour l'accessibilité aux contenus Web 2.0". Il s'agit du document que vous êtes en train de lire. Ce document fournit :
Une introduction ;
Les quatre principes majeurs de l'accessibilité (Perceptible, Utilisable, Compréhensible et Robuste) ;
Les directives (au nombre total de 13, elles ne sont pas spécifiques à une ou plusieurs technologies) ;
Des critères de réussite (normatifs) et des définitions, avantages et exemples (tous non normatifs) pour chaque directive ;
Une annexe contenant des définitions, des références et d'autres informations utiles.
En plus des directives générales, une série de listes de contrôles spécifiques à une technologie sera disponible. Ces documents informeront sur les pratiques à mettre en œuvre, dans le cadre de l'utilisation de diverses technologies, pour satisfaire à l'ébauche des WCAG 2.0.
Note éditoriale : Ces listes de contrôle n'existent pas encore. À cette heure, le caractère normatif ou non des listes de contrôle n'est pas déterminé. Si les listes de contrôle sont non normatives, il sera plus facile de les mettre à jour. Si elles sont normatives, les modifications qui y seront apportées altèreront la définition de la conformité. Néanmoins, il peut s'avérer nécessaire de rendre les listes de contrôle normatives pour que les directives puissent être testées.
Les documents techniques contiendront des exemples de code, des captures d'écran et d'autres informations spécifiques à une technologie. Ces documents seront non normatifs. Ils présenteront différentes stratégies pour satisfaire aux exigences ainsi que les approches en vigueur les plus satisfaisantes quand elles existent. Les techniques documentées couvriront par exemple :
Le langage de balisage hypertexte (HTML) et le langage de balisage hypertexte extensible (XHTML) ;
Les scripts côté serveur ;
Les graphiques vectoriels adaptables (SVG) ;
Le langage d'intégration multimédia synchronisé (SMIL) ;
Le langage de balisage extensible (XML).
(Les éléments ci-dessus deviendront des liens actifs au fur et à mesure que les ébauches correspondantes seront publiées.)
Ces directives ont été rédigées pour répondre aux attentes de nombreux publics différents allant des décideurs aux gestionnaires en passant par les auteurs de contenus Web et les programmeurs. Tout a été fait pour rendre le document aussi lisible et pratique que possible tout en conservant l'exactitude et la clarté indispensables à une spécification technique. Pour les utilisateurs néophytes, la lecture des travaux du groupe de travail Education and Outreach de la Web Accessibility Initiative est vivement recommandée, et en particulier : Getting Started: Making a Web Site Accessible (Faire un site Web accessible, comment commencer).
De nombreux contenus Web sont créés à l'aide d'outils de conception. Souvent, ces outils déterminent la façon dont le contenu Web est implémenté, soit en appliquant directement une conception propre à l'outil ou en limitant les choix à la disposition du concepteur. Ces outils joueront donc un rôle important dans la création de contenus Web conformes aux directives pour l'accessibilité aux contenus Web. De même, nous incitons les concepteurs de sites à se familiariser avec les directives puisque cela les aidera à créer des contenus accessibles et que la prise en compte des directives par les outils de conception est variable d'un outil à l'autre.
Les développeurs d'outils de conception peuvent rendre leurs outils plus conformes aux directives d'accessibilité aux contenus Web en suivant les Authoring Tool Accessibility Guidelines (directives d'accessibilité des outils de conception).
Nous encourageons les utilisateurs et les acheteurs d'outils de conception à considérer la conformité aux Authoring Tool Accessibility Guidelines (directives d'accessibilité des outils de conception) comme un critère de sélection de ces outils.
Note éditoriale : Le groupe de travail sur les directives d'accessibilité des outils de conception a publié une ébauche des ATAG 2.0. Les références ci-dessus devront être mises à jour quand les ATAG 2.0 deviendront les recommandations en vigueur.
Ces directives couvrent un large éventail de difficultés et de recommandations pour rendre les contenus Web plus accessibles. Elles comprennent des recommandations pour rendre les contenus accessibles et utilisables par des personnes avec différentes déficiences. En général, les directives ne comprennent pas de recommandation standard d'utilisabilité, sauf lorsque ces dernières abordent des sujets ayant trait spécifiquement à l'accessibilité.
Cette ébauche des WCAG 2.0 est élaborée à partir des WCAG 1.0 et reflète les commentaires reçus depuis la publication des WCAG 1.0 en mai 1999. Bien que l'accessibilité fasse l'objet de la même approche dans les versions 1.0 et 2.0, l'organisation et la structure du document sont différentes. Là où les WCAG 1.0 utilisent les directives pour regrouper les points de contrôle, cette ébauche des WCAG 2.0 utilise les directives pour regrouper les critères de réussite. Là où les WCAG 1.0 attribuent un niveau de priorité à un point de contrôle, cette ébauche des WCAG 2.0 classe un critère de réussite dans un niveau allant de 1 à 3.
De plus, les principes généraux de conception ont été reformulés pour s'appliquer à un large éventail de technologies, existantes et émergentes. L'ébauche des WCAG 2.0 ne contient pas d'obligation ou de technique relative à des implémentations spécifiques à une technologie ; elle contiendra par contre des liens vers des documents présentant les obligations, des exemples et des techniques spécifiques à une technologie (dès que ces documents seront plus stables).
Le groupe de travail sur les directives pour l'accessibilité des contenus Web œuvre à garantir que les organisations et individus qui utilisent actuellement les WCAG 1.0 (qui restent le document de référence à cette heure) seront capables de passer aisément aux WCAG 2.0. Pour plus d'informations sur les similarités et les différences entre les points de contrôle des WCAG 1.0 et les directives et critères de réussite des WCAG 2.0, merci de vous reporter à l'ébauche Mapping Between WCAG 1.0 and the WCAG 2.0 Working Draft (Comparatif entre les WCAG 1.0 et l'ébauche des WCAG 2.0).
Note éditoriale : hypothèse des technologies de référence
Dans son travail sur les WCAG 2.0, le groupe de travail des WCAG se débat sans cesse avec le rôle joué par les concepteurs de site et par les agents utilisateurs pour rendre les contenus Web accessibles aux personnes handicapées. Dans les WCAG 1.0, nous avons identifié les imperfections des agents utilisateurs et rédigé des directives en utilisant des phrases telles que : "tant que les agents utilisateurs..."
Aujourd'hui, une grande partie des problèmes persiste, mais, nous recherchons un mécanisme plus efficace pour les résoudre que la création de "directives temporaires de transition" ayant pour but de composer avec les imperfections des agents utilisateurs. Un moyen d'y arriver consisterait à écrire des directives en se basant sur l'hypothèse d'un agent utilisateur de référence. Actuellement, nous envisageons d'utiliser les agents utilisateurs conformes aux directives d'accessibilité des agents utilisateurs 1.0 (UAAG 1.0) comme référence pour les WCAG 2.0. Cela étant, cela signifierait que les WCAG 2.0 seraient écrites avec l'hypothèse que tous les utilisateurs possèdent un agent utilisateur conforme à tous les points de contrôle de priorité 1 des User Agent Accessibility Guideline 1.0 (UAAG 1.0) (directives d'accessibilité des agents utilisateurs 1.0). Ceci implique plusieurs choses. Par exemple, que les WCAG 2.0 supposeraient que les agents utilisateurs et les technologies d'assistance peuvent effectivement interagir avec les scripts.
À ce jour, il n'existe pas d'agent utilisateur conforme à tous les points de contrôle de priorité 1 des UAAG 1.0. Si les WCAG 2.0 prennent pour hypothèse que les agents utilisateurs sont conformes aux points de contrôle de priorité 1 des UAAG 1.0, il y aura une sorte de déficit entre le contenu Web conforme au WCAG 2.0 et les agents utilisateurs actuellement disponibles. Pour résoudre ce problème, nous proposons de prendre deux mesures.
Encourager fortement le développement d'agents utilisateurs conformes à tous les points de contrôle de priorité 1 des UAAG 1.0
Développer un ensemble de "techniques de réparation" qui pourraient être utilisées par les concepteurs désireux de créer des contenus non seulement conformes aux WCAG 2.0, mais aussi qui prennent en compte les manques des agents utilisateurs actuels.
Nous aimerions également travailler avec le User Agent Accessibility Guidelines Working Group (UAWG) (groupe de travail des directives d'accessibilité des agents utilisateurs) et le Authoring Tools Accessibility Guidelines Working Group (AUWG) (groupe de travail des directives d'accessibilité des outils de conception) afin d'établir un ensemble de stratégies que les fabricants d'agents utilisateurs pourraient intégrer aux agents utilisateurs afin d'aider à éviter les erreurs les plus communes des concepteurs.
Il en résulterait des WCAG 2.0 plus stables, ainsi qu'une meilleure intégration avec les UAAG pour marquer la part de responsabilité qui incombe à la technologie Web (agent utilisateurs contre contenu Web). Pour plus d'information, se référer aux Interdependent Components of Web Accessibility (composantes d'interdépendance de l'accessibilité du Web).
Le groupe de travail des WCAG analyse cette approche afin de mieux comprendre de quelle manière elle risque d'affecter les utilisateurs. Les directives et les critères de réussite de cette ébauche ne reflètent pas encore cette nouvelle direction. Le groupe de travail des WCAG vous invite à commenter cette approche et les discussions relatives à ce sujet.
Note éditoriale : Il y a plusieurs discussions en cours en ce qui concerne le schéma de conformité proposé. Cette section expose les grandes lignes du schéma de conformité utilisé tout au long de ce document. Les retours, commentaires et propositions sont encouragés.
Les critères de réussite relatifs à chaque directive sont organisés en trois niveaux :
Critères de réussite de niveau 1 :
Atteindre un niveau d'accessibilité minimal via le balisage, les scripts ou d'autres technologies qui interagissent avec les agents utilisateurs ou permettent d'accéder aux ressources, y compris les technologies d'assistance.
Peuvent raisonnablement s'appliquer à toutes les ressources Web.
Critères de réussite de niveau 2 :
Accroître l'accessibilité via une des solutions suivantes ou les deux :
En facilitant davantage la capacité des agents utilisateurs à fournir des contenus accessibles ;
En recommandant les contenus et/ou présentations directement accessibles sans exiger des utilisateurs ou de leurs agents utilisateurs de faire quoi que ce soit de différent qu'un utilisateur sans handicap.
Peuvent raisonnablement s'appliquer à toutes les ressources Web.
Critères de réussite de niveau 3 :
Aller au-delà des niveaux 1 et 2 pour accroître l'accessibilité directe et l'accessibilité étendue des agents utilisateurs.
Le groupe de travail pense que tous les critères de réussite doivent pouvoir être testés. Les tests peuvent être réalisés par des programmes informatiques ou par des personnes qui comprennent ces directives. Les tests réalisés par des personnes qui comprennent ces directives doivent donner les mêmes résultats, à contenu testé et critères de réussite identiques.
Note éditoriale : Pour faciliter les discussions sur les niveaux assignés à chaque critère, une note entre crochets est mentionnée à la fin de chaque critère. "[I]" (invisible) indique qu'un critère ne spécifie pas la manière dont l'information est présentée et "[V]" (visible) indique que la satisfaction du critère peut nécessiter qu'un concepteur présente le contenu de manière particulière.
Note :
Certaines directives ne comportent pas de critère de réussite de niveau 1
Toute conformité aux WCAG 2.0 nécessite que tous les critères de réussite de niveau 1 soient satisfaits pour toutes les directives.
La conformité aux WCAG 2.0 au niveau A signifie que tous les critères de réussite de niveau 1 sont satisfaits pour toutes les directives.
La conformité aux WCAG 2.0 au niveau AA signifie que tous les critères de réussite de niveau 1 et de niveau 2 sont satisfaits pour toutes les directives.
La conformité aux WCAG 2.0 au niveau AAA signifie que tous les critères de réussite de niveau 1, de niveau 2 et de niveau 3 sont satisfaits pour toutes les directives.
Le groupe de travail pense que les critères de réussite des 3 niveaux sont importants ou essentiels pour certains utilisateurs. C'est pourquoi les anciennes descriptions "accès impossible" pour le niveau A, "accès difficile" pour le niveau AA et "quelque peu difficile" pour le niveau AAA ne sont plus utilisées. À la place, nous définissons les 3 niveaux comme ci-dessus.
Toute déclaration de conformité doit au moins comporter les informations suivantes :
La version des directives auxquelles on déclare se conformer.
Une liste d'une ou plusieurs URIs ou formes d'URI identifiant les unités de livraison dont on déclare la conformité. Une ressource est conforme aux WCAG 2.0 à un niveau de conformité donné seulement si l'intégralité du contenu fourni par cette ressource y est conforme.
Note :
Si des représentations multiples peuvent être récupérées à partir d'une URI par négociation de contenu, la déclaration de conformité concernerait l'unité de livraison qui est retournée quand aucune négociation n'est conduite (à moins que le serveur ne renvoie une erreur dans cette situation, auquel cas une des formes négociées doit être conforme).
Note éditoriale : la question se pose de savoir si l'URI est une référence suffisamment spécifique à la ressource qu'on déclare conforme.
Le niveau de conformité déclaré
Note éditoriale : la question a été soulevée de savoir si les informations requises dans les points 1 à 3 devraient toutes être transmises dans l'entête HTTP ou d'une autre manière.
Le niveau de conformité d'une unité de livraison qui contient des unités composées est égal au plus bas niveau de conformité déclaré du contenu de l'unité de livraison et des unités composées qu'elle contient - y compris les déclarations d'unités agrégées.
Une ressource référencée par une URI est conforme aux WCAG 2.0 à un niveau de conformité donné seulement si l'intégralité du contenu fourni par cette ressource y est conforme. Par exemple, si la ressource fournit des informations récupérées d'une base de données en réponse à une requête d'utilisateurs, toutes les unités de livraison contenant de telles informations doivent remplir le critère de réussite des WCAG 2.0 au niveau auquel la conformité est déclarée. Il convient de remarquer qu'une exception se produit si la négociation de contenu est en œuvre et que l'agent utilisateur appelle une version du contenu qui n'est pas conforme aux WCAG 2.0 au niveau déclaré.
Note éditoriale : Nous sommes actuellement en train d'étudier comment gérer les unités composées dont l'origine est inconnue ou communautaire et qui sont créées à l'aide d'un outil d'agrégation. Si l'outil d'agrégation est conforme aux ATAG, peut-on invoquer cette conformité pour conclure que le contenu agrégé est conforme aux WCAG ?
La portée des déclarations de conformité peut être adaptée pour ne concerner que certaines parties d'un site Web. Toutefois, toute déclaration de conformité doit être reliée à une URI ou à un ensemble d'URIs. Il n'est pas permis d'adapter la portée pour exclure un type de contenu particulier d'un site (par exemple, les images ou les scripts) puisque ça reviendrait à permettre l'exclusion de critères individuels de réussite. Il est permis d'adapter la portée par URI pour exclure des sections d'un site afin que les concepteurs puissent établir des déclarations ne portant que sur certaines parties de celui-ci.
Les concepteurs ayant des contenus actuellement conformes aux WCAG 1.0 qui voudraient évoluer vers les WCAG 2.0 souhaiteront tirer profit des efforts d'accessibilité réalisés par le passé. Une déclaration de conformité adéquate pourrait leur permettre cette flexibilité. Par exemple, une déclaration de conformité pourrait comporter la mention suivante : "Les ressources créées ou modifiées avant le 24 avril 2003 sont conformes aux WCAG 1.0. Les ressources créées ou modifiées le 24 avril 2003 ou ultérieurement sont conformes aux WCAG 2.0. Si une unité de livraison est modifiée de manière significative, toute l'unité de livraison devrait être conforme aux WCAG 2.0."
Note éditoriale : sur certains points, il peut être plus facile de respecter l'ébauche des WCAG 2.0 que les recommandations des WCAG 1.0 tandis que d'autres critères peuvent être plus difficiles à satisfaire dans les WCAG 2.0 que dans les WCAG 1.0. Le groupe de travail sur les WCAG étudiera les différences entre la conformité aux WCAG 1.0 et aux WCAG 2.0 et proposera des conseils aux développeurs qui respectent actuellement les WCAG 1.0. Ces conseils pourraient esquisser un plan et fournir les informations nécessaires pour migrer des WCAG 1.0 aux WCAG 2.0. Ces conseils ne sont pas encore disponibles.
Globalement, le but est de créer des contenus Web perceptibles, utilisables et compréhensibles par la plus grande partie possible des utilisateurs, compatibles avec la grande diversité des technologies d'assistance, et ce aujourd'hui comme à l'avenir. Les principes de base sont :
Le contenu doit être perceptible ;
Les éléments d'interaction doivent être utilisables ;
Le contenu et les commandes doivent être compréhensibles ;
Le contenu doit être assez robuste pour fonctionner avec les technologies actuelles et celles à venir.
Les contenus Web accessibles profitent à plusieurs types de publics et pas seulement aux personnes handicapées. Dans le monde réel, les rampes d'accès sont utilisées par les cyclistes, par les personnes avec une poussette et par les personnes en fauteuil roulant. De la même manière, les contenus Web accessibles profitent à plusieurs types de personnes avec ou sans handicap. Par exemple, les personnes se trouvant temporairement dans des conditions gênantes, comme un environnement bruyant où elles ne peuvent que difficilement ou pas du tout entendre, ou des personnes qui conduisent et dont les yeux sont occupés, profiteraient d'un site accessible. De la même manière, un moteur de recherche pourra trouver une réplique célèbre dans un film si ce dernier est sous-titré.
Note :
Ces principes ne s'appliquent qu'aux contenus Web consultés par une personne humaine. Une base de données ou des métadonnées où les informations sont destinées à être utilisées par une autre machine, et qui ne nécessitent pas d'interface, ne font pas partie du champ d'application de ces directives.
Voici quelques exemples, qui ne constituent en aucun cas une liste exhaustive, de différents types de handicaps et des besoins associés :
Une personne ayant des difficultés auditives aura besoin d'une représentation visuelle des informations sonores.
Une personne ayant des difficultés visuelles aura besoin d'entendre ou de toucher (à travers le Braille ou des graphiques tactiles) un équivalent de l'information visuelle.
Une personne qui n'a pas la force de se mouvoir rapidement ou facilement aura besoin d'avoir le moins de mouvements possibles à faire et d'avoir autant de temps que nécessaire quand elle utilise une interface Web.
Une personne ayant des difficultés de lecture préfèrera peut-être entendre les informations à voix haute.
Si un contenu Web observe les principes de conception décrits dans ce document, les utilisateurs devraient pouvoir accéder à ce contenu en utilisant des méthodes adaptées et des technologies d'assistance. Il existe de nombreux outils que les personnes handicapées utilisent pour avoir accès aux contenus Web. Pour avoir des exemples plus précis sur la manière dont les personnes handicapées utilisent les contenus Web accessibles et inaccessibles, merci de lire "How people with disabilities use the Web" (Comment les personnes handicapées utilisent le Web).
Ces directives fournissent les règles de base pour créer des contenus Web accessibles. Ce document n'est pas destiné à fournir, aux personnes intéressées par cet apprentissage, les acquis nécessaires à la conception de contenus Web accessibles d'une manière effective ou complète. À cet effet, les lecteurs sont invités à se référer au groupe de travail Education and Outreach Working Group de la Web Accessibility Initiative.
Comment fournir des équivalents textuels au contenu fonctionnel. (Informatif)
Note : Pour le contenu multimédia, cela signifie qu'une description (comme mentionné dans le critère précédent) et qu'une transcription sont fournies.
Comment fournir des équivalents textuels au contenu qui véhicule une information.. (Informatif)
Comment fournir des équivalents textuels au contenu ayant pour but de créer une expérience sensorielle spécifique. (Informatif)
Comment fournir des équivalents textuels qui peuvent être ignorées par les technologies d'assistance. (Informatif)
Comment associer explicitement l'équivalent textuel au contenu non textuel. (Informatif)
Pour le contenu en direct uniquement audio ou uniquement vidéo comme par exemple une radio Internet ou une webcam, l'équivalent textuel décrit le but de la présentation ou un lien vers un contenu alternatif en temps réel est fourni. Par exemple pour une webcam qui filme la circulation routière, un compte rendu est fourni.
Note : Le contenu en temps réel n'implique pas des sous titres en temps réel.
Note éditoriale : Tout comme pour le point numéro 1 ci dessus, il semble nécessaire de différencier les contenus uniquement audio et uniquement vidéo afin d'éviter la confusion.
Comment fournir les descriptions des informations visuelles importantes dans le multimédia. (Informatif)
Discussions relatives à la directive 1.1 (équivalent textuel)
Les personnes non-voyantes, malvoyantes, qui ont un handicap cognitif ou qui ont des difficultés à lire le texte quelle qu'en soit la raison, pourront avoir le texte lu à voix haute grâce à une assistance technologique.
Les personnes sourdes, malentendantes ou qui ont des difficultés à comprendre une information auditive quelle qu'en soit la raison pourront lire le texte ou l'avoir traduit et représenté en langue des signes grâce à une assistance technologique.
Les personnes sourdes et non-voyantes pourront lire le texte en Braille.
Exemple 1 : Une image utilisée comme bouton.
L'icône d'une loupe est utilisée comme lien vers la page de recherche du site. Un lecteur d'écran identifie le bouton comme un lien et restitue le texte alternatif "recherche"
Exemple 2 : Un graphique représentant des données.
Un schéma est composé de barres pour comparer combien d'articles ont été vendus en juin, juillet et août. L'étiquette de texte est "schéma 1 - ventes en juin, juillet et août". La description longue identifie le type de graphique, fournit un résumé précis des données, comparable à celui disponible sur le graphique, et fournit les données dans un tableau.
Exemple 3 : L'enregistrement d'un discours.
Le lien vers un clip audio dit "discours du président à l'assemblée". Un lien vers une transcription textuelle est fourni juste après le lien vers le clip audio.
Exemple 4 : L'enregistrement d'une symphonie.
Le lien vers le fichier audio dit "5ème symphonie de Beethoven par l'orchestre philharmonique de Vienne".
Exemple 5 : Une animation qui illustre comme fonctionne le moteur d'une voiture.
Une animation montre comment fonctionne le moteur d'une voiture. Il n'y a pas de son et l'animation fait partie d'un tutorial qui décrit comment fonctionne un moteur. La seule chose nécessaire est une description de l'image. Extrait de "Comment fonctionne le moteur d'une voiture : combustion interne".
Note éditoriale : Exemples à développer : une radio en direct et une webcam en direct.
Note éditoriale : Bien qu'il y ait des exemples pour lesquels les sous-titres et les descriptions audio ne soient pas demandés, cette version de la directive 1.2 ne les différencie pas. A la place, la directive présume que les documents techniques fournissent plus de détails et que les personnes en charge de la politique détermineront clairement quand les sous-titres et les descriptions audio seront nécessaires.
Si un contenu est repris d'un autre média, les exigences d'accessibilité restent applicables.
Note éditoriale : Comment faire avec les présentations qui ne contiennent que de l'audio ou que de la vidéo et qui demandent aux utilisateurs d'interagir à des moments donnés de la présentation ? Comme il ne s'agit pas de multimédia, un critère pourrait être ajouté à la directive 1.1. Cependant, le besoin réside dans des alternatives synchronisées, c'est pourquoi un critère pourrait être ajouté à cette directive. Voir à ce sujet la discussion 1272.
Une transcription en langage des signes est fournie pour le contenu multimédia.
Des descriptions sonores prolongées sont fournies pour le contenu multimédia préenregistré.
Des descriptions audio sont fournies pour le contenu multimédia en direct.
Discussions relatives à la directive 1.2 (équivalent multimédia)
Les personnes sourdes ou malentendantes peuvent accéder à l'information auditive grâce aux sous-titres.
Les personnes non-voyantes ou malvoyantes ainsi que les personnes ayant des déficiences cognitives qui ont des difficultés à interpréter visuellement ce qui se passe bénéficient des descriptions auditives des informations visuelles.
Les personnes sans handicap bénéficient également des alternatives au média :
Les personnes dans un environnement bruyant ou avec le son éteint s'en remettent souvent aux sous-titres.
Les sous-titres aident beaucoup de gens à développer leur capacité à lire et à parler.
Les descriptions auditives fournissent une information visuelle aux personnes qui regardent momentanément ailleurs, par exemple en suivant des instructions vidéo et en regardant leurs mains.
Les sous-titres et les descriptions textuelles rendent possible l'indexation et la recherche de fichiers multimédias.
Exemple 1 : un film avec une description sonore.
Transcription du son basée sur les premières minutes de "Enseignement de l'évolution, étude de cas par Bonnie Chen" (copyright WGBH et Clear Blue Sky Productions, Inc.)
Description : Un titre, "Enseignement de l'évolution, étude de cas par Bonnie Chen". Maintenant, un enseignant montre des photographies.
Bonnie Chen : toutes ces photos ont été prises soit dans les Everglades ... aujourd'hui, il s'avère qu'il s'agit d'une espèce d'oiseau marcheur avec un bec comme ceci."
Description : elle donne à chacun deux lamelles de bois plates et fines.
Exemple 2 : un tutorial sous-titré.
Un clip vidéo montre comment faire un nœud. Le sous-titre dit "(musique)
Utiliser une corde pour faire des nœuds
Était une compétence importante
Pour les marins, les militaires et les bûcherons."
Extrait de formatage de transcription par Whit Anderson.
Note éditoriale : Exemples à développer : une animation avec de la musique qui contient des paroles, une présentation interactive et une animation avec de la musique.
Comment s'assurer que la structure et les relations dans le contenu peuvent être déterminées informatiquement. (Informatif)
Note éditoriale : Les concepts de "fiable" et de "standard" doivent être incorporés à la définition de "informatiquement".
Comment s'assurer que l'emphase peut être déterminée informatiquement. (Informatif)
Comment rendre l'information présentée en couleur disponible à travers le contexte ou le balisage. (Informatif)
Comment rendre l'information présentée en couleur disponible sans avoir à interpréter le balisage. (Informatif)
Discussions relatives à la directive 1.3 (séparation de la structure et du contenu)
La séparation du contenu et de la structure de la présentation permet au contenu Web d'être présenté différemment pour satisfaire aux besoins et aux contraintes des différents utilisateurs sans rien perdre de l'information ou de la structure. Par exemple une information qui était originellement prévue pour être présentée visuellement peut être présentée à travers la voix ou le Braille (texte).
Elle permet aussi de faciliter la mise en évidence automatique de la structure ou une navigation plus efficace.
Tout ceci peut bénéficier aux personnes avec des handicaps cognitifs, physiques, auditifs et visuels.
Note éditoriale : Ces exemples sont des améliorations par rapport aux versions précédentes, mais sont spécifiques au HTML. Ils seront généralisés dans les prochaines versions.
Exemple 1 : Un formulaire qui précise textuellement les champs obligatoires manquants.
Lorsqu'un utilisateur soumet un formulaire sans avoir renseigné tous les champs obligatoires, un message apparaît pour l'informer des champs manquants. Les champs manquants sont également indiqués en couleur pour aider les personnes avec des limitations cognitives à reconnaître les champs auxquels ils doivent prêter attention. Puisque le message est également disponible en texte les personnes qui ne peuvent pas distinguer les couleurs connaîtront également les champs qu'ils ont à corriger.
Exemple 2 : Un horaire de bus où les en-têtes sont associés aux cellules.
Une fiche horaire de bus est en fait un tableau où les arrêts sont listés verticalement et les différents bus effectuant le trajet horizontalement. Chaque cellule contient l'heure à laquelle le bus sera à un arrêt donné. Des balises structurelles sont utilisées pour associer chaque cellule à la fois avec l'arrêt et le trajet correspondant.
Exemple 3 : Un formulaire où les libellés des cases à cocher sont associés aux cases à cocher.
Dans un formulaire où les utilisateurs peuvent sélectionner différentes options en utilisant des cases à cocher, les libellés des cases à cocher sont associés aux cases à cocher. Cela profite à plusieurs types d'utilisateurs. Cela permet aux utilisateurs non-voyants de déterminer à quoi correspond la case à cocher. Les personnes avec des fonctions motrices limitées peuvent cocher la case plus facilement puisqu'elles peuvent cliquer n'importe où sur le libellé et pas seulement dans la case à cocher.
Note :
Les images textes conformes à la directive 1.1 devraient satisfaire à ce critère. (voir directive1.1 fournir un équivalent textuel à tout contenu non textuel)
Note éditoriale : Le groupe de travail recherche un algorithme pour mesurer le contraste de façon précise et suffisamment vérifiable de telle manière qu'il puisse être inclus aux directives. Un algorithme en provenance du document techniques for accessibility Evaluation and repair tools est actuellement étudié pour être inclus dans les techniques, mais le groupe de travail n'a pas encore trouvé quelque chose d'assez spécifique pour être inclus dans les directives.
Note :
Une différence de 20 décibels correspond à un niveau sonore environ 4 fois plus faible (ou plus fort). Les fonds sonores conformes à cette exigence seront approximativement 4 fois (4X) plus faibles que le contenu sonore principal.
Discussions relatives à la directive 1.4 (contraste visuel et audio)
Les personnes malvoyantes peuvent facilement lire les caractères, même si elles n'ont pas un champ de vision complet ou une perception complète des couleurs utilisées par les personnes sans problème visuel, pour distinguer le texte des images de fond. Cela va aussi aider les personnes ayant des déficiences cognitives qui bénéficieront de la facilité à discerner le texte. Les contrastes visuels profitent également aux personnes ayant des déficiences auditives qui sont aidées par une présentation claire de l'information visuelle.
Les personnes ayant des déficiences auditives limitant leurs capacités à entendre toutes les fréquences de la voix peuvent distinguer les mots des sons qu'elles peuvent entendre parce que les mots ne sont pas mélangés avec des sons résiduels provenant de la musique.
Note :
Le contraste audio est aussi appelé "rapport signal sur bruit" par les audiologistes, le signal se référant à l'avant-plan et le bruit se référant à l'arrière-plan.
Exemple 1 : une image de fond dans une page.
L'image de fond et le texte sont disposés de telle manière qu'il n'y ait pas d'image derrière le texte ou que l'image soit si pâle que la différence entre la partie la plus sombre de l'image et le texte (qui est sombre) satisfasse aux exigences standards de contraste avant-plan/arrière-plan. De même, l'image de fond ne contient pas de ligne d'une largeur similaire à celle des caractères de telle manière qu'elle n'interfère pas avec la reconnaissance des caractères.
Exemple 2 : un discours sur des bruits arrière-plan.
Puisque la voix est, de façon naturelle, souvent mélangée avec des sons d'arrière-plan (films, actualités, etc.) et qu'ils ne peuvent pas être séparés, des sous-titres sont fournis (voir directive 1.2) pour rendre les dialogues compréhensibles. Cependant tout le monde n'est pas capable de voir ou de lire les sous-titres. Quand la voix est mixée ou enregistrée de telle manière qu'elle soit à un niveau sonore supérieur d'au moins 20 décibels par rapport au son d'arrière-plan, la plupart des gens n'a pas à s'appuyer sur les sous-titres pour comprendre les dialogues.
Note :
Ceci comprend les caractéristiques d'accessibilité fournies par le concepteur
Note:
D'autres interfaces (telle qu'une souris) peuvent être fournies en plus du clavier.
Note:
Voir la directive 4.2 pour les informations concernant la prise en charge par les agents utilisateurs.
Toute fonctionnalité du contenu est conçue pour être pratiquée par un clavier ou une interface clavier.
Discussions relatives à la directive 2.1 (fonctionnement clavier)
Les individus non-voyants (et qui ne peuvent pas utiliser des dispositifs de pointage) peuvent avoir accès à la fonctionnalité du contenu Web ou du site.
Les individus avec des handicaps physiques sévères peuvent utiliser l'entrée vocale (qui simule la frappe des touches) aussi bien pour entrer des données que pour utiliser sur les éléments d'interface de la page.
Exemple 1 : opération avec des périphériques d'entrée multiples.
Le contenu repose uniquement sur la sélection/non sélection et les événements d'activation ; ceux-ci sont définis dans l'API de l'environnement pour lequel le contenu est écrit, et sont destinés à être utilisables par plusieurs périphériques d'entrée, y compris des dispositifs de pointage, des claviers et des systèmes de saisie vocale.
Exemple 2 : exemples de contenu Web qui seraient et ne seraient pas utilisables à partir d'un clavier ou d'une interface clavier
Si le contenu est écrit pour être utilisable à partir d'un clavier d'ordinateur, il est conforme (parce qu'il est utilisable via le clavier).
Si le contenu est écrit pour être utilisé sur un appareil qui normalement n'a pas de clavier tel un téléphone cellulaire, mais qu'il peut être contrôlé par un clavier en option pour cet appareil, il est conforme (une personne qui a besoin d'un clavier - ou d'une interface clavier - peut l'utiliser pour contrôler l'application).
Si le contenu est écrit pour être utilisé avec un appareil qui n'a pas de clavier, mais qu'il peut aussi être utilisé avec des appareils similaires qui possèdent un clavier, et que ce contenu fonctionne dans ces conditions, il est conforme (une personne qui a besoin d'un clavier n'achèterait pas l'appareil sans le clavier. Cet appareil peut lui-même ne pas être considéré comme accessible. Mais le contenu peut être contrôlé depuis un appareil avec un clavier et par conséquent se conforme à ces directives).
Si le contenu est écrit pour fonctionner avec des appareils qui n'ont pas de clavier et qu'il ne peut être utilisé avec aucun appareil muni d'un clavier, alors il n'est pas conforme (il n'est pas accessible via un clavier).
l'utilisateur peut désactiver le délai d'attente, ou ;
l'utilisateur peut largement ajuster le délai d'attente dans une proportion au moins dix fois supérieure à la durée par défaut, ou ;
l'utilisateur est prévenu avant l'expiration du délai d'attente, il est autorisé à prolonger la limite de temps par une action simple (par exemple " pressez une touche ") et il a au moins 20 secondes pour agir, ou ;
Le délai d'attente est une partie importante d'un événement en temps réel (par exemple une vente aux enchères) et aucune alternative au délai d'attente n'est possible, ou ;
le délai d'attente fait partie d'une activité pour laquelle le minutage est essentiel (par exemple des jeux de compétition ou des épreuves de rapidité) et où les limites de temps ne peuvent pas être prolongées sans invalider l'activité.
Discussions relatives à la directive 2.2 (limites de temps)
Les personnes ayant des difficultés de lecture, des déficiences cognitives ou des difficultés d'apprentissage ont souvent besoin de plus de temps que les autres pour lire et comprendre un texte écrit.
Les personnes ayant des handicaps physiques peuvent accéder au contenu qui est souvent mis à jour dans les cas où le contenu ne pourrait pas être traité ni lu avant d'être rechargé, ou lorsque la lecture nécessite une assistance technologique ou un navigateur vocal.
Exemples de contenu qui doivent satisfaire aux critères de réussite de ce point de contrôle :
rafraîchissement automatique,
redirection,
texte clignotant ou défilant,
dialogue qui disparaît après une courte période,
arrêt ou désactivation de la ressource si aucune activité n'est reçue dans un temps donné.
Exemple 1 : un texte clignotant.
Un script côté client est utilisé pour créer du texte clignotant. Le contenu propose une option qui permet à l'utilisateur de désactiver le clignotement.
Exemple 2 : un site d'actualité qui est régulièrement mis à jour.
La page d'accueil d'un site d'actualité est mise à jour toutes les demi-heures. La page d'accueil contient très peu de texte et elle est constituée principalement de liens vers le contenu. Un utilisateur qui ne souhaite pas que la page se mette à jour sélectionne une case à cocher. La case à cocher est dans la partie "préférences de l'utilisateur" du site qui est un des premiers liens sur chaque page.
Note éditoriale : un outil gratuit sera rendu disponible par le "University of Wisconsin's Trace Center" (Centre Trace de l'Université du Wisconsin) qui effectuera les analyses ci-dessus sur le contenu Web.
Note :
La conformité au critère de 1er niveau de la directive 1.3 concerne aussi cette directive au niveau 1.
Note éditoriale : le groupe de travail attend des réactions à propos des recoupements entre les critères 1.3 et 2.4
Note éditoriale : les techniques générales pourraient inclure quelque chose sur la satisfaction de ce critère à l'aide des métadonnées, l'utilisation d'un futur attribut de rôle, etc.
Note éditoriale : le problème est comment spécifier que ce critère s'applique au contenu qui est destiné à apparaître comme une séquence sans nécessiter de test d'intention. Il a été suggéré que l'ordre de lecture est déjà couvert par l'obligation dans la 1.3 de rendre les structures et les relations du contenu déterminables informatiquement. Si le groupe de travail et les autres lecteurs partagent cet avis, cette partie pourrait être supprimée en tant que critère de réussite à part et la Technique Générale relative pourrait être transférée dans la directive 1.3.
Note éditoriale : le critère à propos de l'ordre de lecture est peut-être plus approprié sous le principe 3 : on pourrait arguer que l'ordre de lecture n'est pertinent que s'il affecte la capacité de l'utilisateur à comprendre le contenu. L'ordre de lecture en lui-même n'est pas nécessairement un problème d'accessibilité. Il devient un problème d'accessibilité si un utilisateur avec un handicap (tel qu'un handicap cognitif ou visuel) ne peut pas dériver de façon fiable un ordre de lecture significatif à partir de la présentation par défaut. Si nous voulons retenir ce critère et le conserver sous le 2.4, nous devons écrire quelque chose qui lie l'ordre de lecture à la capacité des utilisateurs à agir sur et à utiliser le contenu. Il n'est pas nécessairement vrai que la seule exposition de la structure à l'agent utilisateur est suffisante pour indiquer un ordre de lecture plausible. L'exemple des Techniques générales sur l'ordre de lecture devra éclaircir ce point.
Discussions relatives à la directive 2.4 (mécanismes de navigation)
Lorsque la structure logique est fournie dans le balisage ou le modèle de données,
Les utilisateurs avec des handicaps physiques peuvent utiliser la structure pour se déplacer plus aisément entre les paragraphes, les chapitres, les sections, etc.
Les utilisateurs avec des handicaps cognitifs peuvent utiliser les éléments de la structure (titres de chapitre, entêtes, etc.) pour obtenir plus de contexte sur le texte qui les suit. Ces éléments fournissent aussi une alerte sur un changement de contexte et réoriente l'utilisateur sur le nouvel élément sélectionné.
Les utilisateurs non-voyants ou malvoyants peuvent naviguer d'entête en entête pour survoler le document ou pour arriver plus rapidement vers la section qui les intéresse.
Les lecteurs malvoyants peuvent parfois (selon la technologie d'affichage) modifier la façon dont les titres de chapitre et les entêtes sont affichés afin de les rendre plus lisibles et plus faciles à utiliser quand ils survolent le document.
Le contenu peut être présenté sur différents appareils parce que le logiciel de l'appareil peut sélectionner seulement les éléments du contenu qu'il est capable d'afficher et qu'il les affiche de la façon la plus efficace pour cet appareil.
Fournir différents mécanismes de navigation peut permettre de mieux correspondre aux différentes compétences des gens, à leurs connaissances, à leurs habitudes pour s'orienter que ce soit de manière textuelle ou visuelle, et au type d'information qu'ils cherchent à ce moment.
Les personnes avec des handicaps cognitifs peuvent trouver plus facile de demander directement ce qu'elles cherchent plutôt que de parcourir des listes de catégories pour en déduire son emplacement.
Les personnes malvoyantes ou non-voyantes peuvent trouver que les techniques consistant à ramener toutes les informations relatives à un thème d'intérêt sont plus faciles que les techniques consistant à parcourir des listes ou du contenu.
Une présentation qui met en valeur la structure :
permet aux utilisateurs avec des handicaps cognitifs ou visuels de s'orienter dans le contenu,
permet aux utilisateurs de se déplacer rapidement dans le contenu et de repérer les divisions importantes du contenu,
permet à tous les utilisateurs, mais surtout aux utilisateurs avec des handicaps cognitifs ou visuels, de se concentrer sur le contenu important,
permet à tous les utilisateurs, mais surtout aux utilisateurs avec des handicaps cognitifs ou visuels, de distinguer les différents types de contenu.
Exemple 1 : La documentation d'un produit.
La structure d'un livre est identifiée par ses chapitres. C'est une façon tout à fait appropriée de mettre en évidence cette structure. À l'intérieur d'un chapitre, les entêtes mettent en évidence les changements de contexte et soulignent les idées contenues dans le texte qui suit. Des différences fines entre l'apparence du titre du chapitre et des entêtes de section aident l'utilisateur à comprendre la hiérarchie et les relations entre le titre et les entêtes. Cette différence peut être la taille de la police ou l'indentation des marges pour une présentation visuelle, ou une voix différente ou précédée par un son pour une présentation orale.
Exemple 2 : l'image redimensionnable d'une bicyclette.
Des lignes et un cercle (rayons et jante) sont groupés pour former une "roue". Des lignes dans un triangle rattaché à chaque roue sont groupées pour former un "cadre".
Exemple 3 : une interface utilisateur.
Les contrôles de l'interface utilisateur sont divisés en groupes organisés.
Exemple 4 : un tableau de données.
Les groupes de lignes et de colonnes sont identifiés avec des entêtes.
Exemple 5 : une présentation audio.
La restitution audio d'un document est générée d'après une feuille de style. Pour lire les titres et les entêtes, elle utilise une voix différente, plus formelle. Ainsi, les auditeurs peuvent facilement identifier ces mots comme étant un titre et non le texte courant.
Si une erreur de l'utilisateur est détectée, l'erreur est identifiée et signalée textuellement à l'utilisateur.
Si une erreur de l'utilisateur est détectée et que des suggestions pour la correction existent et peuvent être fournies sans compromettre la sécurité ni le but, l'erreur est identifiée et les suggestions sont fournies.
Lorsque les conséquences sont importantes et que le temps de réponse ne l'est pas, une des propositions suivantes est vérifiée :
Les actions sont réversibles.
Quand elles ne sont pas réversibles, les actions sont vérifiées avant l'étape suivante du processus.
Quand elles ne sont pas réversibles ni vérifiables, l'utilisateur peut revoir et confirmer ou corriger les informations avant de les soumettre.
Pour un champ de saisie de texte où les options d'entrées sont prédéterminées, qu'elles sont moins de 75 et qu'elles peuvent être fournies sans compromettre ni la sécurité ni un test de validité, etc., les utilisateurs sont autorisés à sélectionner dans une liste d'options aussi bien qu'à saisir le texte directement.
Si c'est possible pour la langue d'origine du texte, une option est fournie qui vérifie l'orthographe des mots dans le texte saisi et propose des suggestions d'orthographe correcte.
Discussions relatives à la directive 2.5 (limiter les erreurs)
L'identification des fautes de frappe aide les personnes avec des limitations au niveau de l'écriture et les personnes dyslexiques qui ont souvent des difficultés à écrire du texte dans les formulaires ou tout autre endroit qui nécessite la saisie de texte.
Certains handicaps rendent plus difficile la manipulation des périphériques d'entrée, d'où des erreurs de saisie plus nombreuses. Par exemple, les personnes dont les fonctions motrices sont limitées risquent plus particulièrement de faire des erreurs lorsqu'elles manipulent une souris ou un clavier. Les systèmes de reconnaissance vocale peuvent avoir plus de difficultés à reconnaître les paroles de personnes avec des difficultés d'élocution. Les fonctions qui aident à la reconnaissance et à la correction des erreurs bénéficient aux personnes avec ces types de handicap.
Exemple 1 : identification des erreurs lors de la soumission d'un formulaire.
Le site Web d'une compagnie aérienne propose des promotions sur des vols à prix réduits. Il est demandé à l'utilisateur de remplir un formulaire simple avec des informations personnelles telles que son nom, son adresse, son numéro de téléphone, ses préférences de placement et son adresse email. Si l'un des champs du formulaire n'est pas saisi ou saisi de façon incorrecte, l'utilisateur est averti de l'erreur de saisie. Le même formulaire est alors présenté à l'utilisateur et toutes les informations précédemment fournies de façon correcte sont disponibles. Il est demandé à l'utilisateur de corriger les champs du formulaire signalés par une flèche rouge ou deux astérisques. Note : la couleur seule n'est pas suffisante pour signaler les erreurs.
Exemple 2 : erreurs dans le nom d'utilisateur et le mot de passe.
L'utilisateur doit saisir un nom d'utilisateur et un mot de passe pour accéder à une page Web. Si l'un des deux est incorrect, l'utilisateur est informé qu'il y a eu une erreur, mais pour des raisons de sécurité on ne lui indique pas dans lequel (nom d'utilisateur ou mot de passe), et on ne lui propose pas de suggestions de corrections.
Exemple 3 : un test en ligne.
Un site Web propose un test en ligne pour une certification dans un domaine d'étude particulier. Le test indique à l'utilisateur les réponses incorrectes mais ne propose pas de suggestions pour les corriger. L'objectif du test en ligne est d'évaluer les connaissances de l'utilisateur et par conséquent donner des conseils sur la réponse correcte irait contre l'objectif du site.
Exemple 4 : la confirmation de commande.
Un détaillant sur le Web propose aux clients d'acheter en ligne. Lorsqu'une commande est soumise, les informations de la commande, y compris les articles commandés, la quantité de chaque article, l'adresse de livraison et le moyen de paiement, sont affichées pour permettre à l'utilisateur de vérifier si elles sont correctes. L'utilisateur peut confirmer la commande ou faire des modifications.
Exemple 5 : une liste de sélection pour réduire les erreurs.
Un détaillant sur le Web propose aux clients d'acheter en ligne du matériel de pêche à la mouche. Lorsque l'utilisateur doit indiquer son pays, une liste déroulante de pays lui est proposée au lieu d'un champ de saisie de texte. Pour faciliter encore les choses, l'utilisateur est informé que les pays sont listés dans l'ordre alphabétique.
Exemple 6 : les fonctions d'un moteur de recherche.
Un moteur de recherche propose différentes options de recherche selon les niveaux de compétence et les préférences des utilisateurs. Ceci comprend une option pour vérifier l'orthographe des termes cherchés et la proposition d'alternatives "terme le plus proche", des recherches "requête par un exemple" et des recherches par similarité.
Exemple 7 : la vérification orthographique pour les formulaires de contact.
Un site Web bancaire fournit à ses clients un formulaire pour poser des questions ou soumettre des propositions. L'interface utilisateur du formulaire comprend une vérification orthographique optionnelle de la zone de saisie de la question ou de la suggestion.
Note :
Cela exclut l'utilisation de mots dans une autre langue dans le cas ou une telle utilisation est une extension standardisée du langage.
Note éditoriale : Des méthodes sont toujours à l'étude pour rendre toutes ou certaines de ces conditions testables (qui pourraient en faire des critères de réussite en soi).
En général
Organiser le matériel pour qu'il soit facile à lire et à utiliser.
Utiliser un cadre de référence pour les styles ainsi qu'un dictionnaire et d'autres matériels de référence.
Tester les documents pour déterminer si les utilisateurs potentiels comprennent le matériel, en incluant dans le groupe de test des personnes ayant des déficiences cognitives, des difficultés d'apprentissage ou des limitations au niveau de la lecture.
Traiter un seul sujet ou sous sujet par paragraphe
Vocabulaire
Utiliser un vocabulaire qui sera familier aux lecteurs ciblés.
Si la ressource s'adresse à des personnes qui travaillent dans un champ d'activités spécifique, considérer l'utilisation d'un "langage contrôlé". Par exemple, une ressource s'adressant à des ingénieurs dans le secteur de l'aérospatial pourrait utiliser un "langage contrôlé" comme celui utilisé par Boeing Aircraft Company.
Si une ressource technique est destinée à la traduction, considérer l'utilisation d'un "langage contrôlé".
Lorsque les ressources s'adressent au grand public ou sont destinées à la traduction, éviter d'utiliser le jargon professionnel, l'argot ou d'autres termes spécialisés dont la signification peut ne pas être claire pour des personnes ne faisant pas partie d'un groupe spécifique. Il peut aussi être utile de réviser le document pour un langage simplifié, en utilisant une liste de contrôle, telles que celles utilisées par les agences gouvernementales américaines ou canadiennes.
Note éditoriale : Besoin d'ajouter des exemples d'autres pays et d'autres langues.
Utiliser des phrases d'une longueur et d'une complexité respectant les bonnes pratiques recommandées pour le public visé, telles que celles qu'on retrouve dans les guides de référence portant sur l'écriture dans le champ ou la discipline du public ciblé.
Phrases
Utiliser des longueurs de phrases appropriées aux pratiques communes dans la langue du document ou pour le public pour lequel le document est destiné. Des manuels de référence portant sur l'écriture dans le champ ou la discipline concernée peuvent être utiles lorsqu'ils sont disponibles.
Syntaxe
Utiliser la forme de phrase la plus simple et la plus appropriée au contenu.
Par exemple, la forme la plus simple d'une phrase en français est Sujet-Verbe-Complément, comme dans John frappe la balle ou Le site Web respecte les WCAG 2.0.
Utiliser des listes à puces ou des listes numérot&