3. L'internet pour les handicapés

3.1 Les solutions logicielles

La plupart des pages Web ne sont pas accessibles pour les personnes handicapées car trop confuses, mal organisées, mal écrites. Nous verrons les recommandations préconisées par le W3C dans la dernière partie de ce chapitre.
En ce qui concerne la messagerie électronique (mail), beaucoup de personnes envoient des mails en HTML. Rappelons que si certains logiciels supportent cette fonctionnalité, le format HTML n'est en aucun cas adapté à l'envoi de courrier électronique. En effet une personne non voyante lisant un mail HTML avec un logiciel de courrier électronique classique verra tout le code HTML et aura d'énormes difficultés à en lire le contenu.

Nous nous attarderons sur les pages Web, car en ce qui concerne

Par contre en ce qui concerne les pages Web, beaucoup plus de possibilités sont offertes à leurs rédacteur : frames, images, vidéos, sons, java, javascript, plugins... Tout cela permet d'embellir les pages Web, mais de plus en plus au détriment des personnes qui ont du mal à y accéder. Avant de parler des recommandations du w3c, nous allons vous présenter quelques outils qui permettent de tester, filtrer et réparer les pages Web.


3.1.1 Les évaluateurs

Bobby
logo Bobby Bobby est un outil qui analyse les pages Web selon leurs critères d'accessibilité pour les personnes handicapées. Pour analyser un site Web, il suffit d'en donner l'URL à Bobby qui se charge de l'examiner selon les critères des Web Content Accessibility Guidelines du W3C.
Pour qu'un site soit déclaré "Bobby approved" (approuvé par Bobby), il doit : 
  • Fournir une équivalence textuelle pour tout ce qui ne l'est pas : images, animations, audio et vidéo. 
  • Fournir des résumés pour tous les graphiques. 
  • S'assurer que toutes les informations mises en couleurs peuvent être lues en noir et blanc. 
  • S'assurer que toutes les légendes correspondent bien à ce qu'elles décrivent. 
  • Organiser le contenu de la page de manière logique et claire. 
  • Fournir une accès alternatif à toutes les fonctionnalités non supportées comme les applets ou les plug-ins. 
Bobby est aussi capable d'analyser l'accessibilité d'une page en fonction du navigateur qui sera utilisé.
Une fois qu'un site a passé le test Bobby, il peut placer l'icône "Bobby approved". Si le test à échoué pour quelques pages seulement, on peut tout de même placer l'icône "Bobby approved" sur les pages approuvées et préciser à l'entrée du site la liste des pages approuvées.
Les chiffres : 
  • Plus de 3 millions de pages sont testées par Bobby tous les mois 
  • Plus de 650 sites ont été approuvés par Bobby 
  • Plus de 4800 sites reférencent ou ont des liens vers Bobby. 
La page de Bobby : http://www.cast.org/bobby/index.htm

Commission de la Fonction Publique du Canada
La Direction du programme des mesures positives d'équité en emploi de la Commission de la fonction publique du Canada (http://www.psc-cfp.gc.ca/dmd/access/welcomf1.htm) propose un test d'auto évaluation pour les pages Web en HTML 2.0 dont voici ici la version texte. A la fin du test, une note est donnée en pourcentage dont voici le barème :

Le service de validation du W3C
Le service de validation du W3C est un outil basé sur un parser sgml qui permet de tester une page Web en HTML 4 si elle est en HTML 4, en HTML 3.2 si elle est en HTML 3.2, etc... Il suffit de rentrer l'URI de la page que l'on souhaite tester, le reste est automatique.
On le trouve à l'adresse suivante : http://validator.w3.org.
Remarque : le validator n'a trouvé aucune erreur sur la page du W3C...


3.1.2 Les filtres

purify
Purify permet de filtrer les pages Web en enlevant les balises non autorisées par les dtd.
Purify supporte ces formats : Pour l'utiliser il suffit de donner l'URL de la page que l'on veut filtrer. De plus, le source du cgi est donné.
On peut trouver purify à l'adresse suivante : http://www.delorie.com/web/purify.html

muffin
Employons les superlatifs : Muffin est un outil génial :

