Introduction à l’accessibilité Web

— Et sinon, t’as déjà entendu parler d’accessibilité Web ?
— Ouais, mais les handicapés c’est pas notre cible donc c’est pas nécessaire de rajouter ça dans le projet.

Voilà, voilà, voilà ! À ce moment de la conversation, toutes les personnes sensibilisées à la question de l’accessibilité Web ont des envies de meurtre et les autres se demandent légitimement quel est le problème. Parce que oui, on est en 2019 et on est encore trop souvent confronté à ce genre de situation quand on met le sujet de l’accessibilité Web sur la table. Mais bon, s’énerver contre son interlocuteur ne fera pas progresser le Schmilblick, aussi, je vous propose qu’on prenne le temps de revoir les bases dans cet article histoire d’offrir de saines lectures à vos collègues/clients/amis mal informés.

Accessibilité et handicap

Avant de parler d’accessibilité il faut parler un peu de handicap. Bon rentrons directement dans le vif du sujet. Dès que l’on parle de handicap, on a tous des images chocs en tête : personnes sourdes, aveugles, tétraplégiques, mentalement déficientes, etc. C’est effectivement l’une des dures réalités du handicap. Cependant réduire le handicap à ces cas extrêmes c’est un peu comme dire que la saga Harry Potter se réduit aux derniers chapitres du dernier livre de la série. Alors certes ce sont les chapitres les plus dramatiques et les plus importants de l’histoire mais si vous n’avez pas lu les sept livres précédents vous risquez d’avoir du mal à mesurer la gravité et l’intensité réelle des enjeux.

Reprenons donc l’histoire depuis le début. WikiPedia propose la définition suivante du handicap :

Le handicap est la limitation des possibilités d’interaction d’un individu avec son environnement, menant à des difficultés psychologiques, intellectuelles, sociales ou physiques.

Cette définition est intéressante car elle permet de poser un premier point: le handicap n’est pas lié à un état mais à une situation. Par exemple, une personne aveugle n’est pas handicapée du fait qu’elle est aveugle (état), elle est handicapée uniquement dans les situations où la vue est nécessaire pour interagir (situation). Plus concrètement : vous êtes atteint de cécité, ou plus communément d’une myopie un peu sévère et vous avez oublié vos lunettes à la maison, et vous devez vous orienter dans un lieu inconnu ; si les seules informations d’orientation sont visuelles (panneaux indicateurs, plans) vous avez un gros problème, vous êtes en situation de handicap. Si par contre vous disposez d’un smartphone avec assistant vocal, qui peut donc vous guider, vous êtes dans la même situation que n’importe qui. Cette distinction entre état et situation est très importante car si on reconnaît aisément que certains états vous propulsent plus fréquemment dans des situations de handicap, n’importe qui peut se retrouver dans une situation de handicap.

Et c’est le deuxième point important: les situations de handicap touchent tout le monde sans distinction. En effet, les états pouvant vous mettre dans une situation de handicap peuvent être soit permanents (surdité, cécité, paralysie, trouble de l’attention, etc.) soit transitoires (vos enceintes/écran/souris/clavier/… tombent en panne, vous vous cassez un bras, vous utilisez votre smartphone en plein soleil, etc.). De même, beaucoup d’états dits permanents évoluent au cours de la vie. Par exemple, la presbyacousie (dégradation de l’audition avec l’âge) touche absolument tout le monde et peut se mesurer dès l’âge de 20 ans, pour autant, cette condition ne vous projettera dans des situations de handicap qu’à un âge et à une fréquence qui sera spécifique à chaque individu. Finalement, quand on y réfléchit cinq minutes, on s’aperçoit qu’on peut très facilement tous se retrouver dans une situation de handicap, que ce soit lié à un état transitoire ou simplement au changement naturel ou accidentel du corps humain au cours de la vie.

Maintenant que l’on a établi ce qu’est le handicap, on peut se risquer à définir l’accessibilité. Ainsi, on peut définir l’accessibilité comme la démarche qui consiste à s’assurer que l’accomplissement d’une tâche ne se heurtera pas à une situation de handicap. Plus spécifiquement l’accessibilité Web consiste en toutes les mesures prises pour qu’un site (ou une application) Web puisse être consulté et utilisé quelles que soient les conditions dans lesquelles se trouve l’utilisateur. Et qu’on ne s’y trompe pas, « toute les mesures prises […] quelles que soient les conditions » ça couvre large, tellement large qu’il est illusoire de croire qu’il sera possible de couvrir tous les cas conduisant à une situation de handicap. Concrètement, on se doute bien qu’entre une personne qui a oublié ses écouteurs et une personne tétraplégique ou autiste, les mesures compensatoire à prendre sont radicalement différentes. Est-ce que pour autant il faut baisser les bras et renoncer à toute mesure: Non. Le plus important dans l’accessibilité c’est la notion de démarche, d’amélioration permanente. Cette démarche part du simple bon sens à l’application de normes et standards qui lissent les problèmes les plus connus pour aller jusqu’à des solutions spécifiques requérant l’intervention d’experts.

