Directives pour l'accessibilité aux contenus Web
version 1.0 - 5 mai 1999

6. Directives d’accessibilité aux contenus Web

Directive 1 : Fournir des alternatives équivalentes au contenu visuel et auditif.

Fournir du contenu qui, présenté à l’utilisateur, convoie essentiellement la même fonction ou raison d’être que le contenu auditif ou visuel.

Bien que certaines personnes ne puissent pas utiliser les images, les films, les sons, les appliquettes, etc. directement, ils peuvent malgré tout utiliser les pages incluant des informations équivalentes au contenu visuel ou auditif. L’information équivalente doit avoir la même raison d’être que le contenu visuel ou auditif. Un texte équivalent à l’image d’une flèche vers le haut servant de lien vers une table des matières pourrait ainsi être " Accéder à la table des matières ". Dans certains cas, un équivalent devrait aussi décrire l’apparence du contenu visuel (par exemple pour les graphiques, tableaux, ou diagrammes complexes) ou le son du contenu audio (par exemple pour les échantillons audio utilisés dans l’éducation).

Cette directive souligne l’importance des équivalents textuels au contenu non-textuel (images, audio et vidéo pré-enregistrées). La puissance des équivalents textuels repose dans leur capacité à être restitués de façon a être accessibles a des personnes émanant de groupes de handicaps divers utilisant différentes technologies. Le texte peut être directement expédié à des synthétiseurs vocaux et à des générateurs de braille, et peut être représenté visuellement (dans une grande variété de tailles) sur des affichages informatiques et du papier. La voix synthétique est indispensable aux individus non-voyants et pour beaucoup de personnes souffrant des difficultés de lecture qui accompagnent souvent les déficiences cognitives, les handicaps d’apprentissages, et la surdité. Le braille est essentiel aux individus qui sont à la fois sourds et aveugles, ainsi que pour de nombreux individus dont le seul handicap sensoriel est la non-voyance. Les utilisateurs sourds tout comme la majorité des utilisateurs du Web bénéficient également du texte affiché visuellement.

La fourniture d’équivalents non-textuels (par exemple des images, des vidéos et de l’audio pré-enregistré) au texte est également bénéfique a certains utilisateurs, en particulier les non-lecteurs et les personnes ayant des difficultés de lecture. Dans les films ou présentation visuelles, les actions visuelles comme le langage corporel ou d’autres indices visuels peuvent ne pas être accompagnés de suffisamment d’information audio pour convoyer la même information. A moins que des descriptions verbales de ces informations visuelles ne soient fournies, les personnes qui ne peuvent pas voir (ou regarder vers) le contenu visuel ne pourront pas le percevoir.

Points à contrôler :

1. Fournir un équivalent textuel à chaque élément non-textuel (par exemple via " alt ", " longdesc ", ou dans le contenu des éléments). Ceci inclut : les images, les représentations graphiques de texte (y compris les symboles), les zones actives de cartes cliquables, les animations (par exemple les GIF animés), les appliquettes et objets programmatiques, l’art ascii, les cadres, les scripts, les images utilisées comme puces pour les listes, les éléments d’espacement, les boutons graphiques, les sons (joués avec ou sans interaction de l’utilisateur), les fichiers audio séparés, les pistes audio de vidéos, et la vidéo. [Priorité 1]
   Par exemple, en HTML :
   • Utiliser " alt " pour les éléments IMG, INPUT et APPLET, ou fournir un équivalent textuel dans le contenu des éléments OBJECT et APPLET.
   • Pour les contenus complexes (par exemple, un graphique) où le texte " alt " ne fournit pas un équivalent texte complet, fournir une description supplémentaire en utilisant, par exemple, " longdesc " avec IMG et FRAME, un lien à l’intérieur d’un élément OBJET, ou un lien de description.
   • Pour les cartes cliquables, utiliser soit un attribut " alt " avec AREA, soit l’élément MAP avec des éléments A (et autre texte) comme contenu.
   Se référer également aux points à contrôler 9.1 et 13.10
   
   
2. Fournir des liens textes redondants pour chaque région active d’une carte cliquable côté serveur. [Priorité 1] Se référer également aux points à contrôler 1.5 et 9.1
   
   
3. Jusqu’à ce que les agents utilisateurs soient en mesure de lire automatiquement à haute voix l’équivalent textuel d’une piste visuelle, fournir une description auditive des informations importantes de la piste visuelle d’une présentation multimédia. [Priorité 1] Synchroniser la description auditive avec la piste audio comme décrit au point 1.4. Se référer au point 1.1 pour des informations sur les équivalents textuels d’informations visuelles.
   
   
4. Pour toute présentation multimédia temporisée (par exemple un film ou une animation), synchroniser les alternatives équivalentes (par exemples les sous-titres ou la description auditive des pistes visuelles) avec la présentation. [Priorité 1]
   
   
5. Jusqu’à ce que les agents utilisateurs soient en mesure de restituer les équivalents textuels des liens des cartes cliquables côté client, fournir des liens textuels redondants pour chaque région active d’une carte cliquable côté client. [Priorité 3]
   Se référer également aux points à contrôler 1.2 et 9.1