Vous l'avez compris, il s'agit d'un proxy permettant de filtrer les immondices de ce genre : http://muffin.doit.org/demo/evil/
Nous l'avons essayé, et nous vous invitons vivement à le faire.
On peut le trouver à l'adresse suivante : http://muffin.doit.org


3.1.3 Les outils de réparation

Tom
tom est un outil permettant aux webmasters de spécifier les attributs ALT de leurs pages. Il a été développé par le National Center for Supercomputing Applications. Pour l'utiliser, il suffit de spécifier l'URL de la page que l'on veut corriger. On a alors le choix entre soit retirer les images et les remplacer par un équivalent textuel, soit ajouter lune balise alt. Le résultat peut être affiché directement dans le navigateur ou bien être reçu par mail. Ensuite, Tom affiche la liste des images de la page et l'utilisateur doit donner un équivalent textuel pour chaque image. Enfin le résultat est calculé.
On peut trouver Tom à l'adresse suivante : http://lunch.ncsa.uiuc.edu/tom/

A-Prompt
A-Prompt (Accessibility Prompt) est un projet ayant pour but de rendre internet plus accessible en proposant aux créateurs de pages Web de corriger leurs documents point par point. A-Prompt est issu de la collaboration entre The Adaptive Technology Resource Centre à l'université de toronto et The Trace Centre à l'université du Wisconsin.
A-prompt fonctionne sous Windows 95/98/NT. Il établi la liste des erreurs et propose de les corriger comme ici :

exemple de correction avec aprompt à l'erreur 4 sur 30

On peut le trouver à l'adresse suivante : http://aprompt.snow.utoronto.ca


3.2 L'accès à l'information

L'accès à l'information se fait principalement par internet. Nous allons donc ici donner les principaux sites dédiés au handicap et à l'internet :


3.3 Les recommandations du W3C

Ce chapitre a pour but de présenter les directives pour l'accessibilité aux contenus Web (version 1.0).
Il s'inspire de la traduction des recommandations du W3C du 5 mai 1999.
Le statut du document qui va suivre se réfère à sa version originale malgré le fait que nous y ayons apporté quelques modifications.

Dernière version :

http://www.w3.org/TR/WAI-WEBCONTENT
Version précédente :
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324
Rédacteurs :
Wendy Chrisholm, Centre Trace R&D, Université du Wisconsin - Madison
Gregg Vanderheiden, Centre Trace R&D, Université du Wisconsin - Madison
Ian Jacobs, W3C
Traducteurs :
Yann Dubois, Arnaud Charpentier, Laurent Gonnard - Atoll Bleu Créations pour le Service d'Information du Gouvernement Français.


Table des matières.

Résumé.
Statut du présent document.
1. Introduction.
2. Thèmes de la conception accessible.
2.1 S’assurer d’une transformation élégante.
2.2 Rendre le contenu compréhensible et navigable.
3. Organisation des directives.
3.1 Conventions du document.
4. Priorités.
5. Conformité.
6. Directives d’Accessibilité du Contenu Web.
6.1. Fournir des alternatives équivalentes au contenu auditif et visuel.
6.2 Ne pas s’en remettre exclusivement aux couleurs.
6.3 Utiliser le balisage et les feuilles de style, et cela de façon appropriée.
6.4 Clarifier l’utilisation du langage naturel.
6.5 Créer des tableaux qui se transforment de façon élégante.
6.6 S’assurer que les pages qui contiennent de nouvelles technologies se transforment de façon élégante.
6.7 Assurer à l'utilisateur le contrôle des changements du contenu lorsque ce dernier varie dans le temps.
6.8 Assurer un accès direct aux interfaces utilisateur intégrées.
6.9 Conception respectant l’indépendance par rapport au périphérique.
6.10 Utilisation de solutions intermédiaires.
6.11 Utilisation des technologies et directives du W3C.
6.12 Fourniture d’informations de contexte et d’orientation.
6.13 Fourniture de mécanismes de navigation clairs.
6.14 S’assurer que les documents sont clairs et simples.
Annexe - La validation.
Références.


Résumé.

