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

W3C

Techniques pour les règles d'accessibilité du contenu Web 1.0

Note du W3C 5-mai-1999

Cette version:
http://www.w3.org/TR/1999/WAI-WEBCONTENT-TECHS-19990505
Les autres versions de ce document ne sont pas disponibles.
Latest version:
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS
Version précédente :
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324/wai-pageauth-tech
Dernière version des "règles pour l'accessibilité du contenu Web 1.0"
http://www.w3.org/TR/WAI-WEBCONTENT
Editeurs :
Wendy Chisholm, Centre R & D Trace, Université du Wisconsin -- Madison
Gregg Vanderheiden, Centre R & D Trace, Université du Wisconsin -- Madison
Ian Jacobs, W3C

Résumé

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

Statut de ce document

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 à wai-wcag-editor@w3.org.

Sommaire


1 Priorités

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é.

[Priorité 1]
Un développeur de contenu Web doit satisfaire ce point de contrôle. Sinon, un ou plusieurs groupes auront l'impossibilité d'accéder à l'information du document. Satisfaire ce point de contrôle est une exigence élémentaire pour que certains groupes puissent être capables d'utiliser les documents Web.
[Priorité 2]
Un développeur de contenu Web devrait satisfaire ce point de contrôle. Sinon, un ou plusieurs groupes auront des difficultés d'accès à l'information du document. Satisfaire ce point de contrôle lèvera certaines barrières empêchant l'accès des documents Web.
[Priorité 3]
Un développeur de contenu Web peut respecter ce point de contrôle. Sinon un ou plusieurs groupes auront quelques difficultés pour accéder à l'information du document. Satisfaire ce point de contrôle améliorera l'accès aux documents Web.

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.


2 Comment les techniques sont-elles organisées ?

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 :

Thèmes sur l'accessibilité
Cette section introduit quelques techniques générales pour promouvoir une accessibilité qui est indépendante de tout langage de balisage.
Techniques HTML
Cette section explique comment mettre en oeuvre des points de contrôle applicables en HTML (voir [HTML40], [HTML32]) et elle inclut de nombreux exemples pratiques.Pour compléter cette section, un index des éléments HTML éléments et des attributs fournit de l'information à propos de tous les éléments de HTML 4.0 et de tous les attributs qui affectent l'accessibilité directement. Pour chaque élément, l'index inclut des liens vers les techniques qui s'y réfèrent.
Techniques CSS
Cette section explique comment mettre en oeuvre les points de contrôle applicables en CSS1 et CSS2 (voir [CSS1], [CSS2]).

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.

2.1 Exemples et exemple déclassés

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.

3 Thème sur l'accessibilité

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.

3.1 Structure contre présentation

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.

3.2 Equivalents texte

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é ?

3.2.1 Vue d'ensemble des technologies

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.

3.2.2 Compatibilité antérieure

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 :

3.3 Pages alternatives

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 :

  1. Permettre aux utilisateurs de naviguer grâce à une page séparée qui est accessible et maintenue avec la même fréquence que la page originale inaccessible.
  2. A la place de page statiques alternatives, paramétrer des scripts côté serveur qui génèrent des versions accessibles des pages à la volée.
  3. Voir les exemples pour les frames et les scripts.
  4. Fournir un numéro de télephone, un numéro de fax, une adresse email ou postale où l'information est disponible et accessible en permanence (24 heures sur 24).

Voici deux techniques pour pour créer un lien vers une page alternative accessible :

  1. Fournir, en haut des pages principales et alternatives, des liens permettant à un utilisateur de passer de l'une à l'autre. Par exemple, en haut d'une page graphique inclure un lien vers une page purement textuelle, et au haut de cette page texte, inclure un lien vers la page graphique associée. S'assurer que ces liens font partie des premiers auxquels l'utilisateur aura accès, en les plaçant avant les autres liens.
  2. Utiliser les méta-informations pour identifier les documents alternatifs. Les navigateurs devraient charger la page alternative automatiquement en fonction des préférences de l'utilisateur et du type du navigateur. Par exemple, en HTML, utiliser l'élément LINK de la façon suivante :

    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.

3.4 Accès du clavier

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 :

Les liens d'images cliquables
Fournir des équivalents texte pour les zones de définition des images cliquables côté client, ou fournir des liens texte redondants pour les zones de définition côté serveur. Voir la section sur les images cliquables.
Les raccourcis clavier
Fournir des raccourcis clavier afin que les utilisateurs puissent combiner des touches pour naviguer les liens et les champs de formulaire sur une page. Note. Les raccourcis clavier -- notamment la touche utilisée pour activer le raccourci -- peuvent être différemment gérés par des systèmes d'exploitations différents. Sur les machines Windows, les touches "alt" et "ctrl" sont plus souvent utilisées alors que sur un macintosh, c'est la pomme ou la touche "trèfle". Voir les sections sur les accès clavier pour les liens et les accès clavier pour les formulaires pour les exemples.
L'ordre de tabulation
L'ordre de tabulation décrit un ordre (logique) pour naviguer de lien en lien ou de champs de formulaire en champs de formulaire (souvent en tapant la touche "tab", d'où le nom). Voir la section sur les accès clavier aux formulaires pour les exemples.

3.4.1 contrôle pour les appareils indépendants pour les interfaces embarquées

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.

3.5 Navigation

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 :

  1. les barres de navigation
  2. le contenu principal d'une page
  3. la publicité

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.

3.6 La compréhension

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.

