Avant d’aborder les règles d’ARIA, rappelons ce qu’est ARIA. ARIA signifie « applications Internet riches et accessibles » (Accessible Rich Internet Applications) et contribue à rendre les contenus ou applications Web plus accessibles aux personnes en situation de handicap. Il est particulièrement utile pour les contenus dynamiques et les contrôles avancés d’interface utilisateur développés avec Ajax, HTML, JavaScript et les technologies associées. Grâce à WAI-ARIA, les développeurs peuvent rendre les applications Web avancées accessibles et utilisables par les personnes en situation de handicap.
Même si ARIA a été créé il y a plusieurs années, certains développeurs continuent de l’utiliser à mauvais escient en raison d’un manque de connaissances approfondies sur le sujet. Une mauvaise utilisation d’ARIA rend l’expérience bien moins accessible que lorsque les développeurs ne l’utilisent pas du tout. C’est pourquoi on dit souvent : « Mieux vaut pas d’ARIA qu’un mauvais ARIA. » Cela dit, les développeurs devraient s'efforcer de comprendre et de respecter les règles d'ARIA, afin de contribuer à offrir une expérience plus accessible aux personnes en situation de handicap. Examinons ci-dessous les règles d'ARIA plus en détail.
Règle n° 1 : n'utilisez pas ARIA, privilégiez plutôt le HTML natif
Avant d'utiliser ARIA, privilégiez d'abord les éléments ou attributs HTML natifs. Si la sémantique que vous recherchez n'est pas disponible en HTML, utilisez alors ARIA.
Let me explain this with the example. To construct the checkbox on a web page, use HTML checkbox (<input type=”checkbox”>) rather than ARIA checkbox (<div role=”checkbox”>…</div>). The reason for this is that HTML checkbox conveys the semantics to people using assistive technology (such as screen readers) without any additional effort because it is already mapped to the accessibility APIs.
La question est maintenant de savoir quand utiliser ARIA. Il existe plusieurs cas de figure dans lesquels nous pourrions être amenés à utiliser ARIA, par exemple :
- Lorsque le site web n'a pas été conçu dès le départ pour répondre aux critères d'accessibilité et qu'il fait l'objet d'une mise à niveau à cet effet, il est préférable d'utiliser ARIA afin de gagner du temps, d'économiser des efforts et de réduire les coûts.
- S'il n'est pas possible d'appliquer un style à l'élément natif (dans certains cas exceptionnels), il est alors possible de créer un élément personnalisé, de lui appliquer un style et de lui attribuer une sémantique à l'aide d'ARIA.
- Si la sémantique requise n'existe pas dans le langage hôte (HTML 5.x), utilisez alors ARIA pour la transmettre. Par exemple, s'il est nécessaire d'utiliser ARIA pour exprimer la sémantique d'arborescence, car il n'existe pas d'élément ou d'attribut HTML équivalent.
- Lorsque certains éléments HTML 5.x ne sont pas pris en charge par l'agent utilisateur, utilisez ARIA.
Règle n° 2 : Ne modifiez pas la sémantique native, sauf si vous y êtes vraiment, vraiment obligé
Comme nous l'avons déjà vu, la plupart des éléments ou attributs HTML véhiculent une signification particulière. Nous ne sommes pas censés modifier cette signification native, sauf si cela s'avère vraiment indispensable. Prenons par exemple le cas où un développeur souhaiterait créer un titre qui ferait office d'onglet :
Ne faites pas cela :
<h2 role=tab>heading tab</h2>
Suivez plutôt cette bonne pratique :
<div role=tab><h2>heading tab</h2></div>
Règle n° 3 : tous les contrôles ARIA interactifs doivent pouvoir être utilisés à l'aide d'un clavier
L'ajout des rôles ARIA apporterait certes une sémantique au contrôle personnalisé, mais cela ne permettrait en aucun cas au contrôle de fonctionner comme prévu avec le clavier. Il faut garder à l'esprit qu'ARIA n'a rien à voir avec les fonctionnalités du clavier, mais qu'il fournit plutôt la sémantique aux API d'accessibilité.
That being said it is the developer’s responsibility to make the custom control accessible with the keyboard by using some scripting. For example, if we construct the custom button(<div role=”button”>) then we need to make sure that it receives the focus and the user is able to activate the associated functionality by using both enter and space keys. To put it in simpler terms, the custom button should work with the keyboard as to how a native button works.
Règle n° 4 : n'utilisez pas « role="presentation" » ni « aria-hidden="true" » sur un élément pouvant recevoir le focus
L'attribut `role="presentation"` ou `role="none"` sert à invalider la sémantique de l'arborescence d'accessibilité ; un élément dont l'attribut `role` est défini sur « none » n'est pas censé être interactif de quelque manière que ce soit. De même, l'attribut `aria-hidden` a pour but de masquer le contenu ou l'élément aux API d'accessibilité ; un élément dont l'attribut `aria-hidden` est défini sur « true » n'est pas censé être interactif de quelque manière que ce soit. La définition de l’un ou l’autre de ces attributs sur des éléments visibles et pouvant recevoir le focus a pour conséquence que certains utilisateurs ne parviennent à mettre le focus sur rien.
Ne faites pas cela :
<button role=presentation>press me</button>
Ne faites pas cela non plus :
<button aria-hidden="true">press me</button>
Suivez plutôt cette bonne pratique :
<button role="presentation" tabindex="-1">Don't Click Me</button> <button style="display: none;">Don't Click Me</button>
Règle n° 5 : Tous les éléments interactifs doivent avoir un nom accessible
Tous les éléments interactifs (tels que les liens, les boutons, les champs de texte, les listes déroulantes, les boutons radio, les cases à cocher, etc.) d'une page Web doivent disposer d'un nom accessible. Sans ce nom accessible, les technologies d'assistance ne peuvent pas comprendre à quoi sert le contrôle. Il existe différentes techniques pour attribuer ce nom accessible, et celles-ci varient d'un contrôle à l'autre. Voyons quelques-unes d'entre elles.
-
- Liens et boutons HTML : quel que soit le texte du lien ou la valeur du bouton que nous fournissons, celui-ci devient le nom d'accessibilité
- Champs de saisie : pour fournir un nom accessible, les contrôles de formulaire doivent être associés à leur libellé visible, de manière implicite ou explicite.
- Widgets personnalisés : afin de fournir un nom accessible aux widgets personnalisés, les auteurs peuvent utiliser soit la technique ARIA-label, soit la technique ARIA-labelledby.
Par exemple :
Le champ de saisie ci-dessous comporte une étiquette visible, mais ne dispose pas de nom accessible :
First name<input type=”text”>
Le champ de saisie ci-dessous dispose à la fois d'une étiquette visible et d'un nom d'accessibilité. Le ou les noms d'accessibilité établissent le lien avec l'identifiant :
<label for=”fname”>First name</label> <input type=”text” id=”fname”>
En résumé
Lorsque les auteurs utilisent ARIA pour améliorer l'accessibilité des contrôles et des widgets, ils doivent respecter les règles d'ARIA. Le non-respect de ces règles lors de l'utilisation d'ARIA peut entraîner de graves problèmes d'accessibilité. C'est pourquoi nous recommandons vivement aux auteurs de respecter les règles d'ARIA lorsqu'ils l'utilisent sur n'importe quel contrôle, afin de rendre le Web plus accessible à tous les utilisateurs, y compris les personnes en situation de handicap.
Références : Utilisation d'ARIA – W3C