Les présentes directives expliquent comment rendre les contenus Web accessibles aux personnes handicapées. Ces directives ont été écrites à l’attention de tous les créateurs de contenu pour le Web (auteurs de pages et concepteurs de sites) et des développeurs d’outils de création de contenu. L’objectif principal de ces directives est de promouvoir l'accessibilité [aux personnes handicapées]. Cependant, en les suivant, le contenu Web s’en trouvera plus accessible à tous les utilisateurs, indépendamment du programme utilisateur (par exemple, logiciel de consultation bureautique [browser], logiciel vocal, téléphone mobile, ordinateur personnel embarqué dans une automobile, etc.) et quelques soient les contingences imposées par l’environnement d’utilisation (par exemple, lieu bruyant, sur- ou sous-éclairé, en gardant les mains libres etc.) En suivant ces directives, on permettra également aux utilisateurs de trouver de l’information sur le Web plus rapidement. Ces directives ne cherchent pas à décourager l’utilisation par les créateurs de contenu d’images, de vidéo, etc., mais expliquent plutôt comment rendre les contenus multimédias plus accessibles à une large audience.

Le présent texte est un document de référence sur les principes et les idées de conception favorisant l’accessibilité. Quelques unes des stratégies abordées dans ce document concernent certaines préoccupations liées à l’internationalisation du Web et à l’accès depuis les mobiles. Cependant, ce document concerne en premier lieu l’accès [aux personnes handicapées] et ne couvre pas entièrement les sujets rattachés qui sont pris en charge par d’autres groupes d’Activités du W3C. Veuillez consulter les pages d’accueil du groupe "W3C Mobile Access Activity home page" et du groupe "W3C Internationalisation Activity" pour plus d’informations.

Ce document se veut stable et ne présente donc pas d’information spécifique sur le support de différentes technologies par les logiciels de consultation puisque ce type d’informations change rapidement. C’est plutôt le site Web de la Web Accessibility Initiative (WAI) qui procure ce type d’information (se référer à [WAI-UA-SUPPORT]).

Ce document inclut une annexe qui regroupe tous les points à contrôler par sujet et par priorité. Les points à contrôler dans l’annexe sont liés à leur définition dans le présent document. Les sujets identifiés dans l’annexe incluent les images, le multimédia, les tableaux les cadres [frames], les formulaires et les scripts.

Un document séparé intitulé "Techniques for Web Content Accessibility Guidelines 1.0" (techniques pour les directives d’accessibilité aux contenus Web version 1.0) ([TECHNIQUES]), explique comment mettre en œuvre les points précis définis dans le présent document. Le document sur les techniques aborde chaque point à contrôler en détail et fournit des exemples utilisant le langage de description de pages HTML (Hypertext Markup Language), les feuilles de style en cascade CSS (Cascading Style Sheets), le langage d’intégration multimédia synchronisé SMIL (Synchronized Multimedia Integration Language), et le langage de balisage mathématique MathML (Mathematical Markup Language). Le document sur les techniques inclut également des méthodes de validation et de test des documents, et un index des éléments et attributs HTML (et des techniques qui les utilisent). Le document sur les techniques a été conçu pour suivre les changements de technologies et devrait donc être mis à jour plus fréquemment que le présent document.
Note. Tous les logiciels de consultation et autres outils multimédia ne supportent peut-être pas les fonctionnalités décrites dans les directives. En particulier, les nouvelles fonctionnalités du HTML 4.0 ou des CSS 1 et CSS 2 peuvent ne pas être supportées.

"Directives pour l’Accessibilité au Contenu Web 1.0" fait partie d’une série de directives concernant la facilité d’accès publiées par l'Initiative d'Accessibilité du Web (Web Accessibility Initiative (WAI)). Cette série inclut également "User Agent Accessibility Guidelines" (Directives d’accessibilité pour les agents utilisateurs) ([WAI-USERAGENT]) et " Authoring Tool Accessibility Guidelines " (Directives d’accessibilité aux outils de création de contenu) ([WAI-AUTOOLS]).

Statut du présent document.