Directive 2. Ne pas s’en remettre exclusivement aux couleurs.

S’assurer que les textes et graphiques sont compréhensibles quand on les visualise sans couleur.

Si les couleurs seules sont utilisées pour convoyer l’information, les personnes qui ne peuvent pas distinguer certaines couleurs et les utilisateurs équipés de périphériques à affichage non-multicolore ou non-visuel ne la recevront pas.

Quand les couleurs de premier plan et d’arrière-plan sont trop proches d’une même teinte, elle peuvent ne pas fournir un contraste suffisant lorsqu’elles sont visualisées sur des affichages monochromes ou par des personnes souffrant de différents handicaps liés à la perception des couleurs.

Points à contrôler :

1. S’assurer que toute information convoyée par des couleurs est également accessible sans couleur, par exemple à partir du contexte ou de balises. [Priorité 1]
   
   
2. S’assurer que la combinaison de couleurs entre le premier plan et l’arrière-plan utilise suffisamment de contraste lorsqu’elle est utilisée par des personnes souffrant d’un déficit de perception des couleurs ou sur un écran noir et blanc. [Priorité 2 pour les images, Priorité 3 pour le texte].
   
   

Directive 3. Utiliser le balisage et les feuilles de style, et cela de façon appropriée.

Baliser les documents avec les éléments structurants appropriés. Contrôler la présentation avec des feuilles de style plutôt qu’avec des éléments et des attributs de présentation.

L’utilisation inappropriée du balisage — c’est à dire sans respecter les spécifications — restreint l’accessibilité. Le fait de détourner une balise pour créer un effet de présentation (par exemple, utiliser une table pour la mise en page ou un en-tête pour changer la taille de la police de caractères) complique la tâche des utilisateurs utilisant des logiciels spécialisés quand ils essayent de comprendre l’organisation de la page ou d’y naviguer. Le fait d’utiliser un balisage de présentation plutôt qu’un balisage structurant pour exprimer la structure (par exemple, construire quelque chose qui ressemble [à l’écran] à des données en tableau avec un élément HTML PRE) complique la restitution intelligible de la page sur d’autres périphériques (se référer à la différence entre contenu, structure et présentation).

Les développeurs de contenu peuvent être tentés d’user (ou d’abuser) de constructions qui rendent possible un effet de formatage sur certains logiciels de consultation anciens. Ils doivent être conscients que ce type de pratiques cause des problèmes d’accessibilité et doivent se demander si l’effet de formatage est d’une telle importance qu’il justifie de rendre le document inaccessible à certains utilisateurs.

A l’autre extrême, les développeurs de contenu ne doivent pas sacrifier un balisage approprié sous prétexte qu’un logiciel de consultation ou une technologie d’assistance donnée ne les interprètent pas correctement. Par exemple, il est approprié d’utiliser l’élément TABLE en HTML pour marquer une information disposée sous forme de tableau, même si certains lecteurs d’écrans anciens ne sont pas en mesure de gérer correctement le texte organisé en colonnes (se référer au point à contrôler 10.3). Utiliser correctement TABLE et créer des tableaux qui se transforment de façon élégante (se référer à la directive 5) donne la possibilité aux logiciels de restituer les tables autrement que sous forme de grilles en deux dimensions.

Points à contrôler :

1. Quand un langage de balisage approprié existe, utiliser des balises plutôt que des images pour convoyer l’information. [Priorité 2]
   Par exemple, utiliser MathML pour baliser les équations mathématiques, et des feuilles de styles pour formater le texte et contrôler la mise en page. Eviter également d’utiliser des images pour représenter du texte — utiliser plutôt du texte et des feuilles de styles. Se référer également aux directives 6 et 11.
   
   
2. Créer des documents qui sont validés par des grammaires formelles publiées. [Priorité 2]
   Par exemple, inclure une déclaration de type de document (" document type declaration ") au début du document, se référant à une DTD publiée (par exemple, la DTD " strict HTML 4.0 ").
   
   
3. Utiliser des feuilles de style pour contrôler la mise en page et la présentation. [Priorité 2]
   Par exemple, utiliser la propriété ‘font’ des CSS plutôt que l’élément FONT du HTML pour contrôler les styles de polices de caractères.
   
   
4. Utiliser des unités relatives plutôt qu’absolues dans les valeurs d’attributs du langage et les valeurs de propriétés des feuilles de style. [Priorité 2]
   Par exemple, dans les CSS, utiliser des longueurs ‘em’ ou des pourcentages plutôt que ‘pt’ ou ‘cm’ qui sont des unités absolues. Si des valeurs absolues sont employées, vérifier que le contenu restitué est utilisable (se référer à la section concernant la validation).
   
   
