Accessibilité des applications internet riches
Par WebAIM
Note : cet article est le deuxième d'une série de 2 concernant AJAX et l'accessibilité des contenus dynamiques. Nous vous recommandons de commencer par lire Accessibilité des applications AJAX - implications.
Table des matières
- Présentation
- Exposer la structure sémantique des documents
- Mise à jour de contenu dynamique
- Améliorer l'accessibilité au clavier
- Accessibilité des Widgets
- Conclusion
Présentation
Cet article propose quelques techniques et approches génériques pour l'accessibilité d'AJAX et des contenus dynamiques dans les applications Internet riches. Sans prétention d'exhaustivité, il présente une vue d'ensemble des moyens de rendre les contenus dynamiques et scriptés accessibles.
Note concernant ARIA
WAI-ARIA (accessibilité des applications Internet riches) est un protocole défini par le W3C pour permettre et améliorer l'accessibilité des contenus dynamiques et scriptés. ARIA fournit des contrôles interactifs accessibles (tels que menus arborescents, glisser-déposer, gestion de tri, etc), des rôles permettant d'identifier la structure des pages (navigation, recherche, contenu principal, etc.), des zones susceptibles de changer dynamiquement (appelées "régions actives" dans ARIA), un meilleur support de l'accessibilité du clavier et de l'interactivité, et bien plus encore.
Disponible dans la plupart des navigateurs et des lecteurs d'écran modernes, ces améliorations sont également présentes dans de nombreuses librairies Javascript. Son manque d'implémentation dans Internet Explorer représente probablement le plus grand frein à son implémentation généralisée, mais Internet Explorer 8 annonce un support complet d'ARIA. Bien que cette technologie ne soit pas encore disponible universellement, elle permet d'améliorer l'accessibilité là où c'est possible, sans poser le moindre problème de rétro-compatibilité pour autant.
Pour plus d'informations sur l'implémentation de WAI-ARIA, référez-vous à la FAQ officielle. Vous pouvez également consulter l'article de WebAIM pour plus d'informations sur l'accessibilité générale de Javascript.
En général, les problèmes d'accessibilité des applications Internet riches correspondent à :
- Exposer la structure sémantique des différentes zones de la page et leur fonction (navigation, contenu principal, etc.).
- Préserver l'accessibilité des contenus susceptibles de changer pendant la consultation de la page (contenus obtenus via des appels AJAX).
- Permettre de donner le focus à certains éléments qui ne le peuvent pas en temps normal (par exemple pour attirer l'attention sur un message d'erreur).
- Rendre accessibles au clavier et pour les lecteurs d'écran les éléments interactifs et la navigation (curseurs, arborescences de menus, etc.).
Exposer la structure sémantique des documents
Les versions actuelles de HTML et XHTML ne disposent pas de mécanisme permettant d'indiquer la fonction ou le but des éléments de sorte qu'elle soit déterminable par programmation (ce qui est une manière très compliquée de dire "d'une façon compréhensible pour un ordinateur"). En d'autres termes, vous ne pouvez pas indiquer dans le code le contenu principal, la navigation, la recherche, etc. en tant que tel. Il est possible -et nécessaire- d'utiliser une structure de titres cohérente dans le document, mais ce n'est pas une manière suffisamment standardisée pour que les utilisateurs puissent accéder ou déterminer le rôle sémantique des différents éléments de la page.
Le fait qu'il soit nécessaire de mettre en place des liens d'évitement ("Aller au contenu" ou "Passer la navigation") montre bien qu'il y a là un problème. Les navigateurs et lecteurs d'écran n'ont aucun moyen de savoir quelle portion de la page contient la navigation, l'auteur est donc obligé de fournir explicitement des liens permettant aux utilisateurs naviguant au clavier d'éviter ces listes de liens. Et même pour localiser une fonctionnalité aussi répandue que la recherche, un utilisateur doit parcourir ou écouter toute la page.
WAI-ARIA permet aux auteurs des documents d'indiquer le rôle des zones du document (et de bien d'autres éléments). Les rôles définis pour les sections de page sont les suivants :
banner(bannière)- Contenu lié au site, tel que son nom, le titre de la page et/ou le logo
navigation- Les liens de navigation dans la page ou le site
main(contenu principal)- Le contenu principal du site
search(recherche)- Section contenant le moyen d'effectuer une recherche dans le site
article- Contenu autonome, capable de faire sens même isolé du reste de la page. On indiquera de cette manière un billet de blog ou un commentaire, une intervention sur un forum, etc. Plus spécifiquement, dans une page de blog, un billet et les différents commentaires pourront chacun recevoir ce rôle.
complementary(complément)- Contenu complétant le contenu principal
contentinfo(informations relatives au contenu)- Informations relatives au document, tel que les notes de pied de page, mention de copyright, lien vers la politique de confidentialité, vers des préférences modifiables, et ainsi de suite.
Sur ce site, le logo et le slogan pourraient avoir le rôle banner. Les onglets de navigation en haut de page auraient le rôle navigation, la zone de recherche bien évidement le rôle de search. Les liens de la colonne de gauche pourraient être qualifiés de complementary. Le corps de l'article serait main, et la section « Voir également... » aurait le rôle contentinfo.
La plupart des pages peut dès maintenant intégrer quelques-uns des rôles structurels : <ul role="navigation">, <div role="main"> et <form role="search">. Ce mécanisme ARIA n'est pas limité aux applications Internet riches, il peut être mis en place sur pratiquement toutes les pages actuelles.
Les aides techniques commencent à intégrer le support de ces rôles structurels. Elles pourraient proposer des raccourcis clavier permettant d'atteindre des emplacements spécifiques ("r" pour la recherche, par exemple), et/ou proposer la liste de tous les rôles présents dans la page web. De plus, ARIA propose de nouveaux types de rôles pour d'autres types d'éléments, tels que role="presentation" pour les tableaux de mise en page.
Les rôles permettent également d'indiquer les éléments obligatoires dans un formulaire, d'améliorer l'étiquetage des types de champs, et de fournir aux utilisateurs de lecteur d'écran un feedback instantané.
Mise à jour de contenu dynamique
La mise à jour dynamique du contenu de la page peut poser des problèmes d'accessibilité. Que faire si le lecteur d'écran est en train de lire un contenu en cours de modification ? Si le nouveau contenu est important, faut-il interrompre l'utilisateur et y déplacer son attention, ou seulement l'informer de la mise à jour, voire ne rien faire du tout ? Et comment attirer son attention ou lui permettre d'atteindre la zone modifiée ?
Dans une situation habituelle, le développeur en charge de l'interactivité est obligé de décider de ce qui doit se produire lorsqu'un changement survient dans la page, par exemple à l'arrivée d'un message de feedback obtenu via AJAX. Il peut laisser la mise à jour se produire sans en informer l'utilisateur, ou le prévenir à l'aide d'un signal sonore, ou encore forcer le curseur du lecteur d'écran à rejoindre la zone modifiée. Pour chaque situation, ce choix est de la responsabilité du développeur, et l'utilisateur n'a aucun contrôle.
Avec la technologie WAI-ARIA, les développeurs peuvent identifier des zones de la page comme étant "actives" ("live region" dans la terminologie ARIA), dans lesquelles la mise à jour s'effectuera d'une manière compréhensible pour un lecteur d'écran. Pour chaque région active, le développeur peut ajouter des fonctionnalité d'alerte additionnelles, des moyens de contrôler cette région, définir la quantité de nouveau contenu à lire, et plus encore.
Pour créer une région active, le développeur doit ajouter l'attribut aria-live en lui donnant une valeur parmi "off" (désactivé), "polite" (poli), "assertive" (autoritaire), et "rude" (malpoli). Cette valeur, ou niveau de politesse, (ou d'intrusivité, si on le voit sous l'angle opposé), indique au lecteur d'écran la conduite à adopter lorsque cette région est modifiée.
Positionnée sur off (aria-live="off"), le lecteur d'écran ignorera la mise à jour. Le contenu ne sera lu que s'il est rencontré au cours de la consultation de la page. C'est la valeur à utiliser pour les mises à jour de contenu non importantes ou sans rapport.
Avec la valeur polite, l'utilisateur est informé du changement dès que sa tâche actuelle est terminée. La notification peut s'effectuer par un bip système, ou par une indication audio. L'utilisateur (ou utilisatrice) peut choisir d'aller directement au contenu modifié. Cette valeur serait la plus courante pour la mise à jour de contenu, en particulier pour la notification, les fluctuations météorologiques ou boursières, la messagerie instantanée, etc.
La valeur assertive servirait à alerter l'utilisateur immédiatement ou le plus tôt possible, et à utiliser pour les mises à jour importantes, telles que des messages d'erreur.
Enfin, la valeur aria-live="rude" est à réserver aux modifications critiques, et informe l'utilisateur instantanément, pouvant même placer d'autorité le curseur au début du contenu modifié.
Les régions actives d'ARIA permettent une grande flexibilité de nuances, tant pour les développeurs que pour les utilisateurs finaux.
Améliorer l'accessibilité au clavier
En HTML, seuls les liens et les champs de formulaires peuvent recevoir le focus clavier, c'est-à-dire qu'en se déplaçant dans la page à l'aide de la touche tabulation, le navigateur ne s'arrêtera pour donner le focus qu'à ce type d'éléments. Il est pourtant possible avec Javascript de faire interagir n'importe quel élément aux évènements déclenchés par la souris. En d'autres termes, un paragraphe ou un simple span peuvent interagir avec la souris (il est par exemple possible de donner à du texte simple l'apparence et le comportement d'un bouton). Les fonctionnalités de ces éléments incapables de recevoir le focus ne peuvent pas être atteintes par ceux qui naviguent exclusivement au clavier. Cependant, les développeurs souhaitent souvent pouvoir rendre interactifs des éléments de la page autre que les liens ou champs de formulaire.
De plus, il est souvent nécessaire d'amener le focus sur des zones particulières de la page. Un message d'erreur de validation de formulaire, par exemple, peut être affiché par Javascript sous forme de texte (plutôt qu'un lien ou un champ de formulaire). Les utilisateurs voyants seront visuellement informés du message d'erreur, en revanche les utilisateurs de revue d'écran risquent fort de passer à côté. Pour pouvoir placer le focus sur le message d'erreur et le faire lire par le lecteur d'écran, il doit pouvoir recevoir le focus, ce qui n'est possible que s'il commence par un lien ou un champ de formulaire.
Ici encore, ARIA permet de contourner ce problème, à l'aide de la propriété tabindex (voir l'article dédié à cette propriété). ARIA permet d'ajouter cette propriété à n'importe quel élément HTML. La valeur tabindex="0" place l'élément dans l'ordre de tabulation normal du document, c'est-a-dire que le navigateur s'arrêtera sur cet élément lorsque l'utilisateur l'atteindra en tabulant. Ce mécanisme permet d'ajouter des fonctionnalités et de l'interactivité à cet élément, par exemple en déclenchant un évènement au moment où l'élément reçoit le focus, ou en fonction d'une touche enfoncée alors que l'élément possède le focus.
La valeur tabindex="-1" permet à un élément de recevoir le focus mais uniquement par programmation. Il faut donc que l'utilisateur active un lien pointant vers cet élément (<a href="/traduction/accessibilite-des-applications-internet-riches#contenu_principal">...) ou que le focus soit déclenché par Javascript (par exemple avec document.getElementById('messageErreur').focus();).
En augmentant le nombre d'éléments pouvant recevoir le focus dans le navigateur, ARIA augmente les possibilités de rendre les scripts accessibles au clavier.
Accessibilité des Widgets
Le terme widget regroupe des éléments interactifs créés et contrôlés par Javascript. Ces éléments sont des contrôles non disponibles en HTML, ou dont l'interactivité est grandement améliorée. On peut citer en exemple les curseurs, menus déroulants, ou dépliés au survol, les arborescences, le glisser-déposer, les champs de saisie avec auto-complétion, les infobulles, et bien d'autres encore.
Les widgets ne sont accessibles ni nativement ni spontanément, et même si les scripts permettent souvent de les rendre accessibles, il n'existe pas de moyen simple et standardisé pour cela. En résumé : on peut souvent rendre ces widgets utilisables au clavier, et aux revues d'écran, mais c'est difficile et, en pratique, le résultat est souvent décevant.
Un menu déroulant, par exemple, tel qu'on en trouve souvent dans le bandeau de navigation des sites web, permet de rassembler un grand nombre de possibilités dans un espace réduit. Le script permet tout-à-fait de rendre les éléments déroulés accessibles au clavier. Le développeur pourrait par exemple masquer ces sous-éléments et faire pointer le lien principal vers une page contenant la liste des sous-éléments, mais ce procédé implique de créer des pages en plus et force les utilisateurs à franchir une étape supplémentaire. Une autre solution consisterait à laisser l'utilisateur tabuler parmi tous les liens de navigation, mais il peut y en avoir un grand nombre (plusieurs centaines sur certains sites), et on perd toute notion de hiérarchie car les liens seraient lus les uns après les autres. Enfin, le développeur peut utiliser Javascript pour rendre la navigation déroulable au clavier, mais il n'existe aucune convention. Doit-on appuyer sur Entrée, flèche bas, ou peut-être Espace pour dérouler le menu ? Et pour les sous-menus ? S'il se déroule avec les flèches, comment un utilisateur aveugle peut-il deviner si c'est un menu déroulant vertical (utiliser la flèche bas) ou un menu déroulant horizontal (flèche droite) ? Et comment présente-t-on la hiérarchie d'un menu déroulant complexe à un utilisateur de lecteur d'écran ?
Ce genre de problèmes se pose également avec les autres types de widgets. Comment rend-on un glisser-déposer accessible au clavier ? Comment présenter les informations de tri pour une liste d'éléments réorganisables ? Comment présenter une infobulle ou des messages en popup à des utilisateurs aveugles ?
ARIA répond à beaucoup de ces interrogations en fournissant un ensemble de rôles, de propriétés et valeurs simples à mettre en œuvre, et permet aux développeurs de prendre ces problématiques en compte.
Voici quelques exemples très basiques d'implémentation d'ARIA :
Elément de formulaire obligatoire
: (obligatoire)
<label for="prenom">Prénom</label>: <input name="prenom" id="prenom" aria-required="true"> <em>(obligatoire)</em>
Ce champ texte présente un problème fréquent : il doit obligatoirement être rempli mais le mot « Obligatoire » se trouve en dehors de la balise label et n'a donc que très peu de chances d'être annoncé par un lecteur d'écran. En revanche, la propriété aria-required="true" permet d'informer le logiciel que ce champ est requis.
À noter :
Bien qu'ARIA fournisse l'information nécessaire dans cet exemple, cela ne fonctionnera que dans les navigateurs et aides techniques qui le supportent. Dans les autres agents utilisateurs, ce formulaire ne serait pas accessible. Nous avons choisi un exemple volontairement maladroit (le mot « Obligatoire » devrait être à l'intérieur de la balise label), mais cela démontre bien la manière dont ARIA permettra de contourner ces problèmes.
Exemple de bouton
Le bouton qui suit est un élément textuel (au lieu d'un bouton généré par la balise HTML appropriée) qui peut être cliqué mais également activé au clavier (tabulez jusqu'au bouton et appuyez sur Entrée ou Espace).
Cliquez-moi
<span style="background-color: #ddd; border: medium outset white;" role="button" tabindex="0" onkeydown="if(event.keyCode==13 || event.keyCode==32) alert('Activé au clavier');" onclick="alert('Activé à la souris');">Cliquez-moi</span>
Dans cet exemple, le texte est stylé pour ressembler à un bouton. Le rôle role="button" indique au navigateur qu'il se comporte comme tel. tabindex="0" ajoute l'élément dans la liste des éléments tabulables afin que les personnes naviguant au clavier puissent l'activer. Le code de cet exemple est un peu forcé (pourquoi ne pas utiliser la balise button tout simplement ?), mais il montre comment ARIA permet de rendre n'importe quel élément accessible au clavier.
Exemple de validation de formulaire
Dans cet exemple,
En temps normal, le message de feedback ne sera pas annoncé par un lecteur d'écran car le focus est replacé directement sur le champ. Nous lui avons cependant attribué role="alert" lorsqu'il est affiché, ce qui oblige le lecteur d'écran à le lire immédiatement. L'utilisateur peut donc retenter de répondre avec ces instructions complémentaires. Une fois que la bonne réponse a été fournie, le focus est placé sur le texte qui suit notre formulaire (auquel nous avons donné tabindex="0" pour qu'il puisse recevoir le focus), afin que la tabulation ne saute pas au premier lien ou champ de formulaire dans la suite de la page.
Conclusion
Ces exemples illustrent quelques moyens simples d'améliorer l'accessibilité d'éléments interactifs en utilisant ARIA dès maintenant. Mais ARIA permet également d'améliorer bien d'autres sortes de widgets et d'interactions. Plutôt que de développer des widgets complexes de A à Z à chaque fois, les développeurs recourent souvent à des librairies Javascript, et ARIA est en cours d'implémentation dans la plupart de ces librairies (notamment dans jQuery, Dojo, YUI, et GWT). Cela n'empêche pas les développeurs d'implémenter ARIA dans leurs propres widgets et applications, mais l'utilisation d'une librairie simplifie énormément la mise en place de ce niveau d'accessibilité.
ARIA n'est pas toujours évident à mettre en place, et ne prétend pas résoudre tous les problèmes d'accessibilité, mais permet d'améliorer grandement l'accessibilité, comparé à ce qui est actuellement possible avec HTML et Javascript uniquement. Le support dans les navigateurs, les aides techniques et les librairies Javascript est en constante progression, et ARIA est un outil précieux pour améliorer l'accessibilité des applications Internet riches.
A voir également
- Javascript Accessibility
- WAI-ARIA Overview
- ARIA FAQ
- Free ARIA Community Mailing List
- ARIA Test Cases
Copyright © 1999-2006 WebAIM (Web Accessibility in Mind). Tous droits réservés.
La société Ideose a conclu un accord avec WebAIM pour traduire leurs documents techniques. Nous invitons donc nos lecteurs à consulter les documents traduits sur le site d'Ideose.
http://www.webaim.org/techniques/aria/