Traducteur : Karl Dubost - <karl+misc@la-grange.net>
La version française peut contenir des erreurs. La version anglaise de cette spécification est l'unique version
normative. Version originale : http://www.w3.org/TR/ATAG10
Cette spécification fournit les règles pour les développeurs d'éditeurs
Web. Elle a deux objectifs : assister les développeurs dans la conception
des outils d'édition qui permettent de produire un contenu web accessible
et d'assister les développeurs dans la création d'interface d'édition
accessible.
Les outils d'édition peuvent rendre possible, encourager et assister
les utilisateurs ("auteurs") dans la création d'un contenu Web accessible
à travers des messages d'invite et d'alerte, des fonctions de vérification et de
correction, des fichiers d'aides et des outils automatisés. Il est aussi
important que toutes personnes puissent rédiger du contenu autant qu'elle
puissent accéder à celui-ci. Par conséquent, les outils utilisés pour créer cette
information doivent être eux-même accessibles. L'adoption de ces règles
contribuera à la prolifération d'un contenu Web qui pourra être lu par une
plus large proportion de lecteurs et à la prolifération d'outil d'édition
qui pourront être utilisés par une plus large proportion d'auteurs.
Cette section décrit le statut de ce document à
la date de sa publication. D'autres documents pourront remplacer
ce document. Le dernier statut de cette série de document
est maintenu au W3C.
Ce document a été validé par les membres
du W3C ainsi que par d'autres organismes et a été
approuvé par le Directeur comme une recommandation du W3C. C'est un document
stable et il peut-être utilisé comme document de
référence et peut être cité comme un
référence normative pour d'autres documents.
Le rôle du W3C dans l'établissement de cette recommandation
est d'attirer l'attention sur la spécification et de promouvoir sa
large diffusion. Ceci améliore la fonctionnalité et
l'interopérabilité du Web.
La version anglaise de cette spécification est l'unique version
normative. De l'information à propos des traductions est disponible à
http://www.w3.org/WAI/AU/ATAG-TRANSLATIONS.
Une liste des recommandations du W3C actuelles et des documents
techniques y compris les brouillons de travail et les notes est disponible
à http://www.w3.org/TR.
Dans ces règles, le terme "outil
d'édition" se réfère au large ensemble de logiciels utilisés
pour créer du contenu Web, dont :
les outils d'édition conçus spécifiquement pour produite du contenu Web
(ex., les éditeurs HTML et XML WYSIWYG) ;
les outils qui offrent la possibilité de sauvegarder dans un format Web
(ex., les traitements de textes ou les suites de PAO) ;
les outils qui transforment les documents dans un format Web (ex.,
les filtres qui transforment les documents de PAO en HTML) ;
les outils qui produisent du multimédia qui doit être utilisé sur le Web
(ex., les suites de production vidéo et d'édition, les ensembles d'édition SMIL) ;
les outils pour la gestion de site ou pour la publication de site qui
génèrent des sites web dynamiquement à partir d'une base de données,
d'outils de conversion à la volée, et des outils de publication de sites
Web ;
les outils pour la gestion de la présentation (ex., les outils de mise
en forme avec les CSS).
Les buts de ce document peuvent être définis de cette manière : que les
outils d'édition soient accessibles aux auteurs quelquesoient leur
handicap, que le contenu produit par défaut soit accesible, et que la
création de contenu accessible soit soutenue et encouragée. Comme la
plupart du contenu du Web est créé en utilisant les outils d'éditions, ils
jouent un rôle critique en assurant l'accessibilité du Web. Depuis que le Web est
un moyen de recevoir et de communiquer de l'information, il est important
que simultanément les contenu Web produit et les outils d'éditions eux-même
soient accessibles.
Pour atteindre ces buts, les développeurs d'outils d'éditions doivent
s'assurer de la conformité aux standards accessibles (ex., HTML 4), de
vérifier et de corriger les problèmes d'accessibilité, d'alerter et de
fournir une documentation et une aide appropriée. Pour obtenir une information
détaillée sur ce qui constitue un contenu accessible, ces règles s'appuient
sur les règles d'accessibilité du contenu Web 1.0 [WCAG10]. De la même façon, plutôt que
de reproduire directement des spécifications existantes qui fixe la
conception générale des logiciels accessibles, ces règles s'appuient sur
d'autres sources. Les règles présentes définit des considérations de
conception spécifiques aux outils d'édition Web comme fournir des
présentations d'édition simples, des aides de navigation et d'accès aux
propriétés d'affichage pour les auteurs.
Les principes définis dans ces règles seront bénéfiques pour beaucoup
de personnes qui n'ont pas de handicaps mais qui ont des besoins
identiques. Cela comprend les personnes qui travaillent dans des
environnements bruyants ou calmes où l'utilisation du son n'est pas
pratique, les personnes qui ont besoin d'utiliser leurs yeux pour d'autres
tâches ou qui ne sont pas capables de voir un écran, et les personnes qui
utilisent de petits appareils mobiles qui ont un petit écran, pas de
clavier, et pas de souris.
Un document séparé, intitulé "Techniques pour les règles
d'accessibilité des outils d'édition 1.0" [ATAG10-TECHS], fournit des
suggestions et des exemples pour satisfaire aux points de contrôle. Cela
inclue également des références à d'autres ressources pour l'accessibilité
(comme des règles d'accessibilité de logiciels spécifiques à certaines
plateformes) qui fournit de l'information supplémentaire sur la manière
pour un outil de satisfaire tous les points de contrôles. Les lecteurs
sont fortement encouragés à devenir familier avec le docuement des
techniques ainsi qu'avec les "techniques pour les règles
d'accessibilité des outils d'édition 1.0" [WCAG10-TECHS]
et les "Techniques pour les règles d'accessibilité des agents utilisateur 1.0"
[UAAG10-TECHS].
Note : Les techniques dans [ATAG10-TECHS] sont uniquement des
exemples informatifs. D'autres stratégies peuvent être utilisées pour
satisfaire les points de contrôle en supplément ou en remplacement de
celles exposées dans [ATAG10-TECHS].
Note : Les outils d'édition qui se conforme à ce
docuement propageront un contenu Web accessible et seront utiles à tous
indépendamment de leur handicap. Il y aura également des outils d'édition
qui produiront du contenu dans des circonstances favorables (ex., un
éditeur de texte utilisé par un auteur motivé), ou qui fourniront une
interface accessible pour les auteurs avec certains handicaps, mais qui ne
se conformeront pas à ces règles.
Les sept règles dans ce document sont des principes généraux pour une
conception permettant l'accessibilité. Chaque règle comprend :
le numéro de la règle ;
l'énoncé de la règle ;
le raisonnement derrière la règle ;
une liste des définitions des points de contrôle.
Les définitions des points de contrôle dans chaque règle spécifient les
exigences qui permettent le respect de la règle par les outils d'édition.
Chaque définition de point de contrôle comprend :
le numéro du point de contrôle ;
l'énoncé du point de contrôle ;
la priorité du point de contrôle ;
dans certains des notes informatives, des exemples d'éclaircissement,
ou des références croisées à d'autres règles ou points de contrôles ;
un lien vers la section des "techniques pour les règles
d'accessibilité des outils d'édition 1.0" [ATAG10-TECHS] ou les
mises en oeuvre et les exemples des points de contrôle sont exposés.
Chaque point de contrôle est prévu pour être assez spécifique afin
qu'il puisse êtr vérifié, tout en restant sufisamment général pour
permettre aux développeurs la liberté d'utiliser les stratégies les plus
appropriées pour le satisfaire.
Un appendice de cette spécification [ATAG10-CHECKLIST] liste tous
les points de contrôle pour plus de commodité.
Chaque point de contrôle a un niveau de priorité. Le niveau de priorité
reflète l'impact du point de contrôle dans le respect des but de cette
spécification. Ces buts sont :
que l'outil d'édition soit accessible ;
que l'outil d'édition produise du contenu accessible par défaut ;
que l'outil d'édition encourage la création de contenu accessible.
Les niveaux de priorité sont assignés comme suit :
Certains points de contrôle qui se réfère à la génération, à l'édition
ou à la vérification de contenu Web ont de multiples priorités. La priorité
dépend des règles d'accessibilité du contenu Web (WCAG) 1.0 [WCAG10].
Il est de priorité 1 pour satisfaire le point de contrôles pour les
caractéristiques de contenu qui sont des exigences de priorité 1 dans
WCAG 1.0.
Il est de priorité 2 pour satisfaire le point de contrôles pour les
caractéristiques de contenu qui sont des exigences de priorité 2 dans
WCAG 1.0.
Il est de priorité 3 pour satisfaire le point de contrôles pour les
caractéristiques de contenu qui sont des exigences de priorité 3 dans
WCAG 1.0.
Par exemple :
Fournir des équivalents textes
pour les images et le son est une exigence de priorité 1 dans WCAG 1.0 tant que, sans eux, un ou
plusieurs groupes auront l'impossibilité d'accéder à l'information. Par
conséquent, c'est une exigence de priorité 1 pour l'outil d'édition de
vérifier (4.1) ou de demander à
l'auteur de vérifier (3.1) que des alternatives
équivalentes existent pour ces types de contenu.
Grouper des liens dans les bars de navigation est une priorité 3 dans WCAG 1.0. Par conséquent, c'est
seulement une priorité 3 pour l'outil d'édition de vérifier (4.1) ou de demander à
l'auteur de vérifier (3.2) que des groupes
de liens ne sont pas groupés dans le balisage comme un mécanisme de
navigation.
Lorqu'un point de contrôle dans ce document se réfère à WCAG 1.0 [WCAG10], seulement les points de contrôle WCAG 1.0, qui se réfèrent au contenu supporté ou
automatiquement généré par l'outil d'édition, s'appliquent. Quelques uns
des points de contrôle WCAG
1.0 appliquables peuvent être satisfaits automatiquement (sans
participation de l'auteur) alors que les autres requèrent le jugement de
l'homme et une aide de l'outil sous la forme de messages d'invite et de
documentation. Des outils différents peuvent satisfaire le même point de
contrôle différemment.
Le niveau de priorité de chaque point de contrôle a été choisi en se
basant sur la supposition que l'auteur est un utilisateur compétent, mais
pas nécéssairement un expert, de l'outil d'édition et que l'auteur a peu
ou pas de connaissance de ce qu'est l'accessibilité. Par exemple, l'auteur
n'a pas nécessairement lu toute la documentation, mais il est attendu
qu'il puisse obtenir la documentation lui fournissant de l'aide.
Cette section explique comment créer un label valide pour qu'un outil d'édition
puisse se conformer à ce document. Tout le monde peut créer un label
(ex., les sociétes à propos de leurs propres produits, des tierces parties
à propos de ces produits, les journalistes à propos des produits, etc.).
Les labels peuvent être publiés n'importe où (ex.,
sur le Web ou dans la documentation du produit).
Les revendicateurs du label sont entièrement responsables de leurs labels et
de l'utilisation des icônes de conformité icônes de conformité. Si le sujet du label (c.-à.-d.,
le logiciel) change après la date du label, le revendicateur du label
est responsable de la mise à jour du label. Les revendicateurs du label
sont encouragés à se conformer au règles les plus récentes disponibles.
Un label de conformité doit indiquer quel niveau de conformité
est respecté :
Niveau "A" de conformité : tous les points de
contrôle de Priorité 1 (y compris les points de contrôle de Priorité
relative) sont satisfaits.
Niveau "Double-A" de conformité : tous les points de
contrôle de Priorité 1 et 2 (y compris les points de contrôle de Priorité
relative) sont satisfaits.
Niveau "Triple-A" de conformité : tous les points de
contrôle de Priorité 1, 2 et 3 (y compris les points de contrôle de Priorité
relative) sont satisfaits.
Note : Les niveaux de conformités sont en toutes lettres dans le
texte (ex., "Double-A" plutôt que "AA"), ainsi ils peuvent être compris
lorsqu'ils sont exprimés sous forme parlée.
le numéro de version et l'OS du logiciel couvert par le label.
Egalement si des mises à jour ou des plug-ins sont nécessaires ;
la date du label ;
les points de contrôle des niveaux de conformité choisis considérés
comme non applicables. Les revendicateurs devront utiliser la liste de
contrôle [ATAG10-CHECKLIST] dans ce but.
Cette information doit être fournie en balisage de texte ou de métadatas
(ex., en utilisant le canevas de description de ressource (RDF)
[RDF10] et un
schéma RDF créé pour les labels de conformité WAI).
Tout contenu dans le label doit être accessible relativement aux
règles d'accessibilité du contenu Web 1.0 [WCAG10].
Voici un exemple de revendication rédigé en HTML :
<p>MyAuthoringTool version 2.3 sur MyOperatingSystem se conforme
aux "Règles d'accessibilité pour les outils d'édition 1.0" du <abbr
title="the World Wide Web Consortium">W3C</abbr>, disponible à
http://www.w3.org/TR/2000/REC-ATAG10-20000203, niveau Double-A. Les détails
de ce label sont fournis à <a href="http://somewhere.com/details">
http://somewhere.com/details</a>.</p>
l'outil d'édition satisfait tous les points de contrôle pour ce niveau.
Les revendicateurs du label (ou les parties asurrante celui-ci) sont
responsables de la validité du label. Quant à la publication de ce
document, le W3C n'agit pas comme un organisme certificateur, mais il
pourrait le devenir dans le futur, ou établier des recommandations pour des
organismes certificateurs.
Les revendicateurs du label sont priés de modifier ou retirer un label
si il a été démontré que le label n'est pas valide. Notez qu'il n'est
pas possible pour l'instant de valider les labels de manière complètement
automatique.
Lors du respect du label de conformité, les personnes peuvent utiliser
une icône de conformité sur un site Web, sur l'emballage d'un produit, dans
la documentation, etc. Chaque icône de conformité (choisie en fonction du
niveau de conformité approprié) doit
établir un lien avec l'explication du W3C de l'icône. La présence d'une
icône de conformité du W3C n'implique pas que le W3C ait examiné ou validé
le label. Une icône doit être accompagnée par un label bien formé.
Si l'outil génère un balisage automatiquement, beaucoup d'auteurs seront
ignorants du statut d'accessibilité du contenu final à moins qu'ils
fassent l'effort supplémentaire de l'examiner et de faire les corrections
appropriées à la main. Comme beaucoup d'auteurs ne sont pas familiers avec
les règles d'accessibilité, les outils d'édition sont responsables de la
génération automatique du balisage permettant l'accessibilité, et lorsque
c'est approprié, de guider l'auteur dans sa production de contenu
accessible.
Beaucoup d'applications offrent la possibilité de convertir des
documents en provenance d'autre formats (ex., Rich Text Format)
en un format balisé spécifiquement prévu pour le Web comme le HTML. Les
changements de balisage peuvent être également fait pour faciliter une
édition ou une manipulation efficace. Il est alors essentiel que ces processus
n'introduisent pas de balisage inaccessible ou effacent le contenu
accessible, particulièrement quand un outil cache les changements du
balisage de la vue de l'auteur.
1.3 S'assurer que lorsque
l'outil génère automatiquement un balisage automatiquement, il se conforme
aux règles d'accessibilité du contenu Web 1.0 [WCAG10] du
W3C. [Priorité relative]
La conformité avec les standards favorise l'interopérabilité et
l'accessibilité en rendant plus facile la création d'
agents
utilisateurs spécialisés qui répondent aux besoins des
utilisateurs ayant des handicaps. En particulier, beaucoup de technologies
d'assistance utilisées par les navigateurs et les players multimédia sont
uniquement capables de fournir l'accès à des
documents Web qui utilisent un balisage valide. Par conséquent,
le balisage valide est un aspect essentiel de l'accessibilité des outils
d'édition.
Quand c'est possible, utilisez les recommandations du
W3C, qui ont été
examinées pour permettre l'accessibilité et l'interopérabilité. Si les
recommandations du W3C
ne peuvent s'appliquer, utilisez un standard publié qui permet
l'accessibilité.
Points de contrôle :
2.1 Utilisez les dernières versions des recommandations du W3C quand elles sont disponibles et appropriées pour une
tâche. [Priorité 2]
Les spécifications du W3C ont subi un examen spécifique qui assure
qu'elles ne nuisent pas à l'accessibilité, et lorsque c'est possible,
l'améliorent.
2.2 S'assurer que l'outil génère
automatiquement un balisage valide. [Priorité 1]
Ceci est nécessaire pour que les agents
utilisateurs soient capables d'interprêter le contenu Web de
façon appropriée pour les besoins d'un utilisateur particulier.
Une information bien structurée et une information alternative équivalente sont
les pierres angulaires de l'élaboration de l'accessibilité, permettant à
l'information d'être présentée de la manière la plus appropriée pour les
besoins de l'utilisateur sans contraindre la créativité de l'auteur. Encore
une fois produire une information équivalente comme des alternatives texte
pour les images et des descriptions auditives pour les vidéos, peut être un
des aspects les plus ambitieux de la conception Web, et les développeurs
des outils d'édition devraient tenter de faciliter et d'automatiser les
mécanismes de ces processus. Par exemple, inviter les auteurs à inclure une
information alternative équivalente comme des équivalents texte,des
titres,
et des descriptions auditives à des moments
appropriés peut faciliter énormément la charge des auteurs. Lorsque cette
information peut être mécaniquement déterminée et offerte comme un choix à
l'auteur (ex., la fonction des icônes dans une barre de navigation générée
automatiquement, ou la description d'un acronyme à partir d'un
dictionnaire), l'outil peut alors assister l'auteur. Dans le même temps,
l'outil peut renforcer le besoin de ce type d'information et le rôle des
auteurs de s'assurer qu'elle est utilisée à bon escient dans chaque
occurence.
3.4 Ne pas générer automatiquement des alternatives équivalentes. Ne pas réutiliser
des alternatives éditées précédemment sans confirmation de l'auteur, sauf
quand la fonction est connu avec certitude.
[Priorité 1]
Par exemple, inviter
l'auteur pour un équivalent texte d'une
image. Si l'auteur a déjà fourni un texte équivalent pour la même image
utilisée dans un autre document, offrir la possibilité de réutiliser ce
texte et inviter l'auteur à confirmer. Si l'outil génère automatiquement
une icône "Recherche", il sera approprié de réutiliser automatiquement
l'équivalent texte précédemment entré pour cette icône. Se référer
également à
point de contrôle 3.3 et à
point de contrôle 3.5.
Note : Les alternatives équivalentes rédigés par un
humain peuvent être disponible pour un objet (par exemple, à travers le point de contrôle 3.5
et/ou le point de contrôle 3.3).
Il est approprié pour l'outil d'offrir ceci par défaut à l'auteur.
Beaucoup d'outils d'édition permettent aux auteurs de créer des
documents avec peu ou pas de connaissances à propos du balisage
sous-jacent. Pour assurer l'accessibilité, les outils d'édition doivent
être conçus de telle manière qu'ils puissent (automatiquement lorsque c'est
possible) identifier le balisage
inacessible, et permettre sa correction même lorsque le
balisage est lui-même caché à l'auteur.
L'aide des outils d'édition pour la création de contenu Web accessible
devrait tenir compte des différents styles d'édition. Les auteurs qui
peuvent configurer les caractéristiques d'accessibilité des outils afin de
s'appuyer sur leur façon de travailler régulièrement sont plus enclains à
accepter les pratiques d'édition pour l'accessibilité (se référer à la règle 5). Par exemple,
certains auteurs peuvent préférrer d'être alerté des problèmes d'accessibilité au fur et à mesure,
alors que d'autres peuvent préferrer de faire une vérification à la fin
d'une saisie complète. Ceci est analogue aux environnements de
programmation qui permettent aux utilisateurs de décider la vérification du
code pendant l'édition ou au moment de la compilation.
Note :La validation du balisage est un aspect
essentiel de la vérification de l'accessibilité d'un contenu.
Note : Les problèmes
d'accessibilité devraient être détectés automatiquement si possible.
Lorsque ceci n'est pas possible, l'outil peut avoir besoin d'
inviter l'auteur à prendre une décision ou
à vérifier manuellement certains types de problèmes.
4.5 Permettre à l'auteur de
transformer le balisage de présentation
qui est utilisé à tort pour transmettre la structure en un balisage structurel, et pour
transformer le balisage de présentation utilisé pour le style en feuilles
de style. [Priorité 3]
Quand une nouvelle option est ajoutée à un logiciel existant sans une
intégration propre, le résultat est souvent une discontinuité manifeste.
Schémas de couleur différents, polices, styles d'interaction, et même la
stabilité du logiciel peuvent être des facteurs affectant la réceptivité
de l'auteur face à la nouvelle option. En plus, la proéminence relative
des différentes manières d'accomplir la même tâche peut influencer laquelle
l'auteur choisira. Par conséquent, il est important que la création du
contenu accessible soit un processus naturel lors de l'utilisation d'un
outil d'édition.
points de contrôle:
5.1 S'assurer que la fonctionnalité
relative aux pratiques
d'édition accessible est naturellement intégré dans l'aspect
général de l'outil. [Priorité 2]
5.2 S'assurer que les pratiques d'édition accessible
définis par les points de contrôle Priorité 1 des règles d'accessibilité du contenu Web 1.0 [WCAG10] font partie des plus manifestement et facilement
inaugurables de l'auteur.
[Priorité 2]
Les auteurs Web peuvent ne pas être familier des questions, concernant
l'accessibilité, émergeant lors de la création d'un contenu Web. Par
conséquent, la documentation et l'aide doivent inclure des explications sur
les problèmes
de l'accessibilité, et devraient exposer des solutions avec des
exemples.
points de contrôle:
6.1 Documenter toutes les options qui
promulgue la production de contenu accessible.
[Priorité 1]
L'outil d'édition est un logiciel avec des éléments d'interface
utilisateur standard et comme tel, doit être conçu en accord avec les
règles d'accessibilités pour l'interface utilisateur. Quand des
composantes d'interfaces habituelles sont créées, il est essentiel qu'elles
soient accessibles à travers les mécanismes standard d'accès pour la
plateforme en question, donc que les technologies d'assistance puissent
être utilisées avec elles.
Quelques considérations supplémentaires sur la conception des interfaces
utilisateur s'appliquement précisément aux outils d'édition Web. Par
exemple, les outils d'édition doivent assurer que l'auteur puisse éditer
(en mode édition) en utilisant un ensemble de
préférences stylistiques et publier en utilisant des styles différents.
Les auteurs qui ont une vision déficiente peuvent avoir besoin d'un texte
élargi au moment de l'édition mais vouloir qu'il soit publié avec une
taille de texte par défaut plus petite. Les préférences de style du mode
édition ne doivent pas affecter le balisage du document publié.
Les outils d'édition doivent également assurer que l'auteur puisse
naviguer dans un document lors de son édition, sans tenir compte de son
handicap. Les auteurs qui utilisent des lecteurs d'écran, des afficheurs
braille dynamiques, ou des agrandisseurs d'écran peuvent faire un usage
limité (sinon de tout) des artéfacts graphiques qui communiquent la
structure du document et agir comme une indication lorsqu'il le parcoure.
Les utilisateurs qui ne peuvent pas utiliser de souris (ex., les personnes
avec des handicaps physiques ou qui sont aveugles) doivent utiliser le
lent et fatigant processus de déplacement étape par étape à travers le
document pour accéder au contenu désiré, à moins que des méthodes
efficaces de navigation soient disponibles.
Les outils d'édition devraient par conséquent fournir un
mode édition qui transmette le sens de la structure globale et
permette une navigation structurée.
Note : La documentation, les fichiers d'aide, et
d'installation font partie du logiciel et doivent être dans une forme
accessible.
points de contrôle :
7.1 Utiliser tous les OS et les standards
et conventions d'accessibilité (Priorité 1 pour les standards et les
conventions qui sont essentielles à l'accessibilité ; Priorité 2 pour
ceux qui sont importantes pour l'accessibilité ; Priorité 3 pour
ceux qui sont salutaires pour l'accessibilité).
les techniques pour ce point de contrôle incluent des références
aux listes de contrôle et aux règles pour nombre de plateformes et aux
règles générales pour les applications accessibles.
7.2 Permettre à l'auteur de changer
la présentation à l'intérieur des modes
édition sans affecter le balisage du document.
[Priorité 1]
Ceci permet à l'auteur d'éditer le document en accord avec ses
exigences personnelles, sans changer la manière dont le document est
traité lorsqu'il est publié.
Au sein de ces règles, le "contenu Web accessible" et l'"outil
d'édition accessible" signifie que le contenu et l'outil peuvent être
utiliser par tous sans se préocupper des handicaps.
Pour comprendre les questions d'accessibilité relatives à la
conception des outils d'édition, considérez que de nombreux auteurs
peuvent être amener à créer du contenu dans des contextes très différents
du votre :
ils peuvent ne pas être capables de voir, entendre, se déplacer, ou ne
pas être capable de traiter certaines informations aisément ou du tout ;
ils peuvent avoir des difficultés à lire ou à comprendre un texte ;
ils peuvent ne pas avoir ou n'être pas capables d'utiliser un clavier
ou une souris ;
ils peuvent avoir des afficheurs textes uniquement, ou avoir un petit
écran.
La conception accessible sera bénéfique aux individus dans ces différents scénarios
d'édition et également à beaucoup d'autres personnes qui n'ont pas du tout
de handicap mais qui ont des besoins similaires. Par exemple, quelqu'un
qui doit travailler dans un environnement bruyant et qui requère alors une
représentation alternative de l'information audio. De même, quelqu'un peut
avoir à travailler dans un environnement où son regard est occuppé et alors
requérir une équivalent audio de l'information qui ne peut être vue. Les
utilisateurs des petits appareils mobiles (avec de petits écrans, pas de
clavier, et pas de souris) ont des besoins fonctionnels identiques aux
utilisateurs avec des handicaps.
L'"information d'accessibilité" est le contenu, incluant l'information et
le balisage qui sont utilisés pour améliorer l'accessibilité d'un document.
L'information d'accessibilité inclut, mais ne se limite pas à, une information alternative équivalente.
Le contenu web inaccessible ou les outils d'édition inaccessibles ne
peuvent pas être utilisés par les personnes qui ont des handicaps.
Les règles d'accessibilité du contenu Web 1.0 [WCAG10]
décrivent comment créer du contenu Web accessible.
Les "pratiques d'édition accessible" améliore l'accessibilité du
contenu Web. Les auteurs, ainsi que les outils s'engagent dans des pratiques
d'édition accessible. Par exemple, les auteurs écrivent clairement,
structurent leur contenu, et fournissent des aides à la navigation. Les
outils génèrent automatiquement un balisage valide et assistent les auteurs
en fournissant et en gérant les alternatives équivalentes appropriées.
Le contenu est "équivalent" à un autre contenu lorsque les deux
remplissent la même fonction ou le même dessein lors de la présentation à
l'utilisateur. Les alternatives équivalentes jouent un rôle important dans
les pratiques d'édition accessible pour tous les utilisateurs (ex., vidéo,
images, audio, etc.). Les auteurs sont encouragés à fournire des
équivalents texte pour tout contenu non textuel puisque le texte peut être
traité comme une parole synthétisé pour les personnes qui ont des
handicaps visuels ou d'apprentissage, comme du braille pour ceux qui sont
aveugles, ou comme un texte graphique pour ceux qui sont sourds ou qui
n'ont pas de handicaps. Pour plus d'informations sur les alternatives
équivantes, réferez vous aux règles d'accessibilité pour le contenu Web
WCAG 1.0
[WCAG10].
Ce document utilise le terme d'"attribut" comme utilisé dans SGML et XML ([XML]) :
Les types d'éléments peuvent être définis comme ayant un certain nombre
d'attributs. Quelques attributs sont essentiels pour l'accessibilité du
contenu (ex., les attributs "alt", "title",
et "longdesc" en HTML).
Une "description auditive" fournit une information à propos des
actions, du langage corporel, des graphiques, et des changements de scène
dans une vidéo. Les descriptions auditives sont communément utilisés par
les personnes qui sont aveugles ou qui ont une vue déficiente, bien
qu'elles puissent être également utilisées comme un équivalent pour les
faibles bandes passantes sur le Web. Une description auditive est toujours
une voix humaine pré-enregistrée ou une voix synthétisée (enregistrée ou
générée automatiquement en temps réel). La description auditive doit être
synchronisée avec la bande son du déroulement de la vidéo,
habituellement dans les pauses sonores de la bande son.
Un "outil d'édition" est un logiciel qui est utilisé pour produire du
contenu destiné à la publication sur le Web. Les outils d'édition incluent :
les outils d'édition spécifiquement conçus pour produire du contenu Web
(ex., des éditeurs WYSIWYG
HTML et XML ) ;
les outils qui offrent l'option de sauvegarder le matériel dans un format Web
(ex., traitements de texte ou suites de PAO) ;
les outils qui transforment les documents dans un format Web
(ex., les filtres qui permettent de transformer de la PAO vers le HTML) ;
les outils qui produisent du multimédia, spécialement celui qui est
destiné au Web (ex., les suites de production vidéo, les ensembles
d'édition SMIL) ;
les outils pour la gestion de site ou la publication de site,
incluant les outils qui génèrent automatiquement les sites Web
dynamiquement à partir d'une base de données, à partir d'une conversion à
la volée et des outils de publication de site Web ;
les outils pour la gestion de la présentation (ex., les outils de mise
en forme CSS).
Les "titres" sont essentiels pour les équivalents texte de la partie sonore d'un film.
Les titres consistent en une transcription textuelle de la bande
son du film ( ou de la présentation vidéo) qui est synchronisée avec les
pistes vidéo et son. Les titres sont généralement graphiquement et sont
salutaires aux personnes qui peuvent voir mais qui sont sourdes, ou qui
sont malentendantes, ou qui ne peuvent pas entendre le son.
Un "outil de conversion" est une application ou l'option d'une
application (ex., "Sauvegarder en HTML") qui transforme un contenu d'un
format vers un autre format (comme un langage de balisage).
Comme mentionné dans lepoint de contrôle
4.1, "vérifier" peut se réferer à trois types de vérification :
A certain moment, un outil d'édition sera capable de vérifier les
problèmes d'accessibilité automatiquement. Par exemple, vérifier la
validité (point de contrôle
2.2) ou tester si une image est le seul contenu d'un lien.
Dans certains cas, l'outil sera capable de "suspecter" ou de "deviner"
qu'il y a un problème, mais aura besoin d'une confirmation de l'auteur.
Par exemple, en s'assurant qu'un ordre de lecture sensible est conservé un
outil peut présenter une version linéarisée d'une page à l'auteur.
Dans certains cas, un outil peut reposer de façon importante sur
l'auteur, et peut seulement demander à l'auteur de vérifier. Par exemple,
l'outil peut inviter l'auteur à vérifier que les alternatives équivalentes
pour du multimédia sont appropriées. C'est le standard mininal à
satisfaire. Subtile, plutôt que envahissante, l'invite est suceptible
d'être plus efficace si elle est un encouragement à l'auteur pour vérifier
l'accessibilité là où cela ne peut pasêtre fait automatiquement.
Un "document" est une série d'éléments qui sont définis par un
is a series of elements that are defined by a langage de balisage (ex., HTML 4 ou
une application XML).
Un "élément" est un objet identifiable à l'intérieur d'un document, par
exemple, un caractère, un mot, une image, un paragraphe, ou une cellule de
tableur. Dans le [HTML4] et le
[XML], un
élément se réfere à une paire de balises et leur contenu, ou une balise
"vide" - soit qui ne requère aucune balise de fermeture ou de contenu.
Le "balisage de présentation" est un langage
de balisage qui encode l'information de présentation désirée ou
de mise en forme du contenu. Par exemple, les feuilles de style imbriquées
([CSS1],
[CSS2])
peuvent être utilisées pour contrôler les polices, les couleurs, le
traitement sonore, et le positionnement graphique. Le balisage de
présentation ne devrait pas être utilisé à la place du balisage structurel
pour transmettre la structure. Par exemple, les auteurs devraient baliser
les listes en HTML avec le balisage de liste approprié et les mettre en
forme avec CSS (ex., pour contrôler l'espacement, les puces, le
numérotage, etc.). Les auteurs ne devraient pas utiliser les CSS ou le
HTMLL incorrectement pour mettre en forme le contenu graphiquement afin que
celui-ci ressemble à une liste.
Une "invite" est une requête de saisie pour l'auteur, que ce soit de
l'information ou une décision. Une invite requère une réponse de l'auteur.
Par exemple, un champ de saisie d'équivalent texte affiché dans un dialogue
d'insertion d'image devraient provoquer une invite. Les invites peuvent
être utilisées pour encourager l'auteur à l'information requise pour rendre
le contenu accessible (comme des équivalents
texte alternatifs).
Une "propriété" est un morceau d'information à propos d'un élément,
par exemple d'information structurelle (ex., C'est l'élément numéro 7 dans une
liste ou un texte seul) ou une information de présentation (ex., Ceci est
balisé en gras, sa taille de police est 14). En XML et en HTML, les
propriétés d'un élément incluent le type de l'élément (ex., IMG ou
DL), les valeurs de ses attributs, et l'information associée au moyen
d'une feuille de style. Dans une base de données, les propriétés d'un
élément particulier peuvent
inclure les valeurs d'une entrée, les types de données acceptables pour
cette entrée.
Le "balisage structurel" est un langage de
balisage qui encode l'information à propos du rôle structurel
des éléments du contenu. Par exemple, les entêtes, les sections, les
membres d'une liste, et les composantes d'un diagramme complexe peuvent
être identifiés en utilisant un balisage structurel. Le balisage
structurel ne devraient pas être utilisé de manière détournée pour contrôler la
présentation ou la mise en forme. Par exemple, les auteurs ne devraient pas
utiliser l'élément BLOCKQUOTE en HTML
[HTML4] pour créer un effet d'indentation visuel. Le balisage
structurel devrait être utilisé correctement pour communiquer les rôles
des éléments du contenu et le balisage de présentation
devrait êtr utilisé séparément pour contrôler la présentation et la mise
en forme.
Une "transcription" est une représentation textuelle des sons dans un
clip audio ou d'une piste sonore d'une présentation multimédia. Une
"transcription textuelle assemblée" pour une vidéo combine (assemble) des
textes de titre avec des textes de description d'une information vidéo (
des descriptions des actions, du langage corporel, des graphiques, et des
changement de scène de la piste image). Les transcriptions textuelles
assemblées sont essentielles pour les personnes qui sont sourdes-aveugles
et qui sont dépendantes du braille pour accéder aux films et à d'autres
contenus.
Une "transformation" est un procédé qui change un document ou un objet
en un autre objet, équivalent, en respectant un ensemble fini de règles.
Ceci inclue les outils de conversion, les
logiciels qui permettent à l'auteur de changer la
DTD définie pour le document original en une autre DTD, et la capacité de changer le balisage des
listes et de les convertir en tableaux.
Un "agent utilisateur" est un logiciel qui extrait et traite le
contenu Web. Les agents utilisateurs comprennent les navigateurs, les plug-ins
pour des types de média particulier, et quelques technologies d'assistance.
Les outils d'édition peuvent traiter le même contenu de plusieurs
façons ; chaque traitement est appelé une "vue." Certains outils d'édition
auront différents types de vue, et certains permettront les vues de
différents documents simultanément. Par exemple, une vue peut montrer le
balisage brut, une seconde peut montrer un arbre structurée, une troisième
peut montrer le balisage avec les objets traités alors qu'une vue finale
montre un exemple de la manière dont le document peut apparaître si il
était interprêté par un navigateur particulier. Un moyen typique de
distinguer les vues dans un environnement graphique est de les placer
chacune dans une fenêtre différente.
Merci beaucoup aux personnes suivantes qui ont contribués par leur
relecture et leur commentaire : Jim Allan, Denis Anson, Kitch Barnicle, Kynn Bartlett, Harvey Bingham,
Judy Brewer, Carl Brown, Dick Brown, Wendy Chisholm, Aaron Cohen, Rob Cumming,
Daniel Dardailler, Mark Day, BK Delong, Martin Dürst, Kelly Ford, Jamie
Fox, Edna French, Sylvain Galineau, Al Gilman, Jon Gunderson, Eric Hansen,
Phill Jenkins, Len Kasday, Brian Kelly, Marja-Riitta Koivunen, Sho Kuwamoto,
Jaap van Lelieveld, Susan Lesch, William Loughborough, Greg Lowney, Karen
McCall, Thierry Michel, Charles Oppermann, Dave Pawson, Dave Poehlman, Loretta
Reid, Bruce Roberts, Chris Ridpath, Gregory Rosmaita, Bridie Saccocio, Janina
Sajka, John Slatin, Jim Thatcher, Irène Vatton, Gregg Vanderheiden,
Pawan Vora, Jason White, and Lauren Wood.
Un appendice de ce document liste tous les points de contrôle,
triés par priorité. La liste de contrôle est disponible aussi bien sous une
forme tabulée (à
http://www.w3.org/TR/2000/REC-ATAG10-20000203/atag10-chktable) ou sous une forme de
liste (à
http://www.w3.org/TR/2000/REC-ATAG10-20000203/atag10-chklist).
"Les icônes de
conformité de ATAG 1.0." L'information à propos des icônes
de conformité ATAG 1.0 est disponible à http://www.w3.org/WAI/ATAG10-Conformance.
"Recommandation CSS,
niveau 1," B. Bos and H. Wium Lie, eds., 17 décembre 1996, révisé 11
janvier 1999. Cette 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. Note : CSS1 a été remplacé
par CSS2. Les outils devraient se baser sur la cascade CSS2.
"Recommandation CSS,
niveau 2," B. Bos, H. Wium Lie, C. Lilley, et I. Jacobs, eds., 12
mai 1998. Cette 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.
"Langage de
balisage mathématique," P. Ion et R. Miner, eds., 7 avril 1998, révisé 7
juillet
1999. Cette recommandation MathML 1.0 est
http://www.w3.org/TR/1998/REC-MathML-19990707. La dernière version de MathML 1.0 est
disponible à http://www.w3.org/TR/REC-MathML.