Ce document a été visé par les Membres du W3C et d’autres parties concernées et a été entériné par son Directeur en tant que Recommandation du W3C. C’est un document stable qui peut être utilisé comme support de référence ou cité comme référence normative par d’autres documents. Le rôle du W3C dans l’élaboration des Recommandations est d’attirer l’attention sur la spécification et de promouvoir son déploiement à grande échelle. Ceci améliore le fonctionnement et l’universalité du Web.
La version anglaise des présentes spécifications est la seule version normative.
Pour des traductions dans d’autres langues, voyez cependant http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS.
La liste des erreurs connues de ce document est disponible sur http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA.
Une liste des Recommandations du W3C courantes et d’autres documents techniques sont disponibles sur http://www.w3.org/TR.
Le présent document a été produit dans le cadre de la Web Accessibility Initiative du W3C. Le rôle du Groupe de Travail sur les Directives concernant le Contenu Web (Web Content Guidelines Working Group) est expliqué dans la charte du Groupe de Travail.

1. Introduction.

Pour le lecteur qui ne serait pas familier avec les problèmes d’accessibilité en matière de conception de pages Web, il convient de considérer que de nombreux utilisateurs peuvent être amenés à opérer dans des contextes très différents du sien : Les développeurs de contenu doivent considérer ces différentes situations au moment de la conception des pages. Bien qu’il y ait plusieurs situations à considérer, chaque fois que l’on choisira une conception accessible, plusieurs groupes de personnes handicapées en bénéficieront en général simultanément. La communauté du Web dans son ensemble en profitera également. Par exemple, en utilisant des feuilles de style pour contrôler le style des polices de caractères et en éliminant l’élément FONT, les auteurs HTML auront plus de contrôle sur leurs pages et rendront ces pages plus accessibles aux mal-voyants. En partageant les feuilles de style, ils raccourciront en général également les temps de chargement pour tous les utilisateurs.

Les présentes directives concernent les problèmes d’accessibilité et fournissent des solutions de mise en page accessibles. Elles répondent à des scénarios typiques (similaires à l’exemple concernant les styles de polices) qui peuvent poser des problèmes aux utilisateurs souffrant d’un handicap donné. Par exemple, la première directive explique comment les développeurs de contenu peuvent rendre les images accessibles. Certains utilisateurs peuvent ne pas être en mesure de voir les images, d’autres peuvent utiliser des logiciels de consultations en mode texte qui ne supportent pas les images, et d’autres encore peuvent avoir désactivé le support des images (par exemple en raison d’une connexion Internet lente). Les directives ne prétendent pas interdire les images afin d’améliorer l’accessibilité. Elles expliquent plutôt que le fait de fournir un équivalent textuel aux images les rendra accessibles.

Comment un équivalent textuel peut-il rendre les images accessibles ? Les deux mots "équivalent textuel" ont leur importance :

Notons qu’en plus du bénéfice qu’en retirent les utilisateurs handicapés, les équivalents textuels peuvent aider tous les utilisateurs à trouver des pages plus rapidement, puisque les robots de recherche peuvent utiliser ce texte quand ils indexent les pages.

Alors que les développeurs de contenu pour le Web doivent fournir des équivalents textuels pour les images et autres contenus multimédia, ce sont les agents utilisateurs (par exemples les logiciels de consultation et les technologies d’assistance telles que les lecteurs d’écrans, les générateurs de braille, etc.) qui ont la responsabilité de présenter l’information à l’utilisateur.

Les équivalents non-textuels du texte (par exemple les icônes, les voix pré-enregistrées, ou une vidéo de personne traduisant le texte en langage des signes) peuvent rendre les documents accessibles aux personnes qui pourraient avoir des difficultés à accéder au texte écrit, ce qui inclut de nombreuses personnes souffrant de déficiences cognitives, de handicaps d’apprentissage et de surdité. Les équivalents non-textuels du texte peuvent également aider les non-lecteurs. Une description auditive est un exemple d’un équivalent non-textuel d’une information visuelle. Une description auditive de la piste visuelle d’une présentation multimédia bénéficie aux personnes qui ne peuvent pas voir l’information visuelle.

2. Thèmes de la conception accessible.

