Directives pour l'accessibilité aux contenus Web (version 1.0)

Résumé

Les présentes directives expliquent comment rendre accesible les contenus Web 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 Internationalization Activity home page 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. L’annexe est disponible soit sous la forme d’un tableau résumant les points à contrôler soit sous la forme d’une liste simple.

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 Hypertext Markup Language (HTML), les feuilles de style en cascade (CSS), langage d’intégration multimédia synchronisé (SMIL), et le langage de balisage mathématique (MathML). 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 la Web Accessibility Initiative. 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 de la présente spécification 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. Veuillez rapporter les erreurs contenues dans ce document à wai-wcag-editor@w3.org.

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 ext expliqué dans la charte du groupe de travail.

Pas encore traduit (2001-10-12) La liste des points de contrôle en annexe est disponible sour la forme de points à contrôler résumés en tableau ou sous la forme d'une simple liste de points à contrôler..

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 :

• Ils peuvent ne pas être en mesure de voir, entendre, bouger. Ils peuvent aussi avoir du mal à traiter certains type d’information, ou ne pas être en mesure de le faire du tout.
• Ils peuvent avoir des difficultés à lire ou à comprendre le contenu textuel.
• Ils peuvent ne pas posséder, ou ne pas être en mesure d’utiliser un clavier ou une souris.
• Ils peuvent avoir un écran n’affichant que le texte, un petit écran, ou une connexion Internet lente.
• Ils peuvent ne pas comprendre couramment la langue dans laquelle le document est rédigé.
• Ils peuvent être dans une situation où leurs yeux, leurs oreilles ou leurs mains sont occupés ou gênés (par exemple s’ils sont en train de se rendre au travail en conduisant, ou travaillent dans un environnement bruyant, etc.).
• Ils peuvent avoir une version ancienne d’un logiciel de consultation, un logiciel entièrement différent, ou un système d’exploitation différent.

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 :

• Un contenu textuel peut être présenté à l’utilisateur sous forme de voix synthétique, de braille, et de texte affiché visuellement. Chacun de ces trois mécanismes utilise un sens différent —l’ouïe pour la voix synthétique, le toucher pour le braille, la vision pour le texte affiché– rendant l’information accessible à des groupes présentant différents handicaps sensoriels et autres.
• Afin d’être utile, le texte doit avoir la même fonction ou raison d’être que l’image. Par exemple, considérons un texte équivalent à une image photographique de la Terre vue de l’Espace. Si la raison d’être de l’image est essentiellement décorative, le texte " photographie de la Terre vue de l’Espace " pourra remplir la fonction. Si le but de l’image est d’illustrer des informations particulières sur la géographie mondiale, le texte équivalent devra également convoyer cette information. Si la photographie a été conçue pour dire à l’utilisateur de sélectionner l’image (par exemple en cliquant dessus) pour obtenir des informations sur la Terre, le texte équivalent serait " Informations sur la Terre ". C’est donc seulement quand le texte possède la même fonction ou raison d’être pour l’utilisateur handicapé que pour les autres utilisateurs que l’on peut le considérer comme équivalent textuel.

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

• Séparer la structure de la présentation (se référer à la différence entre contenu, structure et présentation).
• Fournir du texte (y compris des équivalents textuels). Le texte peut être restitué par des méthodes disponibles sur tous types de systèmes de consultation et accessibles à presque tous les utilisateurs.
• Créer des documents qui fonctionnent même lorsque l’utilisateur ne peut pas voir et/ou entendre. Fournir de l’information ayant la même fonction que l’audio ou que la vidéo de façons alternatives également. Cela n’implique pas la création d’une version audio préenregistrée d’un site Web complet pour le rendre accessible aux utilisateurs non-voyants. Ces derniers peuvent utiliser des technologies de lecteurs d’écran pour restituer toute l’information textuelle d’une page.
• Créer des documents qui ne reposent pas sur un type particulier de matériel. Les pages devraient être accessibles à des personnes dépourvues de souris, utilisant de petits écrans, ou des écrans à basse résolution, en noir et blanc, ou encore sans écran, avec uniquement une sortie vocale ou texte, etc.

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 :

