🗣 L’introduction à l’accessibilité sur le web que j’aurais aimé avoir

Traduction de l’article original de Max Antonucci « The Web Accessibility Introduction I Wish I Had » pour les francophones qui n’ont pas encore atteint 100 000 points sur Duolingo en anglais 🙂

L’aspect le plus important concernant tes responsabilités d’artisan du web, le truc sur lequel tu dois le plus te concentrer, c’est l’accessibilité web. Normalement, ça devrait même être la top priorité en front-end. Sérieusement, si les utilisateurs ne peuvent pas utiliser un site correctement, rien d’autre ne compte. C’est pour ça qu’il aurait été plus intelligent de mettre l’accent sur l’accessibilité beaucoup plus tôt.

Cet article a pour but de te raconter quelques éléments clés sur l’accessibilité. Je ne peux pas tout couvrir, mais je peux parler de :

1. Pourquoi l’accessibilité est importante, très importante
2. Comment faire un site accessible
3. Comment tester l’accessibilité

Let’s begin!

Une mauvaise idée de ce qu’est l’accessibilité

Avant toute chose, je me dois de corriger une chose importante sur lequel j’ai longtemps eu tort à propos de l’accessibilité : l’accessibilité affecte tous les utilisateurs, pas uniquement ceux qui ont des handicaps stéréotypés. Accepter cela, ça veut dire que tu réalises enfin que l’accessibilité, c’est construire en prévoyant les cas de stress.

Les cas de stress ? Ça fait référence à n’importe quelles conditions médicales ou des situations qui peuvent affecter n’importe qui, n’importe quand à différents moments de nos vie. Par exemple, certains cas de stress assez communs sont :

• La vieillesse
• Problèmes de santé chroniques comme l’arthrite
• Être à l’extérieur avec une forte lueur de soleil
• Déficience cognitive due aux médicaments ou au manque de sommeil
• Besoin d’utiliser un site avec différents appareils
• WiFi fragile qui affecte le chargement des différents composants du site

Comme tu peux le voir, certains sont des exemples de stress expérimentés par des personnes ayant un handicap spécifique. D’autres s’appliquent à des conditions médicales qui affectent tout le monde. Certains sont situationnels mais touchent tout le monde.

C’est important que ça te permette de transformer ton idée de l’accessibilité qui est, pour le moment « c’est pas important, ça concerne que certaines personnes, on s’en fout » à « il est impératif qu’on pense à tous les utilisateurs ». Ça va aider tout le monde à comprendre pourquoi l’accessibilité est si importante. Et aussi pourquoi c’est peut-être mieux de parler de « cas de stress ».

Plus d’arguments pour l’accessibilité

Si ce qui précède ne fonctionne pas pour toi, ou tes collègues de la conception ou de la gestion, d’autres arguments du point de vue commercial pourraient vous convaincre (la thune, toujours la thune…) :

• L’accessibilité élargit l’audience potentielle de ton application, en augmentant les bénéfices et l’attrait.
• L’accessibilité réduit les ressources consacrées à l’assistance client ayant besoin d’aide (vu qu’on y a pensé avant), laquelle peut être réinvestie ailleurs.
• L’accessibilité te protège de toute responsabilité juridique potentielle (du moins en Amérique, dans le cadre de la loi américaine sur les personnes handicapées). Il suffit de regarder le procès de la Fédération nationale des aveugles v. Target Corp, qui a permis de créer un précédent concernant les sites largement utilisés nécessitant l’accessibilité de par la loi.

Ces arguments sont utiles pour persuader les gens dont tu as besoin pour développer correctement, mais qui ne sont pas des programmeurs. Ils envoient un message clair selon lequel l’accessibilité est bonne pour l’entreprise, que ce soit pour gagner de l’argent ou économiser de l’argent.

Les quatre clés de l’accessibilité Web

Maintenant que tu sais pourquoi l’accessibilité est importante, passons au comment. Les règles d’accessibilité les plus largement acceptées sont les guides de contenu et d’accessibilité Web 2.0 (Web Content And Accessibility Guides 2.0), ou WCAG 2.0. Ce sont des règles universelles pour toutes les interfaces techniques, ce qui explique en partie leur popularité.

Les quatre principes principaux du WCAG 2.0 sont l’acronyme POUR :
– Perceivable (perceptible),
– Operable (utilisable),
– Understandable (intelligible) et
– Robust (robustesse).
Il y a des sous-points spécifiques pour chacun, mais je vais m’en tenir à un large aperçu pour le moment. Je recommande de lire la liste de contrôle de WCAG 2.0 pour plus de détails !

1. Perceptible

Pour faire court, être perceptible signifie que différents cas de stress n’empêchent pas les utilisateurs de lire, de regarder ou d’écouter ton contenu.

Typographie

Le contenu perceptible doit être lisible ! Un moyen simple de rendre le texte plus lisible consiste à donner suffisamment de contraste aux couleurs du texte et de l’arrière-plan pour que les personnes malvoyantes ou mal éclairées puissent toujours le lire. La typographie doit également s’appuyer sur des tailles plus grandes et être facile à ajuster, pour les mêmes raisons. Cela peut même être dû au fait que plusieurs personnes essaient de lire un écran à la fois, ne peuvent pas s’approcher de trop près, et ont besoin de caractères plus gros pour pouvoir lire en même temps (quand on projette une présentation au mur par exemple).

