Accessibilité du Web - Définition

Les normes d'accessibilité internationales

L'accessibilité Web dépend de plusieurs composantes interdépendantes :

• le contenu Web, c'est-à-dire « l'ensemble de l'information et de l'expérience sensorielle qui est communiquée à l'utilisateur par le biais d'un agent utilisateur, incluant le code ou le balisage qui définit la structure du contenu, sa présentation et les interactions avec lui » ;
• les agents utilisateurs qui exploitent le contenu et le restituent aux internautes : navigateurs, plugins, etc. ;
• les technologies d'assistance logicielles (lecteurs d'écran, logiciels d'agrandissement, etc.) et matérielles (claviers adaptés, commutateurs, etc.) ;
• les outils d'édition du contenu ;
• les outils d'évaluation de l'accessibilité Web ;
• les développeurs de contenu, d'agents utilisateurs, de technologies d'assistance, d'outils d'édition et d'évaluation.

Pour permettre le développement de l'accessibilité à travers ces composants, le W3C a créé des recommandations à travers le projet Web Accessibility Initiative (WAI) créé en 1996. Ces recommandations sont organisées selon trois points de vue :

1. les outils de production de contenu doivent d'une part pouvoir être utilisés par tous, et d'autre part autoriser et favoriser la production d'un contenu accessible. Il s’ensuit qu'ils doivent suivre des lignes de conduite particulières ; ces lignes de conduite sont répertoriées dans les Authoring Tools Accessibility Guidelines ;
2. le contenu mis en ligne lui-même doit être accessible ; c'est ce que l'on entend habituellement par l'accessibilité du Web et dont les recommandations sont regroupées dans les Web Content Accessibility Guidelines ;
3. afin de tirer parti de ce contenu accessible, les outils de consultation (par exemple les navigateurs Internet) doivent être utilisables par tous et exploiter les informations spécifiques qui ont été ajoutées aux contenus pour les rendre accessibles. Les lignes de conduite pour les outils de consultation sont exposées dans les User Agent Accessibility Guidelines.

La WAI intervient également lors de l'élaboration de toutes les spécifications du W3C afin de s'assurer de leur compatibilité avec les directives d'accessibilité. Son groupe de travail sur les protocoles et les formats est ainsi à l'origine d'améliorations du format HTML ainsi que des feuilles de style en cascade (CSS). Enfin, d'autres recommandations en chantier sont consacrées notamment au interfaces riches, ou à XML, SVG, SMIL.

Recommandations pour le contenu

Les recommandations en ce qui concerne le contenu s'adressent à tous les distributeurs de contenu sur le Web. Ces directives se nomment les Web Content Accessibility Guidelines. Succédant aux WCAG1.0 publiées en 1999, les WCAG2.0 sont la recommandation officielle depuis le 11 décembre 2008.

WCAG 1.0

WCAG1.0 comporte 14 directives dont les 11 premières visent à assurer une transformation élégante du contenu dans les différents contextes utilisateurs:

1. fournir des alternatives équivalentes aux contenus visuels et auditifs (images statiques ou animées, contenus audio et vidéo) ;
2. ne pas s'en remettre exclusivement aux couleurs ;
3. utiliser le balisage HTML et les feuilles de styles CSS de façon appropriée ;
4. clarifier l'utilisation du langage naturel ;
5. créer des tableaux HTML qui se transforment de façon élégante ;
6. s'assurer que les pages qui contiennent de nouvelles techniques (objets programmables, styles CSS) se transforment de façon élégante ;
7. assurer à l'utilisateur le contrôle des changements du contenu lorsque ce dernier varie dans le temps (clignotements, mouvements, rafraîchissement du contenu, redirections) ;
8. assurer un accès direct aux interfaces utilisateur intégrées (objets Flash, applets JAVA) ;
9. concevoir de manière indépendante du périphérique (souris, clavier, etc.) ;
10. utiliser des solutions intermédiaires en attendant que les agents utilisateurs aient un meilleur support de l'accessibilité ;
11. utiliser les technologies et directives du W3C.

Les 3 dernières visent à rendre le contenu compréhensible et navigable :

