La version française de cette traduction est :
http://www.la-grange.net/w3c/atag10/

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

W3C

Règles d'accessibilité pour les outils d'édition 1.0

Recommandation W3C 3 février 2000

Cette version :
http://www.w3.org/TR/2000/REC-ATAG10-20000203
Dernière version :
http://www.w3.org/TR/ATAG10
Version précédente :
http://www.w3.org/TR/1999/PR-WAI-AUTOOLS-19991026
Editeurs :
Jutta Treviranus - ATRC, Université de Toronto
Charles McCathieNevile - W3C
Ian Jacobs - W3C
Jan Richards - Université de Toronto

Résumé

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.

Ce document est un élément d'une série de documents publiés par l'Initiative pour l'accessibilité du Web (WAI) du W3C.

Statut de ce document

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.

un journal des changements entre les différentes versions des brouillons de travail est disponible.

Pour de plus amples informations à propos des décisions du groupe de travail, consultez les minutes des réunions du AUWG.

Ce document a été produit par le groupe de travail des règles d'accessibilité des outils d'édition (AUWG) comme une partie de l'Initiative pour l'accessibilité du Web (WAI). Les buts de ce groupe de travail sont discutés dans la charte de l'AUWG.

Envoyez vos commentaires généraux à propos de ce document dans la liste de discussion publique : w3c-wai-au@w3.org (archives publiques).

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.

La liste des erreurs connues de ce document est disponible à http://www.w3.org/WAI/AU/ATAG-ERRATA. Faites part des erreurs de ce document à wai-atag-editor@w3.org.

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.

Sommaire

Un appendice de ce document [ATAG10-CHECKLIST] liste tous les contrôles pour plus de commodité.


1. Introduction

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

1.1 Comment les règles sont organisées ?

Les sept règles dans ce document sont des principes généraux pour une conception permettant l'accessibilité. Chaque règle comprend :

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 :

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

1.2 Les priorités du point de contrôle

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 :

Les niveaux de priorité sont assignés comme suit :

[Priorité 1]
Si le point de contrôle est essentiel pour respecter les buts.
[Priorité 2]
Si le point de contrôle est important pour respecter les buts.
[Priorité 3]
Si le point de contrôle est salutaire pour respecter les buts.
[Priorité relative]

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.

1.3 Conformité à ses règles

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.

Les détails à propos des icônes de conformité sont fournis sur le Web ( se référer à [CONFORMITE]).

Niveaux de conformité

Un label de conformité doit indiquer quel niveau de conformité est respecté :

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.

les labels de conformité bien formés

Un label bien formé doit inclure l'information suivante :

  1. les titre et version des règles: "Règles d'accessibilité pour les outils d'édition 1.0" ;
  2. l'URI des règles : http://www.w3.org/TR/2000/REC-ATAG10-20000203 ;
  3. le niveau de conformité satisfait : "A", "Double-A", ou "Triple-A" ;
  4. 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 ;
  5. la date du label ;
  6. 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>

Validité d'un label

Un label de conformité est valide pour un niveau de conformité donné si :

  1. le label est bien formé, et
  2. 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.

Icônes de conformité

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

2. Règles

Règle 1. Soutenir les méthodes pour l'édition accessibles.

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.

Points de contrôle :

1.1 S'assurer que l'auteur puisse produire un contenu accessible dans le ou les langage(s) de balisage permis par l'outil. [Priorité 1]
Techniques pour le point de contrôle 1.1
1.2 S'assurer que l'outil préserve toute l'information d'accessibilité pendant l'édition, les transformations, et les conversions. [Priorité 1]
Techniques pour le point de contrôle 1.2
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]
Techniques pour le point de contrôle 1.3
1.4 S'assurer que les gabarits fournis par l'outil se conforme aux règles d'accessibilité du contenu Web 1.0 [WCAG10]. [Priorité relative]
Techniques pour le point de contrôle 1.4

Règle 2. Générer un balisage standard.

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.
Techniques pour le point de contrôle 2.1
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.
Techniques pour le point de contrôle 2.2
2.3 Si le balisage produit par les outils ne se conforme aux spécifications du W3C, informez l'auteur. [Priorité 3]
Techniques pour le point de contrôle 2.3