Images

La chose la plus importante avec des images perceptibles est le texte alternatif. Les personnes qui sont aveugles ou qui ne peuvent pas charger les images en raison d’un accès Wi-Fi instable auront tout de même une idée de base de l’image. De même, tu ne devrais jamais mettre de texte important dans une image. Jamais.

Audio et Video

Les contenus audio et vidéo comportent davantage de stress. Les personnes malentendantes, ou celles qui se trouvent dans des endroits très bruyants ou très calmes ou qui préfèrent simplement lire ne peuvent pas écouter ou ne veulent pas faire du bruit. Les transcriptions de vidéos (sous-titres) sont la solution la plus simple, mais les légendes fonctionnent également pour les vidéos très visuelles.

2. L’utilisable

L’utilisable signifie que différents cas de stress ne doivent pas empêcher les utilisateurs d’accéder à toutes les pages et de remplir les formulaires.

Interfaces et Navigation

Ce point est évident. Les utilisateurs doivent pouvoir interagir avec ce dont ils ont besoin, par exemple :

• Les liens vers d’autres pages
• Les formulaires à remplir
• Les boutons à cliquer
• Quelque chose d’autre pour se déplacer sur le site ou envoyer / recevoir des informations.

Cela semble évident, mais c’est aussi la partie la plus importante du Web, il est donc important de vérifier que tout ça fonctionne. Tu serais d’ailleurs surpris de voir combien de fois ces quelques points évoqués ne sont pas accessibles…

La navigation par clavier

Prends le dernier point et ajoute un twist : ne navigue qu’au clavier. La navigation au clavier couvre de nombreux cas de stress : lecteurs d’écran, contrôle des mouvements instables, problèmes médicaux liés aux vertiges et au contrôle des muscles, tapis de souris peu fiable ou simplement préférences personnelles. Dans ton éditeur de texte, tu utiliserais des raccourcis clavier pour travailler rapidement, ça fonctionne de la même manière avec la navigation Web.

L’amélioration progressive

L’amélioration progressive aide dans les cas de stress où, même si tout ou une partie du style se casse la gueule, le site est quand même opérationnel. Les formulaires ne devraient pas être inutilisables sur les navigateurs plus anciens sous prétexte qu’ils ne prennent pas en charge les nouvelles fonctionnalités CSS. Les formulaires peuvent sembler plus simples ou plus crus, mais ils doivent quand même fonctionner. L’amélioration progressive permet de commencer par une base solide et opérationnelle, puis d’ajouter les fonctionnalités disponibles dans la mesure du possible.
Tu ne peux pas contrôler le navigateur d’un utilisateur, tu peux uniquement préparer ses choix.

3. Intelligible, compréhensible

L’intelligible est plus compréhensible que les autres points : Les cas de stress ne doivent pas empêcher les utilisateurs de comprendre le sens voulu des sites internet. Cela permet de couvrir les cas de stress cognitif liés à la manière dont les utilisateurs interprètent et comprennent le message de ton site.

Fais Simple et Explicite

Comme le disait souvent George Carlin, le meilleur langage est simple, honnête et direct. Les longues phrases pompeuses avec du jargon corporate paraît impressionnant aux designers mais dégoûtent complètement les utilisateurs. L’écriture simple est compréhensible et aide les utilisateurs à avoir confiance en ton site. Sinon, ils ont moins tendance à accorder leur attention ou même à acheter les trucs que tu aimerais vendre.

Ne suppose pas

C’est le point qui feraient réagir beaucoup de futurs designers. Et pour cause… De nombreux éléments de site fonctionnent sur l’hypothèse que les utilisateurs comprennent déjà leur signification. Par exemple, en supposant qu’une icône « étoile » signifie qu’on attribue une préférence à un élément. C’est évident pour toi, mais tu ne peux pas être sûr si c’est évident pour les utilisateurs. Cela peut être dû à des cas de stress cognitifs, à des cas de stress culturels ou simplement à des personnes novices sur le Web. Ne compte jamais sur le symbolisme implicite. Il est plus rapide, plus facile et infiniment plus accessible d’ajouter une légende ou un sous-titre pour s’assurer qu’un élément est bien compris. Si le designer rechigne à le faire, n’aies pas peur de rester sur tes positions. C’est pour le bien des utilisateurs.

4. Robustesse

La robustesse signifie que les cas de stress n’empêchent pas les utilisateurs d’accéder au contenu à partir d’une grande variété d’appareils.

Balisage sémantique

Le balisage sémantique est le meilleur moyen de rendre le contenu robuste accessible dans son ensemble. Pour le web, cela signifie :

• Les balises HTML sémantiques
• Utilisation appropriée des balises aria
• Rangement logique des éléments DOM
• Un rendu côté serveur pour s’assurer qu’il est livré correctement