• Le numéro de la directive.
• L’énoncé de la directive.
• Des liens de navigation dans les directives. Trois liens permettent la navigation vers la directive suivante (icône fléchée pointant vers la droite), la directive précédente (icône fléchée pointant vers la gauche), ou la position de la directive courante dans la table des matières (icône fléchée pointant vers le haut).
• Les justifications de la directive et l’énumération de certains groupes d’utilisateurs en bénéficiant.
• Une liste des définitions de points à contrôler.

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 :

• Le numéro du point à contrôler.
• L’énoncé du point à contrôler.
• La priorité du point à contrôler. Les points de première priorité sont mis en exergue à l’aide de feuilles de style.
• En option, des notes informatives, exemples clarificateurs et références croisées à des directives et points de contrôle rattachés.
• Un lien vers une section du document sur les Techniques ([TECHNIQUES]) où les mises en oeuvre et les exemples de points à contrôler sont couverts.

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 :

• Les noms d’éléments sont en lettres majuscules.
• Les noms d’attributs sont placés entre guillemets en lettres minuscules.
• Les liens vers des définitions sont mis en exergue à l’aide de feuilles de style.

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. Sinon, 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 :

• Niveau de Conformité " A ": Tous les points à contrôler de priorité 1 sont satisfaits ;
• Niveau de conformité " Double-A ": Tous les points à contrôler de priorité 1 et 2 sont satisfaits ;
• Niveau de conformité " Triple-A ": Tous les points à contrôler de priorité 1, 2 et 3 sont satisfaits ;

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.

Forme 1 : Spécifier :

• Le titre des directives : " Web Content Accessibility Guidelines 1.0 "
• L'URI des directives : http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
• Le niveau de conformité satisfait : " A ", " Double-A ", ou " Triple-A ".
• L’étendue couverte par la conformité (par exemple page, site, ou portion définie d’un site.).

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é 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.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 point à contrôler 9.1 et point à contrôler 13.10.

Techniques pour point à contrôler 1.1

1.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 au point à contrôler 1.5 and point à contrôler 9.1.

Techniques pour point à contrôler 1.2

point à contrôler 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.

Techniques pour point à contrôler 1.3

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

Techniques pour point à contrôler 1.4

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 and point à contrôler 9.1.

Techniques pour point à contrôler 1.5

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 :

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

Techniques pour point à contrôler 2.1

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

Techniques pour point à contrôler 2.2

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 nformation 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 nt à 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 :

3.1 Quand un langage de balisage approprié existe, utiliser des balises plutôt que des images pour convoyer l’information. [Priori 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 directive 6 et directive 11.

Techniques pour point à contrôler 3.1

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

Techniques pour point à contrôler 3.2

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

Techniques pour point à contrôler 3.3

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

Techniques pour point à contrôler 3.4

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

Techniques pour point à contrôler 3.5

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

Techniques pour point à contrôler 3.6

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

Techniques pour point à contrôler 3.7

Directive 4. rifier 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 langage naturel permet aux moteurs de recherche de trouver les mots-clé et d'identifier les documents dans la langue souhaitée. Le marquage en langage 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 langage 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 :

4.1 Identifier clairement les changements survenus dans le langage 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 point à contrôler 4.1

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

Techniques pour point à contrôler 4.2

4.3 Identifier le langage 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 point à contrôler 4.3

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 tableaux devraient être utilisés pour présenter des données existant à l'origine sous forme de tableau ("tableaux de données"). Les développeurs de contenu devraient éviter leur utilisation pour la mise en page ("tableaux de mise en page"). Les tableaux 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 :

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

Techniques pour point à contrôler 5.1

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

Techniques pour point à contrôler 5.2

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

Techniques pour point à contrôler 5.3

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

Techniques pour point à contrôler 5.4

5.5 Créer des sommaires pour les tableaux. [Priorité 3]

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

Techniques pour point à contrôler 5.5

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

Techniques pour point à contrôler 5.6

Refer also to checkpoint 10.3.

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

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

Techniques pour point à contrôler 6.1

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

Techniques pour point à contrôler 6.2

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

Techniques pour point à contrôler 6.3

6.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 matérielle..

Techniques pour point à contrôler 6.4

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

Techniques pour point à contrôler 6.5

Voir le point à contrôler 11.4.

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 :

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

Techniques pour point à contrôler 7.1

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

Techniques pour point à contrôler 7.2

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

Techniques pour point à contrôler 7.3

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

Techniques pour point à contrôler 7.4

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

Techniques pour point à contrôler 7.5

Note. es é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]) t les Directives pour l'Accessibilité des Outils de Production ([WAI-AUTOOL]).

