H.fr : La technologie peut être un atout majeur pour améliorer l'accessibilité de nos villes, lieux de résidence, voitures... Mais vous arrive-t-il d'être déçu par ces nouvelles interfaces (montres, lunettes, distributeurs, domotique...) qui semblent parfois mises sur le marché sans vérification préalable ?
Marco Zehe, ingénieur AQ Accessibilité chez Mozilla : Souvent, oui. Beaucoup font l'impasse sur cette valeur ajoutée. Environ 20% des personnes en Europe sont porteuses d'un handicap, sans tenir compte des "handicaps temporaires". Ainsi, en théorie, ces entreprises ignorent jusqu'à un cinquième de leur marché.
H.fr : Pensez-vous que votre propre exemple, vous qui personnifiez l'accessibilité numérique, peut aider à mieux comprendre cette problématique et encourager vos collègues à s'en saisir ?
MZ : L'exemplarité est en effet une méthode très efficace. Des rencontres, des démonstrations en direct, permettant de montrer l'impact de l'accessibilité ou de son absence, sont les meilleurs moyens d'éveiller les consciences. À partir du moment où un développeur ou un designer "connaît" une personne en situation de handicap, cela crée de l'empathie. Dans le cas contraire, l'impact de l'accessibilité reste une construction purement théorique, qu'il peut avoir du mal à appréhender.
Handicap.fr : Considérez-vous qu'il est plus facile, aujourd'hui, de promouvoir l'accessibilité numérique, notamment du web, qu'autrefois et pensez-vous que les développeurs sont davantage concernés ?
MZ : Non, par certains côtés c'est plus difficile qu'avant. Il y a aujourd'hui plus de développeurs qui connaissent le Javascript (ndlr : un langage de programmation, noté JS, qui rend dynamique les pages web), mais qui n'ont pas étudié au préalable les bases d'une bonne sémantique HTML (le langage informatique qui constitue la structure de la page) ou comment l'habiller correctement avec du CSS (« feuille de style », un autre langage qui permet « d'habiller » la page) pour le faire ressembler à ce qu'ils veulent. À la place, tout la logique est souvent « balancée » dans du JS, pensée pour fonctionner (uniquement) à la souris, et le tout est, ensuite, directement mis en production. Parfois, ces interfaces marchent aussi avec les écrans tactiles ou au clavier mais c'est souvent par un pur hasard. Une bonne sémantique HTML, pourtant indispensable, est souvent considérée comme vieillotte ("old school"), et pas utile parce que "JS peut tout faire".
Pour répondre à votre question sur l'attention portée à l'accessibilité numérique, je pense donc qu'elle un peu meilleure grâce, notamment, à l'évolution des contraintes légales mais cela reste un sujet qu'on doit explicitement présenter aux développeurs car il ne fait pas partie de leur travail quotidien.
H.fr : Des exemples encourageants, malgré tout ?
MZ : La seule exception que j'ai vue se situe dans le domaine du logiciel libre où des groupes parfois marginalisés et une pensée très inclusive constituent les forces motrices du projet. Par exemple, de nombreux « clients » du réseau social Mastodon (ndlr : un réseau social alternatif décentralisé) sont plus accessibles dès l'origine que beaucoup d'autres projets. L'idée, derrière Mastodon, est de développer un environnement plus inclusif et ergonomique, ce qui inclut les personnes handicapées. Dans ce type de projets, même si des éléments ne fonctionnent pas encore (en termes d'accessibilité), ses responsables sont souvent plus ouverts et acceptent les contributions et les demandes de modifications qui s'y rapportent.
H.fr : Quel est, aujourd'hui, le problème majeur de l'accessibilité numérique ?
MZ : Les fenêtres surgissantes (pop-overs) et les couches de publicité qui s'affichent sur les écrans, difficiles à désactiver avec des boutons eux-mêmes inaccessibles. Il y aussi les "classiques" : images sans textes alternatifs, boutons mal labellisés, structures d'en-tête mal conçues, contrastes de couleurs faibles ou encore design médiocre pour ceux qui utilisent le clavier plutôt que la souris. Ces sujets ne sont pas nouveaux, ce sont nos "compagnons" depuis plus de 20 ans et, pourtant, ces faiblesses je les retrouve quasiment dans tous les projets que je suis.
H.Fr : Si on considère le nombre croissant de sites internet développés avec de grands "frameworks" (environnements de développement intégré), ceux-ci sont-ils suffisamment conscients des problématiques d'accessibilité ?
MZ : Certains sont vraiment très lents à s'y mettre, et, fondamentalement, ces "frameworks" sont sûrement la cause de la dégradation de la perception de l'accessibilité dans les cinq ou six dernières années. Certains ne sont pas accessibles par défaut et, en étant utilisés par des tiers, leur inaccessibilité augmente encore. Des développeurs spécialisés dans l'accessibilité passent alors un temps colossal à corriger et réinjecter certaines fonctionnalités en espérant que les prochaines livraisons du cœur du logiciel ne ruineront pas leur travail. Certains projets incluent maintenant l'accessibilité dès l'origine mais pas tous, et c'est souvent une lutte âpre.
Par certains côtés, on peut dire que l'inaccessibilité des frameworks Javascript a remplacé l'inaccessibilité des environnements en Flash des années 2000. Avec le déclin de Flash, l'accessibilité s'est améliorée avant de décliner à nouveau avec la montée en puissance de ces environnements de développement. La faute ne vient pas du langage Javascript en lui-même mais plutôt du fait que ces environnements génèrent un code informatique qui, par défaut, est inaccessible et n'inclut pas d'information sémantique. Techniquement, le JS ne fait rien d'autre que remplir le DOM (modèle objet du document) de bon vieux HTML, or celui-ci doit être sémantique pour être accessible, et c'est quelque chose qui est rarement enseigné dans les universités et les écoles.
2
3