C’est bien joli de dire ça mais, au-delà de nos éventuels futurs problèmes individuels, il y a des personnes qui sont en incapacité d’accéder à certains contenus maintenant. Alors une démarche d’accessibilité Web, concrètement, ça prend quelle forme ?

L’accessibilité Web au quotidien

L’idée reçue la plus commune sur l’accessibilité web c’est qu’il s’agit d’un problème technique qui se règle en un ou deux jours avant le lancement du projet. Hélas, il s’agit d’une question plus globale qui doit être prise en compte à chaque étape de la vie d’un site/application web.

Une histoire trop ordinaire

Prenons un exemple pour clarifier la question. Vous travaillez sur un projet de site de e-commerce et vous avez une magnifique page qui vous affiche tous vos produits. Vous testez sur votre écran ultra-haute résolution de 27 pouces… Génial ! Vous rentrez à la maison et tout fier de vous, vous montrez votre site à votre conjoint sur votre smartphone… Catastrophe ! Les produits débordent de l’écran de manière anarchique, impossible de les sélectionner, etc. Donc là nous sommes typiquement sur un problème de conception graphique et ergonomique avant même de parler de technique. Mais continuons notre histoire, après avoir revu la conception et fait faire les corrections qui s’imposent, vous faites une présentation en comité de pilotage du projet, cette fois-ci vous projetez votre page via un projecteur et là… c’est le drame ! Votre page est projetée sur un mur blanc en pleine journée, les couleurs et contrastes sont fortement dégradés et donc on ne voit pas grand chose. Petit passage chez les designers pour faire réajuster le tout et cette fois, c’est bon, on va pouvoir montrer ça aux équipes commerciales pour la validation finale. En plus c’est chouette, les équipes marketing ont créé de belles vidéos de présentation de chaque produit. Deux jours plus tard, vous recevez un e-mail dévastateur, les équipes commerciales refusent de valider la page, motif: « un problème technique sur les vidéos qui n’ont pas de son » ! Un problème technique sur les vidéos, vraiment ? Après avoir fait un tour au département commercial il apparaît qu’ils travaillent en open-space et qu’ils sont donc équipés d’ordinateurs sans carte son ! Alors quoi, on enlève les vidéos ? Plus simplement cette fois on va faire un tour du côté de l’équipe marketing pour leur demander de fournir des sous-titre pour chaque vidéo.

On pourrait continuer comme ça à l’infini. Cependant, si vous avez été attentif, vous aurez noté que dans cette petite histoire je ne parle jamais de personnes dites handicapées et les problèmes soulevés ne trouvent pas leur racines dans des questions techniques. C’est intéressant car si le site est corrigé pour résoudre ces problèmes rencontrés par le premier quidam venu et bien spontanément, les personnes atteintes de troubles visuels ou auditifs pourront plus facilement accéder au site sans aucun coût supplémentaire pour le projet. Alors attention, ce n’est évidemment pas toujours aussi rose car certains types de problèmes nécessitent des prises en charge particulières. On peut citer par exemple certains troubles dits mentaux (troubles dys, autismes, troubles mémoriel, etc.) ou physiques (paralysies, trouble de la coordination, etc.) qui peuvent parfois requérir une adaptation plus ou moins importante des contenus et moyens d’interaction. Mais même dans ce cas, si le projet est déjà dans une démarche d’accessibilité, les éventuels surcoûts induits restent finalement marginaux par rapport à une remise à plat complète du projet à une semaine de sa livraison.

Organiser la démarche vers l’accessibilité

Bon, ok, je pense que maintenant vous avez compris : l’accessibilité est une démarche… super, mais concrètement, comment on fait pour éviter de rencontrer des galères à répétition telles que celles de notre petite histoire ? Malheureusement, je n’ai pas la prétention de vous donner la solution miracle dans cet article (en admettant même qu’elle existe, ce dont je doute). Cependant il y a quelques grandes étapes directrices à suivre et qui vont spontanément rendre votre vie plus belle.

