Pourquoi et comment rendre une application Web accessible ?

Ce tutoriel théorique éveille l'attention des développeurs et webmasters en mettant l'accent sur une préoccupation trop souvent ignorée : rendre un site Web accessible à tous, notamment aux mal-voyants. Effectivement, ces derniers ont à leur disposition une série d'outils leur permettant de profiter du Net. Pour peu que les concepteurs de sites respectent certaines manières de faire... Cet article est lié à un prochain article centré sur la partie pratique.

Pour réagir à ce tutoriel, un espace de dialogue vous est proposé sur le forum : Commentez Donner une note à l'article (5)

Article lu   fois.

Les deux auteurs

Site personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Accessibilité ? Pourquoi faire ?

De nos jours, le Web est de plus en plus présent dans la vie quotidienne de chaque individu. Il tend à s'imposer comme étant le seul moyen incontournable d'accès à l'information dans de nombreux domaines.

Il est donc important que tout le monde puisse accéder aux informations, tant à titre personnel que professionnel.

L'accessibilité est l'affaire de tous, que les personnes soient atteintes d'un handicap ou pas !

L'accessibilité fait partie intégrante d'une démarche de recherche ergonomique, elle apporte du confort à tous !

I-A. À qui s'adresse ce document ?

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 !

II. Les auteurs

  • Fabrice LUNEAU : « Passionné par le développement informatique depuis l'âge de dix ans, ce n'est qu'après quelques années dans la comptabilité que j'ai repris des études en BTS d'informatique dont j'ai obtenu le diplôme. Cependant, je n'ai pas exercé tout de suite dans ce domaine. Après une longue maladie en 2010 qui m'a rendu non-voyant, j'ai dû changer de voie professionnelle. La comptabilité ne m'était plus accessible. J'ai alors suivi des formations informatiques, dont une au CRM de Mulhouse. Naturellement, je m'intéresse à l'accessibilité des applications et au métier de développeur pour les déficients visuels dont je connais bien l'univers, car j'étais trésorier bénévole dans une association de mal-voyants et non-voyants.
  • Valérie HACCART : « Amblyope depuis l'âge de treize ans, analyste programmeur (2/3 de la maîtrise d'informatique - 1985) suite à la découverte des lecteurs d'écran, j'ai fait une formation de développeur d'applications. L'accessibilité est devenue tout naturellement mon cheval de bataille parce que, si une application métier n'est pas accessible aux lecteurs d'écran, alors un déficient visuel ne peut pas travailler ! Maintenant, je suis auto-entrepreneuse et je fais de la sensibilisation à la déficience visuelle avec des lunettes simulant les diverses pathologies et je sensibilise les informaticiens afin d'attirer leur attention à l'accessibilité numérique et aux règles de codage pour rendre un site Web et les applications lisibles par tous !

III. Deux types de problèmes pouvant être rencontrés

III-A. Problèmes humains

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.

III-B. Problèmes techniques

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

IV. Comment accéder au monde numérique, quand on n'y voit pas ?

Comment lire, quand on n'y voit pas ? Merci Monsieur Louis BRAILLE !

IV-A. Ouvrez les yeux et voyons ensemble !

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 !

IV-B. Qu'est-ce qu'un lecteur d'écran ?

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.

IV-C. Utilité du lecteur d'écran

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.

IV-D. Comment naviguer sur la toile, quand on n'y voit pas ?

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.

V. Le Web pour tous

L'accessibilité du web est définie par des normes techniques établies par le groupe de travail : Web Accessibility Initiative (abréviation WAI) du World Wide Web Consortium (abréviation W3C).

Image non disponible

L'accessibilité nécessite un traitement tout au long du cycle de vie d'une application métier ou d'un site Web, par l'ensemble de ses acteurs, via des méthodes d'applications, des référentiels métiers et une démarche de suivi.

Bien qu'elle soit une composante et un levier d'amélioration de leur qualité globale, le degré d'accessibilité effectif des sites Web reste encore très faible.

VI. Champ de l'accessibilité

L'accessibilité du Web est définie par la WAI du W3C comme l'une des composantes de l'accessibilité numérique.

Citation provenant de http://www.w3.org/WAI/intro/accessibility.php :

« L'accessibilité du Web signifie que les personnes handicapées peuvent l'utiliser. Plus spécifiquement, elle signifie que ces gens peuvent percevoir, comprendre, naviguer, interagir avec le Web, et y contribuer. L'accessibilité du Web bénéficie également à d'autres, notamment les personnes âgées ayant des capacités diminuées dues au vieillissement. ».

C'est un droit universel, selon l'article 9 de la Convention relative aux droits des personnes handicapées, adoptée en 2006 par l'Organisation des Nations unies.

Même dans cette acception étroitement liée au handicap, l'accessibilité vise une très grande variété de cas utilisateurs.

L'un des enjeux de la démarche d'accessibilité Web est de s'extraire des contraintes spécifiques à ces multiples contextes utilisateurs, et ainsi atteindre un niveau d'abstraction suffisant pour pouvoir se doter d'outils normatifs et de recommandations utilisables par l'industrie :

  • fabricants de navigateurs Web ;
  • créateurs de contenus ;
  • etc.

