Cet article fait partie de la série sur les ateliers Paris Web 2013.
Jean-Pierre Villain (@villainjp) est un des principaux rédacteurs du référentiel Accessiweb.
Son atelier proposait de rendre une petite application de messagerie totalement accessible en quelques étapes.
Le processus est le suivant : à chaque étape, le test d’utilisation de base de l’application était effectué, via la navigation au clavier, et le lecteur d’écran NVDA.
On considère comme fonctionnalités de base :
– écrire un message
– lire la liste des messages
– répondre à un message
– supprimer un message.
Le point de départ était vraiment le désert de l’accessibilité : une page constituée uniquement de div, aucune structure (paragraphes, titres, listes…), aucun lien ou bouton (les interactions s’effectuent en javascript).
Il est intéressant de voir alors à quel point l’utilisation du lecteur d’écran relève du parcours du combattant : l’utilisateur aura beau s’obstiner à chercher « quelque chose qui ressemble à écrire un message », cela ne donnera aucun résultat ni via la navigation, ni les éléments structurants, ni les boutons ou champs de formulaire, ni même la recherche en plein texte.
Ajouter une structure HTML de base rend déjà le plus gros de l’application accessible : il devient possible de naviguer dans les listes de titres, les paragraphes, et trouver le bouton qui lance la création de message.
Il s’agit ensuite d’ajouter de la structuration supplémentaire via les éléments HTML5 : les éléments sectionnants (section, article,…) ou regroupants (header, footer).
C’est l’occasion de rappeler que toute section devrait normalement avoir un titre hn, que nav concerne les navigations dans une liste de pages (pagination incluse), ou qu’un article est à envisager comme un bloc de contenu que l’on peut reprendre à l’extérieur, et pas forcément comme un article de journal.
La dernière étape, qui me semblait la plus intéressante mais qui n’a pu être très développée faute de temps, concerne l’ajout des attributs aria.
Prenons l’exemple de la fenêtre modale : on lui attribue un role= »dialogue » (ou alertdialog), aria-labelledby= »Nouveau gazouilli dialogue », et on gère le tabindex pour qu’elle prenne le focus lorsqu’elle apparait, et qu’après sa fermeture, le focus revienne là où on était.
On aborde aussi rapidement l’utilisation des liveregion, qui permettent au lecteur d’écran de vocaliser les changements qui se produisent dans une zone de la page, par exemple l’apparition d’un nouveau message dans la liste.
Il faudrait donc plonger encore un peu dans les différents attributs aria pour en faire un tour complet, mais l’essentiel était posé et montrait qu’une accessibilité basique est très facilement mise en place.
C’était également l’occasion de différencier 2 sortes de tests d’accessibilité :
– les tests de restitution doivent être effectués à toutes les étapes de développement de l’application, par l’intégrateur et/ou le développeur, avec les technologies concernées (clavier, lecteur d’écran,…)
– les tests utilisateurs sont des mises en situations avec des utilisateurs réels, mais ne peuvent être effectués que lorsque l’accessibilité est entièrement en place sur l’application.
A lire aussi :
Première participation aux ateliers Paris Web
Test unitaire ? Mock ? TDD ? Kezako ? (En finir avec les régressions)