3.6.1 Style d'écriture

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.

  1. Faire tout son possible pour donner des entêtes et des descriptions de lien précis et clairs. Ceci comprend d'utiliser des expressions de lien qui soient laconiques et qui ont du sens lorsque qu'elles sont lues hors contexte ou comme partie d'une série de liens (Certains utilisateurs naviguent en sautant de lien en lien et en écoutant seulement les liens texte. Utiliser des entêtes informatifs tels que les utilisateurs puissent balayer des yeux une page rapidement pour trouver une information plutôt que de la lire en détail.
  2. Exposer le sujet d'une phrase ou d'un paragraphe au début de la phrase ou du paragraphe (Ceci s'appelle le « front-loading » ). Ceci aidera les personnes qui survolent visuellement, ainsi que ceux qui utilisent les synthétiseurs vocaux. "Survoler" avec la voix signifie généralement que l'utilisateur saute d'entête en entête, ou de paragraphe en paragraphe et écoute juste assez de mots pour déterminer si l'ensemble courant d'information (entête, paragraphe, lien, etc.) l'intéresse. Si l'idée principale du paragraphe est au milieu ou à la fin, les utilisateurs du vocal peuvent avoir à écouter la plus grande partie du document avant de trouver ce qu'ils veulent. En fonction de ce que l'utilisateur cherche et de ce qu'il sait à propos du sujet, les fonctionnalités de recherche peuvent également aider les utilisateurs à localiser le contenu plus rapidement.
  3. Limiter chaque paragraphe à une idée principale.
  4. Eviter, l'argot, le jargon, et les significations spécialisées des mots communs, à moins de les avoir définis au sein du document.
  5. Favoriser les mots qui sont souvent utilisés. Par exemple, utiliser "commencer" plutôt que "débuter" ou utiliser "essayer" plutôt que "tenter".
  6. Utiliser des verbes actifs plutôt que des verbes passifs.
  7. Eviter d'utiliser des phrases avec une structure complexe.

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.

3.6.2 Equivalents multimédia

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 :

  1. Un graphique de données complexes, comme les présentations des ventes d'une entreprise pour l'année fiscale accomplie.
  2. Une traduction de texte en un clip filmé, en langage des signes. La langue des signes est une langue très différente des langages parlés. Par exemple, certaines personnes qui peuvent communiquer au moyen du langage signé américain sont incapables de lire de l'anglais américain.
  3. Des sons pré-enregistrés de musique, de langage parlé, ou des effets sonores peuvent également aider une personne ne pouvant lire mais qui peut percevoir des présentations audio. Bien qu'un texte puisse être généré comme une voix grâce à un synthétiseur vocal, des changements de ton dans la voix de la personne enregistrée peuvent véhiculer des informations qu'une synthèse vocale ne peut pas reproduire.

3.7 Négociation du contenu

Points de contrôle dans cette section : 11.3.

  1. Plutôt que d'inclure des liens comme "Lisez ici la version française de ce document", utilisez la négociation du contenu ainsi la version française sera envoyée aux clients faisant la demande des versions françaises des documents.
  2. S'il n'est pas possible d'utiliser la négociation du contenu, indiquez le type de contenu ou la langue à travers le balisage (ex., en HTML utilisez "type" et "hreflang").

3.8 rafraîchissement automatique de pages

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 :

  1. Configurer le serveur pour utiliser le code de statut approprié (301). Il est préférable d'utiliser les entêtes HTTP parce-que cela réduit le traffic internet et les temps de téléchargement, ceci peut être appliqué au documents non-HTML, et cela peut être utilisé par les agents qui ne demande qu'une requête d'entête (ex., les vérificateurs de liens). De plus les codes de statuts du type 30x fournissent des informations comme "moved permanently" (déplacé de façon permanente) ou "moved temporarily" (déplacé temporairement) qui ne peuvent être donnés par un rafraîchissement de type META.
  2. Remplacer la page qui devrait être redirigée par une page statique contenant un lien normal vers une nouvelle page.

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>

3.9 Clignotement d'écran

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

3.10 Documents en lot

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 :

3.11 Validation

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".

3.11.1 Outils de validation automatiques

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 :

  1. Un outil de validation automatique d'accessibilité tel que Bobby (voir [BOBBY]).
  2. Un service de validation HTML comme le service de validation HTML du W3C (voir [HTMLVAL]).
  3. Un service de validation des feuilles de style comme le service de validation CSS du W3C (voir [CSSVAL]).

3.11.2 Outils de réparation

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.

3.11.3 Scénarios d'utilisateur

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 :

  1. Testez vos pages avec un navigateur texte-seul comme Lynx ([LYNX]) ou un émulateur Lynx comme Lynx Viewer ([LYNXVIEW]) ou Lynx-me ([LYNXME]).
  2. Utilisez des navigateurs graphiques multiples, avec :
  3. Utilisez plusieurs navigateurs, anciens et nouveaux. Note. Certains systèmes d'exploitations ou certains navigateurs ne permettent pas d'installations multiples du navigateur sur la même machine. Il peut être également difficile de trouver de vieux logiciels de navigation.
  4. Utilisez d'autres outils comme un navigateur à interprétation vocale (ex., [PWWEBSPEAK] et [HOMEPAGEREADER]), un lecteur d'écran (ex., [JAWS] et [WINVISION]), un logiciel de grossissement, un petit écran, un écran tactile avec clavier, un clavier alternatif, etc.

3.11.4 Vérificateurs d'orthographe et de grammaire

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.

3.12 Support des navigateurs

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.


4 Techniques HTML

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

4.1 Structure du document et metadata

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.

4.1.1 Metadata

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 :

4.1.2 Entêtes de section

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 :

Exemple.

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

4.1.3 Metadata lien et outils de navigation

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.

Exemple.

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.

4.1.4 Groupement structurel

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.

4.2 Information de la langue

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" :

Exemple.

   <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 :

  1. Le sutilisateurs qui lisent le document en braille seront capables de substituer les codes de contrôle appropriés (balise) où les changements de langue interviennent pour assurer que le logiciel de traduction braille générera correctement les caractères (caractères accentués, par exemple). Ces codes de contrôle évitent également les contractions braille d'être générées, ce qui peut troubler l'utilisateur. Les contractions braille combinent des groupes utilisés habituellement qui apparaissent en cellules multiples sous la forme d'une unique cellule. Par exemple, "ing" qui prend habituellement trois cellules (une pour chaque caractère) peut être contracté en une seule cellule.
  2. De même, les synthétiseurs vocaux qui "parlent" plusieurs langues seront capables de générer le texte dans l'accent approprié avec une prononciation correcte. Si les changements ne sont pas marqués, le synthétiseur tentera au mieux d'interpréter les mots dans la langue par défaut de celui-ci. Ainsi, le mot français pour car, "voiture" devraît être prononcer "voter."
  3. Les utilisateurs qui sont incapables de traduire les langues par eux-mêmes, pourront utilisés des traducteurs automatiques des langues qui leur sont inconnues.

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.

Exemple.

    <HTML lang="fr">
       ....reste d'un document écrit en français...
    </HTML>
	

Fin de l'exemple.

4.3 Balisage de texte

Les sections suivantes expliquent les manières d'ajouter une structure aux morceaux de texte.

4.3.1 Mise en valeur

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

4.3.2 Acronymes et abbréviations

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.

4.3.3 Citations

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.

4.3.4 Balisage et Feuilles de style plutôt que les images : l'exemple des mathématiques

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 :

  1. rendre disponible le document TeX (ou LaTeX) sur le Web. Il existe un système appelé "AsTeR" ([ASTER]) qui peut créer un rendu auditif des documents TeX et LaTeX. IBM a également un plug-in pour Netscape et Internet Explorer qui lit les documents TeX/LaTeX et une partie de MathML (voir [HYPERMEDIA]).
  2. s'assurer que le HTML créé par le processus de conversion est accessible. Fournissez une description unique de l'équation (plutôt qu'une texte "alt" sur chaque image générée afin de décrire chacun des petits éléments ou morceaux de l'équation).

4.3.5 Divers balisages structurels

La Spécification HTML 4.0 specification définit les éléments structurels suivants pour les divers besoins de balisage :

CITE
Contient une citation ou une référence vers d'autres sources.
DFN
Indique que c'est le cas précis du terme balisé.
CODE
Designe un morceau de code de programme.
SAMP
Designe un exemple de sortie d'un programmes, de scripts, etc.
KBD
Indique le texte doit êtr entré par l'utilisateur.
VAR
Indique une occurence de variable ou d'un argument de programme.
INS
Indique un texte inséré dans un document.
DEL
Indique un texte effacé d'un document.

4.4 Listes

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.

4.4.1 Utilisez les feuilles de style pour changer les puces des listes

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>

4.5 Tableaux

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.

4.5.1 Tableaux de données

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

Exemple.

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 :

Illustration of coffee table rendering [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]

Travel Expense Report table as rendered by a visual user agent.

4.5.2 Evitez les tableaux pour la présentation

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.

4.5.3 Texte continu dans des tableaux

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.

4.5.4 Problèmes de compatibilité rétroactives des tableaux

Dans les navigateurs HTML 3.2, les lignes d'un élément TFOOT apparaîtront avant le corps du tableau.

4.6 Liens

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.

4.6.1 Groupement et contournement de liens

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.

4.6.2 Accès clavier

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.

4.7 Images et images cliquables

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.

4.7.1 Equivalents texte pour 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.

4.7.2 D-links invisible

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.

4.7.3 Art ascii

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".

4.7.4 Image cliquables

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

4.7.5 Images cliquables côté client

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 :

Exemple.

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

4.7.6 Images cliquables côté serveur

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 :

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.

4.8 Applets et autres objets exécutables

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.

4.8.1 Equivalents textes des applets et des objets exécutables

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>

4.8.2 Applets directement accessibles

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.

4.8.3 Audio et Vidéo produits par des objets dynamiques

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.

4.9 Audio et vidéo

4.9.1 Information audio

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].