Règle 3. Soutenir la création de contenu accessible.

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.

Points de contrôle :

3.1 Inviter l'auteur à fournir une information alternative équivalente (ex., des titres, des descriptions auditives, et des transcriptions texte assemblées pour la vidéo). [Priorité relative]
Note : Quelques points de contrôle dans les règles d'accessibilité du contenu Web 1.0 [WCAG10] peuvent ne pas s'appliquer.
Techniques pour le point de contrôle 3.1
3.2 Aider l'auteur à créer un contenu structuré et à séparer l'information de sa présentation. [Priorité relative]
Note : Quelques points de contrôle dans les règles d'accessibilité du contenu Web 1.0 [WCAG10] peuvent ne pas s'appliquer.
Techniques pour le point de contrôle 3.2
3.3 S'assurer que le contenu préformaté se conforme aux règles d'accessibilité du contenu Web 1.0 [WCAG10]. [Priorité relative]
Par exemple, Inclure destitres, une description auditive, et une transcription texte assemblée avec des films préformatés. Se référer aussi au point de contrôle 3.4.
Techniques pour le point de contrôle 3.3
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.

Techniques pour le point de contrôle 3.4
3.5 Fournir une fonctionnalité pour gérer, éditer et réutiliser les équivalents alternatifs pour les objets multimédia. [Priorité 3]
Note : Ces équivalents alternatifs peuvent être conditionnés avec l'outil, écrit par l'auteur, extrait du Web, etc.
Techniques pour le point de contrôle 3.5

Règle 4. Fournir des moyens de vérifier et de corriger le contenu inaccessible.

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.

points de contrôle :

4.1 Vérifier et informer l'auteur d'un problèmes d'accessibilité. [Priorité relative]
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.
Techniques pour le point de contrôle 4.1
4.2 Assister les auteurs en corrigeant les problèmes d'accessibilité. [Priorité relative]
Au minimum, fournir une aide contextuelle avec la vérification d'accessibilité requise par le point de contrôle 4.1
Techniques pour le point de contrôle 4.2
4.3 Permettre à l'auteur de préserver un balisage non reconnu par l'outil. [Priorité 2]
Note : L'auteur peut avoir à inclure ou à importer un balisage qui améliore l'accessibilité mais qui n'est pas reconnu par l'outil.
Techniques pour le point de contrôle 4.3
4.4 Fournir à l'auteur un sommaire du statut de l'accessibilité des documents. [Priorité 3]
Techniques pour le point de contrôle 4.4
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]
Techniques pour le point de contrôle 4.5

Règle 5. Intégrer des solutions d'accessibilité dans l'ensemble du "look and feel".

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]
Techniques pour le point de contrôle 5.1
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]
Techniques pour le point de contrôle 5.2

Règle 6. Promouvoir l'accessibilité dans l'aide et la documentation.

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]
Techniques pour le point de contrôle 6.1
6.2 S'assurer que la création de contenu accessible est une partie normalement intégrée de la documentation, y compris les exemples. [Priorité 2]
Techniques pour le point de contrôle 6.2
6.3 Dans une section dédiée, documenter toutes les options de l'outil qui promulgue la production de contenu accessible. [Priorité 3]
Techniques pour le point de contrôle 6.3

Règle 7. S'assurer que les outils d'édition sont accessibles aux auteurs avec des handicaps.

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.
Techniques pour le point de contrôle 7.1
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é.
Techniques pour le point de contrôle 7.2
7.3 Permettre à l'auteur d'éditer toutes les propriétés de chacun des éléments et objet dans un mode accessible. [Priorité 1]
Techniques pour le point de contrôle 7.3
7.4 Assurer que le mode édition permet la navigation par la structure du document dans un mode accessible. [Priorité 1]
Techniques pour le point de contrôle 7.4
7.5 Rendre possible l'édition de la structure du document dans un mode accessible. [Priorité 2]
Techniques pour le point de contrôle 7.5
7.6 Permettre à l'auteur de rechercher à l'intérieur des modes édition. [Priorité 2]
Techniques pour le point de contrôle 7.6

3. Glossaire des termes et des définitions