1. La première étape sera toujours la sensibilisation au handicap et à l’accessibilité web (continuez de lire cet article, vous êtes sur la bonne voie) d’autant plus quand on travaille dans les métiers du numérique. En effet, la population des personnes qui conçoivent et mettent en œuvre des sites ou applications web est notoirement jeune ce qui implique une population beaucoup moins touchée par les questions de handicap aussi bien permanent que transitoire (les populations jeunes, entre 20 et 45 ans, sont généralement en meilleure santé et technologiquement lettrées).
2. La deuxième étape consiste à former les différents intervenants des projets et en particulier les chefs de projet, product owners, product managers et tous ceux chargés de prendre des décisions clés pour le projet. En effet, au delà des problématiques triviales que j’ai évoquées ci-avant, inclure l’accessibilité au sein des projets requiert un vrai savoir-faire pratique, aussi bien lors des phases de conception que lors des phases de réalisation et maintenance.
3. La troisième étape sera celle de l’outillage. Il existe pléthore d’outils qui aideront les différents intervenants que ce soit des checklist pour faire du contrôle continu ou des outils de vérification plus ou moins automatique. L’idée étant d’avoir une vision régulière et complète de l’état d’accessibilité de votre projet sans y passer des jours et des jours.
4. La quatrième étape sera de se fixer des objectifs et de s’organiser en conséquence pour pouvoir évaluer régulièrement les progrès réalisés. Cela peut passer par la mise en place de profils dédiés (voir pour les cas les plus extrêmes de services dédiés) ou par l’intervention ponctuelle ou régulière de prestataires externes.

À l’instant où vous en arrivez là, les questions d’accessibilité web n’en seront même plus, elles seront intégrées dans vos workflows de travail sans même que vous vous en rendiez compte.

Dura lex, sed lex

Bien, maintenant qu’on a contextualisé l’accessibilité et qu’on a vu que sa mise en œuvre peut se faire très progressivement, y-a-t-il des attentes formelles vis à vis de l’accessibilité Web ? De ce point de vue, il y a 2 réponses pas si éloignées l’une de l’autre : d’une part, les recommandations et spécifications du W3C (World Wide Web Consortium) et d’autre part, les contraintes réglementaires des états.

W3C Web Accessibility Initiative (WAI)

Les questions d’accessibilité du Web sont débattues et spécifiées depuis des années au W3C. Le fondement des travaux autour de ce thème tient à une célèbre citation de Tim Berners-Lee:

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect. (Le pouvoir du Web tient à son universalité. Que tout le monde puisse y accéder quels que soient ses handicaps en est un aspect essentiel.)

Le WAI a été créé il y plus de 20 ans en 1997 et ses différents groupes de travail sont parmi les plus actifs. De toutes les actions menées, les plus notables sont la création de recommandations fonctionnelles et techniques dont les plus connues sont WCAG (Web Content Accessibility Guideline) et WAI-ARIA (Accessible Rich Internet Applications)

Sans rentrer dans les détails, WCAG est un ensemble de recommandations et bonnes pratiques générales à suivre afin de rendre les contenus Web accessibles. Ces recommandations étant réparties en 3 groupes, des plus simples (A) aux plus contraignantes (AAA). Pour vous donner une idée un peu grossière, un niveau d’accessibilité A s’atteint normalement sans effort pour peu qu’on utilise les standards Web sans les dévoyer. Un niveau AA requiert par contre un engagement pro-actif de la part des éditeurs et développeurs de contenu. Enfin un niveau AAA est assez contraignant et nécessite souvent l’intervention de spécialistes fonctionnels (UX, Design, Ergonomie, etc.) et techniques (HTML, CSS, JavaScript) habitués à ces questions.

De son coté, ARIA étend les capacités natives de HTML et SVG pour expliciter leur intrication avec les couches d’accessibilité sous-jacentes des systèmes d’exploitation et offre donc la possibilité aux créateurs d’applications Web d’ajuster finement l’accessibilité de leurs produits.

Ceci dit, ces spécifications restent complexes à lire, à comprendre et à mettre en œuvre. Comme toutes les spécifications Web, elles sont imparfaites, sujets à interprétation et victimes des aléas d’implémentation technique dans les navigateurs Web. Néanmoins des consensus se détachent et de plus en plus d’organismes se sont sérieusement penchés sur la mise en œuvre de ces recommandations.

