Pourquoi et comment rendre une application Web accessible ?

Ce document est destiné, en particulier, aux développeurs et webmasters qui souhaitent que leurs sites ou applications Web soient accessibles au plus grand nombre d'utilisateurs !

De façon générale, l'accessibilité concerne des déficiences :

• visuelles ;

  • cécité,
  • trouble de la vision,
  • daltonisme,
  • achromatopsie,

• auditives ;

  • surdité : totale ou partielle,
• motrices ;
• cognitives ou neurologiques ;
• liées au vieillissement ;

• accident de la vie, pouvant être temporaires :

  • ex. bras cassé,

Manque de formation des utilisateurs :

• néophytes en informatique ;
• technophobe.

• connexion à Internet en bas débit.

• modification dans la restitution du contenu sur un support différent de celui prévu à l'origine « responsing desing » :

  • tablette,
  • téléphone portable,
  • ultraportable,
  • etc.

Comment communiquer par courriel, « surfer » sur la toile, utiliser la même application métier que son collègue, quand on n'y voit pas ?

Ouf ! Le lecteur d'écran est venu à la rescousse !

Il existe des aides techniques, telles qu'une plage braille, un lecteur d'écran permettant aux non-voyants et mal-voyants de prendre connaissance du contenu d'une page numérique.

Le premier lecteur d'écran : JAWS - Job Access With SpeechCe logiciel a été conçu en 1989 par Ted Henter pour rendre accessible MS-DOS aux déficients visuels.

À partir de 1993, ce logiciel a été adapté à l'interface graphique de Windows sous le nom de JFW (Jaws For Windows).

www.freedomsci.de/serv01fra.htm

D'autres lecteurs d'écran :

• NVDA - No Visual Desktop Acess - lecteur d'écran sous Windows - libre + open source.

www.nvda-fr.org/

• Window-Eyes - autre lecteur d'écran sous Windows.

www.gwmicro.com/

• Orca - lecteur d'écran sous Linux - libre.

https://doc.ubuntu-fr.org/orca

• VoiceOver - lecteur d'écran sous Mac et iPhone.

Le lecteur d'écran est donc un logiciel dont la principale fonctionnalité est d'intercepter l'information qui s'affiche sur l'écran de l'ordinateur, afin de la transmettre à un afficheur braille ou à une synthèse vocale.

Le lecteur d'écran reconnaît un certain nombre d'objets standards de l'environnement Windows tels que :

• les boîtes de dialogue ;
• les icônes du bureau ;
• les éléments des listes ;
• etc.

Il les transforme en données textuelles qui sont ensuite envoyées au synthétiseur vocal qui les lit, ou à l'afficheur braille par l'intermédiaire duquel l'utilisateur aveugle les lit lui-même.

Le lecteur d'écran n'est pas la synthèse elle-même. Il est l'interface entre l'écran de l'ordinateur et l'utilisateur, via la synthèse ou l'afficheur braille. En outre, le lecteur d'écran contient un synthétiseur vocal intégré, d'une qualité sonore tout à fait convenable et comportant plusieurs voix.

Le déficient visuel a plusieurs possibilités pour utiliser un ordinateur :

• des raccourcis clavier ;
• une plage braille.

Lorsque l'internaute non-voyant arrive sur une page, un certain nombre d'informations lui sont annoncées :

• le titre de la page ;
• le nombre de cadres ;
• le nombre de liens ;
• le nombre de titres.

Ensuite le lecteur d'écran commence la lecture du document depuis le début.

En général, l'utilisateur stoppe la lecture et cherche à aller au contenu principal via une touche de raccourcis. En allant au premier titre de niveau un de la page, par exemple. C'est pourquoi il faut proposer des liens d'évitement pour aller au contenu principal « aller au contenu » ou « skip to main content ».

Ensuite il est possible de naviguer avec la touche tabulation pour aller d'élément focalisable en éléments focalisables (liens, éléments de formulaire…). Mais le fait d'appuyer sur la touche tabulation saute la lecture des textes, qui ne sont pas focalisables.

Il est possible d'obtenir la liste de tous les éléments classés par catégories et de demander à se déplacer sur un élément.

En pratique, les lecteurs d'écran permettent d'obtenir :

