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

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.

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 :

• tant que certains agents utilisateur ne supportent pas certaines options HTML,
• tant que les utilisateurs ont la possibilité d'utiliser des navigateurs anciens ou des lecteurs vidéos,
• tant que des probl�mes de compatibilit� peuvent subvenir entre logiciels.

Par conséquent, quand on conçoit pour des technologies anciennes, il faut considérer ces techniques :

• Fournir des équivalents textes intérieurs. Par exemple inclure une description de l'image immédiatement après l'image.
• Fournir des liens vers des équivalents de texte longs qu'ils soient dans une page différente ou dans la même page. Ceux-ci sont appelés des liens de description ou "d-links". Le texte de lien devrait expliquer que le lien désigne une description. Lorsque c'est possible, il devrait également expliquer la nature de la description. Cependant, les développeurs de contenu, conscients de la manière dont le lien de description affecte l'apparence visuelle de la page, peuvent utiliser un lien texte plus discret comme "[D]", ce qui est recommandé par (voir [NCAM]). Dans ce cas, ils devraient également fournir plus d'information à propos de la cible du lien afin que les utilisateurs puissent distinguer les liens qui partagent "[D]" du contenu (ex., avec l'attribut "title" en HTML).

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.

<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

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

• Utilisez les metadata pour décrire les relations entre les composantes du lot (voir liens des metadata pour HTML).
• Utilisez les outils d'archivages comme zip, tar et gzip, et stuffit pour créer le lot.

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 :
   • le chargement des images et des sons activé,
   • le chargement des images non activé,
   • le chargement des sons non activé,
   • sans souris,
   • les frames, les scripts, les feuilles de style, et les applets non chargés
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 :

• TITLE: le titre du document. Notez que l'élément (obligatoire), qui n'apparait qu'une seule fois dans un document est différent de l'attribut "title", qui s'appliquent environ à tous les éléments HTML 4.0. Les développeurs de contenu devraient utiliser l'attribut "title" en accord avec la spécification HTML 4.0. Par exemple, "title" devrait être utilisé avec des liens pour fournir l'information à propos de la cible du lien.
• ADDRESS: peut être utilisé pour fournir de l'information à propos du créateur de la page.
• LINK: peut être utilisé pour indiquer des documents alternatifs (struture différente, langue différente, appareil cible différent, etc.).
• L'élément META peut spécifier des metadata arbitraires pour un document. Voir la section sur le rafraîchissement automatique des pages pour savoir pourquoi les META ne devraient pas être utilisées pour rediriger des pages.

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 :

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

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.

   <LINK rel="Next" href="chapter3">
   <LINK rel="Previous" href="chapter1">
   <LINK rel="Start" href="cover">
   <LINK rel="Glossary" href="glossary">
   

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 :

• Utilisez FIELDSET pour grouper les contrôles de formulaire dans des unités sémantiques et décrivez le groupe avec l'élément LEGEND.
• Utilisez OPTGROUP pour organiser les longues listes des menu d'options en groupes plus petits.
• Utilisez les tableaux pour les données tabulées et décrivez le tableau avec CAPTION.
• Groupez les lignes et les colonnes des tableaux avec THEAD, TBODY, TFOOT, and COLGROUP.
• Imbriquez les listes avec UL, OL, et DL.
• Utilisez les entêtes de section (H1 - H6) pour créer des documents struturés et découpez de long morceux de texte.
• Découpez les lignes de texte en paragraphes (avec l'élément P).

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

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

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.

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

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 :

   <P>Welcome to the <ACRONYM title="World Wide
Web">WWW</ACRONYM>!

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.

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

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 :

• Le texte peut être grossi ou interprêté vocalement ou en braille.
• Les moteurs de recherche peuvent utiliser l'information textuelle.

Par exemple, considérez ces techniques pour placer des formules mathématiques sur le Web :

• S'assurer que les utilisateurs savent ce que les variables représentent, par exemple, dans l'équation "F = m * a", indiquez que F = Force, m = masse, a = accélération.
• Pour des équations simples, utilisez les caractères, comme dans "x + y = z".
• Pour des équations plus complexes, balisez les avec MathML ([MATHML]) où TeX. Notez. MathML peut être utilisé pour créer des documents vraiment accessible mais pour l'instant ce n'est pas aussi utilisé ou répandu que TeX.
• Fournir une description textuelle de l'équation et, si possible, utilisez les références des entités caractères pour créer les symboles mathématiques. Un équivalent texte doit être fourni si l'équation est représenté par une ou plusieurs images.

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.

<STYLE type="text/css">
   UL, OL { counter-reset: item }
   LI { display: block }
   LI:before { content: counters(item, "."); counter-increment: item }
</STYLE>

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.

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

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 :

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

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.

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

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

• Identifiez les groupes structurels de lignes (THEAD pour les entêtes de tableau répétées, TFOOT pour les pieds de tableau répétés, et TBODY pour les autres groupes de colonnes) et groupes de colonnes (COLGROUP et COL). Nommez les éléments du tableau avec les attributs "scope", "headers", et "axis" ainsi les navigateurs futurs et les technologies de support seront capables de sélectionner les données à partir d'un tableau en filtrant sur les catégories. Ce balisage aidera également les navigateurs à linéariser les tableaux (également appelé "serialisation" de tableau). Une version linéaire basée sur les lignes peut être créé en lisant l'entête de ligne, précédant alors chaque cellule avec l'entête de colonne de la cellule. Ou, la linéarisation peut être basée sur les colonnes. Notez que la direction d'écriture de la langue naturelle peut affecter la présentation des colonnes (et donc l'ordre). En HTML, l'attribut " dir" spécifie la présentation de l'ordre des colonnes (ex., dir="rtl" spécifie présentation de la droite vers la gauche).
• N'utilisez pas PRE pour créer une présentation tabulée d'un texte -- utilisez l'élément TABLE ainsi les technologies d'assistance peuvent reconnaître que c'est un tableau.
• Fournissez un titre par l'intermédiaire de l'élément CAPTION.
• Fournissez un résumé via l'attribut "summary". Les résumés sont particulièrement utiles pour les lecteurs non visuels.
• Fournissez des substituts laconiques pour les noms d'entêtes avec l'attribut "abbr" sur TH. Ceci sera particulièrement utiles pour les technologies futures des interpréteurs vocaux qui peuvent lire les noms de lignes et des colonnes pour chaque cellule. Les abbrévations évitent la répétition et racourcissent le temps de lecture.
• Les navigateurs futurs et les technologies d'assistances seront capables de traduire automatiquement les tableaux en une séquence linéaire ou de naviguer dans un tableau cellule par cellule si les données sont labellisées de façon appropriées. Le groupe de travail WAI d'évaluation et de Réparation suit le progrès des outils tout en développant leurs outils propres pour permettre aux utilisateurs de naviguer dans les tableaux cellule par cellule. Voir [WAI-ER].

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

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

Un synthétisuer vocal pourra rendre ce tableau ainsi :

  Titre : Cups of coffee consumed by each senator
  Résumé : This table charts the number of cups of coffee
           consumed by each senator, the type of coffee
          (decaf or regular), and whether taken with sugar.
  Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: No
  Name: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes

Un agent utilisateur visuel affichera le tableau comme suit :

[Description de tableau de café]

Le prochain exemple associe le même entête (TH) et cellules de donnée (TD) comme précédemment, mais cette fois en utilisant l'attribut "scope" plutôt que "headers". "Scope" doit avoir une des valeurs suivantes : "row", "col", "rowgroup", ou "colgroup." Scope spécifie l'ensemble des cellules de donnée qui doit être associé à la cellule entête courante. Cette méthode est particulièrement utile pour les tableaux simples. Il est à noter que le rendu vocal de ce tableau devra être identique que l'exemple précédent. Un choix entre les attributs "headers" et "scope" est dépendant de la complexité du tableau. Cela n'affecte pas la sortie tant que les relations entre les cellules entête et données sont rendus évidentes par le balisage.

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

L'exemple suivant montre comment créer des catégories au sein d'un tableau en utilisant l'attribut "axis".

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

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]

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.

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

Lorsqu'une image est utilisé comme contenu d'un lien, spécifiez un équivalent text pour l'image.

  <A href="routes.html">
     <IMG src="topo.html"
          alt="Current routes at Boulders Climbing Gym">
  </A>

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

• Fournissez un lien qui permet aux utilisateurs de sauter l'ensemble de liens de navigation.
• Utilisez l'attribut HTML 4.0 "tabindex" pour permettre aux utilisateurs de sauter à une ancre située après l'ensemble des liens de navigation. Cet attribut n'est pas largement supporté.
• Fournissez une feuille de style qui permet aux utilisateurs de cacher l'ensemble des liens de navigation.

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

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

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

   <A accesskey="C" href="doc.html" hreflang="en"
      title="XYZ company home page">
         XYZ company home page</A>

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

   <IMG src="magnifyingglass.gif" alt="Search">

Lorsque vous utilisez OBJECT, spécifiez un équivalent texte dans le corps de l'élément OBJECT :

   <OBJECT data="magnifyingglass.gif" type="image/gif">
      Search
   </OBJECT>

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

   <IMG src="97sales.gif" alt="Sales for 1997"
        longdesc="sales97.html">

Pour les agents utilisateurs qui ne supportent pas "longdesc", fournissez un lien de description juste après le graphique :

   <IMG src="97sales.gif" alt="Sales for 1997" longdesc="sales.html">
   <A href="sales.html" title="Description of 1997 sales
figures">[D]</A>

Lorsque vous utilisez OBJECT, spécifiez l'équivalent texte plus long à l'intérieur du contenu de l'élément :

   <OBJECT data="97sales.gif" type="image/gif">
          Sales in 1997 were down subsequent to our
          <A href="anticipated.html">anticipated
          purchase</A> ...
   </OBJECT>

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 :

   <OBJECT data="97sales.gif" type="image/gif">
          Chart of our Sales in 1997.
          A <A href="desc.html">textual description</A> is
available.
  </OBJECT>

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.

<P>
<a href="#post-art">skip over ASCII art</a>
<!-- ASCII art goes here -->
<a name="post-art">caption for ASCII art</a>

L'art ascii peut également être balisé comme ceci [zapper la figure ascii ou consulter une description du graphe]:

  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __
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)

UNe autre option pour de l'art ascci plus petit est d'utiliser un élément ABBR avec un "title".

<P><ABBR title="smiley in ascii art">:-)</ABBR>

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

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

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 :

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