Cela rend le contenu convivial pour la navigation au clavier, les lecteurs d’écran et même une interface utilisable si le CSS ne parvient pas à se charger. Les balises sémantiques et accessibles te mènent loin vers un site Web accessible.

Design Responsive

L’exemple le plus évident de la variété d’appareils est la taille de l’écran, telle que :

• Les montres connectées (peut-être)
• Les smartphones
• Les tablettes
• Les grands écrans externes
• Les écrans de projection
• Les écrans de cinéma si tu deviens célèbre 😉

On peut soutenir que la taille de l’écran affecte davantage les applications Web que les autres types, en particulier avec la montée en puissance des applications web progressives (PWA, Progressive Wep Applications). Même si aucun site ne peut avoir la même expérience avec autant de tailles ou avoir le même rendu pixel par pixel, ils doivent rester utilisables et fonctionnels.

Test d’accessibilité

Damned, tu dois avoir le tournis en voyant la liste de toutes ces exigences. Tout d’abord, rappelle-toi que le travail en vaut la peine. Deuxièmement, tu seras heureux d’apprendre que tu peux automatiquement tester plusieurs de ces points !

Test d’accessibilité automatisé

Certaines choses à tester automatiquement avec un ou plusieurs outils sont :

• Le contraste de couleur
• La sémantique HTML
• Éléments div inutiles
• Texte traduit
• ARIA et autres attributs d’accessibilité comme les titres…

Dans l’ensemble, j’ai constaté que les tests automatiques couvraient au moins 75% de mes problèmes d’accessibilité. Mais à une seule condition: les tests d’accessibilité doivent être ajoutés le plus tôt possible dans un projet. Plus on fait les tests tardivement, plus le problème est perçu comme « un truc à faire plus tard ». C’est dommage, car certaines conceptions sophistiquées ne peuvent pas être conservées en termes d’accessibilité et doivent être modifiées plus tôt. Sinon, les tests d’accessibilité sont voués à toujours échouer.

Tes outils spécifiques changeront pour chaque projet, je ne vais donc pas énumérer d’exemples ici. Tu en apprendras davantage en effectuant des recherches et en constatant à quel point ces outils couvrent les directives WCAG 2.0.

Ce que tu ne peux pas automatiser

Les tests d’accessibilité permettent de mesurer les facteurs liés aux cas de stress, mais pas les cas de stress réels. Certains peuvent simuler des actions de base, comme cliquer sur des éléments, mais cela ne suffit pas. Au moment d’écrire ces lignes, la meilleure façon de procéder consiste à recréer toi-même les cas de stress. Quelques suggestions de départ sont:

• Naviguer avec un clavier
• Naviguer avec un clavier et un lecteur d’écran
• Utiliser un smartphone
• Utiliser un smartphone avec un méga reflet de soleil sur l’écran
• Ralentir ta connexion internet
• Casser un peu ou tout ton style CSS
• Demander à des gens non familiers avec ton site de le tester et d’y faire des trucs basiques.
• Utiliser un filtre de couleur en niveaux de gris (pour le daltonisme)
• Utiliser une seule main
• Utiliser le site en agitant la main pour simuler de l’arthrite ou des douleurs musculaires
• Utiliser en état de fatigue (ou ivre) ou simuler un trouble cognitif
• Utiliser le site en courant dans la rue, poursuivi par un monstre libéré en quête de vengeance

Ma recommandation est de dresser une liste de contrôle des différents cas de stress et d’en couvrir le plus grand nombre possible, du plus important au moins important. Ainsi, si tu ne parviens pas tous les recréer, tu obtiendras au moins ceux qui affectent le plus grand nombre d’utilisateurs.

Ne jamais oublier l’accessibilité

Si tu dois retenir un seul truc, c’est ce que j’ai écrit au début : l’accessibilité concerne les cas de stress qui touchent tout le monde. C’est pour ça que c’est plus important qu’un simple « chouette truc à avoir ». L’accessibilité est aussi fondamentale que la gestion de base de données, l’architecture des applications, la sécurité des données ou les pistolets tranquillisants à longue portée. Sans eux, les choses se détériorent rapidement et peuvent prendre feu.

Malheureusement, aucune de tes études initiales et de tes rares cours universitaires ne mettent suffisamment l’accent sur l’accessibilité. Tu devras donc continuer à rechercher toi-même les méthodes d’accessibilité, à en justifier les arguments, à les apporter rapidement aux applications, à les tester et à partager ces informations avec d’autres. C’est difficile, bien sûr, mais l’investissement en vaut toujours la peine pour ton entreprise et pour le bien de l’internet ouvert.

Quelques ressources

• La checklist de A11Yproject
• Ressources pour utiliser un screen reader (lecteur d’écran)
• Contrast Ratio : Pour tester le contraste des couleurs
• The W3C Markup Validation Service : Pour tester le balisage HTML
• Coblis : Colorblind simulator
• Designing for colour blindness
• Un petit témoignage (en anglais) d’un gars qui ne savait pas qu’il était daltonien… « oui je pensais que le beurre de cacahuète était vert pendant 18 ans ! »

Originally published at mae.ovh on December 30, 2018.