4.9.2 Information visuelle et mouvement

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.

4.9.3 Transcriptions de texte collationné

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.

4.9.4 Equivalents textes pour le multimédia

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.

4.9.5 Des objets multimédias inclus

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].

4.10 Frames

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.

4.10.1 Titrer les frames pour faciliter l'orientation

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.

4.10.2 Equivalents textes pour les frames

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.

4.10.3 S'assurez que les documents sont lisibles avec des frames

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.

4.10.4 Toujours créer la source d'un frame d'un document HTML

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

4.10.5 Evitez d'ouvrir une nouvelle fenêtre pour la cible d'un frame

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".

4.10.6 Alternatives aux frames

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 :

  1. Créez un document pour le mécanisme de navigation (appelez le "nav.html"). Un document séparé signifie que le mécanisme de navigation peut être partagé par plus d'un document.
  2. Dans chaque document requérant le mécanisme de navigation, incluez le au bas du document avec le balisage OBJECT suivant (ou similaire) :

    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.

  3. Utilisez les feuilles de style pour positionner le mécanisme de navigation à l'endroit que vous désirez sur l'écran. Par exemple, La barre de navigation sur la gauche de la page et donnez lui une largeur de 25% de l'espace horizontal disponible :
       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.

4.11 Formulaires

Cette section discute de l'accessibilité des formulaires et des contrôles de formulaire qui peuvent être placé dans un élément FORM.

4.11.1 Rendez les contrôles de clavier accessibles

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.

4.11.2 Groupez les contrôles de formulaire

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.

4.11.3 Labellisez les contrôles de formulaire explicitement

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.

4.11.4 Groupez les options de menu

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.

4.11.5 Accès clavier au formulaire

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.

4.11.6 Boutons graphiques

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 :

4.11.7 Techniques pour des contrôles spécifiques

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.

4.11.8 Problèmes de compatibilités antérieures pour les formulaires

Dans les navigateurs HTML 3.2,

4.12 Scripts

Cette section discutent de l'accessibilité des scripts incluent dans par l'intermédiaire d'un élément SCRIPT.

4.12.1 Scripts de transformation

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.

4.12.2 Gestionnaire d'événements indépendant du matériel

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 :

  1. Utiliser les événements automatiques au niveau application plutôt qu'au niveau interaction de l'utilisateur.En HTML 4.0, les attributs d'événements au niveau application sont "onfocus", "onblur" (l'opposé de "onfocus"), et "onselect". Noter que ces attributs sont désignés indépendamment du matériel, mais sont intégrés comme des événements spécifiques du clavier dans les navigateurs actuels.
  2. Sinon, si vous devez utilisez des attributs dépendants du matériel, fournir des mécanismes redondants de saisie (c.à-d., spécifier 2 gestionnaires pour le même élément)

    Noter qu'il n'y a pas d'équivalent clavier du double-click ("ondblclick") en HTML 4.0.

  3. Ne pas écrire de gestionnaire d'événements qui repose sur les coordonnées de la souris car cela créée une dépendance matérielle pour l'entrée.

4.12.3 Présentation alternative des scripts

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.


5 Techniques CSS

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.

5.1 Règles pour créer des feuilles de style

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.

5.2 Polices

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.

5.3 Style du texte

Points de contrôle dans cette section : 7.2.

Les propriétés CSS2 suivantes peuvent être utilisées pour styler le texte :

5.3.1 Texte à la place des images

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.

5.4 Mise en forme de texte

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.

5.5 Couleurs

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].

5.6 Présentation, positionnement, superposition, et alignement

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) :

5.6.1 Si vous devez utiliser des images pour créer des espacements.

Fournissez des équivalents textes pour toutes les images, y comprus les images transparentes ou invisibles.

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="&nbsp;&nbsp;&nbsp;">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.

5.7 Règles et bordures

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.


Carte de point de contrôle

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.

Règle 1 :

1.1 Fournir un équivalent texte pour tout élément non texte (ex., par "alt", "longdesc", ou dans un élément contenu). Ceci inclut : les images, les représentations graphiques de texte (y compris les symboles), les régions des images cliquables, les animations, (ex., les GIFs animés), les applets et les objets programmables, l'art ascii art, les frames, les scripts, les images utilisées comme puces de liste, les espacements, les boutons graphiques, les sons (joués avec ou sans l'interaction de l'utilisateur), les fichiers audio seuls, les pistes audio des vidéos, et les vidéos. [Priorité 1] (Point de contrôle 1.1 dans le guide des règles)
Voir 3.2 Equivalents texte et
4.7.1 Equivalents texte pour les images
1.2 Fournir des liens texte redondants pour chaque région active d'une image cliquable côté serveur. [Priorité 1] (Point de contrôle 1.2 dans le guide des règles)
Voir 3.2 Equivalents texte et
4.7.6 image cliquable côté serveurs
1.3 Depuis que les agents utilisateur peuvent automatiquement lire l'équivalent texte d'une piste visuelle, fournir une description auditive de l'information importante de la piste visuelle d'une présentation multimédia [Priorité 1] (Point de contrôle 1.3 dans le guide des règles)
Voir 4.9.2 Information visuelle et mouvement
1.4 Pour toute présentation multimédia basée sur le temps (ex., un film ou une animation), synchornisez les alternatives équivalentes (ex., les titres ou les descriptions auditives de la piste visuelle) avec la présentation. [Priorité 1] (Point de contrôle 1.4 dans le guide des règles)
Voir 4.8.3 Audio et vidéo produits par des objets dynamiques
1.5 Depuis que les agents utilisateurs interprête les équivalents texte pour les liens des images cliquables côté client, fournissez des liens texte redondants pour chaque région active d'une image cliquable côté client. [Priorité 3] (Point de contrôle 1.5 dans le guide des règles)
Voir 3.2 Equivalents texte et
4.7.5 Images cliquables côté client

