Information sur la traduction
La version française de cette traduction est http://www.la-grange.net/w3c/WAI-WEBCONTENT-TECHS/. Cette traduction fait partie de l'effort de traduction r�alis�e par La Grange et de la liste des traducteurs francophones des sp�cifications du W3C.
La version française peut contenir des erreurs. La version anglaise de cette note est l'unique version normative.
Version originale : http://www.w3.org/TR/1999/WAI-WEBCONTENT-TECHS-19990505
Traducteur
Copyright © 1999 W3C (MIT, INRIA, Keio), Tous droits réservés. Les règles de responsabilité, marque déposé, utilisation du document et license des logiciels du s'appliquent.
Ce document est une liste de techniques qui met en place la liste des contrôles définie dans le guide des "règles d'accessibilité du contenu Web 1.0".
Ce document fait partie d'une série de documents sur l'accessibilité publiés par le groupe d'initiative sur l'accessibilité du Web (WAI).
Ce document est une NOTE rendue disponible par le W3C pour discussion uniquement. La publication de cette note par le W3C n'implique aucune adhésion de la part du W3C, ou de l'équipe du W3C, ou des membres du W3C.
Tant que les règles d'accessibilité du contenu Web 1.0 ne sont pas devenus un document stable (comme une recommandation du W3C), le document présent evoluera au fur et à mesure du changement des technologies et les développeurs de contenu découvriront des techniques plus efficaces pour concevoir des pages accessibles.
Ce document a été produit comme une partie du groupe d'initiative d'accessibilité du Web du W3C. Le but de ce groupe de travail sur les règles de contenu Web est discuté dans la charte du groupe de travail.
Une liste des Recommandations actuelles et des autres documents techniques peut être trouvée à http://www.w3.org/TR.
Envoyez vos commentaires détaillés sur ce document à [email protected].
Chaque point de contrôle possède un niveau de priorité fixé par le groupe de travail basé sur l'impact du point de contrôle sur l'accessibilité.
Quelques un des points de contrôle ont des niveaux de priorité qui peuvent changer sous certaines conditions (mentionné).
Les points de cont�le de document sont num�rot�s afin de correspondre aux règles d'accessibilité du contenu Web 1.0.
Ce document est une liste des techniques qui mettent en place les points de contrôle définis dans les "règles d'accessibilité du contenu Web 1.0". Ce document est organisé comme suit :
Une table des points de contrôle a été fournie pour se repérer dans les techniques. Pour chaque point de contrôle, la table inclut sa définition (telle qu'elle apparaît dans les "règles d'accessibilité du contenu Web 1.0") et des liens vers les techniques applicables pour ce point de contrôle. De plus, le début de chaque section de ce document liste les points de contrôle qui sont traités dans cette section.
Ce document contient de nombreux exemples qui illustrent des solutions d'accessibilité en HTML, CSS, etc. mais également des exemples déclassés qui illustrent ce que les développeurs de contenu ne devraient pas faire. Les exemples déclassés sont mis en valeurs et les lecteurs devraient les lire avec prudence -- Ils ne sont présent que pour des raisons d'illustrations.
Les sections suivantes exposent quelques thèmes sur l'accessibilité que les développeurs de contenu Web devraient garder à l'esprit lorsqu'ils conçoivent leurs documents et les sites.
Lorsque qu'ils conçoivent un document ou une série de documents, les développeurs de contenu devraient tout d'abord s'efforcer d'identifier la structure voulue pour leurs documents avant même de penser à la façon dont les documents seront présentés à l'utilisateur. Séparer la structure d'un document de la présentation de son contenu offre de nombreux avantages comprenant l'accessibilité, la souplesse de gestion, et la portabilité.
Identifier ce qu'est la structure et ce qu'est la présentation peut sembler difficile parfois. Par exemple, de nombreux développeurs de contenu considèrent qu'un trait horizontal (l'élément HR) définit une division structurelle. Cela peut être vrai pour des utilisateurs voyants, mais pour des utilisateurs non-voyants ou des utilisateurs sans navigateurs graphiques, un trait horizontal n'a pratiquement aucune signification (Certains pourront "deviner" que l'élément HR implique une division structurelle, mais sans autre information, Il n'y a aucune garantie.) En HTML, les développeurs de contenu devraient utiliser les éléments d'entête (H1-H6) pour identifier les nouvelles sections. Celles ci peuvent être complétées visuellement ou par un autre signal comme un trait horizontal, mais ne devraient pas être remplacées par eux.
L'inverse est également vrai : Les développeurs de contenu ne devraient pas utiliser d'éléments structurels afin de créer des effets de présentation. Par exemple en HTML, bien souvent l'élément BLOCKQUOTE peut causer une indentation du texte dans certains navigateurs, il a été conçu pour identifier une citation, non pour créer un effet de décalage au niveau présentation. Les éléments BLOCKQUOTE utilisés pour l'indentation confondent l'utilisateur ainsi que les robbots de recherche, qui s'attendent à un élément balisant une citation.
La séparation de la présentation de la structure dans les documents XML est naturelle. Ainsi que Norman Walsh l'explique dans "A Guide to XML" [WALSH],
les navigateurs HTML sont très rigides. Un titre de premier niveau apparaît d'une certaine façon car le navigateur reconnaît la balise H1. Encore, puisque les documents XML n'ont pas d'ensemble de tags fixes, cette approche ne fonctionnera pas. La présentation d'un document XML est dépendante de sa feuille de style.
Test rapide ! Pour déterminer si le contenu est de type structurel ou de type présentation, créez un arbre (outline) de votre document. Chaque point dans la hiérarchie dénote un changement structurel. Utilisé un balisage structurel pour identifier chaque changement et un balisage de présentation pour les rendre plus apparent visuellement et de manière auditive. Notez que les traits horizontaux n'apparaîtront pas dans cet arbre et par conséquent qu'ils ne sont pas structurels, mais de la partie présentation. Note : Ce test rapide traite de la structure des chapitres, des sections, et des paragraphes. Pour déterminer la structure à l'intérieur des phrases, recherchez les abbrévations, les changements du langage naturel, les définitions et les éléments de liste.
Les points de contrôle dans cette section : 1.1, 1.2, 1.5, 13.10, 3.3, et 12.1, et 12.2.
Le texte est considéré accessible à la plupart des utilisateurs dès qu'il peut être géré par des lecteurs à l'écran, des navigateurs non visuels, et des lecteurs braille. Il peut être affiché visuellement, grossi, synchronisé avec une vidéo pour créer des titres, etc. Lorsque vous concevez un document avec de l'information non-textuelle (images, applets, sons, présentation multimédia, etc.), pensez à compléter cette information avec un équivalent textuel lorsque c'est possible.
Un équivalent texte décrit la fonction ou la signification du contenu. Pour les contenus complexes (diagrammes, graphiques, etc.), l'équivalent texte peut être plus long et inclure des informations descriptives
Les équivalents texte devraient être fournis pour des logos, des photos, des boutons d'envoi, des applets, des puces dans une liste, de l'art ascii, et tous les liens dans une image map ainsi que pour les images invisables utilisées pour modeler une page.
Test rapide ! Un bon test pour déterminer si un équivalent texte est utile est d'imaginer la lecture du document grâce à un téléphone. Que diriez vous à propos de cette image pour la rendre compréhensible à quelqu'un qui écoute au combiné ?
Comment spécifier un équivalent texte dépendant de la langue du document.
Par exemple, en fonction du type d'élément, le langage HTML permet aux développeurs de spécifier des équivalents textes grâce aux attributs ("alt" ou "longdesc" ) ou au sein d'un contenu d'élément (l'élément OBJECT).
Les formats vidéo, tels que Quicktime, permettront aux développeurs d'inclure une variété de pistes alternatives audio et vidéo. SMIL ([SMIL]), permet aux développeurs de synchroniser des clips audio et vid�o alternatifs, et des fichiers texte les uns avec les autres.
En créant les DTDs XML, s'assurer que les éléments qui pourraient avoir besoin d'une description aient une possibilité d'y associer une description.
Certains formats d'image permettent d'incorporer dans les donn�es du fichier une description textuelle de l'image. Si un format d'image supporte le texte (ex., Portable Network Graphics, voir [PNG]) les développeurs de contenu peuvent également fournir l'information de cette façon.
Les développeurs de contenu doivent considérer la compatibilité antérieure lorsqu'ils créent des pages Web ou des sites :
Par conséquent, quand on conçoit pour des technologies anciennes, il faut considérer ces techniques :
Points de contrôle dans cette section: 11.4, et 6.5.
Bien qu'il soit possible de rendre l'ensemble du contenu accessible, il peut arriver que tout ou une partie d'une page reste inaccessible. Les techniques supplémentaires pour créer des alternatives accessibles incluent :
Voici deux techniques pour pour créer un lien vers une page alternative accessible :
Exemple.
Les agents utilisateurs qui supportent LINK chargeront la page alternative pour les utilisateurs qui ont des navigateurs pouvant être identifiés comme des interpréteurs "oraux", "brailles" ou "tty" (terminal texte).
<HEAD> <TITLE>Welcome to the Virtual Mall!</TITLE> <LINK title="Text-only version" rel="alternate" href="text_only" media="aural, braille, tty"> </HEAD> <BODY><P>...</BODY>
Fin de l'exemple.
Points de contrôle dans cette section : 9.2.
Tous les utilisateurs n'ont pas d'environnement graphique avec une souris ou un autre système de pointage. Certains utilisateurs utilisent un clavier, un clavier sp�ciale ou un interpr�teur vocal pour parcourir les liens, activer les champs de formulaire, etc. Les développeurs de contenu devraient toujours s'assurer que les utilisateurs puissent interagir avec une page avec des équipements autres que les outils de pointage. Une page conçue pour un accès clavier (en plus de l'accès par souris) sera généralement accessible aux utilisateurs se servant d'autres interfaces. De plus, concevoir une page pour un accès clavier améliorera souvent son ergonomie.
Les accès clavier aux liens et aux champs de formulaire peuvent être indiqués de plusieurs manières :
Quelques éléments importent des objets (ex., des lecteurs d'applets ou multimédias) ceux dont l'interface ne peut pas �tre contr�l�e � travers le langage de balisage. Dans certains cas, les développeurs de contenu devraient fournir des équivalents alternatifs avec des interfaces accessibles si les objets importés ne peuvent pas eux-même fournir des interfaces accessibles.
Points de contrôle dans cette section : 14.3, 13.4, 13.5, 13.3, 13.7, et 13.2.
Un style logique de présentation sur chaque page permet aux utilisateurs de localiser les systèmes de navigation plus facilement mais également de les passer plus facilement pour trouver le contenu important. Ceci aide les personnes avec des handicaps d'apprentissage et de lecture mais rend également la navigation plus facile pour tous les utilisateurs. Le conditionnement augmente la probabilit� que les personnes retrouvent l'information sur votre site, ou l'�vitent si tel est leur d�sir.
Des exemples de structures qui peuvent apparaître à la même place de page en page :
Un mécanisme de navigation crée un ensemble de chemin qu'un utilisateur peut prendre à travers votre site.Fournir des barres de navigation, des index de sites, et des options de recherche augmentent la probabilit� qu'un utilisateur atteigne l'information qu'il recherche sur votre site. Si votre site est essentiellement visuel, les utilisateurs �prouveront des difficult�s � naviguer dans la structure du site s'ils ne sont pas en mesure de se former une "image mentale" d'o� ils vont et d'o� ils sont all�s. Pour les aider, les d�veloppeurs de contenu devraient d�crire tous les m�canismes de navigation. Il est crucial que les descriptions et les guides de site soient accessibles lorsque les personnes sont perdues sur votre site et qu'elles recherchent ces informations.
Lorsque vous fournissez des fonctionnalités de recherche, les développeurs de contenu devraient offrir des mécanismes de recherche qui satisfont des niveaux de compétences et des préférences variés. La plupart des fonctionnalités de recherche demande à l'utilisateur d'entrer des mots clés pour les termes de la recherche. Les utilisateurs dyslexiques et les utilisateurs non familiers de la langue de votre site auront des difficult�s pour trouver ce dont ils ont besoin si la recherche requiert (n�cessite ?) une orthographe exacte. Les moteurs de recherche devraient inclure un vérificateur d'orthographe, offrir des alternatives de "recherche pertinente", des recherches de type "interrogation par exemple", des recherches de similarité, etc.
Points de contrôle dans cette section : 14.1, 13.8, et 14.2.
Les sections suivantes exposent les techniques pour aider à la compréhension d'une page ou d'un site.
Les suggestions de style d'écriture suivantes devraient vous aider à rendre le contenu de votre site plus facile à lire pour tout un chacun, spécialement pour les personnes qui ont des handicaps de lecture et/ou des handicaps de compréhension. De nombreux guides (tels que [HACKER]) exposent ceci et toutes les arcanes des styles d'écriture avec plus de détails.
Pour vous aider à déterminer si votre document est facile à lire, pensez à utiliser le test de lecture Gunning-Fog (décrit dans [SPOOL] pour les exemples et l'algorithme en ligne à [TECHHEAD]). Cet algorithme produit généralement un score bas lorsque le contenu est plus facile à lire. Comme exemple de résultat, la Bible, Shakespeare, Mark Twain, et le programme TV possèdent tous un indice d'à peu près 6. Time, Newsweek, et le Journal de Wall Street ont un indice moyen d'environ 11.
Pour les personnes qui ne lisent pas bien ou pas du tout, des équivalents (non textuels) multimédias peuvent aider à la compréhension. Faites attention, les présentations multimédias ne rendent pas toujours le texte plus facile à comprendre. Parfois, les présentations multimédia peuvent le rendre plus abscons.
Exemples de multimédia qui complète le texte :
Points de contrôle dans cette section : 11.3.
Points de contrôle dans cette section : 7.4, et 7.5.
Les développeurs de contenu créent quelquefois des pages qui se rafraîchissent ou qui changent sans que l'utilisateur ait demandé le rafraîchissement. Ce rafraîchissement automatique peut désorienter certains utilisateurs. Les auteurs devraient, à la place et par ordre de préférence :
Note. Le point de contrôle 7.4 ainsi que le point de contrôle 7.5 résolvent certains problèmes posés par des agents utilisateurs de première génération. Les nouveaux agents utilisateurs devraient désactiver le rafraîchissement et substituer un lien vers l'information nouvelle en haut de la page.
Ce qui suit sont des exemples HTML tombé en désuétude (deprecated). Le premier change le contenu de l'utilisateur page par page à intervalles réguliers. Les développeurs de contenu ne devraient pas utiliser cette technique pour simuler la technologie "push". Les développeurs ne peuvent pas prévoir combien de temps un utilisateur prendra de temps pour lire une page ; un rafraîchissement prématuré peut désorienter les utilisateurs. Les développeurs de contenu devraient éviter les rafraîchissements périodiques et permettre aux utilisateurs de choisir le moment auquel ils désirent obtenir la dernière information.
exemple tombé en désuétude.
<META http-equiv="refresh" content="60"> <BODY> <P>...Information... </BODY>
L'exemple HTML suivant (utilisant l'élément META) fait avancer l'utilisateur d'une page vers une autre après un délai. Cependant, les utilisateurs ne devraient pas rediriger les utilisateurs avec ce balisage car il est non standard, il désoriente les utilisateurs et il peut pertuber l'historique des pages visitées d'un navigateur
exemple tombé en désuétude.
<HEAD> <TITLE>Don't use this!</TITLE> <META http-equiv="refresh" content="5; http://www.acme.com/newpage"> </HEAD> <BODY> <P>If your browser supports Refresh, you'll be transported to our <A href="http://www.acme.com/newpage">new site</A> in 5 seconds, otherwise, select the link manually. </BODY>
Points de contrôle dans cette section : 7.1.
Un écran clignotant ou flashant peut provoquer des crises chez certains utilisateurs atteints d'épilepsie photosensitive et les développeurs de contenu devraient éviter de faire clignoter l'écran. Les crises peuvent être déclenchées par un clignotement ou un flashage compris dans un intervalle de 4 à 59 flashs par seconde (Hertz) avec un pic de sensibilité à 20 flashs par seconde, ainsi que des changements rapides du sombre au lumineux (comme l'effet stroboscopique).
Points de contrôle dans cette section : 13.9.
Les documents en lot peuvent faciliter la lecture hors ligne. Pour créer un lot cohérent :
Cette section examine les stratégies et les techniques pour tester les documents Web afin de déterminer les problèmes d'accessibilité qui ont été résolus et ceux qui ne l'ont pas été. Ces tests, qui devraient permettre de mettre en évidence les problèmes majeurs, sont très utiles en permettant de réduire un certain nombre des barrières d'accessibilité. Cependant, certains de ces scénarios de test reproduisent seulement les conditions provoquées par un handicap ; ils ne simulent pas toute l'expérience qu'un utilisateur avec un handicap puisse avoir. Dans la vie réelle, vos pages peuvent se trouver être moins accessible que vous ne l'aviez imaginé. Donc, une des stratégies recommande que les développeurs de contenu d'observer les utilisateurs avec différents handicaps lorsqu'ils tentent de lire une page ou d'utiliser un site.
Si, après avoir complété les tests suivants et ajuster votre conception en fonction, vous vous rendez compte que votre page n'est toujours pas accessible, vous devriez alors envisager la création d'une page alternative qui est accessible.
Note. La validation de ces tests ne garantie pas la conformité aux "règles d'accessibilité du contenu Web 1.0".
Un outil de validation peut vérifier la syntaxe de vos pages (ex., HTML, CSS, XML). Une syntaxe correcte aidera à éliminer un certain nombre des problèmes d'accessibilité depuis que les logiciels peuvent traiter les documents bien formés plus facilement. Egalement, certains outils de validation peuvent vous avertir de certains problèmes d'accessibilité basés uniquement sur la syntaxe (ex., un attribut ou une propriété manquant dans un document qui est important pour l'accessibilité). Il faut noter qu'un document avec une syntaxe correcte ne garantit pas qu'un document sera accessible. Par exemple, vous pouvez fournir un équivalent texte pour une image en accord avec la spécification du langage, mais le texte peut être inexact ou insuffisant. Quelques outils de validations vous poseront des questions et vous inviteront à traiter les parties les plus subjectives de l'analyse. Quelques exemples d'outils de validation automatiques incluent :
Les outils de validation signalent généralement les problèmes à résoudre et donnent souvent des exemples pour les résoudre. Ils ne permettent pas généralement d'aider un auteur à travers chaque problème et d'aider l'auteur à modifier le document de façon interactive. Le groupe de travail de réparation et d'évaluation WAI ([WAI-ER]) travaille au développement d'une suite d'outils qui aideront les auteurs non seulement à identifier les problèmes mais également à les résoudre de façon interactive.
Gardez à l'esprit que la plupart des agents utilisateurs (navigateurs) et des systèmes d'exploitations permettent aux utilisateurs de configurer les préférences qui changent l'allure du logiciel, ses sons, et ses comportements. Avec la variété des agents utilisateurs, des utilisateurs différents auront des expériences très différentes du web. Par conséquent :
Une personne lisant une page avec un synthétiseur vocal peut ne pas être capable de déchiffrer la meilleure interprétation du synthétiseur pour un mot comprenant une erreur d'orthographe. Les vérificateurs grammaticaux aideront à déterminer si le contenu textuel d'un epage est correct. Ceci aidera les lecteurs pour lesquelles votre document n'est pas rédigé dans la langue maternelle., ou les personnes qui sont en cours d'apprentissage de la langue du document. Vous permettrez, alors, une meilleure compréhension de votre page.
Points de contrôle dans cette section : 11.1.
Note. A la rédaction de ce document, tous les agents utilisateurs ne supportent les (nouveaux) attributs et éléments du HTML 4 qui améliorent de façon significative l'accessiibilité des pages web.
Voir le site web du W3C ([WAI-UA-SUPPORT]) pour avoir de l'information sur le support des options d'accessibilité des navigateurs et des autres agents utilisateurs.
In general, please note that HTML user agents ignore attributes they don't support and they render the content of unsupported elements.
Les sections suivantes listent quelques techniques pour concevoir des documents HTML accessibles. Les sections sont organisées par sujet (et s'appuie sur l'organisation de la spécification HTML 4.0, [HTML40]).
Points de contrôle dans cette section : 3.2
Les développeurs de contenu devraient utiliser le balisage structurel en accord avec la spécification. Les éléments structurels et les attributs (voir l'index des éléments et des attributs HTML pour les identifier) définissent la consistance des documents et fournissent de l'information à d'autres outils (ex., les outils d'indexation, les moteurs de recherche, les programmes qui extraient les tables des bases de données, les outils de navigation qui utilisent les éléments des entêtes, les logiciels de traduction automatique qui traduisent les textes d'une langue vers une autre.
Points de contrôle dans cette section : 13.2.
Certains éléments structurels fournissent de l'information à propos du document lui-même. C'est ce que l'on appelle "metadata" à propos du document. Des metadatas bien définis peuvent fournir une information d'orientation importante aux utilisateurs. Les éléments HTML qui fournissent de l'information à propos du document incluent :
Points de contrôle dans cette section : 3.5.
Les sections devraient être introduites avec les éléments d'entête HTML (H1-H6). D'autres balisages peuvent compléter ces éléments pour améliorer la présentation (ex., l'élément HR pour une ligne horizontale de séparation), mais la présentation visuelle n'est pas suffisante pour identifier les sections des documents.
Comme certains utilisateurs parcourent rapidement un document en navigant grâce aux entêtes, il est important de les utiliser de façon appropriée pour communiquer la structure du document. Les utilisateurs devraient ordonner les éléments d'entêtes correctement. Par exemple, en HTML, les éléments H2 devraient suivre les éléments H1, les éléments H3 devraient suivre les éléments H2, etc. Les développeurs de contenu ne devraient pas "passer" des niveaux (ex., de H1 directement à H3). N'utilisez pas les entêtes pour créer des effets de police ; utilisez les feuilles de style pour changer les styles des polices par exemple.
Notez qu'en HTML, les éléments d'entêtes (H1 - H6) démarrent uniquement des sections, ils ne les conteignent pas comme un élément. Le balisage HTML suivant montre comment les feuilles de style peuvent être utilisées pour contrôler l'apparence d'un entête et le contenu qui suit :
<HEAD> <TITLE>Cooking techniques</TITLE> <STYLE type="text/css"> /* Indente l'entête et le contenu suivant */ DIV.section2 { margin-left: 5% } </STYLE> </HEAD> <BODY> <H1>Cooking techniques</H1> ... some text here ... <DIV class="section2"> <H2>Cooking with oil</H2> ... text of the section ... </DIV> <DIV class="section2"> <H2>Cooking with butter</H2> ... text of the section ... </DIV>
Fin de l'exemple.
Points de contrôle dans cette section : 13.2.
Les développeurs de contenu devraient utiliser l'élément LINK et les types de liens (voir [HTML40], section 6.12) pour décrire les mécanismes de navigation du document et son organisation. Certains agents utilisateurs peuvent synthétiser des outils de navigation ou permettre de commander l'impression d'un ensemble de documents, basée sur ce balisage.
Les éléments LINK suivants peuvent être inclus dans l'entête du chapitre 2 d'un livre :
<LINK rel="Next" href="chapter3"> <LINK rel="Previous" href="chapter1"> <LINK rel="Start" href="cover"> <LINK rel="Glossary" href="glossary">
Fin de l'exemple.
Voir également la section sur les liens.
Points de contrôle dans cette section : 12.3.
Les mécanismes HTML 4.0 suivants groupent le contenu et le rendent plus facile à comprendre :
Tous ces mécanismes de groupement devraient être utilisés lorsque c'est approprié et naturel, c.à-d., quand l'information se prête elle-même à des groupements logiques. Les développeurs de contenu ne devraient pas créer des groupements de manière aléatoire, car cela désorientera les utilisateurs.
Points de contrôle dans cette section : 4.1, et 4.3.
Si vous utilisez différentes langues dans une page, soyez sûr que tout changement de langues est clairement identifié en utilisant l'attribut "lang" :
<P>And with a certain <SPAN lang="fr">je ne sais quoi</SPAN>, she entered both the room, and his life, forever. <Q>My name is Natasha,</Q> she said. <Q lang="it">Piacere,</Q> he replied in impeccable Italian, locking the door.
Fin de l'exemple.
Il est important d'identifier les changements de langues pour les raisons suivantes :
C'est également une bonne chose d'identifier la langue primaire d'un document, grâce au balisage (comme ci-dessous) ou par l'intermédiaire des entêtes HTTP.
Les sections suivantes expliquent les manières d'ajouter une structure aux morceaux de texte.
Points de contrôle dans cette section : 3.3.
Les éléments HTML adéquats devraient être utilisés pour baliser une mise en valeur : EM et STRONG. Les éléments B et I ne devraient pas être utilisés ; ils sont utilisés pour créer un effet visuel de présentation. Les éléments EM et STRONG ont été créés pour indiquer une mise en valeur structurelle qui peut être traité de multiples façons (changement du style de la polcie, changements de l'inflection de la voix, etc.)
Points de contrôle dans cette section : 4.2.
Balisez les abbrévations et les acronymes avec ABBR et ACRONYM et utilisez un "title" pour indiquer la signification :
Exemple.
<P>Welcome to the <ACRONYM title="World Wide Web">WWW</ACRONYM>!
Fin de l'exemple.
Points de contrôle dans cette section : 3.7.
Les éléments Q et BLOCKQUOTE balisent respectivement les citations au sein d'une phrase et sous forme de bloc textes.
Exemple.
Cet exemple balise une citation plus longue avec BLOCKQUOTE :
<BLOCKQUOTE cite="http://www.shakespeare.com/loveslabourlost"> <P>Remuneration! O! that's the Latin word for three farthings. --- William Shakespeare (Love's Labor Lost). </P> </BLOCKQUOTE>
Fin de l'exemple.
Points de contrôle dans cette section : 3.1.
Utilisez le balisage (et les feuilles de style) où cela est possible plutôt que les images (ex., une équation mathématique). Cela permet de promouvoir l'accessibilité pour les raisons suivantes :
Par exemple, considérez ces techniques pour placer des formules mathématiques sur le Web :
TeX est utilisé d'habitude pour créer des papiers techniques qui sont alors convertis en HTML pour une publication sur le Web. Cependant, les convertisseurs ont tendance à générer des images, à utiliser un balisage obsolète , et à utiliser des tableaux pour la présentation. Par conséquent, les fournisseurs de contenu devraient :
La Spécification HTML 4.0 specification définit les éléments structurels suivants pour les divers besoins de balisage :
Points de contrôle dans cette section : 3.6.
Les éléments HTML de listes DL, UL, et OL devraient utilisés uniquement pour créer des listes, non pour des effets de présentation comme une indentation.
Les listes ordonnées aident les utilisateurs quine peuvent voir à naviguer. Les utilisateurs non voyants peuvent "être perdus" dans des listes, surtout dans des listes imbriquées et celle qui n'indiquent pas le niveau d'imbrication spécifique pour chaque élément de la liste. Jusqu'à ce que les agents utilisateurs fournissent un moyen d'identifier le contexte de la liste clairement (ex., en supportant le pseudo-élément ':before' de CSS2), les développeurs de contenu devront inclure des indications contextuelles dans leurs listes.
Pour les listes numérotées, les nombres composés sont plus informatifs que de simples nombres. Ainsi, une liste numérotée "1, 1.1, 1.2, 1.2.1, 1.3, 2, 2.1," fournit plus de contexte que la même liste sans les nombres composés, qui doit être formattée comme suit :
1. 1. 2. 1. 3. 2. 1.
et doit être dit comme "1, 1, 2, 1, 2, 3, 2, 1", ne trans portant aucune information à propos de la profondeur de la liste.
[CSS1] et [CSS2] permet aux utilisateurs de contrôler les styles des nombres (pour toute liste, pas uniquement les numérotées) grâce aux feuilles de style.
Exemple.
La feuille de style CSS2 suivante montre comment spécifier des nombres composés pour des listes imbriquées créées avec des élements UL ou OL. Les éléments sont numérotés tels que "1", "1.1", "1.1.1", etc.
<STYLE type="text/css"> UL, OL { counter-reset: item } LI { display: block } LI:before { content: counters(item, "."); counter-increment: item } </STYLE>
Fin de l'exemple.
Jusqu'à ce que CSS2 soit largement supporté ou que les agents utilisateurs permettent le contrôle du rendu des listes par un moyen ou un autre, les auteurs devraient envisager de fournir des aides contextuelles dans les listes imbriquées non numérotées. Les utilisateurs non voyants peuvent avoir des difficultés pour savoir où une liste commence et finit et où chaque élément de liste démarre. Par exemple, si une entrée de liste défile sur la ligne suivante à l'écran, il peut sembler que ce soit 2 éléments différents dans la liste. Cela peut poser un problème pour les vieux lecteurs d'écrans.
Pour changer le style des "puces" d'une liste d'élément non ordonnée créée avec l'élément LI, utilisez les feuilles de style. Avec CSS, il est possible de spécifier un style de puce par défaut (ex., 'disc') si une image de puce ne peut pas être chargée.
Exemple.
<HEAD> <TITLE>Using style sheets to change bullets</TITLE> <STYLE type="text/css"> UL { list-style: url(star.gif) disc } </STYLE> </HEAD> <BODY> <UL> <LI>Audrey <LI>Laurie <LI>Alice </UL>
Fin de l'exemple.
Pour s'assurer vraiment que les utilsateurs comprennent les différences entre les éléments de la liste indiqués visuellement, les développeurs de contenu devraient fournir un texte avant ou après la phrase de l'élément de la liste :
Exemple.
Dans cette exemple, une nouvelle information est communiqué grâce au texte ("New"), au stylede la police (gras), et à la couleur (puce jaune, texte rouge sur un fond jaune).
<HEAD> <TITLE>Bullet styles exemple</TITLE> <STYLE type="text/css"> .newtxt { font-weight: bold; color: red; background-color: yellow } .newbullet { list-style : url(yellow.gif) disc } </STYLE> </HEAD> <BODY> <UL> <LI class="newbullet">Roth IRA <SPAN class="newtext">New</SPAN></LI> <LI> 401(k)</LI> </UL> </BODY>
Fin de l'exemple.
Evitez d'utiliser des images comme des puces dans les listes de définition créées avec DL, DT, et DD. Cependant, si cette méthode est utilisée, soyez sûr de fournir un équivalent texte pour les images.
Exemple déconseillé.
<HEAD> <TITLE>Deprecated exemple using image in DL lists</TITLE> </HEAD> <BODY> <DL> <DD><IMG src="star.gif" alt="* ">Audrey <DD><IMG src="star.gif" alt="* ">Laurie <DD><IMG src="star.gif" alt="* ">Alice </DL>
Les développeurs de contenu devraient éviter les styles de liste où les puces fournissent des informations (visuelles) supplémentairtes. Cependant, si vous le faîtes, soyez sûr de fournir un équivalent texte décrivant la signification de la puce :
Exemple déconseillé.
<DL> <DD><IMG src="red.gif" alt="New:">Roth IRA</DD> <DD><IMG src="yellow.gif" alt="Old:">401(k)</DD> </DL>
Cette section discutent de l'accessibilité des tableaux et des éléments qui peuvent être placés dans un élément TABLE. Deux types de tableaux sont exposés : les tableaux utilisés pour organiser les données, et les tableaux utilisés pour un créer une présentation visuelle des pages.
Points de contrôle dans cette section : 5.5, 5.1, 5.2, et 5.6.
Les développeurs de contenu peuvent faire des tableaux de données HTML 4.0 plus accessibles de nombreuses façons :
Le balisage permettra aux navigateurs accessibles et autres agents utilisateurs de restructurer ou de naviguer dans des tableaux d'une manière non visuelle.
Pour de l'information à propos des entêtes de tableau, voir l'algorithme des entêtes de tableau et la discussion dans la recommandation HTML 4.0 Recommendation ([HTML40], section 11.4.3).
Cet exemple montre comment associer les données des cellules ( créées avec TD) avec les entêtes correspondants au moyen de l'attribut "headers". l'attribut "headers" spécifie une liste d'entête de cellules (noms de lignes et de colonne) associée avec la donnée courante de la cellule. Ceci requier que chaque entête de cellule possède un attribut "id".
<TABLE border="1" summary="This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar."> <CAPTION>Cups of coffee consumed by each senator</CAPTION> <TR> <TH id="header1">Name</TH> <TH id="header2">Cups</TH> <TH id="header3" abbr="Type">Type of Coffee</TH> <TH id="header4">Sugar?</TH> <TR> <TD headers="header1">T. Sexton</TD> <TD headers="header2">10</TD> <TD headers="header3">Espresso</TD> <TD headers="header4">No</TD> <TR> <TD headers="header1">J. Dinnen</TD> <TD headers="header2">5</TD> <TD headers="header3">Decaf</TD> <TD headers="header4">Yes</TD> </TABLE>
Fin de l'exemple.
Un synthétisuer vocal pourra rendre ce tableau ainsi :
Titre : Cups of coffee consumed by each senator Résumé : This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar. Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: No Name: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes
Un agent utilisateur visuel affichera le tableau comme suit :
[Description de tableau de
café]
Le prochain exemple associe le même entête (TH) et cellules de donnée (TD) comme précédemment, mais cette fois en utilisant l'attribut "scope" plutôt que "headers". "Scope" doit avoir une des valeurs suivantes : "row", "col", "rowgroup", ou "colgroup." Scope spécifie l'ensemble des cellules de donnée qui doit être associé à la cellule entête courante. Cette méthode est particulièrement utile pour les tableaux simples. Il est à noter que le rendu vocal de ce tableau devra être identique que l'exemple précédent. Un choix entre les attributs "headers" et "scope" est dépendant de la complexité du tableau. Cela n'affecte pas la sortie tant que les relations entre les cellules entête et données sont rendus évidentes par le balisage.
Exemple.
<TABLE border="1" summary="This table charts ..."> <CAPTION>Cups of coffee consumed by each senator</CAPTION> <TR> <TH scope="col">Name</TH> <TH scope="col">Cups</TH> <TH scope="col" abbr="Type">Type of Coffee</TH> <TH scope="col">Sugar?</TH> <TR> <TD>T. Sexton</TD> <TD>10</TD> <TD>Espresso</TD> <TD>No</TD> <TR> <TD>J. Dinnen</TD> <TD>5</TD> <TD>Decaf</TD> <TD>Yes</TD> </TABLE>
Fin de l'exemple.
L'exemple suivant montre comment créer des catégories au sein d'un tableau en utilisant l'attribut "axis".
Exemple.
<TABLE border="1"> <CAPTION>Travel Expense Report</CAPTION> <TR> <TH></TH> <TH id="header2" axis="expenses">Meals <TH id="header3" axis="expenses">Hotels <TH id="header4" axis="expenses">Transport <TD>subtotals</TD> <TR> <TH id="header6" axis="location">San Jose <TH> <TH> <TH> <TD> <TR> <TD id="header7" axis="date">25-Aug-97 <TD headers="header6 header7 header2">37.74 <TD headers="header6 header7 header3">112.00 <TD headers="header6 header7 header4">45.00 <TD> <TR> <TD id="header8" axis="date">26-Aug-97 <TD headers="header6 header8 header2">27.28 <TD headers="header6 header8 header3">112.00 <TD headers="header6 header8 header4">45.00 <TD> <TR> <TD>subtotals <TD>65.02 <TD>224.00 <TD>90.00 <TD>379.02 <TR> <TH id="header10" axis="location">Seattle <TH> <TH> <TH> <TD> <TR> <TD id="header11" axis="date">27-Aug-97 <TD headers="header10 header11 header2">96.25 <TD headers="header10 header11 header3">109.00 <TD headers="header10 header11 header4">36.00 <TD> <TR> <TD id="header12" axis="date">28-Aug-97 <TD headers="header10 header12 header2">35.00 <TD headers="header10 header12 header3">109.00 <TD headers="header10 header12 header4">36.00 <TD> <TR> <TD>subtotals <TD>131.25 <TD>218.00 <TD>72.00 <TD>421.25 <TR> <TH>Totals <TD>196.27 <TD>442.00 <TD>162.00 <TD>800.27 </TABLE>
Fin de l'exemple.
Ce tableau liste les dépenses de voyage à 2 endroits : San José et Seattle, par date, et catégorie (repas, hôtels, et transport). L'image suivante montre comment un agent utilisateur visuel devra afficher le contenu. [Description d'un tableau de voyage]
Points de contrôle dans cette section : 5.3 et 5.4.
Les auteurs devraient utiliser les feuilles de style pour la mise en forme et le positionnement. Cependant, lorsque c'est nécessaire d'utiliser un tableau pour la mise en forme, le tableau doit linéariser dans un ordre de lecture. Quand un tableau est linéarisé, le sommaire des cellules devient une série de paragraphes (ex., down la page) l'un après l'autre. Les cellules devraient avoir du sens quand c'est lu dans l'ordre (par ligne ou par colonne) et devrait inclure des éléments structurels (qui créent des paragraphes, des entêtes, des listes, etc.) donc la page prend du sens après linéarisation.
Egalement, quand vous utilisez les tableaux pour créer une mise en forme, n'utilisez pas de balisage structurel pour créer des effets de présentation visuelle. Par exemple, l'élément TH (entête du tableau) est toujours affiché visuellement centrée, et gras. Si une cellule n'est pas actuellement un entête pour une ligne ou une colonne de données, utilisez les feuilles de style ou les attributs de formatage de l'élément.
Points de contrôle dans cette section : 10.3.
Les tableaux utilisés pour présenter les pages et les tableaux de données où le texte de cellule se déroule pose des problèmes pour les lecteurs d'écran anciens qui n'interpête pas la source HTML ou les navigateurs qui ne permet pas la navigation des cellules de tableau individuel. Ces lecteurs d'écran liront à travers la page, en lisant les phrases sur la même ligne des différentes colonnes comme une seule phrase.
Par exemple, si un tableau est affiché comme ceci sur un écran :
There is a 30% chance of Classes at the University of Wisconsin rain showers this morning, but they will resume on September 3rd. should stop before the weekend.
Cela doit être par un lecteur d'écran comme ceci :
There is a 30% chance of Classes at the University of Wisconsin rain showers this morning, but they will resume on September 3rd. should stop before the weekend.
Les lecteurs d'écran qui lisent la source HTML reconnaîtront la structure de chaque cellule, mais pour les vieux lecteurs d'écran, les développeurs de contenu peuvent miniser le risque du défilement de mot en limitant la quantité de texte dans chaque cellule. Egalement, la portion la plus longue de texte devra être entièrement dans la dernière colonne (la plus à droite pour les tableaux orientés de la gauche vers la droite). Ainsi, si ils se déroulent, ils resteront lisibles de façon cohérente. Les développeurs de contenu devraient tester leur tableau pour le défilement avec une fenêtre de navigateur de dimension "640x480".
Depuis que le balisage de tableau est structurel, et que nous suggérons de séparer la structure de la présentation, nous recommandons d'utiliser les feuilles de style pour créer la mise en forme, l'alignement, et les effets de présentation. Ainsi, les 2 colonnes dans l'exemple précédent pourraient être interprêtées en utilisant les feuilles de style. Voir la section sur les feuilles de styles pour obtenir de l'information.
Test rapide ! Pour obtenir une meilleure compréhension de la façon dont un lecteur d'écran devra afficher un tableau, déplacez une feuille de papier sur votre page en descendant et lisez votre tableau ligne par ligne.
Dans les navigateurs HTML 3.2, les lignes d'un élément TFOOT apparaîtront avant le corps du tableau.
Points de contrôle dans cette section : 13.1, et 13.6.
Les bons textes de liens ne devraient pas être trop général ; n'utilisez pas "cliquer ici." Non seulement, cette phrase est dépendante de l'appareil utilisé (cela implique un appareil de pointage) mais cela ne dit rien sur ce qui doit être trouvé si le lien est suivi. A la place de "cliquer ici", les textes de liens devraient indiquer la nature du lien cible, comme dans "plus d'informations à propos des lions de mer" ou "version texte de cette page". Notez que dans le dernier cas (et d'autres documents au format ou à la langue spécifique), les développeurs de contenu sont invités à utiliser, à la place, la négociation de contenu, ainsi les utilisateurs qui préferrent les versions textes seront fournis automatiquement.
De plus pour expliciter les textes de lien, les développeurs de contenu peuvent spécifier une valeur à l'attribut title qui décrit clairement et précisément la cible du lien.
Si plus d'un lien sur la page partage le même texte de lien, tous ces liens devraient pointer vers la même ressource Ce type de consistance aidera la conception de la page ainsi que son accessibilité.
Si 2 ou plusieurs liens se réfèrent à ces cibles différentes mais partagent le même texte de lien, distinguez les liens en spécifiant une valeur différente pour l'attribut " title" de chacun des éléments A.
"Utilisateurs auditifs" -- les personnes qui sont aveugles, qui ont des difficultés pour voir, ou qui ont des appareils avec de petits ou sans écrans -- sont incapables de balayer la page rapidement de leurs yeux. Pour obtenir une vision d'ensemble de la page ou pour trouver rapidement un lien, ces utilisateurs seront souvent amenés à tabuler d'un lien vers le prochain ou à explorer une liste de liens disponibles sur une page.
Ainsi, pour une série de liens apparentés, introduisez de l'information dans le premier lien, de l'information distinguée dans le lien suivant. Cela fournira une information contextuelle pour les utilisateurs lisant la séquence.
Exemple.
<A href="my-doc.html">My document is available in HTML</A>, <A href="my-doc.pdf" title="My document in PDF">PDF</A>, <A href="my-doc.txt" title="My document in text">plain text</A>
Fin de l'exemple.
Lorsqu'une image est utilisé comme contenu d'un lien, spécifiez un équivalent text pour l'image.
Exemple.
<A href="routes.html"> <IMG src="topo.html" alt="Current routes at Boulders Climbing Gym"> </A>
Fin de l'exemple.
Lorsque les liens sont groupés en un ensemble logique (par exemple, dans une barre de navigation qui apparaît sur chaque page dans un site), ils devraient être balisés comme une unité. Les barres de navigation sont habituellement la première chose qu'une personne rencontre sur une page. Pour les utilisateurs avec des synthétiseurs vocaux, cela signifie qu'ils devront écouter de nombreux liens sur chaque page avant de pour atteindre le contenu intéressant d'une page. Il y a plusieurs façons de permettre aux utilisateurs de contourner des groupes de liens (comme les utilisateurs qui le font avec leur vue quand ils aperçoivent le même ensemble sur toutes les pages.) :
Dans le futur, les agents utilisateurs permettront aux utilisateurs de sauter les éléments comme les barres de navigation.
Avec HTML, uilisez les éléments DIV, SPAN, P, or FRAME pour grouper les liens puis identifiez les groupes avec les attributs "id" ou "class".
Exemple.
Dans cet exemple, l'élément P groupe un ensemble de liens, l'attribut "class" l'identifie comme une barre de navigation (ex., pour les feuilles de style), "tabindex" est paramétré sur une ancre suivant le groupe, et un lien au début du groupe de liens vers l'ancre après le groupe.
<HEAD> <TITLE>How to use our site</TITLE> </HEAD> <BODY> <P class="nav"> [<A href="#how">Bypass navigation bar</A>] [<A href="home.html">Home</A>] [<A href="search.html">Search</A>] [<A href="new.html">New and highlighted</A>] [<A href="map.html">Site map</A>] </P> <H1><A name="how" tabindex="1">How to use our site</A></H1> <!-- content of page --> </BODY>
Fin de l'exemple.
L'accès clavier pour activer les éléments d'une page est important pour beaucoup d'utilisateurs qui ne peuvent pas utiliser un outil de pointage. Les agents utilisateurs peuvent inclure des options qui permettent aux utilisateurs d'associer des touches du clavier à certaines actions. HTML 4.0 permet aux développeurs de contenu de spécifier des raccourcis claviers dans des documents via l'attribut "tabindex".
Exemple.
Dans cet exemple, si l'utilisateur active la touche "C", le lien sera suivi.
<A accesskey="C" href="doc.html" hreflang="en" title="XYZ company home page"> XYZ company home page</A>
Fin de l'exemple.
Les sections suivantes discutent de l'accessibilité des images (y compris des animations simples comme les animations GIF) et les images cliquables.
Pour en savoir plus sur les maths exprimées sous forme d'images, voir la section sur l'utilisation du balisage texte et des feuilles de styles plutôt que les images.
Points de contrôle dans cette section : 1.1.
Quand vous utilisez IMG, spécifiez un équivalent texte court avec l'attribut "alt". Note. La valeur de cet attribut est compris comme "alt-text".
Exemple.
<IMG src="magnifyingglass.gif" alt="Search">
Fin de l'exemple.
Lorsque vous utilisez OBJECT, spécifiez un équivalent texte dans le corps de l'élément OBJECT :
Exemple.
<OBJECT data="magnifyingglass.gif" type="image/gif"> Search </OBJECT>
Fin de l'exemple.
Lorsqu'un équivalent texte court ne suffit pas pour expliciter convenablement la fonction ou le rôle d'une image, fournissez une information supplémentaire dans un fichier désigné par l'attribut "longdesc" :
Exemple.
<IMG src="97sales.gif" alt="Sales for 1997" longdesc="sales97.html">
Dans sales97.html:
A chart showing how sales in 1997 progressed. The chart
is a bar-chart showing percentage increases in sales
by month. Sales in January were up 10% from December 1996,
sales in February dropped 3%, ..
Fin de l'exemple.
Pour les agents utilisateurs qui ne supportent pas "longdesc", fournissez un lien de description juste après le graphique :
Exemple.
<IMG src="97sales.gif" alt="Sales for 1997" longdesc="sales.html"> <A href="sales.html" title="Description of 1997 sales figures">[D]</A>
Fin de l'exemple.
Lorsque vous utilisez OBJECT, spécifiez l'équivalent texte plus long à l'intérieur du contenu de l'élément :
Exemple.
<OBJECT data="97sales.gif" type="image/gif"> Sales in 1997 were down subsequent to our <A href="anticipated.html">anticipated purchase</A> ... </OBJECT>
Fin de l'exemple.
Notez que le contenu OBJECT, à la différence du texte "alt", peut inclure du balisage. Ainsi, les développeurs de contenu peuvent fournir un lien vers l'information supplémentaire à l'intérieur de l'élément OBJECT :
Exemple.
<OBJECT data="97sales.gif" type="image/gif"> Chart of our Sales in 1997. A <A href="desc.html">textual description</A> is available. </OBJECT>
Fin de l'exemple.
Notez. Invisible d-links est désapprouvé en faveur de l'attribut "longdesc".
Un d-link invisible est une petite image (1-pixel) ou transparente dont la valeur de l'attribut "alt" est "D-link" ou "D" et qui fait partie du contenu d'un élément A. Comme les autres d-links, il renvoie à l'équivalent texte d'une image associée. Comme les autres liens, les utilisateurs peuvent y accéder par tabulation. les d-links invisibles, fournissent donc une solution (temporaire) pour les designers qui souhaitent éviter les d-links visibles pour des raisons esthétiques.
Points de contrôle dans cette section : 13.10.
Evitez l'art ascii (illustrations par des caractères) et utilisez de vraies images à la place sachant qu'il est plus fcaile de donner un équivalent texte pour les images. Cependant si l'art ascii doit être utilisé, fournissez un lien pour sauter l'art ASCII, comme suit.
Exemple.
<P> <a href="#post-art">skip over ASCII art</a> <!-- ASCII art goes here --> <a name="post-art">caption for ASCII art</a>
Fin de l'exemple.
L'art ascii peut également être balisé comme ceci [zapper la figure ascii ou consulter une description du graphe]:
Exemple.
% __ __ __ __ __ __ __ __ __ __ __ __ __ __ 100 | * | 90 | * * | 80 | * * | 70 | @ * | 60 | @ * | 50 | * @ * | 40 | @ * | 30 | * @ @ @ * | 20 | | 10 | @ @ @ @ @ | 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 Flash frequency (Hz)
Fin de l'exemple.
UNe autre option pour de l'art ascci plus petit est d'utiliser un élément ABBR avec un "title".
Exemple.
<P><ABBR title="smiley in ascii art">:-)</ABBR>
Fin de l'exemple.
Si l'art ASCII est complexe, s'assurez que l'équivalent texte le décrit avec exactitude.
Une autre manière de remplacer l'art ascii art est d'utiliser des substituts de langage humain. Par exemple, <wink> doit se substituer à un smiley clin d'oeil : ;-). Ou, le mot "par conséquent" peut remplacer des flèches constituées de tiret et de signes plus grand que (ex., -->), et le mot "great" pour l'abbrévation non habituelle "gr8".
Une image cliquable est une image qui possède des "régions réactives". Lorsque l'utilisateur sélectionne une des ces régions, une action s'éxécute -- un lien peut être suivi, de l'information peut être envoyée vers un serveur, etc. Pour rendre une image cliquable accessible, les développeurs de contenu doit s'assurer que chaque action associée à une région visuelle peut être activée sans outil de pointage.
Les images cliquables sotn crées avec l'élément MAP. Le HTML permet 2 types d'images cliquables : côté client (le navigateur de l'utilisateur traite une URI) et côté serveur (le serveur interprête les coordonnées des cliques.). Pour les images cliquables, les développeurs de contenu doit fournir un équivalent texte.
Les développeurs de contenu devraient créer des images cliquabkes côté client (avec "usemap") plutôt que des images cliquables côté serveur (avec "ismap") parce-que les images cliquables côté serveur requèrent un outil d'entrée spécifique. Si les images cliquables côté serveur doivent être utilisées (ex., parce-que la géométrie de la région ne peut être représentée avec des valeurs de l'attribut shape), les auteurs doivent fournir la même fonctionnalité ou l'information dans un format alternatif accessible. UNe manière de faire ceci est de fournir un lien textuel pour chaque région active, ainsi chaque lien est navigable au moyen du clavier. Si vous devez utiliser une image cliquable côté serveur, consultez la section sur les images cliquables côté serveur
Points de contrôle dans cette section : 1.5, 9.1, et 10.5.
Fournissez des équivalents texte pour les images cliquables qui se rapportent à l'information visuelle.
Si AREA est utilisé pour créer la carte, utilisez l'attribut "alt" :
Exemple.
<IMG src="welcome.gif" alt="Image map of areas in the library" usemap="#map1"> <MAP name="map1"> <AREA shape="rect" coords="0,0,30,30" href="reference.html" alt="Reference"> <AREA shape="rect" coords="34,34,100,100" href="media.html" alt="Audio visual lab"> </MAP>
Fin de l'exemple.
L'exemple suivant illustre la même idée, mais utilise OBJECT à la place de IMG pour insérer l'image pour fournir plus d'information à propos de l'image :
Exemple.
<OBJECT data="welcome.gif" type="image/gif" usemap="#map1"> There are several areas in the library including the <A href="reference.html">Reference</A> section and the <A href="media.html">Audio Visual Lab</A>. </OBJECT> <MAP name="map1"> <AREA shape="rect" coords="0,0,30,30" href="reference.html" alt="Reference"> <AREA shape="rect" coords="34,34,100,100" href="media.html" alt="Audio visual lab"> </MAP>
Fin de l'exemple.
En plus de fournir un équivalent texte, fournissez des liens textuels redondants. Si l'élément A est utilisé à la place de AREA, le développeur de contenu peut décrire les régions actives et fournir des liens redondants en même temps :
<OBJECT data="navbar1.gif" type="image/gif" usemap="#map1"> <MAP name="map1"> <P>Navigate the site. [<A href="guide.html" shape="rect" coords="0,0,118,28">Access Guide</A>] [<A href="shortcut.html" shape="rect" coords="118,0,184,28">Go</A>] [<A href="search.html" shape="circle" coords="184.200,60">Search</A>] [<A href="top10.html" shape="poly" coords="276,0,276,28,100,200,50,50,276,0"> Top Ten</A>] </MAP> </OBJECT>
Fin de l'exemple.
Notez que dans l'exemple précédent, l'élément MAP est le contenu de l'élément OBJECT, donc que les liens alternatifs ne seront affichés que si l'image cliquable (navbar1.gif) ne l'est pas.
Notez également que des liens ont été séparés par des crochets ([]). Ceci est pour éviter que les vieux lecteurs d'écran lisent plusieurs liens adjacents comme un lien unique, de même cela aide les utilisateurs voyants à distinguer les liens entre eux visuellement.
Les développeurs de contenu devraient être sûrs qu'ils insèrent des caractères imprimables (comme des crochets ou une barre verticale (|)) entourés par des espaces entre les liens adjacents.
Points de contrôle dans cette section : 1.2.
Quand une image cliquable côté serveur doit être utilisée, les développeurs de contenu devraient fournir une liste alternative de choix d'image cliquable. Il existe trois techniques :
Exemple.
<A href="http://myserver.com/cgi-bin/imagemap/my-map"> <IMG src="welcome.gif" alt="Welcome! (Text links follow)" ismap> </A> <P>[<A href="reference.html">Reference</A>] [<A href="media.html">Audio Visual Lab</A>]
Fin de l'exemple.
Les images cliquables côté client et serveur peuvent être utilisées comme des boutons de validation dans les formulaires. Pour obtenir plus d'information, voir la section sur boutons graphiques.
Bien que les applets puissent être incluses dans un document avec aussi bien l'élément APPLET ou l'élément OBJECT, OBJECT est la méthode préferrée.
Si OBJECT est utilisé, fournissez un équivalent texte dans le contenu de l'élément :
Exemple.
<OBJECT classid="java:Press.class" width="500" height="500"> As temperature increases, the molecules in the balloon... </OBJECT>
Fin de l'exemple.
Un exemple plus complexe prenant avantage du fait que les éléments OBKECT peuvent être inclus pour fournir des représentations alternatives de l'information :
Exemple.
<OBJECT classid="java:Press.class" width="500" height="500"> <OBJECT data="Pressure.mpeg" type="video/mpeg"> <OBJECT data="Pressure.gif" type="image/gif"> As temperature increases, the molecules in the balloon... </OBJECT> </OBJECT> </OBJECT>
Fin de l'exemple.
Si APPLET est utilisé, fournissez un équivalent texte avec l'attribut "alt" et dans le contenu de l'élément APPLET. Ceci permet au contenu de se transformer aiséement pour les agents utilisateurs qui supportent uniquement l'un des deux mécanismes ("alt" ou contenu).
Deprecated exemple.
<APPLET code="Press.class" width="500" height="500" alt="Java applet: how temperature affects pressure"> As temperature increases, the molecules in the balloon... </APPLET>
Points de contrôle dans cette section : 8.1
Si une applet (créée avec OBJECT ou APPLET) requiert une interaction de l'utilisateur (ex., la possibilité d'agir dans une expérience de physique) qui ne peut pas être dupliquée dans un format alternatif, rendez l'applet directement accessible.
Pour avoir plus d'informations sur le développement des applets accessibles, voyez [JAVAACCESS] et [IBMJAVA]. Ces compagnies ont développé une API Accessibilité ainsi qu'ils ont rendu les classes Java Swing accessibles.
Points de contrôle dans cette section : 8.1 et 1.4.
Fournissez un équivalent texte comme pour une image et des descriptions auditives de l'information visuelle et des titres où c'est nécessaire. Si une applet créé des mouvements, les développeurs devraient fournir un mécanisme pour geler ce mouvement (par exemple, voir [TRACE]). Voyez également la prochaine section pour toute information apropos des présentations audio et vidéo accessibles.
Des présentations auditives doivent être accompagnées par des transcriptions texte, des équivalents textuels des événements audio. Lorsque ces transcriptions sont présentées simultanément avec une présentation vidéo, elles sont appelées sous-titres et sont utilisées par les personnes qui ne peuvent pas entendre les bandes sonores du matériel vidéo.
Certains formats de média (ex., QuickTime 3.0 et SMIL) permettent des sous-titres et des descriptions vidéo qui peuvent être ajoutés au clip multimédia. SAMI permet d'ajouter des sous-titres. L'exemple suivant démontre que les sous-titres devraient incluire la voix ainsi que les autres sons d'ambiance qui aident ceux qui visionnent à comprendre ce qui se passe.
Exemple.
Captions for a scene from "E.T." The phone rings three times, then is answered.
[phone rings]
[ring]
[ring]
Hello?"
Fin de l'exemple.
Tant que le format que vous utilisez supporte des pistes alternatives, deux versions du film pourrait être faites, une avec des sous-titres et de la vidéo descriptive, et l'autre sans. Certaines technologies, comme SMIL et SAMI, permettent de séparer les fichiers audio et vidéo pour être combinés avec des fichiers textes au moyen d'un fichier de synchronisation qui permet de créer des sous-titrages de l'audio et de films.
Certaines technologies permettent également à l'utilisateur de choisir entre plusieurs ensembles de sous-titres afin de répondre à leur compétente de lecture. Pour plus d'informations, voyez la spécification SMIL 1.0 ([SMIL]).
Des équivalents pour les sons peuvent être fournis sous la forme d'une phrase de texte sur la page qui lie vers une transcription texte ou une description du fichier son. Le lien de la transcription devrait apparaître à un endroit hautement visible comme le haut de la page. Cependant, si un script charge automatiquement un son, il devrait permettre également de charger une indication visuelle que le sont est en cours d'exécution et fournir une description ou une transcription du son.
Note. Quelques controverses entourent cette technique car le navigateur devrait charger la forme visuelle de l'information à la place de la forme audio si les préférences de l'utilisateur sont paramétrées pour le faire. Cependant, les stratégies doivent fonctionner également dans les navigateurs d'aujourd'hui.
Pour plus d'information, voyez [NCAM].
Points de contrôle dans cette section : 1.3, et 7.3.
Les descriptions audio des pistes visuelles fournissent la narration des éléments clés visules sans interférer avec le son ou les dialogues d'un film. Les éléments visuels clés incluent les actions, les positions, le langage du coirps, les graphiques, et le texte affiché. Les descriptions sonores sont utilisés tout d'abord par les personnes qui sont aveugles pour suivre l'action et l'information non-audio du matériel vidéo.
Exemple.
Here's an exemple of a collated text transcript of a clip from "The Lion King" (available at [DVS]). Note that the Describer is providing the auditory description of the video track and that the description has been integrated into the transcript.
Simba: Yeah!
Describer: Simba races outside, followed by his parents. Sarabi smiles and nudges Simba gently toward his father. The two sit side-by-side, watching the golden sunrise.
Mufasa: Look Simba, everything the light touches is our kingdom.
Simba: Wow.
Fin de l'exemple.
Note. S'il n'y a pas d'information visuel importante, par exemple, une tête animée parlant qui décrit ( à travers une voix préenregristrée) comment utilisé le site, alors une description audio n'est pas nécessaire.
Pour les films, fournissez des descriptions auditives qui est synchronisées avec l'audio originale. Voir la section sur l' information audio pour plus d'informations à propos des formats multimédia.
Les transcriptions de texte collationné permettent l'accès aux personnes avec des handicaps visuels et auditifs. Cela permet également d'indexer et de rechercher l'information contenue dans les matériels audio/visuels.
Les transcriptions de texte collationné incluent les dialogues parlés aussi bien que les autres sons significants, y compris des sons hors-champs et plein-champs, la musique, les rires, les applaudissements, etc. Autrement dit, tous les textes qui apparaissent dans les titres aussi bien que toutes les descriptions fournies dans dans la description auditive.
Lorsque c'est nécessaire, un équivalent texte devrait être fourni pour les informations visuelles afin de permettre la compréhension de la page. Par exemple, prenons une animation se répétant qui montre une couverture nuageuse et la précipitation dans un rapport de bulletin météo. L'animation météo aide à la compréhension du reste du bulletin météo (qui est présenté en langue naturel - texte), une description moins prolixe de l'animation est nécessaire. Cependant, si l'animation apparaît dans un ensemble pédagogique où les étudiants apprennent la formation des nuages en relation avec le relief terrestre, alors l'animation devrait être décrite pour ceux qui ne peuvent pas voir l'animation mais qui veulent également apprendre la leçon.
Voir également la section sur le style du texte pour le contrôle du clignotement.
D'autres objets, tels que ceux qui requèrent un plug-in, devraient également utiliser l'élément OBJECT. Cependant, Pour des raisons de compatibilité antérieure avec les navigateurs Netscape, utilisez l'élément propriétaire EMBED à l'intérieur de l'élément OBJECT comme suit :
Exemple désapprouvé.
<OBJECT classid="clsid:A12BCD3F-GH4I-56JK-xyz" codebase="http://site.com/content.cab" width=100 height=80> <PARAM name="Movie" value="moviename.swf"> <EMBED src="moviename.swf" width=100 height=80 pluginspage="http://www.macromedia.com/shockwave/download/"> </EMBED> <NOEMBED> <IMG alt="Still from Movie" src="moviename.gif" width=100 height=80> </NOEMBED> </OBJECT>
Fin de l'exemple.
Pour plus d'information voir pour [MACROMEDIA].
Pour les utilisateurs capables de voir, les frames peuvent organiser une page en un ensemble de zones différentes. Pour les utilisateurs qui ne peuvent pas voir, les relations entre les contenus des frames (ex., un frame avec un sommaire de navigation, une autre avec le sommaire au complet) doivent être définies par des moyens différents.
Les frames tels qu'ils sont mis en oeuvre aujourd'hui (avec les éléments FRAMESET, FRAME, et IFRAME) sont problématiques pour plusieurs raisons :
Dans les sections suivantes, Nous présentons comment concevoir des frames plus accessibles. Nous fournissons également une alternative aux frames qui utilisent HTML 4.0 et CSS et adressons beaucoup des limitations des réalisations actuelles des frames.
Points de contrôle dans cette section : 12.1.
Exemple.
Utilisez l'attribut "title" pour nommer les frames.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"> <HTML> <HEAD> <TITLE>A simple frameset document</TITLE> </HEAD> <FRAMESET cols="10%, 90%" title="Our library of electronic documents"> <FRAME src="nav.html" title="Navigation bar"> <FRAME src="doc.html" title="Documents"> <NOFRAMES> <A href="lib.html" title="Library link"> Select to go to the electronic library</A> </NOFRAMES> </FRAMESET>
Fin de l'exemple.
Points de contrôle dans cette section : 12.2.
Exemple.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"> <HTML> <HEAD> <TITLE>Today's news</TITLE> </HEAD> <FRAMESET cols="10%,*,10%"> <FRAMESET rows="20%,*"> <FRAME src="promo.html" name="promo" title="promotions"> <FRAME src="sitenavbar.html" name="navbar" title="Sitewide navigation bar" longdesc="frameset-desc.html#navbar"> </FRAMESET> <FRAME src="story.html" name="story" title="Selected story - main content" longdesc="frameset-desc.html#story"> <FRAMESET rows="*,20%"> <FRAME src="headlines.html" name="index" title="Index of other national headlines" longdesc="frameset-desc.html#headlines"> <FRAME src="ad.html" name="adspace" title="Advertising"> </FRAMESET> <NOFRAMES> <p><a href="noframes.html">No frames version</a></p> <p><a href="frameset-desc.html">Descriptions of frames.</a></p> </NOFRAMES> </FRAMESET> </HTML>
frameset-desc.html peut être défini comme suit :
#Navbar - this frame provides links to the major sections of the site: World News, National News, Local News, Technological News, and Entertainment News. #Story - this frame displays the currently selected story. #Index - this frame provides links to the day's headline stories within this section.
Fin de l'exemple.
Notez que si le sommaire du frame change, l'équivalent texte ne s'applique plus. Egalement, les liens vers les descriptions d'un frame devraient être fournis également avec d'autres contenus alternatifs dans l'élément NOFRAMES d'un FRAMESET.
Exemple.
Dans cet exemple, si l'utilisateur lit "top.html" :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"> <HTML> <HEAD> <TITLE>This is top.html</TITLE> </HEAD> <FRAMESET cols="50%, 50%" title="Our big document"> <FRAME src="main.html" title="Where the content is displayed"> <FRAME src="table_of_sommaire.html" title="Table of sommaire"> <NOFRAMES> <A href="table_of_sommaire.html">Table of sommaire.</A> <!-- other navigational links that are available in main.html are available here also. --> </NOFRAMES> </FRAMESET> </HTML>
et si l'agent utilisateur n'affiche pas les frames, l'utilisateur aura accès (via un lien) vers une version non-frame de la même information.
Fin de l'exemple.
Points de contrôle dans cette section : 6.2.
Les développeurs de contenu doivent fournir des équivalents texte des frames, de façon à ce que le sommaire et les relations entre les frames aient du sens. Notez que lorsque le sommaire d'un frame change, que toutes les descriptions changent également. Ce n'est pas possible si une image est insérée directement dans un frame. Donc, les dévéloppeurs de contenu devraient toujours rendre le source ("src") d'un frame d'un fichier HTML. Les images peuvent être insérées à l'intérieur d'un fichier HTML et leurs alternatives textes évolueront correctement.
Exemple.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"> <HTML> <HEAD> <TITLE>A correct frameset document</TITLE> </HEAD> <FRAMESET cols="100%" title="Evolving frameset"> <FRAME name="goodframe" src="apples.html" title="Apples"> </FRAMESET> </HTML>
<!-- In apples.html --> <P><IMG src="apples.gif" alt="Apples">
Fin de l'exemple.
L'exemple suivant desapprouvé devrait être évité car il insère IMG directement dans un frame :
Exemple désapprouvé.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"> <HTML> <HEAD> <TITLE>A bad frameset document</TITLE> </HEAD> <FRAMESET cols="100%" title="Static frameset"> <FRAME name="badframe" src="apples.gif" title="Apples"> </FRAMESET> </HTML>
Notez que si, pour l'exemple, un lien provoque l'insertion d'une nouvelle image dans un frame :
<P>Visit a beautiful grove of <A target="badframe" href="oranges.gif" title="Oranges">oranges</A>
le titre initial du frame ("Apples") ne correspondra plus avec le contenu courant du frame ("Oranges").
Points de contrôle dans cette section : 10.1.
Les développeurs de contenu devraient éviter de spécifier une nouvelle fenêtre comme la cible d'un frame avec target="_blank".
Une des utilisations les plus communes des frames est de séparer la fenêtre du navigateur de l'utilisateur en 2 parties : une fenêtre de navigation et une fenêtre de contenu. Comme alternative aux frames, nous vous encourageons à essayer la chose suivante :
Exemple.
<P> <OBJECT data="nav.html"> Aller au <A href="nav.html">sommaire</A> </OBJECT>
Placer le mécanisme de navigation à la fin du document signifie que lorsque les feuilles de style sont désactivées, les utilisateurs ont accès à l'information importante du document en premier.
OBJECT { float: left; width: 25% }
La règle CSS suivante attache le mécanisme de navigation au coin gauche bas de la page et le conserve même si l'utilisateur défile la page vers le bas :
OBJECT { position: fixed; left: 0; bottom: 0 }
Notez. Que les mécanismes de navigation ou autre contenu peuvent être insérés dans un document au moyen des server-side includes.
Cette section discute de l'accessibilité des formulaires et des contrôles de formulaire qui peuvent être placé dans un élément FORM.
Points de contrôle dans cette section : 9.4 et 9.5.
Voir la section sur l'accès du clavier pour plus d'informations.
Les développeurs de contenu devraient grouper l'information lorsque c'est naturel et approprié. Quand les contrôles de formulaire peuvent être groupés en unités logiques, utilisez l'élément FIELDSET et labellisez ces unités avec l'élément LEGEND :
Exemple.
<FORM action="http://somesite.com/adduser" method="post"> <FIELDSET> <LEGEND>Personal information</LEGEND> <LABEL for="firstname">First name: </LABEL> <INPUT type="text" id="firstname" tabindex="1"> <LABEL for="lastname">Last name: </LABEL> <INPUT type="text" id="lastname" tabindex="2"> ...more personal information... </FIELDSET> <FIELDSET> <LEGEND>Medical History</LEGEND> ...medical history information... </FIELDSET> </FORM>
Fin de l'exemple.
Points de contrôle dans cette section : 12.4 et 10.2.
Un exemple de LABEL utilisé avec "for" en HTML 4.0 est donné dans la section précédente.
Les développeurs de contenu devraient grouper l'information lorsque c'est naturel et approprié. Pour des listes longues de menu de sélection (ce qui être difficile à suivre), les développeurs de contenu devraient grouper les éléments SELECT (définis par OPTION) de façon hiérarchique en utilisant l'élément OPTGROUP. Spécifier un label pour le groupe des options avec l'attribut label sur OPTGROUP.
Exemple.
<FORM action="http://somesite.com/prog/someprog" method="post"> <P> <SELECT name="ComOS"> <OPTGROUP label="PortMaster 3"> <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 with ComOS 3.7.1 <OPTION label="3.7" value="pm3_3.7">PortMaster 3 with ComOS 3.7 <OPTION label="3.5" value="pm3_3.5">PortMaster 3 with ComOS 3.5 </OPTGROUP> <OPTGROUP label="PortMaster 2"> <OPTION label="3.7" value="pm2_3.7">PortMaster 2 with ComOS 3.7 <OPTION label="3.5" value="pm2_3.5">PortMaster 2 with ComOS 3.5 </OPTGROUP> <OPTGROUP label="IRX"> <OPTION label="3.7R" value="IRX_3.7R">IRX with ComOS 3.7R <OPTION label="3.5R" value="IRX_3.5R">IRX with ComOS 3.5R </OPTGROUP> </SELECT> </FORM>
Fin de l'exemple.
Dans le prochain exemple, nous spécifions un ordre de tabulation au sein des éléments (par ordre, "field2", "field1", "submit") avec "tabindex":
Exemple.
<FORM action="submit" method="post"> <P> <INPUT tabindex="2" type="text" name="field1"> <INPUT tabindex="1" type="text" name="field2"> <INPUT tabindex="3" type="submit" name="submit"> </FORM>
Fin de l'exemple.
Cet exemple spécifie "U" comme la clé d'accès (par "accesskey"). Taper "U" donne une précision sur le label, qui à son tour donne une précision sur le contrôle d'entrée, ainsi l'utilisateur peut saisir le texte.
Exemple.
<FORM action="submit" method="post"> <P> <LABEL for="user" accesskey="U">name</LABEL> <INPUT type="text" id="user"> </FORM>
Fin de l'exemple.
Utiliser les images pour décorer les boutons permet aux développeurs de rendre leurs formulaires uniques et plus faciles à comprendre. Utiliser une image pour un bouton (ex., avec l'élément INPUT ou BUTTON) n'est pas forcément inaccessible - en considérant qu'un équivalent texte est fourni pour l'image.
Cependant, un bouton graphique d'envoi de formulaire créé avec INPUT, type="image" crée un type d'image cliquable côté client. Lorsque le bouton est cliqué avec une souris, les coordonnées x et y du clic de la souris sont envoyés au serveur comme une partie des données d'envoi du formulaire.
Dans la section Image et image cliquable, Nous expliquons pourquoi il est préférable de ne pas utiliser les images cliquables côté serveur, et nous suggérons d'utiliser les images cliquables côtés client à la place. En HTML 4.0, les boutons graphiques peuvent être dorénavant des images cliquables côté client. Pour préserver la fonctionnalité fournie par le serveur, les auteurs ont les options suivantes, tels que définies dans la recommandation HTML 4.0 ([HTML40], section 17.4.1) :
Si le serveur agit différemment dépendant de l'endroit cliqué, les utilisateurs de navigateurs non graphiques seront désavantagés.
Pour cette raison, les auteurs devraient considérer des approches différentes :
- Utilisez plusieurs boutons d'envoi (chacun avec sa propre image) à la place d'un bouton d'envoi graphique unique. Les auteurs peut utiliser les feuilles de style pour contrôler la position de ces boutons.
- Utilisez une image cliquable côté client en même temps que le scripting.
Points de contrôle dans cette section : 10.4.
Exemple.
Certaines technologies d'assistance requèrent un texte initiale dans les contrôles de formulaire tels que TEXTAREA afin que cela fonctionne correctement.
<FORM action="http://somesite.com/prog/text-read" method="post"> <P> <TEXTAREA name=yourname rows="20" cols="80"> Please enter your name here. </TEXTAREA> <INPUT type="submit" value="Send"><INPUT type="reset"> </P> </FORM>
Fin de l'exemple.
Fournissez un équivalent texte pour les images utilisées comme un bouton d'envoi (submit) :
Exemple.
<FORM action="http://somesite.com/prog/text-read" method="post"> <P> <INPUT type="image" name=submit src="button.gif" alt="Submit"> </FORM>
Fin de l'exemple.
Voir également la section sur les accès clavier car cela s'applique aux contrôles de formulaire.
Dans les navigateurs HTML 3.2,
Cette section discutent de l'accessibilité des scripts incluent dans par l'intermédiaire d'un élément SCRIPT.
Points de contrôle dans cette section : 6.3.
Les développeurs de contenu doivent s'assurer que les pages sont accessibles avec les scripts désactivés ou dans des navigateurs qui ne supportent pas les scripts.
Exemple déprécié. Ceci est un lien mort pour un agent utilisateur qui ne supportent pas les scripts ou ceux-ci sont désactivés.
<A href="javascript:">...</A>
Points de contrôle dans cette section : 9.3 et 6.4.
Un gestionnaire d'événement est un script qui est appelé lorsqu'un certain événement a lieu (e.x., la souris se déplace, une touche est tapée, le document est chargé, etc.). En HTML 4.0, les gestionnaires d'événement sont attachés à des éléments via les attributs de gestion d'événement (les attributs commence avec "on", come dans "onkeyup").
Certains gestionnaires d'événements, lorsqu'ils sont invoqués, produisent des effets purement décoratifs comme une mise en valeur de l'image ou un changement de la couleur d'un élément du texte. D'autres gestionnaires d'événements produisent des effets bien plus substantiels, tels que la prise en charge de calcul, la fourniture d'une information importante à l'utilisateur, ou soumettre un formulaire. Pour les gestionnaires d'événement qui font plus que le changement de présentation d'un élément, les développeurs de contenu devraient faire les choses suivantes :
Noter qu'il n'y a pas d'équivalent clavier du double-click ("ondblclick") en HTML 4.0.
Une façon d'accomplir cecu est avec l'élément NOSCRIPT. Le contenu de cet élément est interprêté lorsque les scripts ne sont pas opérationnels.
Exemple.
<SCRIPT type="text/tcl"> ...Un script Tcl pour donner la feuille de résultats d'un sport... </SCRIPT> <NOSCRIPT> <P>Results from yesterday's games:</P> <DL> <DT>Bulls 91, Sonics 80. <DD><A href="bullsonic.html">Bulls vs. Sonics game highlights</A> ...more scores... </DL> </NOSCRIPT>
Fin de l'exemple.
Points de contrôle dans cette section : 3.3.
Les sections suivantes listes quelques techniques utilisant CSS pour concevoir des documents accessibles et quelques pour écrire des feuilles de style efficaces. En HTML, Les feuilles de style peuvent être spécifiées de façon externe par l'élément LINK, dans l'entête du document par l'élément STYLE, ou pour un élément spécifique par l'attribut style.
CSS1 ([[CSS1]) et CSS2 ([[CSS2]) permettent aux développeurs de contenu de dupliquer la plupart des possibilités de présentation de HTML 4.0 et donnent plus de latitude à moindre coût. Cependant, tant que la plupart des utilisateurs ne possèdent pas de navigateurs qui supportent les feuilles de style, toutes les tournures stylistiques ne peuvent être définies de façon satisfaisante avec les feuilles de style. Nous fournissons également des exemples sur les façons d'utiliser les options de HTML 4.0 (ex., tableaux, texte bitmap) de manière plus accessibles lorsqu'elles doivent être utilisées.
Voir également la section sur le balisage de texte.
Points de contrôle dans cette section : 6.1 et 3.4.
Voici les règles pour créer des feuilles de style qui permettent l'accessibilité :
Quelques exemples suivent.
Exemple.
Utilisez em pour préciser les tailles de police, comme dans :
H1 { font-size: 2em }plutôt que :
H1 { font-size: 12pt }
Fin de l'exemple.
Exemple.
Utilisez les longueurs relatives et les pourcentages.
BODY { margin-left: 15%; margin-right: 10%}
Fin de l'exemple.
Exemple.
Utilisez uniquement les unités de longueur absolue quand les caractéristiques physiques du médium de sortie sont connues.
.businesscard { font-size: 8pt }
Fin de l'exemple.
Exemple.
Toujours spécifier une police générique par défaut :
BODY { font-family: "Gill Sans", sans-serif }
Fin de l'exemple.
Exemple.
Utilisez des nombres, non pas des noms, pour les couleurs :
H1 {color: #808000} H1 {color: rgb(50%,50%,0%)}
Fin de l'exemple.
A la place d'utiliser des éléments et des attributs de présentation dépréciés, utilisez les nombreuses propriétés CSS pour contrôler les caractérisques des polices : 'font-family', 'font-size', 'font-size-adjust', 'font-stretch', 'font-style', 'font-variant', et 'font-weight'.
Les propriétés CSS2 suivantes peuvent être utilisées pour contrôler l'information sur la police : 'font', 'font-family', 'font-size', 'font-size-adjust', 'font-stretch', 'font-style', 'font-variant', et 'font-weight'.
Utilisez les à la place des éléments et des attributs de police dépréciés suivants en HTML : FONT, BASEFONT, "face", et "size".
Si vous devez utiliser des éléments HTML pour contrôler l'information sur la police, utilisez BIG et SMALL, qui ne sont pas dépréciés.
Exemple.
<STYLE type="text/css"> P.important { font-weight: bold } P.moins-important { font-weight: lighter; font-size: smaller } H2.soussection { font-family: Helvetica, sans-serif } </STYLE>
Fin de l'exemple.
Points de contrôle dans cette section : 7.2.
Les propriétés CSS2 suivantes peuvent être utilisées pour styler le texte :
Les développeurs de contenu devraient utiliser les feuilles de style pour styler le texte plutôt que de représenter le texte en images. Utilisez le texte à place des images signifie que l'information sera accessible à un plus grand nombre d'utilisateurs (avec des synthétiseurs vocaux, des afficheurs braille, des afficheurs graphiques, etc.). Utiliser les feuilles de style permettront également aux utilisateurs de remplacer les styles des auteurs et de changer les couleurs ou les tailles de polices plus facilement.
S'il est nécessaire d'utiliser un bitmap pour créer un effet de texte(police spéciale, transformation, ombres, etc.) le bitmap doit être accessible (voir les sections sur les équivalents textes et sur les pages alternatives).
Exemple.
Dans cet exemple, l'image insérée montre les caractères "exemple" en grands et rouges, et est capturée par ma valeur de l'attribut "alt".
<P>This is an <IMG src="BigRedexemple.gif" alt="exemple"> of what we mean. </P>
Fin de l'exemple.
Les propriétés CSS2 suivantes peuvent être utilisées pour contrôler la mise en forme et la position du texte :
L'exemple suivant montre comment utiliser les feuilles de style pour créer un effet de lettrine.
Exemple.
<HEAD> <TITLE>Lettrines</TITLE> <STYLE type="text/css"> .dropcap { font-size : 120%; font-family : Helvetica } </STYLE> </HEAD> <BODY> <P><SPAN class="dropcap">O</SPAN>nce upon a time... </BODY>
Note. Au moment de l'écriture de ce document, le pseudo-élément ':first-letter', qui permet aux développeurs de contenu de faire référence à la première lettre d'un corps de texte, n'est pas supporté de façon importante.
Points de contrôle dans cette section : 2.1 et 2.2.
Utilisez les propriétés CSS pour spécifier les couleurs :
S'assurez que l'information n'est pas fournie à travers les couleurs seulement. Par exemple, quand vous demandez une entrée de la part des utilisateurs, n'écrivez pas "Sélectionnez un élément parmi la liste de ceux qui sont en vert." A la place , s'assurez que l'information est disponible à d'autres effets de style (ex., un effet de police) et à travers le contexte (ex., des liens textes explicites).
Par exemple, dans ce document, des exemples sont stylés par défaut (grâce à des feuilles de style) comme suit :
Test rapide ! Pour tester si votre document continue à fonctionner sans les couleurs, examiner le avec un écran monochrome ou les couleurs du navigateur désactivées. Essayez également un schéma de couleur dans votre navigateur qui n'utilisent que le noir, le blanc, et les quatres gris des navigateurs et voyez si vos pages sont toujours consistantes.
Test rapide ! Pour tester si le contraste de couleur est suffisant pour être lu par des personnes avec des déficiences de couleur ou par ceux qui ont des écrans avec de basses résolutions, imprimer les pages sur une imprimante noir et blanc (avec les fonds et les couleurs apparaissant en niveau de gris). Essayez également de prendre la sortie et de la photocopier itérativement 2 à 3 fois pour voir comment la copie se dégrade. Cela vous montrera si vous avez besoin d'ajouter des informations redondantes (exemples : des hyperliens qui sont habituellement soulignés sur les pages web), ou si les information sont trop petites ou indistinctes pour être traitées correctement.
Pour obtenir plus d'information sur les couleurs et les contrastes, voir [LIGHTHOUSE].
Présentation, positionnement, superposition, et alignement devraient être réalisés grâce à des feuilles de style (notamment en utilisant le positionnement CSS flottant et absolu) :
Si les développeurs de contenu ne peuvent pas utiliser les feuilles de style et doivent utiliser des images transparentes ou invisibles (ex., avec IMG) pour présenter les images sur la page, ils devraient spécifier le alt="" pour celles-ci.
Exemple déprécié.
Les auteurs ne devraient pas utiliser les espaces pour la valeur de "alt" pour éviter que les motes s'associe lorsque les images ne sont pas chargées :
mom poème requère un grand espace<IMG src="10pttab.gif" alt=" ">ici
Dans l'exemple suivant, une image est utilisée pour forcer l'apparition d'un graphique à une position donnée :
<IMG src="spacer.gif" alt="spacer"> <IMG src="colorfulwheel.gif" alt="The wheel of fortune">
Fin de l'exemple.
Les règles et bordures peuvent évoquer la notion de "séparation" aux utilisateurs voyants mais cette signification ne peut pas être déduite en dehors d'un contexte visuel.
Utilisez les propriétés CSS pour spécifier le style de la bordure :
Les auteurs devraient utiliser les feuilles de style pour créer les règles et les bordures.
Exemple.
Dans cet exemple, l'élément H1 aura une bordure supérieure qui est large de 2px, rouge et séparée du contenu de 1em :
<HEAD> <TITLE>Ligne rouge avec feuille de style</TITLE> <STYLE type="text/css"> H1 { padding-top: 1em; border-top: 2px red } </STYLE> </HEAD> <BODY> <H1>Chapitre 8 - Afficheurs auditifs et tactiles</H1> </BODY>
Fin de l'exemple.
Si une règle (ex., l'élément HR) est utilisée pour indiquer la structure, soyez sûr d'indiquer la structure d'une manière non-visuel également. (ex., en utilisant un balisage structurel).
Exemple.
Dans cet exemple, l'élément DIV est utilisé pour créer une barre de navigation, qui inclut un séparateur horizontal.
<DIV class="navigation-bar"> <HR> <A rel="Next" href="next.html">[Page suivante]</A> <A rel="Previous" href="previous.html">[Page précédente]</A> <A rel="First" href="first.html">[Première page]</A> </DIV>
Fin de l'exemple.
Cet index liste chaque point de contrôle et les sections dans ce document où ils sont expliqués. Egalement, chaque numéro de régle est lié à sa définition dans le document des règles. Chaque point de contrôle est lié également à sa définition dans le document des règles.
Points de contrôle dans cette section : 11.2.
Version linéaire de l'index des éléments HTML 4.0.
Cet index liste tous les éléments HTML 4.0. La première colonne de ce tableau donne un lien vers la définition de l'élément dans la spécification HTML 4.0 ([HTML40]). Les éléments qui sont dépréciés en HTML 4.0 sont suivis par un astérique. Les éléments qui sont obsolètes en HTML 4.0 ou qui n'existe pas dans les spécifications W3C du HTML (2.0, 3.2, 4.0) n'apparaissent pas dans ce tableau.
La seconde colonne indique les autres spécifications pour le HTML qui comprennent chaque élément. La troisième colonne indique le rôle de l'élément.
La dernière colonne liste les sections dans le document courant où les éléments sont présentés. Une entrée "N/A" signifie que l'élément n'est pas discuté dans ce document.
Version linéaire de l'index des attributs HTML 4.0.
Cet index liste quelques attributs de HTML 4.0 qui affecte l'accessibilité et à quels éléments ils s'appliquent. La première colonne de ce tableau donne le lien vers la définition de l'attribut dans la spécification HTML 4.0 ([HTML40]). Les attributs et les éléments qui sont dépréciés en HTML 4.0 ([HTML40]) sont suivis par un astérisque (*). Les attributs et les éléments qui sont obsolètes en HTML 4.0 ou qui n'existe pas dans les spécification W3C de HTML (2.0, 3.2, 4.0) n'apparaissent pas dans ce tableau. Les attributs qui s'appliquent à la plupart des éléments HTML 4.0 sont indiqués comme tels ; consultez la spécification HTML 4.0 pour la liste exacte des élements avec leurs attributs.
La seconde colonne indique d'autres spécifications HTML qui inclut chaque attribut. La troisième colonne indique les éléments qui sont concernés par chaque attribut. La quatrième colonne indique le rôle de l'attribut.
La dernière colonne liste les sections dans le document courant où les attributs sont discutés. Une entrée "N/A" signifie que l'attribut n'est pas discuté dans ce document.
La liste suivante donne l'ensemble des attributs qui ne sont pas directement reliés à des problèmes d'accessibilité. Les développeurs de contenu devraient utiliser les feuilles de style à la place des attributs de présentation. Pour plus de détails sur tous les attributs de gestion d'événements, voyez la section sur les gestionnaires d'événements indépendants du matériel.
Le brouillon original de ce document est basé sur "The Unified Web Site Accessibility Guidelines" ([UWSAG]) rassemblé par the Trace R & D Center à l'Université du Wisconsin. Ce document inclut une liste supplémentaire traditionnelle de participants.
Pour la dernière version des spécifications du W3C, consultez la liste des Rapports Techniques du W3C.
Note. W3C cannot maintain stability for any of the following references outside of its control. These references are included for convenience.