Point à contrôler :

8.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 la fonctionnalité est importante et non présente ailleurs, sinon Priorité 2.]

Voir également la directive 6.

Techniques pour point à contrôler 8.1

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 texte. Voir également la directive 1.

Générallement, les pages qui permettent une interaction clavier sont également accessibles grâce à des commandes vocales ou grâce une interface par commande textuelle.

Points à contrôler :

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

Techniques pour point à contrôler 9.1

9.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 matérielle.

Voir également directive 8.

Techniques pour point à contrôler 9.2

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

Techniques pour point à contrôler 9.3

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

Techniques pour point à contrôler 9.4

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

Techniques pour point à contrôler 9.5

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

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 :

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

Techniques pour point à contrôler 10.1

10.2 Jusqu'à ce que le 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 point à contrôler 10.2

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

Techniques pour point à contrôler 10.3

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

Techniques pour point à contrôler 10.4

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

Techniques pour point à contrôler 10.5

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

Note. Convertir des documents (à partir de PDF, PostScript, RTF, etc.) en un langage de balisage du W3C (HTML, XML) ne permet pas toujours de créer un document accessible. Ainsi, validez chaque page pour vérifier l'accessibilité et l'utilisabilité après la conversion (voir la section sur la validation). Si une page n'est pas valide directement, modifiez la page jusqu'à ce que la représentation originale soit convertie correctement ou fournissez une version HTML ou texte seul.

Points à contrôler :

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

Techniques pour point à contrôler 11.1

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

Techniques pour point à contrôler 11.2

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

Techniques pour point à contrôler 11.3

11.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 une information (ou fonctionnalité) équivalente, et est mise à jour aussi régulièrement que la page (originale) innacessible. [Priorité 1]

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

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 :

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

Techniques pour point à contrôler 12.1

12.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 description du lien.

Techniques pour point à contrôler 12.2

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

Techniques pour point à contrôler 12.3

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

Techniques pour point à contrôler 12.4

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

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

Les liens textes evraient ê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")

Techniques pour point à contrôler 13.1

13.2 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 ([RDF]) our indiquer l'auteur du document, le type de contenu, etc.

Note. Certains gents-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 point à contrôler 13.2

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

Techniques pour point à contrôler 13.3

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

Techniques pour point à contrôler 13.4

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

Techniques pour point à contrôler 13.5

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

Techniques pour point à contrôler 13.6

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

Techniques pour point à contrôler 13.7

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

Techniques pour point à contrôler 13.8

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

Techniques pour point à contrôler 13.9

13.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 l'exemple d'art ASCII présenté dans le glossaire.

Techniques pour point à contrôler 13.10

Directive 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 langage 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 langage 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 langage des signes tireront avantage d'une langue claire et simple.

Points à contrôler :

14.1 Utiliser le langage le plus clair et le plus simple possible adapté au contenu de votre site. [Priorité 1]

Techniques pour point à contrôler 14.1

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

Techniques pour point à contrôler 14.2

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

Techniques pour point à contrôler 14.3

Annexe A. -- 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 technique à la section validation.

1. Utilisez un outil de vérification automatique pour l'accessibilité, et pour la compatibilité avec les navigateurs. Note. Les outils logiciels ne répondent pas à tousles problèmes potentiels d'accessibilité, tels que la pertinence del'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 :
   • son et images activés,
   • images désactivées,
   • sons désactivés,
   • pas de souris,
   • les cadres, scripts, feuilles de style et les appliquettes
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 simpicité. 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, dûs à 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é.

Annexe B. -- Glossaire

Accessible

Le contenu est dit accessible quand il peut être utilisé par une personne ayant un handicap.

Appliquette

Programme inséré dans une page web.

Technologie d'assistance