Règle 2 :

2.1 S'assurez que toute information définie par les couleurs est également disponible sans couleur, par exemple à partir du contexte ou du balisage [Priorité 1] (Point de contrôle 2.1 dans le guide des règles)
Voir 5.5 Couleurs
2.2 S'assurez que les combinaisons de couleurs de premier plan et de fond fournissent un contraste suffisant lorsqu'elles sont vues par quelqu'un ayant des déficiences sur la couleur ou si elles sont vues sur un écran noir et blanc. [Priorité 2 pour les images, Priority 3 pour le texte]. (Point de contrôle 2.2 dans le guide des règles)
Voir 5.5 Couleurs

Règle 3 :

3.1 Lorsqu'un langage de balisage approprié existe, utilisez le balisage plutôt que les images pour fournir l'information. [Priorité 2] (Point de contrôle 3.1 dans le guide des règles)
Voir 4.3.4 Balisage et feuilles de style plutôt que les images : L'exemple des maths
3.2 Créez des documents qui sont valides par rapport aux grammaires formelles publiées. [Priorité 2] (Point de contrôle 3.2 dans le guide des règles)
Voir 4.1 Structure de documents et metadata
3.3 Utilisez les feuilles de style pour contrôler la présentation et la mise en page. [Priorité 2] (Point de contrôle 3.3 dans le guide des règles)
Voir 3.2 Equivalents textes et
4.3.1 Accentuation et
5 Techniques CSS
3.4 Utilisez des unités relatives plutôt que absolues dans les valeurs d'attibutes du langage de balisage et les valeurs des propriétés des feuilles de style. [Priorité 2] (Point de contrôle 3.4 dans le guide des règles)
Voir 5.1 Règles pour créer les feuilles de style.
3.5 Utiliser les éléments entêtes pour spécifier la structure du document et utilisez les en accord avec les spécifications. [Priorité 2] (Point de contrôle dans le guide des règles 3.5)
Voir 4.1.2 Section entêtes
3.6 Balisez les listes et les éléments de liste correctement [Priorité 2] (Point de contrôle 3.6 dans le guide des règles)
Voir 4.4 Listes
3.7 Balisez les citations. N'utilisez pas le balisage des citations pour des effets de mise en forme comme l'indentation. [Priorité 2] (Point de contrôle 3.7 dans le guide des règles)
Voir 4.3.3 Citations

Règle 4 :

4.1 Identifiez clairement les changements de la langue naturelle du texte d'un document et de tous les équivalents textes. (ex., titres). [Priorité 1] (Point de Contrôle 4.1 dans le guide des règles)
Voir 4.2 Information de langue
4.2 Spécifiez la signification de chaque abbrévation ou acronyme dans un document à leur première occurence. [Priorité 3] (Point de contrôle 4.2 dans le guide des règles)
Voir 4.3.2 Acronymes et abbréviations
4.3 Identifiez la langue naturelle première d'un document. [Priorité 3] (Point de contrôle 4.3 dans le guide des règles)
Voir 4.2 Information de langue

Règle 5 :

5.1 Pour les tableaux de données, identifiez les entêtes de ligne et de colonne. [Priorité 1] (Point de contrôle 5.1 dans le guide des règles)
Voir 4.5.1 Tableaux de données
5.2 Pour les tableaux de données qui ont deux niveaux logiques ou plus d'entêtes de ligne ou de colonne, utilisez le balisage pour associer les cellules de données et les cellules d'entête. [Priorité 1] (Point de Contrôle 5.2 dans le guide des règles)
Voir 4.5.1 Tableaux de données
5.3 N'utilisez pas les tableaux pour la mise en forme à moins que les tableaux prennent du sens lorsqu'ils sont linéarisés. Si le tableau n'a pas de sens, fournir une alternative équivalente (qui peut être une version linéarisée). [Priorité 2] (Point de Contrôle 5.3 dans le guide des règles)
Voir 4.5.2 Eviter les tableaux pour la mise en forme
5.4 Si un tableau est utilisé pour la mise en forme, n'utilisez aucun balisage structurel pour obtenir un formattage visuel [Priorité 2] (Point de contrôle 5.4 dans le guide des règles)
Voir 4.5.2 Evitez les tableaux pour la mise en forme
5.5 Fournissez un sommaire des tableaux. [Priorité 3] (Point de Contrôle 5.5 dans le guide des règles)
Voir 4.5.1 Tableaux de données
5.6 Fournissez des abbréviations pour les labels d'entête. [Priorité 3] (Point de Contrôle 5.6 dans le guide des règles)
Voir 4.5.1 Tableaux de données

Règle 6 :

6.1 Organisez les documents de façon à ce qu'ils puissent être lus sans feuilles de style. Par exemple, quand un document HTML est interprêté sans les feuilles de style associées, il doit toujours être possible de lire le document. [Priorité 1] (Point de Contrôle 6.1 dans le guide des règles)
Voir 5.1 Règles pour créer les feuilles de style
6.2 S'assurez que les équivalents pour les contenus dynamiques sont mis à jour quand le contenu dynamique change. [Priorité 1] (Point de Contrôle 6.2 dans le guide des règles)
Voir 4.10.4 Toujours faire le source d'un frame, un document HTML
6.3 S'assurez que les pages sont utilisables quand les scripts, les applets ou objets programmatiques sont désactivés ou non supportés. Si ce n'est pas possible, fournissez une information équivalente sur une page alternative accessible. [Priorité 1] (Point de contrôle 6.3 dans le guide des règles)
Voir 4.12.1 Transformation élégante des scripts
6.4 Pour les scripts et les applets, s'assurez que les gestionnaires d'événements sont indépendants du matériel. [Priorité 2] (Point de Contrôle 6.4 dans le guide des règles)
Voir 4.12.2 Gestionnaires d'événement indépendants du matériel
6.5 S'assurez que le contenu dynamique est accessible ou fournissez une présentation ou une page alternative. [Priorité 2] (Point de contrôle 6.5 dans le guide des règles)
Voir 3.3 Pages alternatives

Règle 7 :