Accessibilité (Voir aussi : Accessible)
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 :
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.
Information d'accessibilité
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.
Problème d'accessibilité (Voir aussi : Balisage inaccessible)
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.
Pratique d'édition 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.
Alerte
Une "alerte" attire l'attention de l'auteur sur un événement ou une situation. Elle peut requérir une réponse de la part de l'auteur.
Information alternative (Voir aussi : Alternative équivalente)
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].
Attribut
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).
Description auditive
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.
Outil d'édition
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 :
Titres
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.
Outil de conversion
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).
Vérifier
Comme mentionné dans lepoint de contrôle 4.1, "vérifier" peut se réferer à trois types de vérification :
  1. 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.
  2. 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.
  3. 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.
Document
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).
Mode édition
Un "mode édition" est un mode fournit par l'outil d'édition qui permet d'éditer.
Elément
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.
Informer
"Informer" est d'avertir l'auteur d'un événemen ou d'une situation grâce à une alerte, une invite, un son, un flash, ou tout autre moyen.
Langage de balisage
Les auteurs encodent l'information en utilisant un "langage de balisage" comme HTML [HTML4], SVG [SVG], ou MathML [MATHML].
Balisage de présentation
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.
Invite
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).
Propriété
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.
Balisage structurel
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.
Transcription
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.
Transformation
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.
User Agent
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.
Vue
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.

4. Remerciements

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.

5. Références

Pour obtenir la dernière version de n'importe quelle spécification du W3C consultez la liste des rapports techniques du W3C à http://www.w3.org/TR.

[ATAG10-CHECKLIST]
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).
[ATAG10-TECHS]
"Techniques pour les règles d'accessibilité des outils d'édition 1.0," J. Treviranus, J. Richards, I. Jacobs, et C. McCathieNevile eds. La dernière version est disponible à http://www.w3.org/TR/ATAG10-TECHS.
[CONFORMITE]
"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.
[CSS1]
"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.
[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.
[HTML4]
"Recommandation HTML 4.01 ," D. Raggett, A. Le Hors, et I. Jacobs, eds., 24 décembre 1999. La recommandation HTML 4.01 est http://www.w3.org/TR/1999/REC-html401-19991224. La dernière version de HTML 4 est disponible à http://www.w3.org/TR/html4. Dernière version disponible à : http://www.w3.org/TR/html401
Version française (non complète) disponible à : http://www.la-grange.net/w3c/html401/
[MATHML]
"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.
[RDF10]
"Spécification du modèle et de la syntaxe du canevas de description de ressources (RDF)," O. Lassila, R. Swick, eds. La recommandation du 22 février 1999 est http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. La dernière version de RDF 1.0 est disponible à http://www.w3.org/TR/REC-rdf-syntax.
[SVG]
"Scalable Vector Graphics (SVG) 1.0 Specification (Working Draft)," J. Ferraiolo, ed. The dernière version de the SVG specification is available at http://www.w3.org/TR/SVG.
[UAAG10-TECHS]
"Techniques pour les règles d'accessibilité des agents utilisateur 1.0," J. Gunderson, et I. Jacobs, eds. La dernière version de Techniques pour les règles d'accessibilité des agents utilisateur 1.0 est disponible à http://www.w3.org/TR/UAAG10-TECHS/.
[WCAG10]
"règles d'accessibilité du contenu Web 1.0," W. Chisholm, G. Vanderheiden, et I. Jacobs, eds., 5 mai 1999. Cette recommandation est http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505. La dernière version de règles d'accessibilité du contenu Web 1.0" est disponible à http://www.w3.org/TR/WCAG10/.
[WCAG10-TECHS]
"Techniques pour les règles d'accessibilité du contenu Web 1.0," W. Chisholm, G. Vanderheiden, et I. Jacobs, eds. La dernière version de Techniques pour les règles d'accessibilité du contenu Web 1.0 est disponible http://www.w3.org/TR/WCAG10-TECHS/.
[XML]
"Le langage de balisage extensible (XML) 1.0," T. Bray, J. Paoli, C. M. Sperberg-McQueen, eds., 10 février 1998. Cette recommandation XML 1.0 http://www.w3.org/TR/1998/REC-xml-19980210. La dernière version de la spécification XML est disponible à http://www.w3.org/TR/REC-xml.
Version française disponible à : http://babel.alis.com/web_ml/xml/REC-xml.fr.html

Level Double-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0