Se dit d'un logiciel ou matériel spécialement conçu pour assister les personnes handicapées à exercer leurs activités quotidiennes. Les technologies d'assistance incluent les fauteuils roulants, les machines pour lire, les outils servant à saisir, etc. Pour l'accessibilité au Web, dans les technologies d'assistance logicielles courantes, on trouve des lecteurs d'écran, des "loupes" d'écran, des synthétiseurs vocaux, et des logiciels permettant de traiter la voix, qui opèrent conjointement avec des logiciels de consultation bureautique en mode graphique (parmi d'autres agents utilisateurs). Les technologies d'assistance matérielles incluent des claviers et des outils de pointage alternatifs.

Art ASCII

L'art ASCII fait référence à la combinaison de caractères et symboles qui sont combinés pour créer une image. Par exemple, ";-)" est une émoticône, ou smiley. La figure suivante est untableau ascii montrant la relation entre la fréquence d'un flash et les réponse [photoconvulsives] des patients avec les yeux ouverts et fermés. [sautez le tableau ascii ou consultez une description de la figure.]

  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __
100 |             *                             |
 90 |                *  *                       |
 80 |          *           *                    |
 70 |             @           *                 |
 60 |          @                 *              |
 50 |       *        @              *           |
 40 |                   @              *        |
 30 |    *  @              @  @           *     |
 20 |                                           |
 10 |    @                       @  @  @  @     |
      0  5 10 15 20 25 30 35 40 45 50 55 60 65 70
      Fréquence Flash (Hertz)

Outil de création de contenu

Est un outil de création de contenu tout éditeur HTML, outil de conversion de documents, outils de génération de pages Web à partir de bases de données. Pour toute information à propos du développement d'outils de création accessibles, se référer au document "Authoring Tool Accessibility Guidelines" Directives d'accessibilité pour les outils de création de contenu. [WAI-AUTOOLS]

Rétro-compatible

Conception de site qui continue de fonctionner avec d'anciennes versions de langages, de programmes, etc.

Braille

Le braille utilise six points saillant selon différents agencements pour représenter les nombres et les lettres que les personnes aveugles liront avec le bout des doigts. Ci-dessous le mot "Accessible" en braille :

Un affichage en braille, plus couramment connu comme un "affichage dynamique de braille", met ou enlève le relief des points, générant des agencements de braille, et est commandé par un système électronique, généralement un ordinateur. Le résultat est une ligne de braille qui change par intermittence. L'échelle des tailles des affichages dynamiques de braille oscille entre une cellule (six ou huit points) et une ligne de quatre-vingts cellules, la plupart ayant entre 12 et 20 cellules par ligne.

Développeurs de contenu

Personne qui créé des pages Web ou qui conçoit des sites Web.

Désapprouvé

Un élément obsolète est un élément périmé par de nouvelles constructions. Les éléments désapprouvés peuvent devenir obsolètes dans les futures versions du HTML. L'index des éléments et attributs du HTML dans le Document Techniques, indique quels éléments et attributs sont désapprouvés dans le HTML 4.0.

Les créateurs devraient éviter d'utiliser des éléments et des attributs Désapprouvés. Les agents utilisateurs devraient continuer à les supporter pour des raisons de rétro-compatibilité.

Indépendance vis-à-vis des périphériques :

Les utilisateurs doivent être capables d'interagir avec un agent utilisateur (et le document qu'il affiche), en utilisant les périphériques supportés de leur choix. Les périphériques d'entrée peuvent comprendre, entre autres, des périphériques de pointage, claviers, périphériques braille, microphone casque, microphones. Les périphériques de sortie peuvent inclure les moniteurs, les synthétiseurs vocaux, les générateurs de Braille.

Note. "Support indépendant du périphérique" ne signifie pas que les agents utilisateurs doivent supporter tous les périphériques d'entrée ou de sortie. Les agents utilisateurs devraient offrir des mécanismes d'entrée et de sortie indépendants pour les périphériques supportés. Par exemple, si un agent utilisateur supporte les entrées via la souris et le clavier, les utilisateurs devraient être capables d'interagir avec toutes les fonctionnalités en utilisant soit la souris soit le clavier.

Contenu, Structure et Présentation d'un document