7.1 Jusqu'à ce que les agents utilisateurs permettent aux utilisateurs de contrôler l'oscillation, évitez de créer des phénomènes d'oscillations à l'écran. [Priorité 1] (Checkpoint 7.1 dans le guide des règles)
Voir 3.9 Oscillation d'écran
7.2 Jusqu'à ce que les agents utilisateurs permettent le contrôle du clignotement, évitez le clignotement du contenu (i.e., changement de la présentation à un taux régulier, comme allumage et extinction). [Priorité 2] (Point de Contrôle 7.2 dans le guide des règles)
Voir 5.3 Style de texte
7.3 Jusqu'à ce que les agents utilisateurs permettent aux utilisateurs de figer le contenu mobile, évitez le mouvement dans les pages. [Priorité 2] (Point de Contrôle 7.3 dans le guide des règles)
Voir 4.9.2 Information visuelle et mouvement
7.4 Jusqu'à ce que les agents utilisateurs fournissent la possibilité d'arrêter un rafraîchissement, ne créez pas de pages qui se rafraîchissent automatiquement de façon périodique. [Priorité 2] (Point de Contrôle 7.4 dans le guide des règles)
Voir 3.8 Rafraîchissement automatique de page
7.5 Jusqu'à ce que les agents utilisateurs fournissent la possibilité de stopper l'auto-redirection, n'utilisez pas de balisages permettant la redirection automatique des pages. A la place, configurez le serveur pour effectuer les redirections. [Priorité 2] (Point de Contrôle 7.5 dans le guide des règles)
Voir 3.8 Rafraîchissement automatique des pages

Règle 8 :

8.1 Rendez les éléments programmatiques comme les scripts et les applets directement accessibles ou compatibles avec des technologies d'assistance. [Priorité 1 si la fonctionnalité est importante et n'est pas présenté ailleurs, sinon Priority 2.] (Point de Contrôle 8.1 dans le guide des règles)
Voir 4.8.2 Applets directement accessibles et
4.8.3 Audio et Vidéo produits par des objets dynamiques

Règle 9 :

9.1 Fournissez des images cliquables côté client à la place des images cliquables côté serveurs excepté lorsque les régions ne peuvent être définies avec une forme géométrique disponible. [Priorité 1] (Point de Contrôle 9.1 dans le guide des règles)
Voir 4.7.5 Images cliquables côté client
9.2 S'assurrez que tout élément qui possède sa propre interface peut être utilisé de façon indépendante par rapport au matériel. [Priorité 2] (Point de Contrôle 9.2 dans le guide des règles)
Voir 3.4 Accès clavier
9.3 Pour les scripts, spécifiez des gestionnaires d'événements logiques plutôt que des gestionnaires d'événements dépendants du matériel. [Priorité 2] (Point de Contrôle 9.3 dans le guide des règles)
Voir 4.12.2 Gestionnaires d'événements indépendants du matériel
9.4 Créez un ordre logique de tabulation entre les liens, les contrôles de formulaire, et les objets. [Priorité 3] (Checkpoint 9.4 dans le guide des règles)
Voir 4.11.1 Rendez les contrôles de clavier accessibles
9.5 Fournissez des raccourcis clavier pour les liens importants (y compris ceux dans les images cliquables côté client), les contrôles de formulaire, et les groupes de contrôle de formulaire. [Priorité 3] (Point de Contrôle 9.5 dans le guide des règles)
Voir 4.11.1 Rendre les contrôles de clavier accessibles

Règle 10 :

10.1 Jusqu'à ce que les agents utilisateurs permettent aux utilisateurs de désactiver les fenêtres "surgissantes", ne créez pas de "pop-ups" ou apparition d'autres fenêtres et ne changez pas la fenêtre courante sans en informer l'utilisateur. [Priorité 2] (Checkpoint 10.1 dans le guide des règles)
Voir 4.10.5 Evitez d'ouvrir une nouvelle fenêtre comme cible d'un frame
10.2 Jusqu'à ce que les agents utilisateurs supportent explicitement les associations entre les labels et les contrôles de formulaire, pour tous les contrôles de formulaire avec des labels associés implicites, s'assurez que le label est correctement positionné. [Priorité 2] (Point de Contrôle 10.2 dans le guide des règles)
Voir 4.11.3 Nommez les contrôles de formulaire explicitement
10.3 Jusqu'à ce que les agents utilisateurs (y compris les technologies d'assistance) rendent le texte en vis à vis correctement, fournissez une alternative linéaire du texte (sur la page actuelle ou d'autres) pour tous les tableaux qui mettent le texte en parallèle, des colonnes de mots sécables. [Priorité 3] (Point de contrôle 10.3 dans le guide des règles)
Voir 4.5.3 Texte enveloppé dans un tableau
10.4 Jusqu'à ce que les agents utilisateurs prennent en compte les contrôles vides correctement, y compris par défaut, placez des caractères dans les boites d'édition et dans les aires de texte. [Priorité 3] (Point de contrôle 10.4 dans le guide des règles)
Voir 4.11.7 Techniques pour les contrôles spécifiques
10.5 Jusqu'à ce que les agents utilisateurs (y compris les technologies d'assistance) rendent les liens adjacents de façon distincte, incluez les non-liens, les caractères imprimables (entourés par des espaces) entre les liens adjacents. [Priorité 3] (Point de contrôle 10.5 dans le guide des règles)
Voir 4.7.5 Images cliquables côté client

Règle 11 :

11.1 Utilisez les technologies du W3C si elles sont disponibles ou appropriées pour une tâche donnée et utilisez les dernières versions si elles sont supportées. [Priorité 2] (Point de Contrôle 11.1 dans le guide des règles)
Voir 3.12 Support des navigateurs
11.2 Evitez d'utiliser les fonctionnalités dépréciées des technologies du W3C. [Priorité 2] (Point de Contrôle 11.2 dans le guide des règles)
Voir
11.3 Fournissez l'information telle que les utilisateurs peuvent recevoir les documents en fonction de leurs préférences (ex., langue, type de contenu, etc.) [Priorité 3] (Point de Contrôle 11.3 dans le guide des règles)
Voir 3.7 Négociation du contenu
11.4 Si, après les plus grands efforts, vous ne pouvez pas créer une page accessible , fournissez un lien vers une page alternative qui utilisent les technologies du W3C, est accessible, a une information équivalente (ou une fonctionnalité) et est mise à jour aussi souvent que page (originale) inaccessible. [Priorité 1] (Point de contrôle 11.4 dans le guide des règles)
Voir 3.3 Pages alternatives

Règle 12 :

12.1 Titrez chaque frame pour faciliter l'identification et la navigation des frames. [Priorité 1] (Point de contrôle 12.1 dans le guide des règles)
Voir 3.2 Equivalents texte et
4.10.1 Titrez les frames pour une navigation aisée
12.2 Décrivez le but des frames et comment les frames sont en relation les uns avec les autres si cela n'est pas explicite par les titres des frames seulement. [Priorité 2] (Point de Contrôle 12.2 dans le guide des règles)
Voir 3.2 Equivalents texte et
4.10.2 Equivalents texte pour les frames
12.3 Divisez les grands blocs d'information en groupes plus gérable lorsque c'est approprié et naturel. [Priorité 2] (Point de Contrôle 12.3 dans le guide des règles)
Voir 4.1.4 Groupement structurel
12.4 Associez les labels explicitement avec leur contrôles. [Priorité 2] (Point de Contrôle 12.4 dans le guide des règles)
Voir 4.11.3 Nommez les contrôles de formulaire explicitement