En plus de fournir un équivalent texte, fournissez des liens textuels redondants. Si l'élément A est utilisé à la place de AREA, le développeur de contenu peut décrire les régions actives et fournir des liens redondants en même temps :

   <OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
   <MAP name="map1">
     <P>Navigate the site.
     [<A href="guide.html" shape="rect"
        coords="0,0,118,28">Access Guide</A>]
     [<A href="shortcut.html" shape="rect"
        coords="118,0,184,28">Go</A>]
     [<A href="search.html" shape="circle"
        coords="184.200,60">Search</A>]
     [<A href="top10.html" shape="poly"
        coords="276,0,276,28,100,200,50,50,276,0">
          Top Ten</A>]
   </MAP>
   </OBJECT>

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 :

• Inclure les liens alternatifs à l'intérieur du corps de l'élément OBJECT (voir l' exemple précédent illustrant les liens dans les éléments OBJECT).
• Si IMG est utilisé pour insérer l'image, fournir une liste alternative de liens après celle-ci et indiquer l'existence et la localisation d'une liste alternative (ex., au moyen de l'attribut "alt").

  Exemple.

      <A href="http://myserver.com/cgi-bin/imagemap/my-map">
      <IMG src="welcome.gif" alt="Welcome! (Text links follow)" ismap>
      </A>
  
     <P>[<A href="reference.html">Reference</A>]
        [<A href="media.html">Audio Visual Lab</A>]
  

  Fin de l'exemple.

