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

La documentation Notes on Using ARIA in HTML devrait être entre les mains de tout développeur soucieux d’implémenter ARIA. Illustrée d’exemples, elle permet de comprendre les bases fondamentales d’une utilisation raisonnée de l’API.

Cet article en trois parties détaille les cinq règles de base et l’utilisation spécifique de certaines propriétés en s’appuyant notamment sur leurs conséquences pour l’utilisateur.

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.

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 ?

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) ?

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.

Dans la seconde partie de ce kit de survie, nous aborderons les deux dernières règles, plus complexes et qui nécessitent de bien maîtriser les conséquences pour les utilisateurs.