Règle 13 :

13.1 Identifiez clairement la cible de chaque lien. [Priorité 2] (Point de Contrôle 13.1 dans le guide des règles)
Voir 4.6 Liens
13.2 Fournissez des metadata pour ajouter l'information sémantique aux pages et aux sites. [Priorité 2] (Point de contrôle 13.2 dans le guide des règles)
Voir 3.5 Navigation et
4.1.1 Metadata et
4.1.3 Lien de metadata et outils de navigation
13.3 Fournissez de l'information à propos de la mise en forme d'un site (ex., une carte de site ou un sommaire). [Priorité 2] (Point de Contrôle 13.3 dans le guide des règles)
Voir 3.5 Navigation
13.4 Utilisez des mécanismes de navigation d'une façon consistante. [Priorité 2] (Point de Contrôle 13.4 dans le guide des règles)
Voir 3.5 Navigation
13.5 Fournissez des barres de navigation pour mettre en valeur et donner accès au mécanisme de navigation. [Priorité 3] (Point de contrôle 13.5 dans le guide des règles)
Voir 3.5 Navigation
13.6 Groupez les liens relatifs, identifiez le groupe (pour les agents utilisateurs), et, jusqu'à ce que les agents utilisateurs le puissent, fournissez un moyen de sauter le groupe. [Priorité 3] (Point de contrôle 13.6 dans le guide des règles)
Voir 4.6 Liens
13.7 Si des fonctions de recherche sont fournies, rendez possibke différent types de recherche pour des niveaux et des préférences différentes. [Priorité 3] (Point de contrôle 13.7 dans le guide des règles)
Voir 3.5 Navigation
13.8 Placez une information évidente au début des entêtes, des paragraphes, des listes, etc. [Priorité 3] (Point de contrôle 13.8 dans le guide des règles)
Voir 3.6 Compréhension
13.9 Fournissez de l'information à propos de l'ensemble des documents (i.e., des documents comprenant plusieurs pages.). [Priorité 3] (Point de Contrôle 13.9 dans le guide des règles)
Voir 3.10 Documents collectifs
13.10 Fournissez un moyen de passer un dessin ASCII de plusieurs lignes. [Priorité 3] (Point de Contrôle 13.10 dans le guide des règles)
Voir 3.2 Equivalents textes et
4.7.3 Art ascii

Règle 14 :

14.1 Utilisez le langage approprié le plus clair et le plus simple pour un contenu de site. [Priorité 1] (Point de Contrôle 14.1 dans le guide des règles)
Voir 3.6 Compréhension
14.2 Compléter le texte avec des graphiques ou avec des présentations auditives où elles permettent de faciliter la compréhension de la page. [Priorité 3] (Point de contrôle 14.2 dans le guide des règles)
Voir 3.6 Compréhension
14.3 Créez un style de présentation qui est consistent de page en pages. [Priorité 3] (Point de Contrôle 14.3 dans le guide des règles)
Voir 3.5 Navigation

Index des éléments et des attributs HTML

Points de contrôle dans cette section : 11.2.

Eléments

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.