• la liste des liens hypertexte : grâce à elle, il est possible de parcourir la liste pour rechercher le lien désiré. C'est pourquoi les liens doivent avoir un texte évocateur ;

  • un lien nommé : « cliquer ici » ne veut rien dire ;
• la liste des titres par niveau. Celle-ci permet de se déplacer dans le document pour rechercher le contenu désiré. Le lecteur d'écran nous annonce « titre de niveau n » et après nous lit le texte, ce qui nous indique la hiérarchie et le classement des titres. Ce niveau des titres est la vocalisation de la grosseur de la police de caractères que vous voyez : gras - italique -+grande - +petit - souligné - etc.
• le niveau du titre est annoncé en fonction de la balise <hx>. C'est pourquoi les niveaux de titres doivent être utilisés pour leur niveau et non pour leur apparence. Il faut utiliser les balises HTML de façon sémantique. Si l'on souhaite agir sur la présentation il faut utiliser les propriétés CSS.

Même un texte non visible : blanc sur blanc ou le transparent sera lu par le lecteur d'écran !

• La liste des zones de formulaire. Notamment pour les formulaires, il est possible d'obtenir toute la liste des éléments et de naviguer directement, parmi ces derniers.
  Liste de cinq éléments :

  • champs ;
  • zone de texte ;
  • case à cocher ;
  • bouton ;
  • bouton radio.

Remarque importante et astuce

Un certain nombre d'éléments cachés aux internautes voyants sont lus par le lecteur d'écran.

Par exemple, Google propose sur sa page de résultats un lien caché destiné aux non-voyants qui permet de désactiver la recherche instantanée.

« Si vous utilisez un lecteur d'écran, cliquez ici pour désactiver la recherche instantanée ».

Le lecteur d'écran lit tous les éléments présents dans la page, qu'ils soient visibles ou pas. Ainsi, un texte qui a la même couleur que le fond de la page, sera lu par le lecteur d'écran.

Certains acteurs de l'accessibilité Web étendent son champ au-delà de la question du handicap, à tous les contextes utilisateurs, en s'inspirant en particulier de l'objectif du « Web pour tous ».

Citation provenant de https://www.w3.org/Consortium/mission :

« Mettre le web et ses services à la disposition de tous les individus, quels que soient leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales. »

L'accessibilité des contenus reste cependant, aux points de vue normatif et opérationnel, un aspect spécifique de cette ambition, et ne se confond pas davantage avec la notion de qualité Web dont elle est également une composante.

Recommandations du W3C

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.

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 WCAG 1.0 publiées en 1999, les WCAG 2.0 sont la recommandation officielle depuis le 11 décembre 2008 et une norme ISO, la 40500 depuis le 26 octobre 2012.

WCAG 1.0 comporte quatorze directives dont les onze 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.

Quatre grands principes régissent les WCAG 2.0 :

1. Perceptibilité ;
2. Utilisabilité ;
3. Compréhensibilité ;
4. Robustesse.

Afin de répondre aux besoins de divers groupes et de différents contextes, trois niveaux de conformité ont été définis :

Ces outils automatiques, constituent une aide précieuse lors d'une phase d'évaluation ou d'audit, en dégageant l'évaluateur humain de tâches fastidieuses.

L'évaluation, le plus souvent limitée en nombre de pages, est davantage destinée à des audits d'échantillons qu'au suivi des contenus. Cependant, quelques solutions comme IBM Rational Policy Tester ou Opquast, permettent une évaluation systématique et continue des contenus de l'ensemble d'un site ou d'un parc de sites.

La plupart des points de contrôle comme la pertinence des intitulés de lien ou des alternatives textuelles, les changements de langue, la dégradation harmonieuse de la présentation et des contenus selon le dispositif de rendu… ne sont pas automatisables, ou ne le sont que partiellement.

Mais, ils permettent de mettre en place des indicateurs globaux : ainsi l'EIAO (European Internet Accessibility Observatory) a pu mener en 2008 une étude sur l'accessibilité de 2 317 sites Web européens, grâce à un moteur d'évaluations automatisées sur la base de 26 tests issus de WCAG 1.0 (indicateur WAM ou Web Accessibility Metric) :

« Un processus entièrement automatisé d'évaluation de l'accessibilité a plusieurs avantages évidents sur les évaluations purement manuelles. L'EIAO a pu traiter et évaluer un bien plus grand nombre de sites que n'aurait pu le faire un expert. En outre, les évaluations sont répétables, ce qui autorise la comparaison d'un mois sur l'autre. Enfin, contrairement au travail de l'expert, les résultats ne sont pas influencés par des facteurs humains tels que l'expérience du site acquise par l'expert.

