Kit de survie du développeur ARIA (1 sur 3)

Dans cette première partie, nous aborderons les trois premières règles :

• utiliser des éléments HTML natif ;
• ne pas modifier la sémantique d’un élément HTML ;
• rendre les composants utilisables au clavier.

Utiliser ARIA à bon escient

Si vous pouvez utiliser un élément ou un attribut HTML natif qui propose les propriétés et les comportements voulus au lieu de surcharger un élément HTML avec des propriétés ARIA pour le rendre accessible, faites le. (source : First rule of ARIA use)

Cette première règle est une recommandation de bon sens. ARIA contient des équivalences de rôle et de comportement pour à peu près tous les éléments HTML, ce qui laisse la possibilité d’utiliser un élément quelconque, par exemple un div et de le « transformer » en autre chose, par exemple un bouton.

Mais utiliser un élément natif peut poser problème, par exemple :

• si vous ne pouvez pas le styler selon vos besoins (par exemple, l’élément details ou le type range) ;
• s’il n’a pas un support parfaitement homogène (par exemple le type date) ;
• s’il n’est pas encore supporté ;
• si vous ne pouvez pas modifier le code HTML employé.

Dans ces situations, le recours à un équivalent développé ou surchargé avec JavaScript et ARIA se justifie pleinement.

Théoriquement, si le développeur et le navigateur font correctement le boulot, la sémantique et les comportements définis pour l’élément devraient être mis à disposition des technologies d’assistance.

Conséquences pour l’utilisateur

Si le support d’ARIA s’est considérablement amélioré pour les lecteurs d’écran, il peut subsister des technologies d’assistances avec des supports limités ou défaillants.

Il peut également y avoir aussi des conséquences plus subtiles qui justifient de préférer systématiquement l’utilisation d’éléments natifs.

En effet, même si la plupart des rôles et des propriétés sont correctement transmis, certains lecteurs d’écran modifient légèrement les restitutions. C’est le cas, par exemple, du rôle checkbox avec NVDA dont la restitution n’est pas tout à fait identique avec ARIA. Si ces différences n’ont pas de conséquences graves quant à l’utilisation des composants, leur multiplication ou la co-existence dans un même contexte d’éléments similaires, les uns natifs, les autres développés avec ARIA, peut être relativement perturbant pour l’utilisateur.

La deuxième conséquence réside dans le fait que certains raccourcis claviers peuvent cesser de fonctionner avec des éléments surchargés avec ARIA, comme la navigation par titre ou par liste par exemple.

L’ensemble de ces problèmes potentiels devraient vous conduire à respecter cette règle autant que possible.

Que dit le RGAA ?

Le RGAA n’implémente pas cette règle qui est particulièrement contextuelle et laisse aux développeurs le soin de choisir la meilleure approche, notamment dans le cas où ARIA est utilisé comme méthode de correction d’un code impossible à modifier.

Exemples

La plupart des éléments natifs supportés par l’ensemble des navigateurs ne posent pas de problèmes notables ; le recours à des éléments JavaScript/ARIA ne peut que vous compliquer la tâche !

En revanche, certains nouveaux éléments HTML 5 et plusieurs types de champs de formulaire se montrent rétifs dès lors que l’on souhaite les personnaliser finement avec CSS. C’est le cas par exemple de :

1. input de type range
2. input de type file
3. input de type date
4. input de type number
5. input de type meter
6. select
7. élément details

Dans ce cas, le recours à des composants développés avec JavaScript/ARIA est tout à fait justifié.

Ne pas changer la sémantique native d’un élément HTML

Ne changez pas la sémantique native d’un élément sauf si vous avez réellement besoin de le faire. (source : Second rule of ARIA use)

Cette règle est complexe car l’utilisation d’ARIA se base principalement sur ce que l’on appelle des surcharges de rôle et consiste donc à modifier la sémantique native d’un élément HTML.

Il y a de nombreuses situations dans lesquelles un développeur doit le faire, par exemple :

• lorsqu’ARIA est utilisé comme méthode de correction sur un code existant qu’on ne peut pas modifier autrement que par JavaScript ;
• lorsqu’on va ajouter une couche ARIA sur un ou des éléments dont la sémantique sera utilisée comme méthode de fallback. C’est typiquement le cas d’un calendrier de saisie basé sur un tableau de donnée transformé avec ARIA en simple grille ou d’un système d’onglets basé sur une liste ul surchargée avec un rôle tablist.

Conséquences pour l’utilisateur

Pour bien appréhender cette règle, il est nécessaire de comprendre les conséquences pour l’utilisateur.