Cette directive s’intéresse à deux thèmes généraux : assurer une transformation élégante, et rendre le contenu compréhensible et navigable.

2.1 S’assurer d’une transformation élégante.

En suivant ces directives, les développeurs de contenu peuvent créer des pages qui se transforment de façon élégante. Celles-ci restent accessibles malgré toutes les contraintes décrites dans l’introduction, y compris les handicaps physiques, sensitifs et cognitifs, les contingences professionnelles, et les barrières technologiques. Voici quelques clés pour concevoir de telles pages : Le thème de la transformation élégante est traité principalement par les directives 1 à 11.

2.2 Rendre le contenu compréhensible et navigable.

Les développeurs doivent s’attacher à rendre le contenu qu’ils créent compréhensible et navigable. Cela implique non seulement de rendre le langage clair et simple, mais également de fournir des mécanismes compréhensibles pour naviguer à l’intérieur et entre les pages. Fournir des outils de navigation et des informations d’orientation au sein des pages maximisera l’accessibilité et la facilité d’utilisation. Tous les utilisateurs ne sont pas en mesure d’utiliser des indices visuels comme les cartes cliquables, les barres de défilement proportionnelles, les cadres juxtaposés, ou les éléments graphiques qui guident les utilisateurs qui sont en mesure de les voir à l’aide de logiciels de consultation bureautiques en mode graphique. Les utilisateurs perdent également les informations contextuelles quand ils ne peuvent visualiser qu’une partie de la page, soit parce qu’ils y accèdent mot à mot (synthétiseurs vocaux ou générateurs de braille), ou sélection par sélection (petit écran ou écran en mode "loupe"). Sans information d’orientation, les utilisateurs peuvent ne pas être en mesure de comprendre de très grands tableaux, listes, menus, etc. Le thème de la conception de contenu compréhensible et navigable est couvert principalement par les directives 12 à 14.

3. Organisation des directives.

Ce document comprend quatorze directives, ou principes généraux de la conception accessible. Chaque directive inclut : Les définitions de points à contrôler de chaque directive expliquent comment la directive s’applique dans des scénarios de développement de contenu typiques. Chaque définition de point à contrôler inclut : Chaque point de contrôle est prévu pour être suffisamment précis pour que quelqu’un vérifiant une page ou un site puisse vérifier que le critère a été respecté.

3.1 Conventions du document.

Les conventions éditoriales suivantes sont utilisées tout au long de ce document :

4. Priorités.

Chaque point à contrôler se voit assigner un niveau de priorité par le Groupe de Travail, fondé sur l’impact du critère contrôlé sur l’accessibilité.

[Priorité 1]
Un développeur de contenu Web doit satisfaire à ce critère. A défaut, un ou plusieurs groupes seront dans l’impossibilité d’accéder aux informations contenues dans le document. La satisfaction de ce critère est un pré requis fondamental pour que certains groupes puissent utiliser des documents Web.

[Priorité 2]
Un développeur de contenu Web devrait satisfaire à ce critère. A défaut, un ou plusieurs groupes aura des difficultés à accéder aux informations contenues dans le document. La satisfaction de ce critère lèvera des barrières significatives à l’accès aux documents Web.

[Priorité 3]
Un développeur de contenu Web peut se préoccuper de ce critère. A défaut, un ou plusieurs groupes éprouveront quelques difficultés à accéder aux informations contenues dans le document. La satisfaction de ce critère améliorera l’accès aux documents Web.

Certains points à contrôler spécifient un niveau de priorité qui peut varier sous certaines conditions (précisées).

5. Conformité.

Cette section définit trois niveaux de conformité à ce document : Note. Les niveaux de conformité sont épelés sous forme de texte afin d’être compris lors d’une restitution vocale.

Les revendications de conformité au présent document doivent utiliser l’une des deux formes suivantes.

Exemple de forme 1 :

Cette page est conforme aux directives "Web Content Accessibility Guidelines 1.0", disponibles sur http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, niveau Double-A.

Forme 2 : Inclure, sur chaque page prétendant à la conformité, l’une des trois icônes fournies par le W3C et lier l’icône à l’explication appropriée de la revendication par le W3C. Des informations sur ces icônes et la façon de les insérer dans les pages sont disponibles sur [WCAG-ICONS].