Nom de l'élément Défini aussi dans Rôle Techniques
A 2.0, 3.2 Structure 4.6 Liens, 4.7.2 d-links invisibles, 4.7.5 Images cliquables côté client
ABBR   Structure 4.3.2 Acronymes and abbréviations, 4.7.3 Art ascii
ACRONYM   Structure 4.3.2 Acronymes and abbréviations
ADDRESS 2.0, 3.2 Metadata 4.1.1 Metadata
APPLET* 3.2 Remplacé 4.8 Applets et autres objets programmatiques, 4.8.1 Equivalents textes pour les applets et autres objets programmatiques, 4.8.2 Applets directement accessibles
AREA 3.2 Structure 4.7.5 Images cliquables côté client
B 2.0, 3.2 Présentation 4.3.1 Accentuation
BASE 2.0, 3.2 Traitement N/A
BASEFONT* 3.2 Présentation 5.2 Polices
BDO   Traitement N/A
BIG 3.2 Présentation 5.2 Polices
BLOCKQUOTE 2.0, 3.2 Structure 3.1 Structure vs. Présentation, 4.3.3 Citations, 5.4 Mise en forme du texte
BODY 2.0, 3.2 Structure N/A
BR 2.0, 3.2 Présentation N/A
BUTTON   Structure 4.11.6 Boutons graphiques, 4.11.8 Compatibilité antérieures pour les formulaires
CAPTION 3.2 Structure 4.1.4 Groupage structurel, 4.5.1 Tableaux de données
CENTER* 3.2 Présentation 5.6 Mise en forme, positionnement, superposition, et alignement
CITE 2.0, 3.2 Structure 4.3.5 Balisage structurel divers
CODE 2.0, 3.2 Structure 4.3.5 Balisage structurel divers
COL   Structure 4.5.1 Tableaux de données
COLGROUP   Structure 4.1.4 Groupage structurel, 4.5.1 Tableaux de donnée
DD 2.0, 3.2 Structure 4.4.1 Utilisez les feuilles de style pour changer les puces de liste
DEL   Metadata 4.3.5 Balisage structurel divers
DFN 3.2 Structure 4.3.5 Balisage structurel divers
DIR* 2.0, 3.2 Structure N/A
DIV 3.2 Structure 4.6.1 Groupages et sauts des liens
DL 2.0, 3.2 Structure 4.1.4 Groupage structurel, 4.4 Listes, 4.4.1 Utilisez les feuilles de style pour changer les puces de liste
DT 2.0, 3.2 Structure 4.4.1 Utilisez les feuilles de style pour changer les puces de liste
EM 2.0, 3.2 Structure 4.3.1 Accentuation
FIELDSET   Structure 4.1.4 Groupage structurel, 4.11.2 Groupe de contrôle de formulaire
FONT* 3.2 Présentation 5.2 Polices
FORM 2.0, 3.2 Structure 4.11 Formulaires
FRAME   Remplacé 4.6.1 Groupages et sauts des liens, 4.10 Frames
FRAMESET   Présentation 4.10 Frames, 4.10.2 Equivalents textes pour les frames
H1 2.0, 3.2 Structure 3.1 Structure vs. Présentation, 4.1.2 Entêtes de section, 4.1.4 Groupage structurel
HEAD 2.0, 3.2 Structure N/A
HR 2.0, 3.2 Présentation 3.1 Structure vs. Présentation, 4.1.2 Entêtes de section
HTML 2.0, 3.2 Structure N/A
I 2.0, 3.2 Présentation 4.3.1 Accentuation
IFRAME   Remplacé 4.10 Frames
IMG 2.0, 3.2 Remplacé 4.7.1 Equivalents textes pour les images, 4.7.6 Images cliquables côté serveur, 4.10.4 Créez toujours le source d'un frame un document HTML, 5.6.1 Si vous devez utiliser des images comme espacement
INPUT 2.0, 3.2 Structure 4.11.6 Boutons graphiques, 4.11.8 Problèmes de compatibilité antérieures des formulaires
INS   Metadata 4.3.5 Balisage structurel divers
ISINDEX* 2.0, 3.2 Structure N/A
KBD 2.0, 3.2 Structure 4.3.5 Balisage structurel divers
LABEL   Structure 4.11.3 Nommez les contrôles de formulaire explicitement
LEGEND   Structure 4.1.4 Groupage structurel, 4.11.2 Groupe de contrôle de formulaire
LI 2.0, 3.2 Structure 4.4.1 Utilisez les feuilles de style pour changer les puces de liste
LINK 2.0, 3.2 Metadata 3.3 Pages alternatives, 4.1.1 Metadata, 4.1.3 Lien metadata et outils de navigation , 5 Techniques CSS
MAP 3.2 Structure 4.7.4 Images cliquables
MENU* 2.0, 3.2 Structure N/A
META 2.0, 3.2 Metadata 3.8 Rafraîchissement automatique de page, 4.1.1 Metadata
NOFRAMES   Alternative 4.10.2 Equivalents textes pour les frames
NOSCRIPT   Alternative 4.12.3 Présentation alternative des scripts
OBJECT   Remplacé 3.2.1 Vue globale des technologies, 4.7.1 Equivalents textes des images, 4.7.5 Image cliquable côté client, 4.7.6 image cliquable côté serveur, 4.8 Applets et autres objets programmatiques, 4.8.1 Equivalents textes pour les applets et autres objets programmatiques, 4.8.2 Applets directement accessibles, 4.9.5 Objets multimédia inclus, 4.10.6 Alternatives aux frames
OL 2.0, 3.2 Structure 4.1.4 Groupage structurel, 4.4 Listes
OPTGROUP   Structure 4.1.4 Groupage structurel, 4.11.4 Options de groupe de menu
OPTION 2.0, 3.2 Structure 4.11.4 Options de groupe de menu
P 2.0, 3.2 Structure 4.1.4 Groupage structurel, 4.6.1 Groupages et sauts des liens
PARAM 3.2 Traitement N/A
PRE 2.0, 3.2 Présentation 4.5.1 Tableaux de donnée
Q   Structure 4.3.3 Citations
S*   Présentation N/A
SAMP 2.0, 3.2 Structure 4.3.5 Balisage structurel divers
SCRIPT 3.2 (DTD) Traitement 4.12 Scripts
SELECT 2.0, 3.2 Structure 4.11.4 Options de groupe de menu
SMALL 3.2 Présentation 5.2 Polices
SPAN   Structure 4.6.1 Groupages et sauts des liens
STRIKE* 3.2 Présentation N/A
STRONG 2.0, 3.2 Structure 4.3.1 Accentuation
STYLE 3.2 (DTD) Traitement 5 Techniques CSS
SUB 3.2 Présentation N/A
SUP 3.2 Présentation N/A
TABLE 3.2 Structure 4.5 Tableaux
TBODY   Structure 4.1.4 Groupage structurel, 4.5.1 Tableaux de donnée
TD 3.2 Structure 4.5.1 Tableaux de donnée
TEXTAREA 2.0, 3.2 Structure 4.11.7 Techniques pour les contrôles spécifiques
TFOOT   Structure 4.1.4 Groupage structurel, 4.5.1 Tableaux de donnée, 4.5.4 Problèmes de compatibilité antérieure pour les tableaux
TH 3.2 Structure 4.5.1 Tableaux de donnée
THEAD   Structure 4.1.4 Groupage structurel, 4.5.1 Tableaux de donnée
TITLE 2.0, 3.2 Metadata 4.1.1 Metadata
TR 3.2 Structure N/A
TT 2.0, 3.2 Présentation N/A
U* 3.2 Présentation N/A
UL 2.0, 3.2 Structure 4.1.4 Groupage structurel, 4.4 Listes
VAR 2.0, 3.2 Structure 4.3.5 Balisage structurel divers

Attributs

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.

Nom de l'attribut s'applique aux éléments Rôle Techniques
abbr TD, TH Alternative 4.5.1 Tableaux de donnée
accesskey A, AREA, BUTTON, INPUT, LABEL, LEGEND, TEXTAREA Interface utilisateur 4.11.5 Accès clavier au formulaire
alt APPLET, AREA, IMG, INPUT Alternative 3.2.1 Aperçu des technologies, 4.7.1 Equivalents textes pour les images, 4.7.2 d-links invisibles, 4.7.5 Image cliquable côté client, 4.7.6 Image cliquable côté serveurs, 4.8.1 Equivalents textes pour les applets et les objets programmatiques, 5.6.1 Si vous devez utiliser des images comme espacement
axis TD, TH Structure 4.5.1 Tableaux de donnée
class La plupart des éléments Structure 4.6.1 Groupages et sauts des liens
dir La plupart des éléments Traitement 4.5.1 Tableaux de donnée
for LABEL Structure 4.11.3 Nommez les contrôles de formulaire explicitement
headers TD, TH Structure 4.5.1 Tableaux de donnée
hreflang A, LINK Metadata 3.7 Négociation de contenu
id La plupart des éléments Structure 4.6.1 Groupages et sauts des liens
label OPTION Alternative 4.11.4 Options de groupe de menu
lang La plupart des éléments Metadata 4.2 Information de langue
longdesc IMG, FRAME, IFRAME Alternative 3.2.1 Aperçu des technologies, 4.7.1 Equivalents texte des images
scope TD, TH Structure 4.5.1 Tableaux de donnée
style La plupart des éléments Traitement 5 Techniques CSS
summary TABLE Alternative 4.5.1 Tableaux de donnée
tabindex A, AREA, BUTTON, INPUT, OBJECT, SELECT, TEXTAREA Interface utilisateur 4.6.1 Groupages et sauts des liens, 4.6.2 Accès clavier, 4.11.5 Accès clavier aux formulaires
title La plupart des éléments Metadata 3.2.2 Compatibilité antérieure, 4.1.1 Metadata, 4.3.2 Acronymes et abbréviations, 4.6 Liens, 4.7.3 Art ascii
usemap IMG, INPUT, OBJECT Traitement 4.7.4 Images cliquables

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.

Autres attributs structurels :
start*, value*, rowspan, colspan, span
Autres attributs de présentation :
align*, valign*, clear*, nowrap*, char, charoff, hspace*, vspace*, cellpadding, cellspacing, compact*, face*, size*, background*, bgcolor*, color*, text*, link*, alink*, vlink*, border, noshade*, rules, size (deprecated according to element), marginheight, marginwidth, frame, frameborder, rows, cols
Autres attributs d'instruction de traitement :
ismap, coords, shape
Autres attributs d'interface utilisateur :
target, scrolling, noresize
Autres attributs metadata :
type, cite, datetime
Attributs de gestionnaires d'événement :
onblur, onchange, onclick, ondblclick, onfocus, onkeydown, onkeypress, onkeyup, onload, onload, onmousedown, onmousemove, onmouseout, onmouseover, onmouseup, onreset, onselect, onsubmit, onunload

