J’avais annoncé une série de billets suite à celui sur les valeurs du développeur. Vous pouvez les retrouver sur la page dédiée au Numérique Responsable. Voici celui sur l’accessibilité.

Valeurs épisode 2 : accessibilité

Problématique

La prise de conscience pour l’accessibilité se fera principalement sur les axes suivants :

  • bien comprendre ce qui peut entraver l’utilisation du web par un utilisateur. Voici quelques mises en situation,
  • prendre conscience des personnes concernées par ces handicaps. Microsoft propose un guide très bien fait sur l’inclusive design.
    En très résumé, il s’agit de revoir notre perception de l’accessibilité et, par extension, du handicap. Le but de l’accessibilité est de rendre un outil utilisable par tous (ce qui est un peu la mission première du développeur/designer/concepteur/etc). On oublie trop souvent les handicaps temporaires ou situationnels. Voici quelques exemples pour resituer :
  • utiliser un smartphone avec un bras dans le plâtre ou dans un environnement trop lumineux
  • s’appuyer sur de la reconnaissance vocale lorsqu’on a une défaut d’élocution ou un fort accent
  • naviguer sur un site web lorsqu’on a oublié sa souris ou qu’elle ne fonctionne plus

La liste est longue mais l’idée est de comprendre que l’accessibilité agit pour le bénéfice de tous les utilisateurs et permet donc de toucher un public (ou une clientèle) plus large.

En plus, l’accessibilité est inscrite dans les réglementations française et européenne. Pour autant, la grande majorité des sites internet présentent des problèmes d’accessibilité.

Pour finir, voici quelques vérités à garder à l’esprit.

Diagnostic

Les outils sont nombreux, certains sont même inclus nativement dans Firefox (F12 -> Accessibility) et Chrome (F12 -> Audits -> cocher la case “Accessibility”).

Comme souvent, il est illusoire d’espérer trouver un outil qui fasse tout automatiquement. Voici donc quelques exemples de procédures utilisées pour tester l’accessibilité d’un site :

  • https://daverupert.com/2018/07/assistive-technologies-i-test-with/
  • https://www.a11ywithlindsey.com/blog/web-accessibility-testing-process
  • https://benrobertson.io/accessibility/how-to-run-quick-accessibility-audit Partant de là, c’est en pratiquant que vous construirez votre propre procédure (et je vous invite alors à la partager à votre tour).

Mise en place

Pour partir sur de bonnes bases, Udacity propose une formation très bien conçue sur ce sujet.
Les ressources sur le sujet ne manquent pas et il est rapide d’acquérir suffisamment de bagage pour dégager les actions à prioriser. Voici déjà quelques pistes pour commencer :

Pour ceux qui préfèrent une bonne checklist en français, Opquast est (comme souvent) le bon endroit pour commencer : premier pas vers WCAG

Et, en bonus, la newsletter qui va bien pour découvrir le sujet aussi bien que se tenir au courant.

Actions prioritaires

Commençons par une fiche résumant l’essentiel.
Voici quelques notions qui sont à mon avis à regarder en priorité (et que vous retrouverez dans le cours Udacity indiqué plus haut) :

  • Alt, sous-titres: il est important de prévoir des alternatives (le plus souvent textuelles) aux contenus visuels ou audio. Et s’il était encore besoin de vous rappeler que l’accessibilité ne touche pas que les personnes en situation de handicap, pensez aux contenus sous-titrés qu’on retrouve un peu partout pour les séries et les films.
  • ARIA
  • Commencez par utiliser du HTML sémantique, il n’en sera que plus propre (et de même pour votre CSS). Et gardez toujours à l’esprit que HTML propose bien plus de fonctionnalités que ce qu’on connaît.

Bénéfices attendus

Un site plus accessible le sera aussi pour les robots, ce qui améliorera notamment votre référencement naturel.
Enfin, on ne le dira jamais assez, améliorer l’accessibilité de votre site revient à améliorer l’expérience de l’ensemble de vos utilisateurs.

Réglementation française

Depuis septembre 2019, les choses bougent autour de l’accessibilité en France. Voici les principaux points à retenir :

  • l’obligation d’accessibilité des plateformes numériques, jusque-là réservée aux acteurs publics, s’étend désormais aux acteurs privés dont le CA annuel dépasse 250 millions d’euros.
  • pour tous les acteurs concernés, une déclaration d’accessibilité recensant les conformités et non-conformités au référentiel devra ête publiée sur le site. En cas de non-conformité, des sanctions sont possibles (2000 ou 20000€, selon les cas).

Le référentiel mis à jour est disponible ici.
Il recense les différents critères ainsi que les tests et conditions de tests afin de mener un audit complet. D’ici fin 2019, des ressources seront ajoutées afin de faciliter les démarches d’audit et de mise en conformité. De même, une liste des critères non-obligatoires sera également publiée afin d’aller encore plus loin dans cette démarche.
Plus que jamais, c’est un bon point de départ pour comprendre les critères de conformité liés à l’accessibilité mais aussi leur mise en oeuvre.
Pour les entreprises, la mise en conformité doit intervenir avant :

  • avant le 1er octobre 2020 pour des sites internet ou intranet créés avant le 1er octobre 2019.
  • immédiatement pour les sites internet ou extranet créés après le 1er octobre 2019.
  • avant le 1er juillet 2021 pour les applications mobiles, progiciels ou mobiliers numériques urbains (distributeurs de tickets pour les transports en commun, etc).

Conclusion

Le chantier de l’accessibilité pour le web est déjà très riche et encadré par plusieurs réglementations. Pour autant, l’état des lieux dressé par WebAIM souligne tout ce qu’il reste encore à faire. En incorporant la notion d’accessibilité dès aujourd’hui dans vos méthodes de travail, vous verrez rapidement que (comme pour les autres valeurs abordées dans la présente série d’articles), il est facile d’identifier des mesures simples avec un impact plus que conséquent.
La question de l’accessibilité pour les applis mobiles reste entière. Les bonnes pratiques de conception existent (car c’est souvent à ce niveau que tout se joue) mais je ne connais pas forcément d’outils pour mesurer l’accessibilité similaires à ceux utilisés pour les sites internet. Toutefois, c’est aussi pour moi une bonne raison supplémentaire de se pencher plutôt que les Progressive Web Apps (voir mon billet précédent à ce sujet).