• Si d'autres ne permettent pas l'accessibilité de l'image cliquable, créer une page alternative qui est accessible.

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 :

  <OBJECT classid="java:Press.class" width="500" height="500">
        As temperature increases, the molecules in the balloon...
  </OBJECT>

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 :

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

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

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

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.

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 :

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

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 :

• Sans langage de scripting, Ils ont tendance à briser les fonctionnalités de "page précédente" offerte par les navigateurs.
• Il est impossible de donner référence à l'état courant d'un frameset avec un URI ; une fois qu'un frameset change de menu, l'URI original ne s'applique plus.
• Ouvrir un frame dans une nouvelle fenêtre du navigateur peut désorienter ou simplement ennuyer l'utilisateur.

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.

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

4.10.2 Equivalents textes pour les frames

Points de contrôle dans cette section : 12.2.

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

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

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

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

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.

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

L'exemple suivant desapprouvé devrait être évité car il insère IMG directement dans un frame :

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

  <P>Visit a beautiful grove of
  <A target="badframe" href="oranges.gif"
title="Oranges">oranges</A>

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 :

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

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.

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

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

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

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.

   <FORM action="submit" method="post">
   <P>
         <LABEL for="user" accesskey="U">name</LABEL>
         <INPUT type="text" id="user">
   </FORM>

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 :