5. Utiliser les éléments d’en-tête pour convoyer la structure du document, et les utiliser en conformité avec les spécifications. [Priorité 2]
   Par exemple, en HTML, utiliser H2 pour indiquer une sous-section de H1. Ne pas utiliser les en-têtes pour réaliser des effets de polices de caractères.
   
   
6. Marquer les listes et les éléments de listes correctement [Priorité 2]
   Par exemple, en HTML, imbriquer les listes OL, UL et DL correctement.
   
   
7. Baliser les citations. Ne pas utiliser le balisage correspondant aux citations pour obtenir des effets de présentation comme l’indentation. [Priorité 2]
   Par exemple, en HTML, utiliser les éléments Q et BLOCKQUOTE pour baliser les citations courtes et plus longues, respectivement.
   
   

Directive 4. Clarifier l’utilisation du langage naturel

Utiliser un balisage facilitant la prononciation ou l’interprétation du texte abrégé ou en langue étrangère.

Quand les développeurs de contenu balisent les changements de langage naturel dans un document, les synthétiseurs vocaux et les générateurs de braille peuvent automatiquement passer au nouveau langage, rendant le document plus accessible aux utilisateurs polyglottes. Les développeurs de contenu devraient rendre identifiable le langage prédominant du contenu d’un document (en utilisant des balises ou des en-têtes). Les développeurs de contenu devraient aussi fournir des descriptions explicites des abréviations et acronymes.

Outre qu'il sert aux technologies dont le but est d'assister l'accès, le marquage en language naturel permet aux moteurs de recherche de trouver les mots-clé et d'identifier les documents dans la langue souhaitée. Le marquage en language naturel améliore la lisibilité du web pour tous, y compris ceux souffrant de difficultés d'apprentissage, de déficience cognitive, ou de surdité.

Lorsque les abbréviations ou les changements survenus dans le language naturel ne peuvent être identifiés, il se peut qu'ils soient indéchiffrables lorsqu'ils sont prononcés par une machine ou écrits en Braille.

Points à contrôler :

1. Identifier clairement les changements survenus dans le language naturel du texte d'un document et équivalents (par exemple les légendes). [Priorité 1]
   Par exemple, en HTML utilisez l'attribut "lang". En XML, utilisez "xml:lang".
   
   
2. Spécifier la forme complète de toutes les abbréviations ou acronymes employés dans le document lors de la première utilisation. [Priorité 3]
   Par exemple, en HTML utilisez l'attribut "title" ou les éléments ABBR et ACRONYM. Pour faciliter l'utilisation de votre document, vous devez également fournir la version complète des abbréviations utilisées dans le corps du document.
   
   
3. Identifier le language naturel principal du document. [priorité 3]
   Par exemple, en HTML placez l'attribut "lang" dans le code HTML. En XML, utilisez "xml:lang". Les administrateurs des serveurs devraient configurer leurs machines de manière à utiliser les fonctions de négociation de contenu du http ([RFC2068], section 14.13), de manière à ce que les postes clients puissent récupérer automatiquement les documents dans la langue recommandée.
   
   

Directive 5. Créer des tableaux qui se transforment de façon élégante.

Assurez vous que vos tables possèdent les balises nécessaires pour être interprétées par les logiciels de consultation existants et autres agents utilisateurs.

Les tables devraient être utilisées pour présenter des données existant à l'origine sous forme de tables ("tableaux de données"). Les développeurs de contenu devraient éviter leur utilisation pour la mise en page ("tables de mise en page"). Les tables tous-usages posent également des problèmes aux utilisateurs de dispositifs vocaux de lecture d'écran (voir le point à contrôler 10.3)

Certains agents-utilisateurs permettent aux utilisateurs de naviguer parmi les cellules d'une table, et d'accéder aux en-têtes et autres informations relatives aux cellules. De telles tables ne pourront pas fournir aux agents les informations appropriées, a moins d'être correctement balisées. (voir également la directive 3.)