Lorsque vous modifiez la sémantique d’un élément HTML, vous modifiez son rôle dans l’arborescence accessible (accessible tree) qui est utilisée par les technologies d’assistance pour récupérer et interagir avec le contenu.

Transformer un paragraphe en titre n’aura que peu de conséquences et vous pouvez le faire, mais transformer un titre en bouton aura une conséquence majeure : la fonctionnalité qui permet à l’utilisateur de naviguer de titre en titre ou d’afficher la liste des titres peut devenir inefficace.

De même, s’appuyer sur une liste HTML surchargée par ARIA peut annuler la navigation rapide dans les éléments de liste proposés à l’utilisateur.

Vous devriez vous alerter à chaque fois que vous transformez avec ARIA un élément HTML interactif (toujours !) ou un élément HTML (titre, liste, tableau…) sur lequel une fonctionnalité de navigation est proposée.

Une ressource indispensable

La spécification ARIA fournit une table de restriction de rôle (Document conformance requirements for use of ARIA attributes in HTML) qui permet une première approche de cette problématique de surcharge de rôle.

À noter que les moteurs de validation de code devraient utiliser cette table de correspondance pour remonter les erreurs d’implémentation d’ARIA.

Que dit le RGAA ?

Le RGAA n’implémente pas la règle elle-même mais exige que l’utilisation d’ARIA soit conforme à cette table de restriction : Test 7.1.4 : Chaque modification du rôle natif d’un élément HTML respecte-t-elle les règles et préconisations indiquées dans la spécification HTML5 et les notes techniques associées ?

Exemple

Nous avons vu dernièrement ceci :

<h3 role="button" tabindex="0" aria-expanded="false">Que faire en cas de perte ?</h3>

Il s’agissait d’une FAQ et l’intention était bonne : titrer les questions et s’en servir pour déplier la réponse. Mais la surcharge appliquée a pour conséquence de faire disparaitre la sémantique du titre de contenu que l’on a transformé, avec ARIA, en bouton.

La correction est très simple :

<h3><button aria-expanded="false">Que faire en cas de perte ?</button></h3>

Rendre les composants interactifs utilisables au clavier

Tous les contrôles interactifs ARIA doivent être opérables avec le clavier. (source : Third rule of ARIA use)

Trop souvent ignorée, cette règle, est pourtant une simple règle de bon sens. Elle rappelle un principe WCAG fondamental qui stipule que chaque interaction utilisateur doit être indépendante du périphérique utilisé.

Conséquences sur l’utilisateur

Tous les utilisateurs vont être gravement impactés par le manque d’accessibilité au clavier ; les aveugles bien sûr mais surtout les handicapés moteurs.

À noter : la règle est incomplète. Un élément interactif doit être utilisable au clavier, mais aussi à la souris qui peut être le mode d’interaction exclusif de certains utilisateurs.

Que dit le RGAA ?

Le RGAA réserve un critère entier à cette problématique : Critère 7.3 [A] Chaque script est-il contrôlable par le clavier et la souris (hors cas particuliers) ?

Exemple

Même si la situation tend à s’améliorer du fait de l’utilisation de bibliothèques de composants prêts à l’emploi, nous voyons encore régulièrement ce genre d’implémentation :

<div role="button" aria-expanded="false"><span class="sr">Menu</span></div>

Par exemple, pour implémenter un burger menu. Un div ne pouvant pas, par défaut, recevoir le focus du clavier, il sera tout bonnement inutilisable par tous ceux qui ne peuvent utiliser que le clavier pour naviguer et interagir.

La correction fait intervenir le vieil attribut HTML tabindex, tombé en désuétude et récupéré par ARIA, pour rendre un élément atteignable au clavier notamment. Il suffit d’utiliser tabindex="0" pour rendre immédiatement n’importe quel élément HTML utilisable au clavier :

<div role="button" aria-expanded="false" tabindex="0"><span class="sr">Menu</span></div>

Conclusion

Si ces trois premières règles sont importantes, nous avons vu que les deux premières peuvent poser quelques problèmes d’application qui peuvent justifier de les adapter au contexte.

En revanche, la troisième règle est incontournable et ne devrait jamais faire l’objet d’exception.

Ne manquez pas la suite de cette série :

1. la deuxième partie aborde les deux dernières règles, qui sont plus complexes et nécessitent de bien maîtriser les conséquences pour les utilisateurs : Kit de survie ARIA, 2 sur 3 ;
2. la troisième et dernière partie précise d’autres subtilités à l’utilisation d’ARIA : Kit de survie ARIA, 3 sur 3.