Cet article fait partie de la série KiwiParty : le plein de vitamines web.
Accessibilité = universalité d’accès
Laura Kalbag (@laurakalbag) inaugure la journée avec une plénière sur l’accessibilité. Comme elle le dit à juste titre, on ne parle pas ici de fauteuils roulants ou d’aveugles, mais bien « d’universalité d’accès ». C’est-à-dire que toute personne puisse accéder au contenu d’un site, quelles que soient son contexte et ses capacités de vision, d’écoute, de déplacement, et de compréhension.
Peu importe que l’on soit « designer » ou « codeur » (ou les deux) : chaque personne travaillant sur le projet prend des décisions sur la façon de fonctionner et donc sur l’utilisabilité du produit final.
En dehors de l’empathie pure et simple, cela aura aussi des retombées économiques positives : chaque amélioration d’accessibilité est un pas de plus vers les utilisateurs, une facilitation d’usage et donc de conversion.
Sur les sites internet, lorsqu’on parle d’accessibilité, on pense souvent en premier aux lecteurs d’écrans, pour les aveugles. Or, qui ne s’est jamais retrouvé face à un texte trop petit ou trop peu contrasté, qui force à plisser les yeux ? Pas besoin d’être malvoyant pour que la lisibilité d’un texte joue une place importante dans le confort d’utilisation.
C’est donc sur ces points basiques mais essentiels que Laura va appuyer : taille du texte, hiérarchisation visuelle du contenu, contrastes, rédaction des intitulés, animations, sous-titres, messages d’erreurs de formulaires… Autant d’éléments qui vont impacter la compréhension et donc les actions des utilisateurs.
Laura émaille sa présentation d’exemples concrets sur des sites actuels, ainsi que des recommandations et outils disponibles pour tester ses sites.
Un des détails qui m’a marquée, c’est la démonstration de vision de son site avec les défauts les plus répandus dans la vision des couleurs : ils sont peu connus et pourtant, si l’on compare les pourcentages, ils mériteraient autant d’efforts d’optimisation que ceux que l’on fait actuellement pour les utilisateurs de navigateurs obsolètes…
Même si, au final, la présentation se focalisait plutôt sur les aspects basiques de l’accessibilité, cela fait toujours du bien de se les entendre rappeler, de manière simple et concrète.
On aurait même envie d’en faire une petite checklist de projet, à consulter régulièrement pour voir si on reste sur la bonne voie.
Pour le coup, c’était aussi une belle expérience d’accessibilité : pour la seule conférence anglophone de la journée, Laura a pris un soin particulier à présenter des slides bilingues (traduites par Stéphanie Walter), permettant ainsi à tous de suivre, quel que soit leur niveau d’anglais.
Elle en a fait d’ailleurs un retour d’expérience sur son blog.
Entrons dans le détail : ARIA
C’est l’après-midi que nous avons abordé un point beaucoup plus technique de l’accessibilité : Stéphane Deschamps (@notabene) avait le difficile horaire de la digestion pour la 3ème plénière de la journée, sur ARIA (Accessible Rich Internet Applications).
ARIA est une spécification qui indique comment rendre accessible les « applications internet riches », en d’autres termes, principalement les sites fonctionnant avec du Javascript (on parle donc de l’écrasante majorité des sites). Cette spécification est née après l’arrivée d’AJAX (en simplifiant : chargement de contenus externes via Javascript), et a pris en quelques sorte le relais de WCAG, qui se chargeait déjà de définir comment rendre accessible les pages HTML, les PDFs, les fichiers Flash…
On parle d’ »applications » ou de « sites applicatifs » dès lors que les interactions induisent un changement du contenu sans que la page se recharge : onglets, accordéons, déploiement de menu au survol, on est déjà dans un fonctionnement « applicatif », et c’est pour cela que tous les sites sont concernés.
Ce contenu qui apparait ou est modifié n’est pas présent tel quel initialement dans la structure HTML. Pour un utilisateur « lambda », cela n’est pas gênant dans le sens où il va visuellement se rendre compte de ces changements. Mais tout le monde n’est pas lambda au niveau visuel : les personnes mal- ou non-voyantes peuvent utiliser des lecteurs d’écrans, logiciels qui permettent de naviguer via des descriptions auditives des éléments.
C’est principalement pour ces lecteurs d’écrans que les éléments ARIA vont jouer un rôle : indiquer les liens entre les contenus (ex : onglet et son contenu, description d’un champ de formulaire), où le contenu change (ex : message d’erreur dans un formulaire, ouverture de popin…), et surtout permettre de naviguer de manière claire entre ces contenus.
On remarquera donc que nous sommes ici plutôt dans une « niche d’accessibilité », à la différence de la conférence de Laura du matin. Mais en même temps, se poser des questions sur la logique de fonctionnement et le lien entre les éléments incline à simplifier et clarifier les choses, ce qui ne peut qu’être bénéfique pour l’ensemble des utilisateurs. Sans oublier que la navigation avec les lecteurs d’écran se fait au clavier, et si elle est facilitée, elle l’est pour tous ceux qui naviguent au clavier.
Stéphane nous a donc présenté les attributs ARIA les plus utiles et utilisés.
La mise en application est plutôt simple, puisqu’il suffit d’ajouter les bons attributs aux bons éléments. Mais il faut également que les comportements (régis par Javascript) obéissent aux spécifications : que le bon élément prenne le focus au bon moment, naviguer dans le menu avec les mêmes touches du clavier que pour un menu de logiciel… C’est là que se niche le plus gros du travail, et cela se passe plutôt du côté du Javascript.
Au final, cela donne envie d’implémenter au plus vite les attributs les plus simples, mais rebute quant aux fonctionnements plus complexes (menus, popins, …).
C’était dans tous les cas une présentation très intéressante et enrichissante, et l’humour de Stéphane permettait de garder une fraicheur pour ce sujet plutôt technique.