En revanche, l'EIAO a ses désavantages. Principalement, il ne peut apporter le même niveau de détail qu'un expert. Ensuite, le robot ne peut évaluer des pages protégées par un mot de passe. Enfin, l'évaluation des contenus Web nécessitant une interaction utilisateur (Flash, Javascript) n'est pas supportée. ».

Le recours à des tests d'accessibilité d'un site impliquant des personnes handicapées peut apporter plusieurs bénéfices, dont en particulier :

• permettre aux développeurs d'outils de production et aux rédacteurs de découvrir comment ces personnes interagissent avec le site, quelles difficultés anticipent-elles et quelles sont leurs stratégies et leurs démarches pour les résoudre ;
• motiver développeurs, rédacteurs et responsables de sites en mettant en évidence les conséquences concrètes de leur investissement dans l'accessibilité ;
• découvrir et prioriser les points de blocage lors de la réalisation de scénario d'utilisation lors de ces tests.

Accéder à son application Web avec un navigateur textuel tel que Lynx, permet d'obtenir un aperçu des informations, qui se rapproche du rendu d'un lecteur d'écran.

ARIA est en fait une surcouche sémantique que l'on vient ajouter au-dessus d'un langage existant, tel que HTML, XML, etc.

Il se compose :

• de rôles ;
• d'états ;
• de propriétés.

qui sont, en fait, de nouveaux attributs des balises. Ces ajouts sémantiques vont permettre au lecteur d'écran de renvoyer à l'utilisateur des informations quant à la nature de ce qui est affiché à l'écran. En particulier, nous allons pouvoir décrire sémantiquement des composants d'interfaces originaux sans équivalent HTML (potentiomètre à curseur, pop-up ou fenêtre modale…)

En effet, dans les applications Web ou les sites Web modernes, il n'est pas rare de trouver des composants d'interface proches de ceux présents dans les applications traditionnelles. Il s'agit par exemple d'onglets, d'arbres dépliants, de cover flows, d'info-bulles, de fenêtres modales. Autant d'éléments qui ne peuvent être décrits sémantiquement par le simple langage HTML, y compris HTML5.

Donc, je rappelle, ARIA ne rajoute que de la sémantique, l'interactivité et l'accès clavier sont assurés par JavaScript et la mise en page par CSS.

Si vos composants d'interfaces peuvent être décrits uniquement avec du HTML, préférez le HTML. Dès lors que ce n'est pas le cas, notamment parce qu'il n'existe pas de balise pour décrire sémantiquement votre composant ou que la balise (html5) existante est mal ou non supportée par les navigateurs, alors ARIA a sa place.

Il sera par exemple préférable de faire :

<a href="xxx">lien</a>

à :

<span role="link">lien</span>.

De plus, il ne faut pas oublier que l'ajout de rôle ARIA ne supprime pas les comportements classiques des navigateurs.

Ainsi, un bouton que l'on modifie pour en faire un titre :

<button role="heading">titre</button>

reste cliquable, atteignable au clavier et ressemble toujours à un bouton alors qu'il sera restitué par la synthèse vocale, comme un titre et donc non signalé comme cliquable.

Ne pas faire :

<h1 role=button>heading button</h1>

mais plutôt :

<h1><span role=button>heading button</span></h1>

ou mieux encore :

<h1><button>heading button</button></h1>.

Toute page Web peut être divisée - structurée en région - zone comme une page Word, par exemple :

en-tête + corps du texte + pied de page.

Cette structure peut être aisément appliquée grâce aux « landmarks » ("points de repère") et elle offrira des points de repère pour une navigation commune à chaque site.

En effet, les landmarks sont utilisés pour assigner aux différentes parties de la page des rôles sémantiques correspondant à leur vocation et à leur contenu.

L'avantage réside dans le découpage sémantique en différentes zones et la caractérisation par des rôles de ces différentes parties de la page.

Les landmarks permettent de définir le rôle des différentes parties de la page, par exemple, une zone présentant le contenu principal de la page, une zone assignée aux types de contenu généralement présentée dans le footer (pied de page), une zone contenant la navigation, etc.