Le contenu d'un document fait référence à ce qu'il dit à l'utilisateur à travers le langage naturel, les images, les sons, les films, les animations, etc. La structure d'un document représente la façon dont il est organisé logiquement (par exemple en chapitres, avec une introduction et une table des matières, etc.). Un élément (par exemple, P, STRONG, BLOCKQUOTE en HTML) qui spécifie la structure du document est appelé un élément structurel. La présentation d'un document est son rendu (par exemple, comme une impression, un graphique en deux dimensions, une présentation en texte seul, comme discours vocal synthétisé, comme du braille, etc.). Un élement faisant état de la présentation d'un document (par exemple, B, FONT, CENTER) est appelé élément de présentation.

Considérons par exemple l'en-tête d'un document. Le contenu de celui-ci est ce qu'il nous dit (par exemple, " voiliers"). En HTML, l'en-tête est un élément structurel, marqué par, par exemple, un élément H2. Enfin, laprésentation de l'en-tête pourrait être un bloc de texte en gras dans lamarge, une ligne de texte centrée, un titre prononcé d'une certaine façon(comme une police orale), etc.

HTML dynamique (DHTML)

DHTML est le terme marketing appliqué à un mélange de standards qui inclut le HTML, les feuilles de style, le Document Object Model [DOM1] et desscripts. Cependant, aucune spécification du W3C ne définit de façonformelle le DHTML. La plupart des directives peuvent être appliquées à des applications utilisant le DHTML, cependant les directives suivantestraitent plus particulièrement des thèmes liés aux scripts et aux feuillesde style : directive 1, directive 3, directive 6, directive 7, and directive 9.

Elément

Ce terme est utilisé dans ce document au sens strict que lui donne le SGML (un élément est une construction syntaxique) et plus généralement pour désigner un type de contenu (comme de la vidéo ou du son) ou une construction logique (comme un en-tête ou une liste). La seconde signification souligne qu'une directive inspirée par le HMTL pourrait aisément s'appliquer à un autre langage balisé.

Notez que certains éléments (SGML) ont un contenu qui est rendu (par exemple, les éléments P, LI, ou TABLE en HTML), certains sont remplacés par du contenu externe (par exemple, IMG) et d'autres affectent le traitement (par exemple, STYLE et SCRIPT font traiter des informations par une feuille de style ou moteur de script). Un élément qui fait inclure les caractères d'un texte dans le document est appelé un élement texte.

Equivalent

Un contenu est équivalent à un autre contenu quand les deux remplissent essentiellement la même fonction ou le même propos quand ils sont présentés à l'utilisateur. Dans le contexte de ce document, l'équivalent doit remplir essentiellement la même fonction pour la personne ayant un handicap (au moins dans la mesure du possible, étant donné la nature du handicap et l'état de la technologie), que celle que remplit le contenu primaire pour une personne n'ayant aucun handicap. Par exemple, le texte "La Pleine Lune" pourrait, lors de sa présentation aux utilisateurs, convoyer la même information qu'une image représentant une pleine lune. L'important dans l'information équivalente est de remplir la même fonction. Si l'image fait partie d'un lien et que la compréhension de l'image est essentielle pour deviner la cible du lien, l'équivalent doit aussi donner aux utilisateurs une idée de la cible du lien.

Fournir des informations équivalentes pour du contenu inaccessible, est un moyen primordial pour les créateurs de rendre leurs documents accessibles aux personnes ayant un handicap. Pour remplir la même fonction que le contenu, un équivalent peut en être une description (i.e. description visuelle ou orale du contenu).

Par exemple, pour que les utilisateurs comprennent l'information fournie par un tableau complexe, les créateurs devraient décrire l'information visuelle contenue dans ce tableau. Comme le contenu texte peut être présenté à l'utilisateur sous forme de synthèse vocale, de braille, ou de texte affiché visuellement, ces directives nécessitent des équivalents texte pour les informations graphiques et audio. Les équivalents textes doivent être écrits de façon à communiquer tout le contenu essentiel. Les équivalents non-textuels (par exemple une description orale d'une présentation visuelle, une vidéo d'une personne racontant une histoire en utilisant le langage des signes comme équivalent de l'histoire écrite, etc.) améliorent aussi l'accessibilité pour une personne qui ne peut accéder aux informations visuelles ou aux textes écrits. Cela inclut plusieurs personnes atteints de cécité, handicaps intellectuels, handicaps d'apprentissage, et surdité.