• Utilisez plusieurs boutons d'envoi (chacun avec sa propre image) à la place d'un bouton d'envoi graphique unique. Les auteurs peut utiliser les feuilles de style pour contrôler la position de ces boutons.
• Utilisez une image cliquable côté client en même temps que le scripting.

4.11.7 Techniques pour des contrôles spécifiques

Points de contrôle dans cette section : 10.4.

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

Fournissez un équivalent texte pour les images utilisées comme un bouton d'envoi (submit) :

<FORM action="http://somesite.com/prog/text-read" method="post">
<P>
<INPUT type="image" name=submit src="button.gif" alt="Submit">
</FORM>

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,

• L'élément BUTTON n'apparaît pas
• INPUT avec type="button">apparaîtra comme un champs de saisie texte

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.

• Eviter la créatin de contenu à la volée par le client. Si un navigateur d'utilisateur ne gère pas les scripts, aucun contenu ne sera généré ou affiché. Cependant, Ceci est différent lorsqu'il s'agit d'afficher ou de cacher un contenu déjà existant en utilisant une combinaison de feuilles de style et de scripting ; S'il n'y a pas de scripts, le contenu sera tout de même affiché. Cela ne s'applique pas aux pages générées à la volée par le serveur et distribuées au client.
• Eviter la création de liens qui utilisent "javascript" pour l'URI. Si un utilisateur n'utilise pas les scripts, il sera alors incapable d'utiliser le lien car le navigateur ne pourra créé le lien.

  Exemple déprécié. Ceci est un lien mort pour un agent utilisateur qui ne supportent pas les scripts ou ceux-ci sont désactivés.

      <A href="javascript:">...</A>
  

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)
   • Utiliser "onmousedown" avec "onkeydown".
   • Utiliser "onmouseup" avec "onkeyup"
   • Utiliser "onclick" avec "onkeypress"

   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.

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

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

• Utilisez un nombre minimal de feuille de style pour votre site.
• Si vous en avez plus d'une, utilisez les mêmes noms "class" pour les mêmes concepts dans toutes les feuilles de style.
• Utilisez les feuilles de style liées plutôt que les feuilles de style incluses, et éviter les feuilles de style internes.
• Les développeurs de contenu ne devraient pas écrire de règles "!important". Les utilisateurs devraient lorsque nécessaire.
• Utilisez l'unité "em" pour définir les tailles de police.
• Utilisez les unités de longueur relative et les pourcentages. CSS vous permet d'utiliser des unités relatives même dans le positionnement absolu. Ainsi, vous pouvez placer une image en retrait par "3em" du haut de son élément conteneur. ceci est une distance fixe, mais elle est relative à la taille actuelle de la police, donc elle se met à l'échelle de façon élégante.
• Utilisez uniquement les longueurs absolues quand les caractéristiques physiques du médium de sortie sont connues.
• Spécifier toujours une police générique par défaut.
• Utilisez des nombres, pas de noms, pour les couleurs.
• Fournir un équivalent texte pour toutes les images importantes ou les textes générés par les feuilles de styles (ex., par les propriétés 'background-image', 'list-style', ou 'content'). Notez. Les textes générés par les feuilles de style font partis du document source et ne seront pas disponible aux technologies d'assistance qui accèdent au contenu grâce au DOM, level 1 ([DOM1]).
• Soyez sûr de vérifier que vos pages soient toujours accessible sans les feuilles de style.