Les réglementations locales

Avec l’essor du Web sur les 20 dernières années, de plus en plus de pays se sont mis à légiférer en matière d’accessibilité numérique (pas simplement le Web). Les plus actifs en la matière étant l’Amérique du nord (USA, Canada), l’Europe et les grand pays du numérique en asie (Chine, Corée, Hong Kong, Japon, Taiwan).
La plupart de ces législations sont avant tout contraignantes pour les organismes publics mais dans certains pays elles peuvent également cibler les acteurs privés. L’exemple le plus connu est la « section 508 » américaine (de son nom complet: « Section 508 of the Rehabilitation Act of 1973 ») qui est une des législations les plus anciennes (1998) et qui contraint, entre autres choses, les administrations à produire des contenus qui doivent proposer une accessibilité minimum de niveau WCAG AA. C’est loin d’être le seul texte régulateur aux USA, ainsi le 21th Century Communications and Video Accessibility Act (CCVA) de 2010 étend les contraintes de la section 508 aux acteurs privés. C’est, par exemple, pour cette raison que YouTube propose un système de sous-titrage automatique de ses vidéos en anglais 😉

La France n’est pas en reste sur le sujet avec la loi du 11 février 2005 pour l’égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées et la loi du 7 octobre 2016 pour une République numérique. À la différence des États-Unis, la France a défini un référentiel opérationnel qui explicite les points d’accessibilité à mettre en œuvre : Le Référentiel Général d’Accessibilité des Administration (RGAA). Ce référentiel est une version opérationnelle des recommandations WCAG 2.0, le but étant de limiter au maximum les possibilités d’interprétation de la spécification WCAG et de fournir un outil de travail clair en français pour les créateurs de contenu Web.

Même si en France la contrainte sur le secteur privé est faible, elle n’est pas nulle. Les grandes entreprises (Orange, BNP, etc.) français vont être contraintes de suivre les recommandations fournies par le RGAA (on attend justes les décrets d’application), elles ont donc déjà commencé leurs démarches. Si vous êtes francophone, je ne saurais trop vous recommander au moins une fois pendant vos projets de prendre la checklist du référentiel et de vérifier le niveau de conformité de votre projet histoire de vous donner une idée de ce que ça représente. Histoire de bien comprendre de quoi il s’agit, prenons un petit exemple: Le critère d’accessibilité pour les contenus non-textuels de la spécification WCAG 2.1 dis que « All non-text content that is presented to the user has a text alternative that serves the equivalent purpose » (Tous les contenus non-textuels présentés à l’utilisateur disposent d’une alternative textuelle équivalente). C’est assez vague et générique et il n’est pas évident de savoir ce que ça implique. WCAG fournis des critères de succès mais ils sont nombreux et il peut être difficile de choisir la bonne solution pour un contexte donné. Le RGAA vient résoudre ce problème en proposant des solutions opérationnelles, en français, à des problèmes clairement identifiés. Par exemple, dans le cas des contenus non-textuels, comment résoudre le problème spécifique des images contenant du texte.

Conclusion

Comme on le voit le sujet est assez dense, résumons donc un peu tout ce qu’on vient de se raconter.

L’accessibilité Web est une démarche qui consiste à rendre accessible et utilisable vos contenus et applications Web par tout le monde quelles que soient les situations dans lesquelles sont vos utilisateurs. Il y a deux points clés dans la phrase précédente : la notion de démarche et la notion d’universalité. Rendre un service réellement accessible à tout le monde est un idéal vraisemblablement impossible à atteindre, mais c’est un horizon que l’on se fixe. C’est en ceci que la notion de démarche est clé. La démarche d’accessibilité c’est l’ensemble des actions que l’on va prendre pour tendre vers cet idéal. Cela va aller de la démarche individuelle d’un développeur Web qui va faire attention à la sémantique de son code HTML jusqu’à des organisations complètes d’amélioration continue de l’accessibilité qui vise une mise en conformité réglementaire et son maintien dans le temps.

Vous avez lu cet article en entier ? Bravo vous avez fait votre premier pas sur le chemin de l’accessibilité Web ! Dans de futurs articles nous prendrons le temps de détailler des points plus précis mais l’important c’est d’entrer dans la démarche. Maintenant c’est à vous de jouer, informez-vous, formez-vous, outillez-vous, organisez-vous et l’accessibilité Web ne sera plus jamais un problème dans vos projets.