De plus, il est important de noter que pour l'instant, ceux sont les seuls éléments ARIA sans points de blocage et donc, dès à présent utilisables. Effectivement, si ça ne fonctionne pas pour l'utilisateur, aucun préjudice à l'usage puisqu'ils n'apportent que du confort de navigation.

La mise en place des landmarks est un processus indolore pour ajouter des rôles marquants. Il suffit d'ajouter un attribut de rôle à un élément HTML, en utilisant la valeur de rôle la plus appropriée pour le contenu du récipient. Comme :

• banner : zone d'en-tête de la page, ce que l'on appelle souvent le header. Cette zone contiendra souvent le titre de la page et le logo ;
• navigation : cette zone contiendra les éléments propres à la navigation dans le site (liens, menus, etc.) ;
• main : cette zone contiendra le « cœur de page » le contenu principal et spécifique à la page ;
• contentinfo : cette zone contiendra des informations générales à la page (mentions légales, etc.), on retrouvera ici les informations que l'on met généralement dans ce que l'on appelle « footer  ».

Les éléments ARIA ne seront pleinement fonctionnels que s'ils sont exploités par le couple navigateur/synthèse vocale capable de les prendre en charge. Le tout devant être utilisable aussi bien à la souris qu'au clavier.

Du côté des navigateurs, sur Internet Explorer, le support d'ARIA a été introduit depuis IE8, puis amélioré sur IE9. Sur Safari (OS X et iOs), le support a été introduit depuis la version 4, et largement amélioré sur la version 5 et 5.1. Sur Firefox, le support partiel a débuté dans la version 3, et est désormais complet. Enfin sur Chrome, un début de support existe depuis la version 9 et progresse régulièrement.

Du coté des lecteurs d'écran, la plupart des versions disponibles sur le marché annoncent désormais supporter ARIA. C'est notamment le cas de Jaws, NVDA et VoiceOver. Néanmoins, malgré ce support plutôt bon, sur le terrain, il est encore possible de rencontrer des soucis de compatibilité. Il reste donc impératif de tester son code régulièrement au fil des versions afin de vérifier le bon fonctionnement/support ou de faire appel à des utilisateurs réguliers de lecteur d'écran pour vous le faire.

Certaines propriétés ARIA, appelées états, peuvent varier en fonction des actions de l'utilisateur, mais c'est toujours modifié par JavaScript.

Comme par exemple, un slider : à la prise de focus sur l'élément déclaré comme étant un slider.

role="slider"

L'utilisateur peut alors incrémenter ou décrémenter la valeur avec les touches de direction. Et la valeur est mise à jour dynamiquement par JavaScript qui modifie la valeur de l'état aria-valuenow, qui indique la valeur du composant à un instant donné.

Il faut savoir que les éléments ARIA ont été intégrés par des librairies JavaScript comme Jquery, Dojo, Yahoo UI…

À l'heure actuelle, Dojo dispose du meilleur support d'ARIA, les composants de Jquery UI ou de YUI intègrent partiellement ARIA sur certains d'entre eux.

Vous n'auriez donc rien à faire pour ceux-là, tout est géré par la bibliothèque !

Néanmoins, la documentation à ce sujet est parfois très lacunaire, voire inexistante, il est donc très difficile de savoir précisément ce qui est fait et ce qui ne l'est pas, sans aller analyser le code.

ARIA, il serait temps de s'y mettre !

Édition Nº 8 | le train de 13h37

Magazine francophone dédié à la conception Web édité par la société WAGON 42.

contact@wagon42.fr

Départ régulièrement à 13h37 pour une nouvelle édition.

Accueil - ARIA au pays du Web

http://qelios.net/demo_aria/index.php

Notice sur les interfaces riches

http://wiki.accede-web.com/notices/interfaces-riches-javascriptDokuWiki=cc0hmaqhm531r9e3fcjef7o5r3

WAI-ARIA

http://www.lesintegristes.net/2008/12/09/introduction-a-wai-aria-traduction/

L'ensemble de la spécification ARIA est disponible à l'adresse suivante :

http://www.w3.org/TR/wai-aria/

Wcag 2 en français

http://www.w3.org/Translations/WCAG20-fr/

Comprendre les wcag 2

http://www.w3.org/Translations/NOTE-UNDERSTANDING-WCAG20-fr/