6. Directives d’Accessibilité du Contenu Web.

6.1. Fournir des alternatives équivalentes au contenu auditif et visuel.

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 :

    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 :

    Se référer également aux points à contrôler 9.1 et 13.10

    Techniques pour le point à contrôler 1.1

    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

    Techniques pour le point à contrôler 1.2

    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]

    Se référer au point 1.1 pour des informations sur les équivalents textuels d’informations visuelles.

    Techniques pour le point à contrôler 1.3

    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]

    Techniques pour le point à contrôler 1.4

    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

    Techniques pour le point à contrôler 1.5

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

    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]

    Techniques pour le point à contrôler 2.1

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

    Techniques pour le point à contrôler 2.2

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

    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.

    Techniques pour le point à contrôler 3.1

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

    Techniques pour le point à contrôler 3.2

    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.

    Techniques pour le point à contrôler 3.3

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

    Techniques pour le point à contrôler 3.4

    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 h3 pour indiquer une sous-section de H1. Ne pas utiliser les en-têtes pour réaliser des effets de polices de caractères.

    Techniques pour le point à contrôler 3.5

    Marquer les listes et les éléments de listes correctement [Priorité 2]

    Par exemple, en HTML, imbriquer les listes OL, UL et DL correctement.

    Techniques pour le point à contrôler 3.6

    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.

    Techniques pour le point à contrôler 3.5

6.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 HTTP). 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 abré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 :

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

    Techniques pour le point à contrôler 4.1

    Spécifier la forme complète de toutes les abré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 abréviations utilisées dans le corps du document.

    Techniques pour le point à contrôler 4.2

    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.

    Techniques pour le point à contrôler 4.3

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

    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.

    Techniques pour le point à contrôler 5.1

    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.

    Techniques pour le point à contrôler 5.2

    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

    Techniques pour le point à contrôler 5.3

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

    Techniques pour le point à contrôler 5.4

    Créer des sommaires pour les tables. [priorité 3]

    Par exemple, en HTML, utiliser l'attribut "summary" de l'élément TABLE.

    Techniques pour le point à contrôler 5.5

    Prévoir des abréviations pour les étiquettes d'en-têtes. [priorité 3]

    Par exemple, en HTML utiliser l'attribut "abbr" pour l'élément TH.

    Techniques pour le point à contrôler 5.6

Voir également le point à contrôler 10.3

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

    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.

    Techniques pour le point à contrôler 6.1

    S'assurer que les équivalences pour le contenu dynamique soient mises à jour lorsque ledit contenu dynamique change. [priorité 1]

    Techniques pour le point à contrôler 6.2

    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.

    Techniques pour le point à contrôler 6.3

    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.

    Techniques pour le point à contrôler 6.4

    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.

    Techniques pour le point à contrôler 6.5

Voir également le point à contrôler 11.4

6.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 suffisamment 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 :

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

    Techniques pour le point à contrôler 7.1

    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]

    Techniques pour le point à contrôler 7.2

    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.

    Techniques pour le point à contrôler 7.3

    Jusqu'à ce que les agents-utilisateurs permettent de stopper 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.

    Techniques pour le point à contrôler 7.4

    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]

    Techniques pour le point à contrôler 7.4

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.

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

    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.

    Techniques pour le point à contrôler 8.1

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

    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.

    Techniques pour le point à contrôler 9.1

    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.

    Techniques pour le point à contrôler 9.2

    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]

    Techniques pour le point à contrôler 9.3

    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 grâce à l'attribut "tabindex" ou garder une conception de page logique.

    Techniques pour le point à contrôler 9.4

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

    Techniques pour le point à contrôler 9.5

6.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 fonctionnent 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 :

    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.

    Techniques pour le point à contrôler 10.1

    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.

    Techniques pour le point à contrôler 10.2

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

    Techniques pour le point à contrôler 10.3

    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 exemple, en HTML, respectez ces instructions pour les TEXTAREA et INPUT.

    Techniques pour le point à contrôler 10.4

    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]

    Techniques pour le point à contrôler 10.5

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

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