12. fournir des informations de contexte et d'orientation ;
13. fournir des mécanismes de navigation clairs ;
14. s'assurer que les pages sont claires et simples.

Chaque directive détermine un ou plusieurs points de contrôles. Par exemple, la directive 2 demande de « ne pas s'en remettre exclusivement aux couleurs » et prévoit à cet effet deux points de contrôle :

1. « s’assurer que toute information convoyée par des couleurs est également accessible sans couleur, par exemple à partir du contexte ou de balises » ;
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 ».

Les 65 points de contrôle WCAG1.0 concernent les thématiques des contenus (images, objets programmables, objets multimédia), des structures (tableaux, cadres, titres), du graphisme et de la mise en forme (couleurs, séparation de la structure et de la présentation), de l'interactivité et de la navigation (liens, formulaires, redirections).

Chaque point de contrôle s'est vu attribuer un degré de priorité, en fonction des impossibilités ou des difficultés d'accès qu'il permet de lever. La validation de tous les points de contrôle d'un degré donné et des degrés inférieurs détermine le niveau d'accessibilité du site concerné :

Les niveaux d'accessibilité WCAG1.0

Priorité	Obligation	Portée	Niveau d'accessibilité	Exemple
1	Ce qui doit être fait.	Lève les barrières obstructives à l'accès aux contenus	Niveau A (respect des points de contrôle de priorité 1)	Toute information véhiculée par la couleur est également perceptible sans couleur.
2	Ce qui devrait être fait	Lève d'autres barrières significatives	Niveau AA (respect des points de contrôle de priorité 1 et 2)	Les contrastes de couleurs entre avant-plan et arrière-plan sont suffisants dans les images.
3	Ce qui peut être fait	Améliore le confort d'accès	Niveau AAA (respect des points de contrôle de priorité 1, 2 et 3)	Les contrastes de couleurs entre avant-plan et arrière-plan sont suffisants dans les textes.

L'exemple de la couleur illustre la manière de répartir des points de contrôle par niveau de priorité :