Quelques exemples suivent.

   H1 { font-size: 2em }

   H1 { font-size: 12pt }

   BODY { margin-left: 15%; margin-right: 10%}

   .businesscard { font-size: 8pt }

   BODY { font-family: "Gill Sans", sans-serif }

   H1 {color: #808000}
   H1 {color: rgb(50%,50%,0%)}

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.

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

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 :

• Casse : 'text-transform' (pour majuscule, minuscule, et capitalisation).
• Ombres portées : 'text-shadow'
• Souligné, surligné, clignotement : 'text-decoration'. Note. Si le clignotement (ex., une manchette qui apparaît et disparaît à intervalles réguliers) est utilisé, founissez un mécanisme pour stopper le clignotement. En CSS, 'text-decoration: blink' provoquera un clignotement du contenu et permettra à l'utilisateur de stopper l'effet en désactivant les feuilles de style ou en choisissant sa feuille de style propre. N'utilisez pas les éléments BLINK et MARQUEE. Ces éléments ne font partie d'aucune spécification du W3C pour HTML (i.e., ce sont des éléments non standards).

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

<P>This is an
   <IMG src="BigRedexemple.gif" alt="exemple">
   of what we mean.
</P>

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 :

• Indentation : 'text-indent'. N'utilisez pas l'élément BLOCKQUOTE ou tout autre élément structurel pour indenter le texte.
• Espacement lettre/mot : 'letter-spacing', 'word-spacing'. Par exemple à la place d'écrire "H E L L O" (ce que les utilisateurs reconnaîtront comme le mot "hello" mais sera entendu comme des lettres individuelles), les auteurs peuvent créer le même effet visuel avec la propriété 'word-spacing' appliquée à "HELLO". Les textes sans espaces seront transformés plus efficacement pour la synthétisation.
• Espace blanc : 'white-space'. Cette propriété contrôle l'espace blanc lors du traitement du contenu d'un élément.
• Direction du texte : 'direction', 'unicode-bidi'.
• Les pseudo-éléments :first-letter et :first-line permettent aux auteurs de faire référence à la première lettre ou à la première ligne d'un paragraphe d'un texte.

L'exemple suivant montre comment utiliser les feuilles de style pour créer un effet de lettrine.

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

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 :

• 'color', pour la couleur de premier plan du texte.
• 'background-color', pour les couleurs de fond.
• 'border-color', 'outline-color' pour les couleurs de bordure.
• Pour les couleurs de liens, voir les pseudo-classes :link, :visited, et :active.

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 :

• Ils sont entourés par une bordure.
• Ils utilisent une couleur de fond différente.
• Ils commencent avec le mot "Exemple" (ou "Exemple déprécié").
• Ils se terminent également avec la phrase "Fin de l'exemple", mais cette phrase est cachée par défaut avec 'display: none'. Pour les agents utilisateurs qui ne supportent pas les feuilles de style ou qui ont les feuilles de style désactivées, ce texte aide à marquer la fin de l'exemple pour les lecteurs qui ne seraient pas capables de voir la bordure autour de l'exemple.

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

• 'text-indent', 'text-align', 'word-spacing', 'font-stretch'. Chacune de ces propriétés permet aux utilisateurs de contrôler l'espacement sans ajouter d'espaces supplémentaires. Utilisez 'text-align: center' à la place de l'élément déprécié CENTER.
• 'margin', 'margin-top', 'margin-right', 'margin-bottom', 'margin-left'. Avec ces propriétés, les auteurs peuvent créer des espaces sur les 4 côtés du contenu d'un élément à la place d'ajouter des espaces non sécables (&nbsp;), qui sont un balisage non-standard, pour créer des espaces autour d'un élément.
• 'float', 'position', 'top', 'right', 'bottom', 'left'. Avec ces propriétés, l'utilisateur peut contrôler la position visuelle de la plupart des éléments d'une manière indépendante de l'endroit où les éléments doivent apparaître dans le document. Les auteurs devraient toujours concevoir leur document qui reste compréhensible une fois la feuille de style désactivée (i.e., le document devrait être écrit dans un ordre "logique") et ensuite appliquer la feuille de style pour créer les effets visuels Les propriétés de positionnement peuvent être utilisées pour créer des notes de marge (qui peuvent être numérotées automatiquement), des barres de côté, des effets de type frame, des hauts et des pieds de pages, et plus.
• La propriété 'empty-cells' permet aux utilisateurs de laisser vide une cellule de tableau et donne tout de même les bordures correctes à l'écran ou sur le papier. Une cellule de données qui est considérée comme vide ne devrait pas être remplie avec un espace blanc ou un espace non sécable uniquement pour réaliser un effet visuel.

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.

   mom poème requère un grand espace<IMG src="10pttab.gif"
alt="&nbsp;&nbsp;&nbsp;">ici

   <IMG src="spacer.gif" alt="spacer">
   <IMG src="colorfulwheel.gif" alt="The wheel of fortune">

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 :

• 'border', 'border-width', 'border-style', 'border-color'.
• 'border-spacing' et 'border-collapse' for tables.
• 'outline, 'outline-color', 'outline-style', et 'outline-width' pour les plans (outlines) dynamiques.

Les auteurs devraient utiliser les feuilles de style pour créer les règles et les bordures.

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

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

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

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.

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.

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.