L'information équivalente peut être fournie de plusieurs façons, comme à travers des attributs (par exemple, une valeur texte pour l'attribut "alt" en HTML et SMIL), à l'intérieur d'un élement contenu (par exemple, OBJECT en HTML), comme une partie du thème du document, ou via un document lié (par exemple désigné par l'attribut "longdesc" en HTML ou un lien vers une description). Selon la complexité de l'équivalent, il peut être nécessaire de combiner les techniques (par exemple, utiliser un "alt" pour un équivalent abrégé, utile pour les lecteurs chevronnés, en conjonction avec "longdesc" pour un lien vers de plus amples informations, utiles pour les lecteurs qui viennent pour la première fois. Les détails sur quand et comment fournir une information équivalente se trouvent dans le Document Technique ([TECHNIQUES]).

Une transcription texte est un équivalent texte d'une information sonore qui inclut des mots parlés et des sons non parlés tels que les effets sonores. Une légende est une transcription texte pour la piste audio d'une présentation dont les pistes audio et vidéo sont synchronisées. On affiche généralement les légendes par superposition sur la vidéo, ce qui bénéficie surtout pour les personnes sourdes et malentendantes, et toute personne qui ne peut entendre le son (par exemple dans une salle bondée). Une légende texte collationnée combine les légendes avec des descriptions textuelles de l'information vidéo, du langage corporel et des changements de scènes sur la piste vidéo. Ces équivalents texte rendent les présentations accessibles aux personnes qui sont sourdes et aveugles, et aux personnes qui ne peuvent exécuter des films, des animations, etc. Cela rend l'information accessible aussi aux moteurs de recherche.

Un exemple d'un équivalent non-textuel est une description orale des éléments clés visuels d'une présentation. La description est soit une voix humaine pré-enregistrée, soit une voix synthétisée (enregistrée ou générée au vol). La description orale est synchronisée avec la piste audio de la présentation, d'habitude pendant des pauses naturelles de la piste audio. Les descriptions orales incluent des informations à propos des actions, du langage corporel, des images et des changements de scène.

Image

une présentation graphique.

Carte cliquable

Image qui a été divisée en régions auxquelles on a associé des actions. Quand on clique sur une région active, cela déclenche un événement.

Quand un utilisateur clique sur une région active, d'une carte-cliquable côté client, l'agent utilisateur calcule dans quelle région le clic a eu lieu et suit le lien associé à cette région. Cliquer dans une région active d'une carte cliquable côté serveur, envoie au serveur les coordonnées du clic au serveur, qui alors, effectue une action.

Les développeurs de contenu peuvent rendre des cartes cliquables côté client accessibles en fournissant un accès, indépendant de tout périphérique aux liens associés aux régions de la carte cliquable. Les cartes cliquables côté client permettent à l'agent utilisateur de dire immédiatement si le pointeur de l'utilisateur est ou n'est pas sur une région active.

Important

L'information dans un document est importante si la compréhension de cette information est essentielle pour comprendre le document.

Table restituée linéairement

Le traitement de rendu d'une table où les contenus des cellules deviennent une série de paragraphes s'enchaînent l'un après l'autre. Les paragraphes apparaissent dans le même ordre que celui dans lequel les cellules sont définies dans le document source. Les cellules devraient être logiques quand elles sont lues dans l'ordre et devraient inclure des éléments structurels (qui créent des paragraphes, des en-têtes, des listes, etc.) pour que, après avoir été restituée linéairement, la page soit logique.

Lien texte

Le rendu du contenu texte d'un lien.

Langue maternelle

Langages humains écrits, parlés, ou par signes, tels que le Français, le Japonais, le langage américain des signes, et le braille. Le langage naturel d'un contenu peut être indiqué par l'attribut "langue" en HTML [HTML40], section 8.1) et l'attribut "xml:lang" en XML ([XML], section 2.12).

Mécanisme de Navigation

Un mécanisme de navigation est n'importe quel moyen par lequel un utilisateur peut naviguer à l'intérieur d'une page ou d'un site. Quelques mécanismes caractéristiques :

Barres de navigation

Une barre de navigation rassemble les liens vers les parties les plus importantes d'un document ou d'un site.

Cartes de site

Une carte d'un site fournit une vue générale de l'organisation d'une page ou d'un site.

Table des matières

Une table des matières liste généralement les parties les plus importantes d'un document ou d'un site et fournit des liens y conduisant

Assistant Numérique Personnel (Personal Digital Assistant - PDA)

Un PDA est un petit appareil informatique portable. La plupart des PDAs sont utilisés pour maintenir des données personnelles telles que calendriers, contacts, et courrier électronique. Un PDA tient généralement dans la main, a un petit écran et accepte des entrées via plusieurs sources. sources.

Loupe d'écran

Logiciel qui grossit une partie de l'écran, pour qu'il puisse être vu plus facilement. Ils sont utilisés surtout par les personnes mal-voyantes.

Lecteur d'écran

Logiciel qui lit à haute voix le contenu de l'écran à l'utilisateur. Ils sont surtout utilisés par les personnes non-voyantes. D'habitude, ils ne peuvent lire que le texte imprimé à l'écran, non le texte dessiné.

Feuilles de Style

Une feuille de style est un ensemble de déclarations qui spécifie la présentation d'un document. Les feuilles de style peuvent avoir plusieurs origines différentes : elles peuvent avoir été écrites par les fournisseurs de contenu, créées par les utilisateurs, ou construites dans les agents utilisateurs. Dans les CSS ([CSS2]), on appelle cascade l'interaction des feuilles de style des fournisseurs de contenu, des utilisateurs et des agents utilisateurs.

Une présentation balisée est une présentation qui permet des effets de style (plutôt que des effets de structure), tels que les éléments B et I du HTML. Attention, les éléments STRONG et EM ne sont pas considérés comme des balises de présentation puisqu'ils donnent une information indépendante d'un style particulier de police.

Information en tableaux de données

Quand les tables sont utilisées pour représenter les relations logiques entre les données - textes, nombres, images, etc., l'information est dite mise en tableaux de données, et les tables sont appelées "tableaux de données". Les relations exprimées par une table peuvent être rendues visuellement (souvent dans une grille à deux dimensions), oralement (souvent en faisant précéder les cellules par un en-tête d'information), ou dans d'autres formats.

