Gestion de la navigation clavier avec ARIA

  • Composant

Introduction

La gestion des interactions clavier est un des piliers de la recommandation ARIA (Accessible Rich Internet Application) du W3C/WAI. Le but est de standardiser la navigation clavier dans les composants d’interface d’une page.
Globalement, la navigation clavier entre les composants d’interface (widget) se fait « classiquement » en tabulant. En revanche, à l’intérieur d’un widget, la navigation clavier va être gérée finement en respectant les design patterns qui sont partie intégrante de la recommandation ARIA.

Design patterns

TabIndex

En HTML5, ARIA étend l’attribut tabindex à tous les éléments visibles et autorise l’utilisation :

  • d’une valeur négative (-1) pour les éléments ne devant pas être accessibles à la navigation au clavier (pas de prise de focus), mais pouvant recevoir le focus par programmation.
  • d’une valeur à 0, il permet à l’élément de recevoir le focus comme tout élément nativement focusable.

Design Patterns

En ARIA, tout part d’un besoin d’homogénéiser les interactions clavier en demandant que la navigation clavier soit identique à une application desktop (client lourd). Il faut donc pour chaque widget implémenter l’interaction clavier selon son type (accordéon, barre de navigation, d’outils, potentiomètre…) en se reportant aux design patterns (https://www.w3.org/WAI/ARIA/apg/patterns/). En plus de la navigation clavier à implémenter les design patterns donnent aussi la manière de mettre en œuvre les propriétés et états ARIA pour rendre accessible son widget toujours en fonction de son type.

Tests utilisateurs

Pour valider l’utilisabilité pour les personnes en situation de handicap et la robustesse en fonction des agents utilisateurs (aides techniques et navigateurs), il faut faire tester par des utilisateurs de lecteurs d’écran, à minima (c’est la population la plus impactée par des problèmes d’implémentation des design patterns).

Dans tous les cas, il faut tester les développements sur les environnements cibles (couple navigateurs/aides techniques). C’est un gros travail absolument nécessaire pour les cas complexes car sur un site ou une application internet classique, il faut, à minima, tester avec Safari/VoiceOver, Jaws/Internet Explorer et Firefox/NVDA.

Ces tests utilisateurs vont vous permettre de valider que votre widget est ergonomique donc utilisable pour ce type d’utilisateurs et par extension pour l’ensemble des utilisateurs bénéficiant de l’accessibilité (pour rappel, 15% de la population totale).