ARIA : la première règle est de ne pas s'en servir

ARIA permet de décrire aux technologies d'assistance le rôle, l'état et les relations d'éléments d'interface que le langage natif ne couvre pas. C'est utile, et c'est dangereux : ARIA ne change rien au comportement réel du composant. Il ne fait que déclarer une promesse, qu'il faut ensuite tenir en code.

La première règle

Formulée par la spécification elle-même

Si un élément natif existe pour ce que vous voulez faire, utilisez-le. Un bouton natif est focalisable, activable au clavier et correctement annoncé, sans une ligne supplémentaire.

Un élément neutre transformé en bouton demande un rôle, un index de tabulation, un gestionnaire de clic et un gestionnaire de clavier — et échoue presque toujours sur l'un des quatre.

Les trois briques

Ce que chaque famille déclare
BriqueRôleExemple d'usage
RôleCe qu'est l'élémentUne barre de progression construite sur mesure
PropriétéUne caractéristique stableLe lien entre un champ et son texte d'aide
ÉtatUne caractéristique variableUn panneau déplié ou replié

Quand ARIA est réellement utile

Les erreurs les plus coûteuses

Usages fautifs et conséquence
ErreurConséquence
Déclarer un rôle sans implémenter le comportement clavier L'élément s'annonce comme un bouton mais ne répond pas — pire que rien
Redéclarer le rôle d'un élément natif Inutile, et source de divergence entre navigateurs
Écraser le nom visible par un nom accessible différent La reconnaissance vocale ne trouve plus la commande
Créer la région de statut au moment du message Rien n'est annoncé : la région doit préexister dans le document
Masquer aux technologies d'assistance un élément focalisable L'utilisateur atteint un élément qui n'est pas annoncé

Le cas des messages de statut

C'est l'usage d'ARIA le plus utile et le plus souvent raté. Trois conditions : la région existe dès le chargement de la page, elle est vide au départ, et le message y est inséré au moment voulu. Créer la région en même temps que le message ne produit aucune annonce.

Voir l'accessibilité des applications monopages, où ce point est central.

Comment vérifier

ARIA ne se teste pas en lisant le code : il se teste en écoutant. L'inspecteur d'accessibilité du navigateur montre le nom, le rôle et l'état calculés ; le lecteur d'écran dit ce qui est réellement restitué. Les deux sont nécessaires, et le second tranche. Voir tester au lecteur d'écran.

Poursuivre

Pour le composant où ARIA sert le plus, voyez les formulaires accessibles.