Note. Utiliser les technologies du W3C lorsque elles sont disponibles et adaptée à une tache.

Points à contrôler :

    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.

    Techniques pour le point à contrôler 11.1

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

    Techniques pour le point à contrôler 11.2

    Fournir des informations de manière à ce que les utilisateurs puissent recevoir les documents selon 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.

    Techniques pour le point à contrôler 11.3

    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]

    Techniques pour le point à contrôler 11.4

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.

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

    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.

    Techniques pour le point à contrôler 12.1

    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 seule lecture des titres. [priorité 2]

    Par exemple, en HTML, utiliser "longdesc" ou une description du lien.

    Techniques pour le point à contrôler 12.2

    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.

    Techniques pour le point à contrôler 12.3

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

    Techniques pour le point à contrôler 12.4

6.13 Fourniture de mécanismes de navigation clairs.

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 :

    Identifier clairement la cible de chaque lien. [priorité 2]

    Les liens textes devraient être suffisamment 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").

    Techniques pour le point à contrôler 13.1

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

    Techniques pour le point à contrôler 13.2

    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.

    Techniques pour le point à contrôler 13.3

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

    Techniques pour le point à contrôler 13.4

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

    Techniques pour le point à contrôler 13.5

    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]

    Techniques pour le point à contrôler 13.6

    Si l'on prévoit des fonctions de recherche, il convient de rendre possibles plusieurs types de recherches, correspondant à différents niveaux de compétences et à différents choix. [priorité 3]

    Techniques pour le point à contrôler 13.7

    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.

    Techniques pour le point à contrôler 13.8

    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.

    Techniques pour le point à contrôler 13.9

    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.

    Techniques pour le point à contrôler 13.10

6.14 S’assurer que les documents sont clairs et simples.

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 :

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

    Techniques pour le point à contrôler 14.1

    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.

    Techniques pour le point à contrôler 14.2

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

    Techniques pour le point à contrôler 14.3

Annexe - La validation.

Valider l'accessibilité avec des outils automatiques et la vérification humaine.

Les méthodes automatiques sont généralement rapides et pratiques, mais ne peuvent pas identifier tous les problèmes d'accessibilités potentiels. Une vérification réalisée par un humain peut aider à assurer la clarté du langage et la facilité de la navigation.

Les méthodes de validation doivent être utilisées dès le début du développement. Plus les problèmes d'accessibilités potentiels sont identifiés tôt, plus il sera facile de les corriger ou de les éviter.

Ci-dessous vous trouverez quelques méthodes de validation importantes, développées de façon plus détaillée dans le document techniques à la section validation.

  1. Utilisez un outil de vérification automatique pour l'accessibilité, et pour la compatibilité avec les navigateurs.

    2. Note. Les outils logiciels ne répondent pas à tous les problèmes potentiels d'accessibilité, tels que la pertinence de l'intitulé d'un lien, la possibilité d'utiliser des équivalents textuels, etc.
  2. Vérifiez la syntaxe (par exemple : HTML, XML, etc.).
  3. Vérifiez les feuilles de style (par exemple : CSS).
  4. Utilisez un navigateur ou un émulateur texte.
  5. Utilisez plusieurs navigateurs graphiques avec :
  6. Utilisez plusieurs navigateurs, anciens et récents.
  7. Utilisez des navigateurs lisant le contenu des pages, des lecteurs d'écran, des logiciels de grossissement, un petit écran.
  8. Utilisez des 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 proposition du synthétiseur pour un mot mal orthographié.
  9. Faites attention à la clarté et la lisibilité. Les statistiques de lisibilité telles que celles générées par certains traitements de textes peuvent être des indicateurs utiles de la clarté et de la simplicité. Encore mieux, faites relire le contenu par un rédacteur humain pour améliorer sa clarté. Les rédacteurs peuvent aussi améliorer l'usage des documents en identifiant des problèmes culturels qui pourraient se poser, dus à l'utilisation de la langue ou d'icônes.
  10. Invitez des personnes ayant un handicap à regarder les documents. Des utilisateurs experts ou novices handicapés auront des réactions valables quant aux problèmes d'accès et d'utilité, ainsi que leur gravité.