Remerciements

Co-direction du groupe de travail sur le guide des règles du contenu Web :
Chuck Letourneau, Starling Access Services
Gregg Vanderheiden, Trace Research and Development
Contacts équipe W3C :
Judy Brewer and Daniel Dardailler
Nous souhaitons remercier les personnes suivantes qui ont contribué par leur temps et leurs commentaires précieux pour créer ce guide de règles :
Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, Jaap van Lelieveld, and Jason White

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.

Spécifications références

Pour la dernière version des spécifications du W3C, consultez la liste des Rapports Techniques du W3C.

[CSS1]
"CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds., 17 December 1996, revised 11 January 1999. La recommandation CCS1 est : http://www.w3.org/TR/1999/REC-CSS1-19990111.
La dernière version de CSS1 est disponible à : http://www.w3.org/TR/REC-CSS1.
[CSS2]
"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. La recommandation CSS2 est à : http://www.w3.org/TR/1998/REC-CSS2-19980512.
La dernière version de CSS2 est disponible à : http://www.w3.org/TR/REC-CSS2.
[DOM1]
"Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds., 1 October 1998. La recommandation DOM Level 1 est à : http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
La dernière version de DOM Level 1 est disponible à : http://www.w3.org/TR/REC-DOM-Level-1
[HTML40]
"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 17 December 1997, revised 24 April 1998. La recommandation HTML 4.0 est à : http://www.w3.org/TR/1998/REC-html40-19980424.
La dernière version de HTML 4.0 est disponible à : http://www.w3.org/TR/REC-html40.
[HTML32]
"HTML 3.2 Recommendation", D. Raggett, ed., 14 January 1997. La dernière version de HTML 3.2 est disponible à : http://www.w3.org/TR/REC-html32.
[MATHML]
"Mathematical Markup Language", P. Ion and R. Miner, eds., 7 April 1998. La recommandation MathML 1.0 est à : http://www.w3.org/TR/1998/REC-MathML-19980407.
La dernière version de MathML 1.0 est disponible à : http://www.w3.org/TRREC-MathML.
[PNG]
"PNG (Portable Network Graphics) Specification", T. Boutell, ed., T. Lane, contributing ed., 1 October 1996. La dernière version de PNG 1.0 is: http://www.w3.org/TR/REC-png.
[RDF]
"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds., 22 February 1999. La recommandation RDF est à : http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
La dernière version de RDF 1.0 est disponible à : http://www.w3.org/TR/REC-rdf-syntax
[RFC2068]
"HTTP Version 1.1", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners-Lee, January 1997.
[SMIL]
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 June 1998. La recommandation SMIL 1.0 est à : http://www.w3.org/TR/1998/REC-smil-19980615
La dernière version de SMIL 1.0 est disponible à : http://www.w3.org/TR/REC-smil
[TECHNIQUES]
"Techniques pour les règles d'accessibilité du contenu Web 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds. This document explains how to implement the checkpoints defined in "règles d'accessibilité du contenu Web 1.0". The latest draft of the techniques est disponible à : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/
[WAI-AUTOOLS]
"Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds. The latest Working Draft of these guidelines for designing accessible authoring tools est disponible à : http://www.w3.org/TR/WAI-AUTOOLS/
[WAI-UA-SUPPORT]
This page documents known support by user agents (including assistive technologies) of some accessibility features listed in this document. The page est disponible à : http://www.w3.org/WAI/Resources/WAI-UA-Support
[WAI-USERAGENT]
"User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds. The latest Working Draft of these guidelines for designing accessible user agents est disponible à : http://www.w3.org/TR/WAI-USERAGENT/
[WCAG-ICONS]
Information about conformance icons for this document and how to use them is available at http://www.w3.org/WAI/WCAG1-Conformance.html
[UWSAG]
"The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. The Unified Web Site Guidelines were compiled by the Trace R & D Center at the University of Wisconsin under funding from the National Institute on Disability and Rehabilitation Research (NIDRR),  U.S. Dept. of Education. This document est disponible à : http://www.tracecenter.org/docs/html_guidelines/version8.htm
[XML]
"Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 February 1998. The XML 1.0 est à : http://www.w3.org/TR/1998/REC-xml-19980210.
La dernière version de XML 1.0 est disponible à : http://www.w3.org/TR/REC-xml

Services

Note. W3C cannot maintain stability for any of the following references outside of its control. These references are included for convenience.

[ASTER]
For information about ASTER, an "Audio System For Technical Readings", consult T. V. Raman's home page.
[BOBBY]
Bobby is an automatic accessibility validation tool developed by Cast.
[BROWSERCAPS]
BrowserCaps.
[CSSVAL]
The W3C CSS Validation Service.
[DVS]
DVS Descriptive Video Services.
[HACKER]
Hacker, Diana. (1993). A Pocket Style Manual. St. Martin's Press, Inc. 175 Fifth Avenue, New York, NY 10010.
[HOMEPAGEREADER]
IBM's Home Page Reader.
[HTMLVAL]
The W3C HTML Validation Service.
[HYPERMEDIA]
IBM's techexplorer Hypermedia Browser.
[IBMJAVA]
IBM Guidelines for Writing Accessible Applications Using 100% Pure Java are available from IBM Special Needs Systems.
[JAVAACCESS]
Information about Java Accessibility and Usability is available from the Trace R&D Center.
[JAWS]
Henter-Joyce's Jaws screen reader.
[LIGHTHOUSE]
The Lighthouse provides information about accessible colors and contrasts.
[LYNX]
Lynx is a text-only browser.
[LYNXME]
Lynx-me is a Lynx emulator.
[LYNXVIEW]
Lynx Viewer is a Lynx emulator.
[MACROMEDIA]
Flash OBJECT and EMBED Tag Syntax from Macromedia.
[NCAM]
The National Center for Accessible Media includes information about captioning and audio description on the Web.
[PWWEBSPEAK]
The Productivity Works' pwWebSpeak.
[SPOOL]
Spool, J.M., Sconlong, T., Schroeder, W., Snyder, C., DeAngelo, T. (1997). Web Site Usability: A Designer's Guide User Interface Engineering, 800 Turnpike St, Suite 101, North Andover, MA 01845.
[TECHHEAD]
Tech Head provides some information about the Fog index described in [SPOOL].
[TRACE]
The Trace Research & Development Center. Consult this site for a variet of information about accessibility, including a scrolling Java applet that may be frozen by the user.
[WAI-ER]
The WAI Evaluation and Repair Working Group
[WALSH]
Walsh, Norman. (1997). "A Guide to XML." In "XML: Principles, Tools, and Techniques." Dan Connolly, Ed. O'Reilly & Associates, 101 Morris St, Sebastopol, CA 95472. pp 97-107.
[WEBREVIEW]
webreview.com style sheet browser compatibility charts.
[WINVISION]
Artic's WinVision.