• au niveau de priorité le plus élevé : une information véhiculée uniquement par une couleur, telle que dans la légende d'une carte, ne sera pas perceptible pour de nombreux types d'utilisateurs (par exemple, les personnes aveugles utilisant un lecteur d'écran) ;
• au niveau intermédiaire, un degré de contraste insuffisant dans une image rendra celle-ci difficilement compréhensible pour des utilisateurs daltoniens ou plus généralement malvoyants, bien qu'une technologie d'assistance puisse éventuellement améliorer le rendu de l'image ;
• au niveau de priorité le moins élevé, assurer un degré de contraste suffisant dans les textes HTML évite aux utilisateurs malvoyants d'avoir à désactiver les styles de présentation du site pour être certains de pouvoir lire aisément ceux-ci.

Les points de contrôle sont donc la base de la validation WCAG1.0.

WCAG 2.0

Alors que les WCAG1.0 concernent principalement les contenus HTML, les WCAG2.0 font abstraction de la technologie spécifiquement utilisée et ont pour objectifs d'être :

• applicables à toutes les technologies actuelles et futures de conception de pages Web, qu'il s'agisse de technologies du W3C comme CSS, XML et SMIL ou d'autres technologies telles que Flash, Silverlight ou PDF. WCAG2.0 adopte à cet effet le concept de « technologie compatible avec l'accessibilité », défini par le fait qu'une technologie est conçue de manière à permettre aux agents utilisateurs d'accéder à toute l'information nécessaire pour restituer le contenu à l'utilisateur de manière appropriée, et que les agents utilisateurs et les technologies d'assistance aient été adaptés à l'usage de cette technologie. WCAG2.0 tient ainsi compte de l'évolution des services Web et de l'émergence des interfaces enrichies : une des ruptures les plus notables avec WCAG1.0 est que JavaScript est désormais reconnu comme une technologie compatible avec l'accessibilité, qui ne nécessite donc plus d'alternative pour les agents utilisateurs n'en ayant pas le support. Là où WCAG1.0 recourait au bannissement de technologies considérées comme non accessibles, WCAG2.0 privilégie le développement de l'interopérabilité et autorise l'utilisation de technologies non accessibles dans la mesure où elles n'interfèrent pas avec l'information équivalente fournie par ailleurs via les technologies accessibles ;
• plus aisées à comprendre et à utiliser. Pour cela, les WCAG2.0 sont dotées d'un guide d'implémentation, Understanding WCAG 2.0 et d'un exemple de méthode d'application dans le cadre XHTML CSS, les Techniques for WCAG 2.0 ;
• plus aptes à l'évaluation humaine ou logicielle grâce à des critères de succès explicites et testables, afin de répondre aux besoins en matière de préconisations lors de la conception de site, d'évaluation de la conformité des solutions, de règlementation et d'accords contractuels.

WCAG2.0 adopte également une approche thématique plus rigoureuse en structurant 12 directives principales selon 4 principes fondamentaux :

1. des contenus perceptibles :
   • fournir des alternatives textuelles à tous les contenus non textuels, de sorte qu'ils puissent être adaptés sous une forme répondant aux besoins des utilisateurs,
   • fournir des alternatives synchronisées aux média synchronisés,
   • créer du contenu qui puisse être mis en forme de différentes manières sans perte d'information ou de structure,
   • permettre aux utilisateurs de voir et d'entendre plus facilement le contenu, notamment en séparant avant-plan et arrière-plan ;
2. des contenus utilisables :
   • rendre toutes les fonctionnalités utilisables au clavier,
   • garantir aux utilisateurs handicapés un temps suffisant pour comprendre et utiliser le contenu,
   • ne pas mettre en forme le contenu d'une manière connue comme entraînant des dommages,
   • fournir des aides aux utilisateurs handicapés pour naviguer, rechercher du contenu et se situer dans ceux-ci ;
3. des contenus compréhensibles :
   • fournir des textes lisibles et compréhensibles,
   • permettre aux pages Web d'apparaître et de se comporter de manière prévisible,
   • aider les utilisateurs à rectifier leurs erreurs ;
4. des contenus robustes :
   • optimiser la compatibilité avec les agents utilisateurs actuels et futurs, y compris les technologies d'assistance.

Chacune des 12 directives se décompose en un ou plusieurs « critère de succès » de niveau A, AA ou AAA, qui deviennent la base d'évaluation d'accessibilité du site. Pour chaque critère de succès, WCAG2.0 indique des « techniques suffisantes et indicatives » qui fournissent un guide limité à XHTML CSS, sans pour autant faire dépendre la conformité ni de l'emploi exclusif de ces formats, ni des techniques spécifiquement détaillées pour ceux-ci.

La définition des trois niveaux d'accessibilité tient désormais compte de leur faisabilité :

Les niveaux d'accessibilité WCAG2.0

Niveau	Objectif	Faisabilité	Exemple
A	Atteindre un niveau d'accessibilité minimum.	Critères de succès essentiels pouvant raisonnablement s'appliquer à toutes les ressources Web.	La couleur n'est pas le seul moyen visuel de véhiculer l'information.
AA	Améliorez le niveau d'Accessibilité	Critères de succès supplémentaires pouvant raisonnablement s'appliquer à toutes les ressources Web.	Les textes de petite taille ont un ratio de contraste au moins égal à 4.5
AAA	Atteindre un niveau supérieur d'accessibilité.	Critères de succès ne s'appliquant pas à toutes les ressources Web.	Les textes de petite taille ont un ratio de contraste au moins égal à 7

WCAG2.0 entérine enfin le choix du niveau AA comme objectif des politiques d'accessibilité globale, le niveau AAA n'étant pertinent que pour certains projets, en fonction des contenus spécifiques qui sont concernés.

Cette évolution a été contestée par certains experts, à l'initiative de Joe Clark qui a récusé le mode de fonctionnement de la WAI pour privilégier une mise à jour de WCAG1.0, sous la forme d'un errata WCAG1.0 réalisé indépendamment de la WAI par le projet WCAG Samurai.

Recommandations pour interfaces riches

L'essor des services et applications en ligne reposant sur l'utilisation croissante de technologies hybrides telles que JavaScript, AJAX et SVG, l'élaboration par la WAI de l'Accessible Rich Internet Applications Suite (ARIA) vise à mettre en place le cadre normatif nécessaire à l'accessibilité des application Web dynamiques.

Quelques éditeurs mettent à disposition des acteurs de l'accessibilité des bibliothèques de techniques accessibilisées en tout ou en partie. C'est notamment le cas de Dojo, de JQuery, ou encore de YUI.

Recommandations pour les outils de production de contenu

Les lignes de conduite les plus à jour pour les logiciels d’édition de HTML, les éditeurs de page ou logiciel de publication de site Web créant le code HTML, sont les Authoring Tools Accessibility Guidelines dans leur version 1.0, datant de février 2000.

Depuis la publication des ATAG1.0, sont sortis les systèmes de gestion de contenu et les blogues pour lesquels les ATAG2.0 sont en chantier. ATAG2.0 distingue deux aspects clés de l'accessibilité des outils de production :

• l'accessibilité de l'interface des d'outils de production, qui renvoie pour l'essentiel aux directives d'accessibilité des contenus Web, et qui dépend :
  • de sa compatibilité avec les technologies d'assistance,
  • de sa capacité à être perceptible,
  • de sa capacité à être utilisable,
  • de sa capacité à être compréhensible ;
• la capacité des outils à favoriser la production de contenus accessibles, c'est-à-dire :
  • supporter les solutions d'accessibilité que les rédacteurs doivent intégrer aux contenus,
  • aider et guider les rédacteurs dans la production d'un contenu accessible, les alerter en cas d'actions générant des problèmes d'accessibilité,
  • inciter les rédacteurs à prendre en compte l'accessibilité et favoriser celle-ci d'une manière générale.

Les solutions de publication de plus en plus utilisées amènent à une séparation accrue entre le travail de production éditorial et les aspects techniques du contenu, et donc entre métiers de rédacteur et d'intégrateur. Dès lors, une responsabilité croissante incombe aux outils de production pour assurer autant que possible, et de manière aussi transparente que possible, le respect des directives d'accessibilité des contenus. Ils ne peuvent cependant en être les seuls garants : les rédacteurs de contenu jouent un rôle final majeur, illustré par les référentiels métier liés aux compétences éditoriales.

Recommandations pour les outils de consultation

Afin de tirer le meilleur parti des sites Web accessibles, il est essentiel que les outils de consultation de ces sites soient eux-mêmes utilisables par des personnes handicapées. C’est dans l'intention de définir des recommandations à ce sujet qu’ont été écrites les User Agent Accessibility Guidelines 1.0. Les travaux continuent dans le cadre d'une nouvelle version en cours d'élaboration, les UAAG2.0.

UAAG2.0 est organisé autour de 5 principes (décomposés en directives correspondant elles-mêmes à un ou plusieurs critères de succès) :

1. respecter les normes et conventions applicables ;
2. favoriser l'accès par les technologies d'aide ;
3. garantir que l'interface utilisateur soit perceptible ;
4. garantir que l'interface utilisateur soit utilisable ;
5. garantir que l'interface utilisateur soit compréhensible.

Les cycles d'implémentation de l'accessibilité

L'interdépendance entre les composantes du Web permet à une amélioration de l'accessibilité pour l'une d'entre elle d'entraîner des améliorations en chaîne. Par exemple :

• la prise en compte d'une directive d'accessibilité par les agents utilisateurs incite les utilisateurs eux-mêmes à réclamer sa prise en compte par les éditeurs de contenu ;
• la prise en compte d'une directive d'accessibilité par les éditeurs de contenu les incite à réclamer son implémentation dans leurs outils d'édition.

Inversement, cette interdépendance conduit à des blocages lorsqu'une composante présente des faiblesses, par exemple : une absence d'implémentation dans un navigateur incite les éditeurs de contenu à ne pas tenir compte d'une directive d'accessibilité, ce qui peut conduire à leur tour les développeurs d'outils d'édition à ne pas la prendre en charge. La question peut alors se poser de son maintien dans les normes techniques du Web, comme par exemple dans le cas des descriptions étendues d'images dans le format HTML5.