Références.

Pour la dernière version de n'importe laquelle des spécifications du W3C, merci de consulter la liste des rapports techniques du W3C.

[CSS1]

"CSS, level 1 Recommendation", B. Bos, H. Wium Lie, ds., 17 décembre 1996, révisé 11 janvier 1999.
la recommandation CSS1 est disponible à : 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, et I. Jacobs, eds., 12 mai 1998.
la recommandation CSS2 est disponible à : 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, et L. Wood, eds., 1er octobre 1998.
la recommandation DOM niveau 1 est disponible à l'adresse : http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
la dernière version de DOM niveau 1 est disponible à l'adresse : http://www.w3.org/TR/REC-DOM-Level-1.
[HTML40]
"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, et I. Jacobs, eds., 17 décembre 1997, révisé le 24 avril 1998.
la recommandation HTML 4.0 est disponible à l'adresse : http://www.w3.org/TR/1998/REC-html40-19980424.
la dernière version de CSS2 est disponible à l'adresse : http://www.w3.org/TR/REC-html40.
[HTML32]
"HTML 3.2 Recommendation", D. Raggett, ed., 14 janvier 1997.
La dernière version de HTML 3.2 est disponible à l'URL : http://www.w3.org/TR/REC-html32.
[MATHML]
"Mathematical Markup Language", P. Ion and R. Miner, eds., 7 avril 1998.
La recommandation MathML 1.0 est à l'URL : http://www.w3.org/TR/1998/REC-MathML-19980407.
La dernière version de MathML 1.0 est disponible à l'URL : http://www.w3.org/TRREC-MathML.
[PNG]
"PNG (Portable Network Graphics) Specification", T. Boutell, ed., T. Lane, contributing ed., 1er octobre 1996.
La dernière version de PNG 1.0 est à l'URL : http://www.w3.org/TR/REC-png.
[RDF]
"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds., 22 février 1999.
La recommandation RDF est à l'URL : http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
la dernière version of RDF 1.0 est disponible à l'URL : 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, janvier1997.
[SMIL]
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 juin 1998.
La recommandation SMIL est à l'URL : http://www.w3.org/TR/1998/REC-smil-19980615.
la dernière version de SMIL 1.0 est disponible à l'URL : http://www.w3.org/TR/REC-smil.
[TECHNIQUES]
"Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds.
Ce document explique comment mettre en place les points de contrôle definis dans le document "Web Content Accessibility Guidelines 1.0"
La dernière version des techniques est disponible à l'URL : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/.
[WAI-AUTOOLS]
"Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds.
La dernière version de travail des directives pour le développement des outils de création est disponible à l'URL : http://www.w3.org/TR/WAI-AUTOOLS/.
[WAI-UA-SUPPORT]
Cette page documente ce que l'on sait sur le support de fonctions d'accessibilité listées dans ce document par des agents utilisateurs (en incluant les technologies d'assistance.
Cette page est disponible à l'URL : http://www.w3.org/WAI/Resources/WAI-UA-Support.
[WAI-USERAGENT]
"User Agent Accessibility Guidelines", J. Gunderson et I.Jacobs, eds.
La dernière version de travail de ces directives pour la conception d'agents utilisateurs accessibles est disponible à l'URL : http://www.w3.org/TR/WAI-USERAGENT/.
[WCAG-ICONS]
L'information à propos des icônes de conformité pour ce document et comment les utiliser est dipsonible à l'URL : http://www.w3.org/WAI/WCAG1-Conformance.html.
[UWSAG]
"The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds.
Les directives unifiées pour les sites web ont été compilées par le centre Trace de R&D de l'Université du Wisconsin avec un financement du National Institute on Disability and Rehabilitation Research (NIDRR), U.S. Dept. Of Education.
Ce document est disponible à l'URL : 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 février 1998.
La recommandation 1.0 du XML est disponible à l'URL : http://www.w3.org/TR/1998/REC-xml-19980210.
La dernière version du XML 1.0 est disponible à l'URL : http://www.w3.org/TR/REC-xml.