VII. Effets induits de l'accessibilité des contenus

Au-delà des bénéfices atteints pour les utilisateurs handicapés, l'accessibilité Web profite plus largement à tous les utilisateurs et acteurs, notamment en termes d'utilisabilité, de maîtrise de la production des contenus, de retours sur investissement.

VII-A. Accessibilité des contenus ou accessibilité universelle ?

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.

VIII. Recommandations pour le contenu

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 de deux améliorations :

  1. Du format HTML ;
  2. Des feuilles de style en cascade (CSS).

Enfin, d'autres recommandations en chantier sont consacrées notamment :

  • aux interfaces riches ;
  • à XML.

VIII-A. Directives

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.

IX. Classement des niveaux d'accessibilité WCAG 2

IX-A. Les trois niveaux de conformité

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

NIVEAU

OBJECTIF

FAISABILITÉ

EXEMPLE

A

Atteindre un niveau d'accessibilité minimal

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

Atteindre un niveau supérieur d'accessibilité

Les textes de petite taille ont un ratio de contraste au moins égal à 7

X. Comment tester son application ou son site ? Comment tester son site ?

Un certain nombre des points de contrôle des WCAG étant automatisables, de nombreux outils ont été mis au point afin de faciliter le développement, ou la validation de sites Web accessibles.

Les outils de vérification sont le plus souvent des services en ligne. Certains fournissent un retour sous forme d'icônes ajoutées à la page évaluée (par exemple, WAVE ).

Ou d'autre, qui fournissent un rapport textuel, comme OCAWA, créé par URBILOG propriété de France Télécom.

X-A. Tests « machines »

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

X-B. Tests utilisateurs

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.

X-C. Testes utilisateurs avec un navigateur textuel

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.

XI. Problématique technique

Les lecteurs d'écran vocalisent tous les éléments textuels et focalisables, or un certain nombre d'éléments ne disposent pas par défaut de texte, comme les images et les champs de formulaires.

De plus le texte fournit doit avoir du sens dans le contexte de la page et hors du contexte. Car la navigation sur une page n'est pas forcément linéaire. Elle peut être interrompue et lors de la reprise l'information fournie peu être incompréhensible hors de son contexte, si l'on arrive directement sur un élément. Par exemple un lien intitulé « ici », qui est précédé du texte « pour télécharger le logiciel cliquer ici », n'a pas de sens si l'on arrive directement dessus avec la touche tabulation. Il faut réunir les deux informations.

Il faut aussi ne pas oublier que l'internaute non-voyant n'utilise pas de souris, et donc des éléments non focalisables au clavier seront inaccessibles.

Par exemple, une image simulant un bouton de formulaire, sera cliquable seulement à la souris et ne sera donc pas accessible !

Les solutions requièrent peu de technique. Elles reposent en grande partie sur la mise à disposition d'un texte accessible et à sa mise en valeur par le code HTML.

XII. Pourquoi créer un site totalement accessible ?

En tant que mal-voyante je pense que l'exclusion professionnelle par la fracture numérique est inacceptable !

Évitons la fracture numérique et que la France soit une république numérique pour tous.

XIII. Résolution des problèmes

C'est dans le but de lever ces éventuelles difficultés que le W3C propose une spécification techniquou mieux encore : e nommée ARIA : « Accessible Rich Internet Application ».

XIII-A. Qu'est-ce qu'ARIA ?

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.

XIII-B. Quand et comment utiliser ARIA ?

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

Ne modifiez pas la sémantique native des éléments (sauf à de très rares exceptions).

  • Contraintes graphiques.
  • Pas d'équivalent en HTML.
  • Existe en HTML5, mais pas implémenté ou pas accessible.

Rajouter un rôle ARIA modifie la sémantique native de l'élément mais pas ses propriétés.

Valeur

Utilisation

Unique

HTML

application

Région ne fonctionnant que comme une application Web

   

Banner

En général, première région de la page, avec du contenu générique propre au site (son nom, le logo…)

Oui

page header

complementary

Région secondaire du contenu principal ayant son propre rôle sémantique

 

<aside>

contentinfo

Région contenant des information sur la page ou le site (les mentions légales, les droits d'auteur…)

Oui

page footer

Form

Région de formulaire

 

<form>

Main

Région du contenu principal de la page

Oui

<main>

navigation

Région constituée de groupe de liens de navigation inter ou intra-page

 

<nav>

Search

Région de formulaire de recherche et les éléments en relation

   

XIII-C. Les repères de ARIA : meilleures pratiques

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

XIII-D. Les couples navigateur et lecteur d'écran

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.

XIII-E. Action du JavaScript sur les états

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

XIII-F. Bibliothèque JavaScript et support ARIA

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.

XIII-G. Webographie pour ARIA

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/

XIV. Conclusion et remerciements

Nous tenons à remercier jacques-jean pour sa relecture orthographique et Malick SECK pour la mise au gabarit.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+