Jusqu'à ce que des agents utilisateurs...

Dans la plupart des points de contrôle, on demande aux développeurs de contenu de s'assurer que leurs pages et leurs sites sont accessibles. Cependant, certains besoins d'accessibilité seraient remplis de façon plus appropriée par des agents utilisateurs (en incluant des technologies d'assistance). Au moment de la publication de ce document, tous les agents utilisateurs ou les technologies d'assistance ne fournissent pas le contrôle sur l'accessibilité que demandent les utilisateurs (par exemple, certains agents utilisateurs ne permettent d'arrêter le clignotement des contenus clignotants, ou des lecteurs d'écran peuvent ne pas gérer correctement les tables). Les points de contrôle qui contiennent la phrase "jusqu'à que les agents utilisateurs..." nécessite que les développeurs de contenu fournissent un support supplémentaire pour l'accessibilité jusqu'à que la plupart des agents utilisateurs disponibles pour leur audience intègrent les fonctionnalités nécessaires.

Note. Le site Web W3C WAI (se référer à [WAI-UA-SUPPORT]) fournit de l'information à propos du support des fonctions d'accessibilité par les agents utilisateurs. Les développeurs de contenu sont encouragés à consulter régulièrement cette page pour une information à jour.

Agent utilisateur

Logiciels pour accéder au contenu du Web, incluent les logiciels de consultation graphiques des postes de bureau, logiciels de consultation texte, logiciels de consultation vocaux, téléphones mobiles, lecteurs multimédia, extensions, et des technologies logicielles d'assistance utilisées en conjonction avec les navigateurs, telles que les lecteurs d'écran, les loupes d'écran et logiciels de reconnaissance vocale.

Remerciements

Co-administrateurs du groupe de travail : directives de contenu web :

Chuck Letourneau, Starling Access Services

Gregg Vanderheiden, Trace Research and Development

Contacts au W3C :

Judy Brewer et Daniel Dardailler

Nous souhaitons remercier les personnes suivantes qui ont contribué à la rédaction de ces directives en donnant de leurs temp et des commentaires de valeur

Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, Jaap van Lelieveld, and Jason White

La version originale de document est basée sur "The Unified Web Site Accessibility Guidelines" ([UWSAG]) réalisé par le centre Trace de R & D à l'University du Wisconsin. Ce document inclut une liste de personnes supplémentaires ayant contribué.

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, eds., 17 December 1996, revised 11 January 1999. La recommandation CSS1 est à : http://www.w3.org/TR/1999/REC-CSS1-19990111.
la dernière version de CSS1 est disponible à : http://www.w3.org/TR/REC-CSS1.

[CSS2]

"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. La recommandation CSS2 est à : http://www.w3.org/TR/1998/REC-CSS2-19980512.
la dernière version de CSS2 est disponible à : http://www.w3.org/TR/REC-CSS2.

[DOM1]

"Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds., 1 October 1998. La recommandation DOM Level 1 est à : http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
la dernière version de DOM Level 1 est disponible à : http://www.w3.org/TR/REC-DOM-Level-1

[HTML40]

"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 17 December 1997, revised 24 April 1998. La recommandaion Hest à : http://www.w3.org/TR/1998/REC-html40-19980424.
la dernière version de HTML 4.0 est disponible à : http://www.w3.org/TR/REC-html40.

[HTML32]

"HTML 3.2 Recommendation", D. Raggett, ed., 14 January 1997. The latest version of HTML 3.2 is available at: http://www.w3.org/TR/REC-html32.

[MATHML]

"Mathematical Markup Language", P. Ion and R. Miner, eds., 7 April 1998. The MathML 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-MathML-19980407.
la dernière version de MathML 1.0 est disponible à : http://www.w3.org/TRREC-MathML.

[PNG]

"PNG (Portable Network Graphics) Specification", T. Boutell, ed., T. Lane, contributing ed., 1 October 1996. The latest version of PNG 1.0 is: http://www.w3.org/TR/REC-png.

[RDF]

"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds., 22 February 1999. The RDF Recommendation is: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
la dernière version de RDF 1.0 est disponible à : http://www.w3.org/TR/REC-rdf-syntax

[RFC2068]

"HTTP Version 1.1", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners-Lee, January 1997.

[SMIL]

"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 June 1998. La recommandation SMIL 1.0 est à : http://www.w3.org/TR/1998/REC-smil-19980615
la dernière version de SMIL 1.0 est disponible à : http://www.w3.org/TR/REC-smil

[TECHNIQUES]

"Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds. This document explains how to implement the checkpoints defined in "Web Content Accessibility Guidelines 1.0". The latest draft of the techniques is available at: http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/

[WAI-AUTOOLS]

"Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds. The latest Working Draft of these guidelines for designing accessible authoring tools is available at: http://www.w3.org/TR/WAI-AUTOOLS/

[WAI-UA-SUPPORT]

This page documents known support by user agents (including assistive technologies) of some accessibility features listed in this document. The page is available at: http://www.w3.org/WAI/Resources/WAI-UA-Support

[WAI-USERAGENT]

"User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds. The latest Working Draft of these guidelines for designing accessible user agents is available at: http://www.w3.org/TR/WAI-USERAGENT/

[WCAG-ICONS]

Information about conformance icons for this document and how to use them is available at http://www.w3.org/WAI/WCAG1-Conformance.html

[UWSAG]

"The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. The Unified Web Site Guidelines were compiled by the Trace R & D Center at the University of Wisconsin under funding from the National Institute on Disability and Rehabilitation Research (NIDRR),  U.S. Dept. of Education. This document is available at: http://www.tracecenter.org/docs/html_guidelines/version8.htm

[XML]

"Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 February 1998. La recommandation XML 1.0 est à : http://www.w3.org/TR/1998/REC-xml-19980210.
la dernière version de XML 1.0 est disponible à : http://www.w3.org/TR/REC-xml