Les aides suivantes concernent directement les gens qui accèdent aux tables par des dispositifs audio (comme un dispositif vocal de lecture d'écran, ou un ordinateur personnel embarqué), ou ceux qui ne peuvent voir qu'une partie de la page à la fois (comme les handicapés visuels qui utilisent une sortie vocale ou un écran braille, ou bien encore les utilisateurs équipés de petits écrans etc.)

Points à contrôler:

1. Pour les tableaux de données, identifier les en-têtes de lignes et de colonnes. [Priorité 1]
   Par exemple, en HTML, utiliser TD pour signaler les cellules de données et TH pour signaler les en-têtes.
   
   
2. Pour les tableaux de données qui ont deux niveaux logiques d'en-tête de colonne ou de ligne ou plus , utiliser des balises pour associer les cellules de données et les cellules d'en-tête. [priorité 1]
   Par exemple, en HTML, utiliser THEAD, TFOOT et TBODY pour regrouper les lignes, COL et COLGROUP pour regrouper les colonnes et les attributs "axis", "scope" et "headers" pour décrire des relations plus complexes entre les données.
   
   
3. Ne pas utiliser les tables pour la mise en page, à moins qu'elles n'aient un sens lorsqu'elles sont déchiffrées en mode linéaire. Autrement, si la table n'a pas de signification, prévoir une version alternative (qui pourra être une version linéaire). [priorité 2]
   Note. Lorsque les dispositifs clients supporteront le positionnement par feuilles de styles, les tables ne devront plus être utilisées pour la mise en page. Voir également le point à contrôler 3.3
   
   
4. Dans le cas ou une table est employée pour la mise en page, il ne faut pas utiliser de balises structurelles dans un but de formatage visuel. [priorité 2]
   Par exemple, en HTML il ne faut pas utiliser l'élément TH pour centrer et mettre en gras le contenu d'une cellule (si cette dernière n'appartient pas à l'en-tête d'une table).
   
   
5. Créer des sommaires pour les tables. [priorité 3]
   Par exemple, en HTML, utiliser l'attribut "summary" de l'élément TABLE.
   
   
6. révoir des abbréviations pour les étiquettes d'en-têtes. [priorité 3]
   Par exemple, en HTML utiliser l'attribut "abbr" pour l'élément TH.
   
   

Directive 6. S’assurer que les pages qui contiennent de nouvelles technologies se transforment de façon élégante.

S'assurer que les pages sont accessibles même lorsque les dernières technologies ne sont pas supportées ou sont désactivées.

Bien que les développeurs de contenu soient encouragés à utiliser les dernières technologies pour résoudre les problèmes causés par les technologies actuelles, ils doivent savoir créer des pages visibles par des anciens navigateurs ou par des navigateurs récents ayant désactivés certaines options.

Points à contrôler :

1. Organiser les documents de manière à ce qu'ils puissent être lus sans feuilles de style. Par exemple, lorsque un document HTML est restitué sans la feuille de style lui étant associée, il doit rester lisible. [priorité 1]
   Lorsque le contenu est organisé de manière logique, il sera restitué de manière compréhensible lorsque les feuilles de style sont désactivées ou non supportées.
   
   
2. S'assurer que les équivalences pour le contenu dynamique soient mises à jour lorsque ledit contenu dynamique change. [priorité 1]
   
   
   
3. S'assurer que les pages soient visibles lorsque les scripts, les applets ou autres artefacts programmables sont désactivés ou non supportés. Lorsque ce n'est pas possible, fournissez une information équivalente sur une page alternative. [priorité 1]
   Par exemple, assurez vous que les liens qui activent les scripts fonctionnent même lorsque ces derniers sont désactivés ou non supportés (par ex. Il ne faut pas utiliser "javascript:" comme cible des liens). Si vous ne pouvez construire une page utilisable sans scripts, placez une équivalence avec l'élément NOSCRIPT, ou utilisez un script côté serveur au lieu d'un script exécutable sur le poste client. Vous pouvez également proposer une page alternative comme précisé dans le point à contrôler 11.4. Voir également la directive 1.
   
   
4. Pour les scripts et les applets, faites en sorte que les gestionnaires d'événements soient indépendants du dispositif d'entrée. [priorité 2]
   Voir la définition de l'indépendance d'un dispositif.
   
   
5. S'assurer que le contenu dynamique reste accessible, ou fournir une présentation alternative de la page. [priorité 2]
   Par exemple, en HTML, utilisez l'élément NOFRAMES à la fin de chaque jeu de cadres (Frameset). Pour certaines applications, les scripts côté serveur seront plus accessibles que des scripts côté client.
   
   

Directive 7. Assurer à l'utilisateur le contrôle des changements du contenu lorsque ce dernier varie dans le temps.

S'assurer que les fonctions permettant de faire bouger, clignoter, défiler ou mettre à jour automatiquement des objets ou des pages puissent être mises en pause ou stoppées.

Certaines personnes souffrant d'incapacités mentales ou visuelles ne peuvent pas lire un texte lorsqu'il bouge. Les mouvements peuvent causer une telle distraction que le reste d'une page peut devenir illisible pour des gens souffrant de handicap cognitif. Les dispositifs vocaux de lecture d'écran ne peuvent lire un texte en mouvement. Certaines personnes souffrant de handicap physique pourraient ne pas être en mesure de bouger suffisemment vite ou précisément pour interagir avec des objets en mouvement.

Note. Tous les points à contrôler qui suivent engagent la responsabilité des développeurs de contenu, jusqu'à ce que les agents-utilisateurs puissent fournir des mécanismes de contrôle du contenu adéquats.

Points à contrôler :

1. Jusqu'à ce que les agents-utilisateurs permettent à l'utilisateur de contrôler les changements brusques de luminosité, il convient d'éviter de causer de tels changements sur l'écran.
[priorité 1]
Note. Certaines personnes souffrant d'épilepsie causée par une sensibilité particulière à la lumière peuvent avoir des crises déclenchées par des cligotements dans la zone des 4 à 59 flashs par seconde (Hertz). La sensibilité maximale est atteinte à 20 flashs par seconde. Ces crises peuvent être causées également par de brusques changements de luminosité (comme des lumières stroboscopiques).


2. Jusqu'à ce que les agents-utilisateurs permettent de désactiver le clignotement, éviter de faire clignoter le contenu
(par ex. Changer une présentation à intervalles régulier, comme une activation ou une désactivation). [priorité 2]


3. Jusqu'à ce les agents-utilisateurs permettent de geler le contenu mobile, éviter les mouvements sur les pages.
[priorité 2]
Lorsqu'une page comprend un contenu mobile, prévoir un mécanisme (via un script ou une appliquette) permettant à l'utilisateur d'immobiliser les mouvements ou les mises à jour. L'utilisation de feuilles de styles en association avec des scripts pour créer les mouvements permet à l'utilisateur de désactiver cet effet plus facilement. Voir également la directive 8.


4. Jusqu'à ce que les agents-utilisateurs permettent de stoper les mises à jour, éviter de créer des pages se mettant à jour automatiquement.
[priorité 2]
Par exemple, en HTML n'utilisez pas "http-EQUIV=refresh" pour mettre à jour vos pages, jusqu'à ce que les agents-utilisateurs permettent de désactiver cette fonction.


5. Jusqu'à ce que les agents-utilisateurs permettent de désactiver la fonction de redirection automatique, ne pas utiliser de commandes pour rediriger automatiquement les pages.
Configurez plutôt le serveur pour accomplir cette fonction. [priorité 2]
Note. Les éléments BLINK et MARQUEE ne font partie d'aucune recommandation HTML émanant du W3C, et ne doivent pas être utilisés. Voir également la directive 11.

Directive 8. Assurer un accès direct aux interfaces utilisateur intégrées.

S'assurer que l'interface utilisateur respecte les principes d'accessibilité: Accès aux fonctionnalités indépendant du type d'interface-utilisateur, accès depuis le clavier, commandes vocales etc. Lorsqu'un objet inclus possède sa "propre interface", l'interface - comme celle du navigateur lui même - doit être accessible. Si on ne peut rendre accessible l'interface de l'objet intégré, on veillera à proposer une solution alternative.

Note. Pour des informations sur les interfaces accessibles, on consultera les Directives sur l'Accessibilité des Agents-Utilisateurs ([WAI-USERAGENT]) et les Directives pour l'Accessibilité des Outils de Production ([WAI-AUTOOL]).

Point à contrôler :

1. Concevoir les éléments programmables tels que scripts et appliquettes de manière à ce qu'ils puissent être directement accessibles ou compatibles avec les différentes technologies d'assistance aux utilisateurs.
[priorité 1 si les fonctions sont importantes et non présentes ailleurs, sinon priorité 2.]
Voir également la directive 6.

Directive 9. Conception respectant l’indépendance par rapport au périphérique.

Utiliser des fonctions permettant l'activation des éléments d'une page grâce à différentes interfaces d'entrée.

Un accès indépendant de l'interface signifie que l'utilisateur peut interagir avec le document ou l'agent-utilisateur via une interface d'entrée (ou de sortie) de prédilection - la souris, le clavier, la voix ou autres. Prenons par exemple un champ de formulaire qui ne peut être activé que par une souris ou autre dispositif de pointage. Dans ce cas, une personne souffrant d'une vision déficiente qui accèderait à la page via un dispositif à commande vocale ou autre interface d'entrée n'utilisant pas le pointage ne serait pas capable d'utiliser le formulaire.

Note. Pour permettre aux utilisateurs d'interagir avec des cartes cliquables ou des liens hypertextes sous forme d'images sans utiliser de dispositifs de pointage, il faut prévoir des équivalents textes. Voir également la directive 1.

Points à contrôler :

1. Prévoir des cartes cliquables côté client au lieu de cartes côté serveur, sauf lorsque les régions ne peuvent être définies par des formes géométriques disponibles.
[Priorité 1]
Voir également les points de contrôle 1.1, 1.2 et 1.5.


2. S'assurer que tout élément qui possède sa propre interface peut être activé d'une manière indépendante du dispositif.
[priorité 2]
Voir la définition de l'indépendance par rapport au dispositif.
Voir également la directive 8.


3. En ce qui concerne les scripts, il importe de spécifier les gestionnaires d'événements logiques plutôt que des gestionnaires d'événements dépendants de l'interface.
[priorité 2]


4. Développer un ordre logique de tabulation, pour les liens, éléments de formulaires et objets
[priorité 3]
Par exemple, en HTML, spécifier un ordre de tabulation grace à l'attribut "tabindex" ou garder une conception de page logique.


5. Prévoir des raccourcis clavier pour les liens importants (y compris ceux derrière les cartes cliquables côté client), les champs de formulaires, groupés ou individuels.
[priorité 3]
Par exemple en HTML, spécifier des raccourcis grâce à l'attribut "accesskey".

Directive 10. Utilisation de solutions intermédiaires.

Utiliser des solutions d'accessibilité intermédiaires, de manière à ce que les technologies d'assistance et les anciens navigateurs fonctionnenet correctement.

Par exemple, les anciens navigateurs ne permettent pas aux utilisateurs de naviguer entre champs d'édition vides. Les anciens dispositifs vocaux de lecture d'écran lisent les listes de liens consécutifs comme un seul lien. Il est donc difficile voir impossible d'accéder à

de tels éléments actifs.

Le fait de changer la fenêtre active du navigateur, ou d'ouvrir plusieurs fenêtres successives peut particulièrement désorienter les utilisateurs qui ne sont pas en mesure de voir de tels événements.

Note. Les points à contrôler qui suivent sont à appliquer jusqu'à ce que les agents-utilisateurs (incluant les technologies d'assistance)résolvent ces problèmes. Ces

points sont qualifiés "d'intermédiaires". C'est à dire que le Groupe de Travail en charge des Directives pour la création de contenu Web les considère comme valides et nécessaires à l'accès au web, au moment de la publication du présent document. Cependant le groupe de travail estime que ces points ne seront plus nécessaires dans le futur, lorsque les technologies du web auront incorporé les fonctionnalités ou possibilités suivantes.

Points à contrôler :

1. Jusqu'à ce que le agents-utilisateurs permettent aux utilisateurs de fermer les fenêtres générées, ne pas produire de fenêtre successives ou à ouverture automatique, et ne pas modifier la fenêtre active sans prévenir l'utilisateur.
[priorité 2]
Par exemple, en HTML, ne pas utiliser de cadres dont la cible est une nouvelle fenêtre.


2. Jusqu'à ce que les agents-utilisateurs supportent les associations explicites entre étiquettes et contrôles de formulaires, s'assurer que les étiquettes sont correctement positionnées pour tous les contrôles de formulaire avec étiquettes implicitement associées.
[priorité 2]
L'étiquette doit immédiatement précéder le contrôle qui lui est associé, sur la même ligne (permettant de placer plusieurs couples contrôle/étiquette par ligne). On peut également placer l'étiquette au niveau de la ligne précédent immédiatement le contrôle (avec dans ce cas une seule étiquette et un seul contrôle par ligne). Voir également le point à contrôler 12.4.


3. Jusqu'à ce que les agents utilisateurs (comprenant les technologies d'assistance) puissent restituer des textes adjacents correctement, prévoir une alternative en mode texte linéaire (sur la page concernée ou sur une autre) pour toutes les tables qui formattent le texte en colonnes parallèles et qui ajustent le texte sur la largeur de la colonne.
[priorité 3]
Note. Consulter la définition des tables linéarisées. Ce point à contrôler concerne les utilisateurs possédant des agents-utilisateurs (comme certains déchiffreurs vocaux d'écrans) ne pouvant gérer des blocs de textes présentés côte à côte; ce point à contrôler ne doit cependant pas décourager les développeurs de contenu dans leur utilisation des tables pour représenter des données en tableaux.


4. Jusqu'à ce que les agents-utilisateurs puissent gérer correctement les contrôles vides, placer du texte pour occuper l'espace dans les champs vides des formulaires [boîtes de textes et lignes d'entrée de texte].
[priorité 3]
Par exdemple, en HTML, respectez ces instructions pour les TEXTAREA et INPUT.


5. Jusqu'à ce que les agents utilisateurs (comprenant les technologies d'assistance) puissent gérer correctement les liens hypertextes adjacents, insérer entre ces liens des caractères imprimables non-hypertextes.
` [priorité 3]

Directive 11. Utilisation des technologies et directives du W3C

Utiliser les technologies préconisées par le W3C (selon les spécifications), et respecter les Directives d'accessibilité. Lorsque on ne peut utiliser une technologie du W3C, ou si en le faisant on ne peut obtenir un résultat qui se transforme de façon élégante, il faut prévoir une version alternative pour présenter le contenu.

Les directives actuelles recommandent l'utilisation des technologies du W3C (Par ex. HTML, CSS, etc.) pour plusieurs raisons:

* Les technologies du W3C comprennent des options d'accessibilité "embarquées".

* Les spécifications du W3C subissent des révisions précoces, de manière à intégrer les solutions d'accès dès la phase de conception.

* Les spécifications du W3C sont élaborées de manière ouverte et découlent d'un consensus de l'industrie.

Plusieurs standards non-W3C (par ex. PDF, Shockwave, etc.) reposent sur l'utilisation de plug-ins ou de logiciels séparés pour la visualisation. Souvent, on ne peut consulter ou regrader le contenu à ces formats avec les agents-utilisateurs courants (y compris les technologies d'assistance). En évitant d'utiliser des technologies non-W3C ou non-standard (éléments, attributs, propriétés et extension propriétaires) on pourra produire des pages plus accessibles, et accessibles à plus de gens utilisant une plus grande variété de matériel et de logiciels. Lorsque l'on doit utiliser des technologies non-accessibles (propriétaires ou non), on devra prévoir des pages accessibles équivalentes.

Même lorsqu'on utilise des technologies du W3C, on doit respecter les directives d'accessibilité. Lorsque on utilise des technologies récentes, on s'assurera qu'elles se transforment de façon élégante. (Voir également la directive 6.)

Points à contrôler :

1. Utiliser les technologies du W3C lorsque elles sont disponibles et adaptée à une tache. Utilisez les dernières versions supportées.
[priorité 2]
Consultez la liste des références si vous recherchez les dernières spécifications du W3C et [WAI-UA-SUPPORT] pour des informations sur le support des technologies du W3C par les agents-utilisateurs.


2. Eviter d'utiliser les options des technologies du W3C qui ne sont plus supportées.
[priorité 2]
Par exemple, en HTML, ne plus utiliser l'élément FONT, qui n'est plus supporté; Utiliser les feuilles de style (CSS) à la place. (par ex. La propriété 'font' des CSS).


3. Fournir des informations de manière à ce que les utilisateurs puissent recevoir les documents selont les préférences qu'ils ont spécifiées. (par ex. la langue, le type de contenu, etc.)
[priorité 3]
Note. Utiliser les options de négociation du contenu lorsque c'est possible.


4. Si, malgré vos efforts vous ne parvenez pas à produire une page accessible, créez un lien vers une autre page accessible, qui utilise les technologies du W3C, et qui présente la même information (ou fonctionnalité).
Elle devra être remise à jour aussi souvent que la page d'origine (inaccessible). [priorité 1]
Note. Les développeurs de contenu ne devraient se résoudre à utiliser cette technique des pages alternative qu'en dernier ressort, car ces pages sont généralement remises à jour moins souvent que les pages d'origine. Une page qui n'est plus à jour peut être aussi frustrante qu'une page inaccessible, puisque, dans les deux cas, l'information présente sur la page d'origine est inaccessible.
La génération automatique de pages alternatives permet des mises à jour plus fréquentes, mais les développeurs de contenu doivent cependant veiller à ce que les pages générées de cette manière soient lisibles, et à ce qu'un utilisateur puisse visiter le site en utilisant les pages principales, les pages alternatives ou les deux. Avant de vous résoudre à utiliser des pages alternatives, repensez la conception de la page d'origine; En la rendant accessible, vous l'améliorerez probablement pour tous les utilisateurs.

Directive 12. Fourniture d’informations de contexte et d’orientation.

Fournir des informations relatives au contexte et à l'orientation pour que les utilisateurs puissent comprendre les éléments et les mises en pages complexes.

On peut aider tous les utilisateurs en groupant les éléments et en fournissant des informations contextuelles sur les relations entre éléments. Les relations complexes entre éléments d'une page peuvent être difficiles à interpréter pour les personnes souffrant de difficulté de compréhension, ou d'un défaut de vision.

Points à contrôler :

1. Donner un titre à chaque cadre pour faciliter l'identification et la navigation entre cadres.
[priorité 1]
Par exemple, en HTML utiliser l'attribut "title" de l'élément FRAME.


2. Décrire l'objectif des cadres et la manière dont les cadres interagissent les uns avec les autres, si ce n'est pas évident à la la seule lecture des titres.
[priorité 2]
Par exemple, en HTML, utiliser "longdesc" ou une desription du lien.


3. Lorsque c'est approprié, diviser les grands blocs d'information en groupes plus petits et plus facilement manipulables.
[priorité 2]
Par exemple, en HTML, utiliser OPTGROUP pour regrouper les éléments OPTION d'un champ SELECT; regrouper les contrôles de formulaires avec FIELDSET et LEGEND; utiliser des listes imbriquées lorsque c'est nécessaire; utiliser des en-têtes pour structurer les documents, etc. Voir également la directive 3.


4. Associer les étiquettes avec leurs éléments de contrôle de manière explicite.
[priorité 2]
Par exemple, en HTML, utiliser LABEL et son attribut "for".

Directive 13. Fourniture de mécanismes de navigation clairs.

Prochaine directive: 14 Directive précédente: 12 Accès à la table des matières

Prévoir des mécanismes de navigation clairs et cohérents - information d'orientation, barres de navigation, carte du site etc. - de manière à ce qu'un utilisateur puisse trouver ce qu'il cherche sur le site.

Des mécanismes de navigation clairs et cohérents sont primordiaux pour les personnes souffrant de difficultés de compréhension ou de vision, et bénéficient à tous les utilisateurs.

Points à contrôler :

1. Identifier clairement la cible de chaque lien.
[priorité 2]
Les liens textes devraient être suffisemment explicites pour être compréhensibles même lorsque on les lit en dehors de leur contexte - de manière isolée ou parmi d'autres liens. Les liens textes doivent également être concis.
Par exemple, en HTML, écrivez "Information sur la version 4.3" au lieu de "cliquez ici". En plus du lien en version texte, les développeurs pourraient spécifier la cible d'un lien à l'aide d'un lien informatif sous forme de titre (par ex. en HTML, l'attribut "title").


2. Prévoyer des meta-données pour ajouter des informations d'ordre sémantique aux pages et aux sites.
[priorité 2]
Par exemple, utiliser RDF ([RDF)] pour indiquer l'auteur du document, le type de contenu, etc.
Note. Certains agents-utilisateurs HTML peuvent construire des outils de navigation à partir des informations décrites par l'élément HTML 'LINK' et les attributs "rel" ou "rev" (par ex. rel="prochain", rel="précédent", rel="index", etc.) Voir également le point à contrôler 13.5.


3. Fournir des informations concernant la mise en page générale d'un site. (par ex. la carte d'un site, ou une table présentant le contenu).
[priorité 2]
Mettre en avant et expliquer les options d'accessibilité disponibles lors de la description de la mise en page d'un site.


4. Utiliser les mécanismes de navigation de manière cohérente.
[priorité 2]


5. Prévoir des barres de navigation pour mettre en avant et donner accès aux mécanismes de navigation.
[priorité 3]


6. Regrouper les liens de même nature, identifier le groupe (pour les agents-utilisateurs), et jusqu'à ce que les agents utilisateurs le permettent, donner un moyen de s'affranchir du groupe.
[priorité 3]


7. Si l'on prévoit des fonctions de recherche, il convient de rendre possibles plusieurs types de recherches, correspondant à différents niveaux de compétances et à différents choix. [priorité 3]
   
   
8. Placer des informations distinctives au début des en-têtes, des paragraphes, des listes etc.
[priorité 3]
Note. On qualifie communément cette technique de "front-loading" ou "chargement frontal". Elle est particulièrement utile pour les personnes qui accèdent à l'information via des dispositifs série comme les synthétiseurs vocaux.


9. Fournir des informations sur les regroupements de documents (par ex. les documents qui comprennent plusieurs pages, etc.).
[priorité 3]
Par exemple, en HTML identifier les groupes de documents à l'aide de l'élément LINK et des attributs "rel" et "rev". On peut également créer un groupe de documents en construisant une archive (par ex. avec Zip, Tar-Gzip, Stuffit etc.).
Note. Le gain de performances obtenu grâce au traitement "offline" de l'information peut rendre la navigation internet bien meilleur marché pour les personnes souffrant de handicaps qui pourraient naviguer lentement.


10. Prévoir des moyens pour s'affranchir de l'art ASCII prenant plusieurs lignes.
[priorité 3]
Voir le point à contrôler 1.1 et les exemples d'art ASCII présentés dans le glossaire.

Directive 14. S’assurer que les documents sont clairs et simples.

Prochaine directive: 1 Directive précédente: 13 Accès à la table des matières

S'assurer que les documents soient clairs et simples, de manière à ce qu'ils puissent être facilement compris.

Une mise en page cohérente, des graphismes identifiables et un language facile à comprendre pourront bénéficier à tous les utilisateurs. En particulier, ils aideront les personnes souffrant de difficulté de compréhension, ou qui ont des problèmes de lecture. (Cependant assurez vous que les images ont des équivalents textuels pour les non-voyants, les mal voyants, ou pour les utilisateurs qui ne peuvent pas ou ont choisi de ne pas voir les images. Voir également la directive 1.)

Une communication efficace passe par l'utilisation d'un language clair et simple. L'accès à l'information écrite peut être difficile pour les personnes souffrant de problèmes de compréhension ou d'apprentissage. Les personnes dont la langue maternelle diffère de la votre, ou ceux qui utilisent le language des signes tireront avantage d'une langue claire et simple.

Points à contrôler :

1. Utiliser le language le plus clair et le plus simple possible adapté au contenu de votre site.
[priorité 1]


2. Associer du contenu visuel ou audio au texte, lorsque cela peut faciliter la compréhension d'une page.
[priorité 3]
Voir également la directive 1.


3. Créer un style de présentation cohérent pour toutes les pages.
[priorité 3]