« Retour

30 days of accessibility testing

"Qui vient sur mon site web ?"

Une question de stratégie...

Qui vient visiter mon site ? Derrière cette question se trouve le nerf de la guerre de toute stratégie digitale. Sociétés, organisations, blogueurs et autres webmasters souhaitent augmenter leur audience afin de gagner en notoriété et gonfler leurs ventes en ligne. Connaître ses utilisateurs est un prérequis fondamental pour qui veut augmenter le ROI de son site web, mais cette problématique peut être abordée de manières très différentes.

... une question de sécurité...

En février, le Ministry of Testing a donné une autre saveur à cette phrase. Qui visite mon site web : un client potentiel, un bot envoyé par désœuvrement par un packet monkey, ou un hacker désireux de récupérer les adresses e-mail de mes clients ? A travers une série de 30 défis, nous nous sommes plongés dans les tests de sécurité.

... une question d'accessibilité !

Ce mois-ci, la question change encore de perspective. Qui visite mon site : une personne en mesure de lire les texte, de voir les images, d'écouter les contenus audio ? De taper un texte sans difficulté ? De manipuler une souris ? Ou quelqu'un dont l'expérience en ligne nécessite des aménagements spécifiques ? Bienvenue dans l'univers des tests d'accessibilité !

La période est particulièrement bien choisie par le Ministry of Testing, sachant qu'aujoud'hui, le 18 mai, se tient la journée mondiale de la sensibilisation à l'accessibilité (ou GAAD, pour Global Accessibility Awareness Day).

Voici donc la façon dont nous nous sommes approprié les défis, en mettant une fois de plus l'accent sur notre contexte calédonien. Si vous êtes du Caillou, il est possible que vous reconnaissiez certains sites qui seront évoqués ici...

1) Comprendre les différents handicaps (y compris liés à l'âge) à prendre en compte

Voici une liste des différentes incapacités à prendre en compte lors de la mise en place d'une politique d'accessibilité sur le web :

  • Cécité
  • Malvoyance
  • Dyschromatopsie (ou daltonisme)
  • Surdité
  • Déficience auditive
  • Handicaps physiques (touchant notamment les bras, les mains et les doigts)
  • Troubles du langage
  • Dyslexie
  • Troubles de la concentration
  • Troubles de l'apprentissage
  • Troubles de la mémoire
  • Troubles de la santé mentale (on tient compte également des effets secondaires des médicaments associés à ces troubles, notamment la vision floue et les tremblements des mains)
  • Malaises déclenchés par un scintillement visuel ou par des signaux audio à une certaine fréquence (typiquement, l'épilepsie)

Certaines personnes, en particulier les personnes âgées, peuvent cumuler plusieurs handicaps : DMLA, dyschromatopsie, troubles de la mémoire...

Le Laboratoire d’expérimentation et de promotion de l’accessibilité du Web, un projet initié par le RAAMM (Regroupement des Aveugles et Amblyopes du Montréal Métropolitain), se base sur deux études afin d'établir une démographie des internautes touchés par une ou plusieurs incapacités. L'Enquête québécoise sur les limitations d’activités, d'une part, et l’Enquête canadienne sur l’incapacité (ECI) d'autre part, nous apprennent qu'au Canada,

  • 7,2% des personnes ont des limitations motrices
  • 3,9% des personnes ont des limitations cognitives
  • 3,2% des personnes ont des limitations auditives
  • 2,8% des personnes ont des limitations visuelles

La prévalence des incapacités n'est pas homogène dans toute la population. Elle s'accentue à mesure que l'âge des sujets augmente. Ainsi, seulement 4,4 % des 15-24 ans présentent une incapacité, alors que les plus de 65 ans sont concernés à 33,2 %. On peut supposer que l'on retrouvera des chiffres similaires dans les populations d'autres pays développés.

Les incapacités sont donc multiples et concernent une proportion non négligeable de la population des internautes. D'autre part, avec les phénomènes conjoints de vieillissement de la population, de la démocratisation du numérique auprès des seniors, voire du développement de la silver économie en ligne, il devient d'autant plus pressant d'intégrer la notion d'accessibilité à la démarche qualité des logiciels.

2) Utiliser un outil tel que WAVE pour scanner une page web

WAVE est un outil en ligne gratuit qui permet de scanner les problèmes d'accessibilité d'une page web. Il suffit d'entrer une URL, et WAVE fournit une preview du site avec des repères pour localiser les points d'amélioration.

Bonne pêche : un petit bug d'accessibilité

Nous analysons le site web de l'OPT avec le logiciel WAVE.

En rouge, les erreurs. En jaune, les avertissements. En vert, les informations.

La copie d'écran ci-dessus montre une partie de la page d'accueil du site de l'OPT (Office des Postes et des Télécommunications) de Nouvelle Calédonie. Ici, on voit que l'image cliquable Mobitag a été correctement renseignée avec un texte alternatif "Mobitag". Comme il s'agit d'une bonne pratique d'indiquer un texte alternatif, l'étiquette est verte.

Mais juste en-dessous de l'image Mobitag se trouve un lien dont le texte est également "Mobitag". Les deux liens hypertextes mènent sur la même page. L'utilisateur utilisant un lecteur d'écran entendra donc deux fois "Mobitag", d'où l'étiquette jaune pointant un texte alternatif redondant. Ce n'est pas un bug bloquant, mais cela rend la page un peu moins ergonomique pour une personne déficiente visuelle.

Alors qu'aurait-il fallu faire ? Ne pas mettre de balise de texte alternatif du tout à l'image ? Non, car dans ce cas, le lecteur d'écran donne tout de même des renseignements sur l'objet image ("élément de liste", "image"... bref, rien de très parlant). La meilleure solution, dans le cas présent, aurait été de fournir un texte alternatif vide : alt="".

3) Partager son outil préféré d'a11y

Tout d'abord, une précision sur ce barbarisme : pourquoi a11y ? C'est simplement la compression du terme "accessibility", tout simplement parce qu'il y a 11 lettres entre le "a" initial et le "y" final. Un terme paradoxal, car complètement obscur lorsqu'il est lu par un lecteur d'écran... mais tout de même utile pour gagner quelques caractères dans un hashtag sur Twitter.

Nous avons apprécié ce scanner en ligne qui permet d'évaluer la complexité du texte d'une page web. L'outil détecte notamment les phrases trop longues et mots compliqués. Les formules des différents indices sont présentées en bas de la page. Il est intéressant de voir comment ils sont calculés.

4) Comprendre les avantages d'un design inclusif

Un design inclusif est un design qui a été pensé pour être pertinent auprès d'un maximum de personnes, quel que soit leur profil. S'il est impossible de fournir une expérience optimale à 100 % des internautes (il y aura toujours des cas particuliers), un effort peut être fait pour permettre au plus d'internautes possible de s'impliquer.

Il est bon de préciser que les problématiques d'inclusion ne sont pas seulement tournées vers les personnes souffrant de handicaps physiques et mentaux (comme c'est le cas lorsqu'on parle d'accessibilité, selon le W3C), mais aussi vers celles dont le handicap est matériel (connexion internet bas débit). En 2015, Facebook a ainsi mis en place des "mardis 2g" pour sensibiliser ses ingénieurs aux conditions de navigation mobile que l'on peut par exemple connaître en Inde. Le handicap peut également être culturel : une personne n'ayant pas été scolarisée (analphabète) ou ne maîtrisant pas la lecture, même après avoir été scolarisée (illettrée). En outre, tous les internautes ne parlent pas la langue présente dans la page, il faut aussi penser à eux. Cela se complique !

Un design inclusif permet, de manière évidente, d'augmenter son audience, et donc par extension, sa notoriété et ses ventes. En multipliant les interactions avec des utilisateurs de tous profils et tous horizons, on peut éventuellement s'ouvrir à de nouveaux marchés et augmenter les chances d'opportunités.

L'image de marque peut aussi profiter de la politique d'inclusivité.

Par exemple, un site web internationalisé est, par nature, plus accessible qu'un site monolingue. Traduire un site demande un travail important mais permet parfois de doubler (voire tripler, décupler...) son audience. Mais cela renforce aussi au passage l'image de l'organisation dont il est issu, car cela connote une ouverture sur le monde, une notoriété internationale...

Un autre exemple : même si l'on n'est pas concerné directement par un handicap, on peut porter un regard plus favorable à un site web qui contient un lien vers un "mode accessible". Un exemple sur le site web du Projet Voltaire, qui propose un mode d'apprentissage des règles orthographiques avec une interface adaptée aux malvoyants et non-voyants :

Le site du Projet Voltaire propose un mode d'entraînement spécial pour les malvoyants et les non-voyants.

Le site de e-learning propose également un mode favorisant l'inclusion des dyslexiques. L'interface, très paramétrable, permet à chacun de forger l'expérience utilisateur la plus confortable pour lui. En plus de fournir un service accessible, le site contribue à la sensibilisation à la dyslexie.

Les multiples options peuvent être prévisualisées lors du paramétrage.

Enfin, un design inclusif est globalement favorable au référencement. Les contenus spécifiques créés dans un but d'inclusion seront indexés par les moteurs de recherche et augmenteront les correspondances possibles avec les requêtes des utilisateurs. Autre exemple, les textes alternatifs des images renforceront l'indexabilité de celles-ci, qui seront plus facilement trouvables par exemple dans Google Images. Attention tout de même, il peut quand même exister quelques divergences entre accessibilité et SEO, le second ayant tendance à favoriser les pages bavardes en mots-clés, alors que la première privilégie avant tout la clarté.

5) Lire les 12 directives du WCAG 2.0 et commenter l'une d'elles + 7) Naviguer sans souris ni pavé tactile

Les 12 commandements de l'accessibilité

Derrière l'imprononçable acronyme de WCAG (Web Content Accessibility Guidelines) se trouvent 4 principes fondamentaux : il faut que les sites web soient perceptibles (perceivable), utilisables (operable), compréhensibles (understandable) et robustes (robust). Il existe 3 niveaux de conformité à ces directives : A, AA et AAA.

Voici en français ces 12 directives :

  1. Les contenus non-textuels doivent présenter un texte alternatif
  2. Les contenus audiovisuels doivent proposer une alternative
  3. Le contenu doit pouvoir être présenté de différentes façons sans perte d'informations
  4. Les utilisateurs doivent pouvoir facilement distinguer les informations visuelles et auditives
  5. Toutes les fonctionnalités doivent pouvoir être accessibles via le clavier seul
  6. Suffisamment de temps doit être accordé aux utilisateurs pour lire et interagir avec le contenu de la page
  7. La conception doit réduire au maximum le risque épileptique
  8. La page doit contenir des points de repères et des informations pour aider l'utilisateur
  9. Les textes doivent être lisibles et intelligibles au plus grand nombre
  10. Le comportement des pages doit être prévisible
  11. Les erreurs des utilisateurs doivent être anticipées et corrigeables
  12. Le contenu doit pouvoir être supporté par un maximum d'agents utilisateurs

La 3è directive se découpe en trois parties :

  • Informations et relations,
  • Ordre séquentiel logique,
  • Caractéristiques sensorielles

C'est sur le deuxième point que nous allons nous attarder.

Mettons TED au défi...

Nous avons eu envie de challenger le site web de TED, qui propose des vidéos de vulgarisation scientifique dans tous les domaines, et s'efforce de proposer pour chaque contenu une transcription écrite. Les transcriptions sont traduites manuellement, notamment grâce au programme de volontariat Amara, afin de fournir un contenu de la plus haute qualité.

Certaines vidéos de TED sont traduites en une multitude de langues, que l'on peut choisir dans un interminable menu déroulant.

Alors, TED est-il un modèle d'accessibilité ?

Le bouton muet

Si l'on se fie à la page d'accueil, pas totalement. Celle-ci contient des carrousels de vidéos, qui sont navigables grâce à des boutons qu'un utilisateur sans problème de vue peut aisément interpréter comme menant vers les vidéos précédentes et les vidéos suivantes. En revanche, un utilisateur se déplaçant uniquement à l'aide de son clavier et de son lecteur d'écran ne pourra pas comprendre ces boutons. Après la dernière vidéo visible, lorsque l'on se déplace sur le fameux bouton permettant d'afficher les vidéos suivantes, ChromeVox lit simplement "Bouton".

Le code HTML du bouton n'est pas très parlant.

Pour "faire parler" ce bouton, on aurait pu par exemple ajouter un attribut aria-label à la div englobant le bouton. Que veut dire "aria" ? C'est l'acronyme de Accessible Rich Internet Applications, ou Applications Internet riches accessibles. Les attributs ARIA sont définis dans la documentation du W3C et permettent avec concision de donner davantage d'informations aux personnes utilisant un lecteur d'écran.

Le labyrinthe des contenus

Revenons à notre exemple sur le site de TED. L'absence de texte associé aux boutons de navigation n'est pas le seul problème. En effet, si l'on décide de tout de même cliquer dessus (avec la touche Entrée par exemple), les vidéos suivantes apparaissent bien, mais si l'on appuie de nouveau sur la touche de tabulation, le focus ne se fait pas sur la première vidéo de la série qui vient d'apparaître, mais sur la première vidéo de la playlist suivante. Sans le savoir, l'utilisateur aura donc "zappé" des contenus qui auraient pu l'intéresser.

Bien sûr, il est possible de revenir en arrière (avec les touches majuscule + tabulation) et d'accéder aux vidéos qui sont apparues suite au clic du bouton, mais cela ne se devine pas. Cela n'a aucun sens d'un point de vue ergonomique.

Ce qui semble tout à fait intuitif pour une personne qui peut voir se révèle donc assez tarabiscoté pour quelqu'un qui ne voit pas ! Fournir un ordre séquentiel logique quel que soit le mode d'accès au contenu n'est pas une chose aisée.

Accessibilité des durées

Enfin, un dernier détail qui peut troubler l'expérience utilisateur lors d'une navigation sonore : la durée des vidéos est lue avant leur titre, et avec ChromeVox, "16:02" est lu "16 heures 2" au lieu de "16 minutes 2". Pour contourner ce problème, Youtube pour sa part a choisi de donner à la durée des vidéos l'attribut "aria-hidden=true". De cette façon, la durée des vidéos est tout simplement ignorée par les lecteurs d'écran. Etrange, étant donné que la durée d'une vidéo fait partie intégrante de nos critères de choix de visionnage.

[EDIT du 2 avril 2018] Ce n'est plus le cas, le span contenant la durée des vidéos comprend maintenant un aria-label compréhensible, par exemple "1 heure, 17 minutes". Bonne nouvelle !

6) Comprendre les technologies hardware d'assistance

Parmi ces technologies, nous pouvons lister :

  • les souris gyroscopiques, qui permettent de déplacer le curseur sur l'écran de l'ordinateur grâce à ses mouvements de tête
  • les souris oculaires, qui détectent le mouvement des yeux et déplacent le curseur en fonction
  • les souris-joysticks
  • les téléagrandisseurs, des loupes qui permettent de mieux voir l'écran
  • les licornes, des dispositifs qui se positionnent sur le crâne et qui permettent de toucher une écran ou un clavier en fonction du mouvement de la tête
  • les claviers à grands caractères
  • les claviers à touches espacées
  • les claviers dont l'agencement des lettres est adapté aux personnes n'utilisant qu'un doigt ou une licorne
  • les claviers monomanuels pour droitier ou gaucher
  • les guide-doigts, des grilles qui se fixent sur le clavier et évitent d'appuyer sur deux touchent en même temps
  • les plages Braille
  • les imprimantes Braille
  • les bras supports d'écran

Cette diversité d'appareils laisse percevoir la potentielle difficulté physique que peut présenter le simple fait de naviguer sur un site web ou de taper un texte.

8) Lire un livre sur l'accessibilité

Encore mieux qu'un livre : un MOOC ! Ce cours en ligne en est à sa deuxième session et a débuté le 9 mai 2017 sur la plateforme France Université Numérique.

[EDIT du 2 avril 2018] Une nouvelle édition du MOOC débutera le 14 mai 2018, avec possibilité de s'inscrire jusqu'au 29 juin. La durée estimée d'investissement requis est de deux à trois heures par semaines.

9) Désactiver les images dans le navigateur et voir si on comprend toujours la page, 10) Tester un site web avec un lecteur d'écran et 11) Eteindre son écran et se fier uniquement au lecteur d'écran

Cet exercice permet de se mettre à la place d'internautes dont le débit est très réduit, ou d'identifier plus rapidement des problèmes touchant les personnes utilisant un lecteur d'écran. Attention, sur Chrome, cette fonctionnalité désactive parfois également des éléments qui ne sont pas des images.

Nous avons trouvé un exemple particulièrement parlant sur la page d'accueil du site de la Province Sud de Nouvelle Calédonie.

L'interface du site est dynamique et colorée.

Le menu principal est composé de quatre modules dynamiques, qui déploient des options lorsque l'on passe la souris au-dessus. C'est très joli, mais... le problème, c'est que chacun de ces modules est une image sans balise de texte alternatif, et que tant que l'image n'est pas survolée avec la souris, le contenu du sous-menu est invisible et illisible (il a l'attribut CSS display=none).

Le résultat est le suivant :

Sans images, le site devient abscons !

Le lecteur d'écran passe donc outre le bloc entier de navigation et aucune expérience alternative n'est possible. "Circulez, y a rien à voir !" comprend le lecteur d'écran. Les modules sont tout simplement inaccessibles pour une personne ne se servant pas de son écran.

Bloquant !

[EDIT du 2 avril 2018] Le site n'a plus du tout la même apparence, vous ne pourrez pas reproduire ce comportement.

12) Lire et partager un article sur l'accessibilité

Nous avons apprécié ce comparatif du W3C concernant les captchas. Ce tableau permet d'identifier les avantages et inconvénients de chaque système du point de vue de leur accessibilité.

13) Lire et partager une vidéo sur l'accessibilité + 22) Comprendre l'importance du HTML sémantique

Cette vidéo, réalisée par les développeurs de Google Chrome, permet de comprendre l'utilité des balise HTML sémantiques.

Prenant analogique d'une théière, qui nous permet d'un coup d'oeil de comprendre comment nous pourrons nous en servir (présence d'une anse, d'une poignée de couvercle...), le speaker met en avant l'importance de l'utilisation des balises qui, en tant que telles, nous laissent deviner la manière dont on va pouvoir interagir avec elles.

Avec JavaScript, une multitude d'éléments peuvent devenir cliquables grâce à l'attribut HTML onclick ; en revanche, les problématiques d'accessibilités nous rappellent à l'ordre. Pour une personne qui ne voit pas l'écran, il est plus compréhensible d'entendre "Nos nouveautés - Bouton" (balise button) plutôt que "Nos nouveautés - Groupe" par exemple. Cela permet par exemple de différencier un simple intitulé d'un élément cliquable.

La notion d'arbre d'accessibilité évoquée dans la vidéo est importante à retenir. Il s'agit d'un sous-ensemble du DOM qui correspond au contenu qui pourra être accessible par tout utilisateur.

14) Trouver un problème qui pourrait impacter une personne sourde

Certaines plateformes hébergeant des MOOC (cours en ligne ouverts et massifs) proposent systématiquement une transcription afin d'offrir d'autres moyen de parcourir les contenus, par exemple le site France Université Numérique (FUN) :

L'interface propose une liste de formats de téléchargement.

Mais ces facilités de consultation n'existent pas pour tous les MOOC. Le format vidéo, souvent privilégié pour son aspect convivial, est très populaire pour ce type de contenu ; en outre, il n'est pas sans rappeler les cours dispensés dans les lieux d'enseignement traditionnels. En revanche, ce parti-pris doit être compensé par des solutions alternatives afin de ne pas laisser de côté certains utilisateurs.

A noter que la transcription des contenus audiovisuels ne favorise pas seulement l'inclusion des personnes sourdes et malentendantes, mais aussi les personnes dotées d'une connexion internet à bas débit, et celles qui pour des raisons contextuelles ne peuvent pas profiter de la sortie audio de leur machine (pas d'écouteurshauts-parleurs défectueuxbureau partagé, etc.)

15) Trouver un problème qui pourrait impacter une personne daltonienne

"Vert c'est ok, jaune c'est bof, orange c'est pire, rouge c'est mal".

Voilà un code couleur simple comme bonjour (du moins dans les sociétés occidentales (saviez-vous qu'au Japon, c'est le bleu qui est utilisé en lieu et place du vert dans ce type de contexte ? C'est pour cette raison que, par défaut, les builds Jenkins réussis affichent une pastille bleue)). Mais qu'en est-il si l'on souffre d'achromatopsie, c'est-à-dire que l'on ne peut pas discerner les couleurs, quelles qu'elles soient ?

Pour effectuer ces tests, nous avons utilisé l'extension Google Chrome Colorblinding. Cette extension permet de simuler différents types de daltonismes.

Avec Jenkins, tout va bien...

Dans Jenkins, des infobulles complètent l'information portée par la seule couleur de la pastille qui donne le statut du dernier build.

L'interface de Jenkins est compréhensible même en noir et blanc.

Une autre solution par Squash TM

Autre exemple, dans Squash TM, dans l'espace d'exécution des tests, la liste du plan d'exécution des tests affiche simultanément une pastille de couleur et le texte du statut.

Sur cette interface, les pastilles de couleur n'apportent pas d'information exclusive.

Accessibilité des graphiques

En revanche, toujours dans Squash TM, si l'on consulte le tableau de bord de l'exécution, on ne comprend plus rien. Pour une personne ne voyant pas les couleurs, la légende ne permet pas de comprendre à quoi correspond chaque part du diagramme camembert.

Les niveaux de gris sont trop rapprochés pour fournir une information claire.

En outre, passer la souris par-dessus chaque part du camembert n'aide pas vraiment : le texte "Cliquer pour voir le détail" apparaît et nous invite à charger une popup qui contient bien plus d'informations que ce que nous cherchons actuellement. Attention donc aux légendes...

16) Trouver un problème qui pourrait impacter une personne qui ne peut pas utiliser ses mains

Un utilisateur de Google Docs sur Firefox ne peut pas couper, copier ou coller du texte sans passer par les raccourcis Ctrl + X, Ctrl + C et Ctrl + V. En voilà un problème qui pourrait affecter une personne se servant d'une licorne pour accéder à son clavier et qui, par conséquent, ne peut pas appuyer sur deux touches en même temps.

Google Docs affiche un message d'erreur.

Cela fait des mois que cette anomalie existe.

[EDIT du 2 avril 2018] Etonnament, ce bug est toujours d'actualité.

17) Trouver un problème qui pourrait impacter une personne dyslexique

Nous avons trouvé une liste de ces problèmes dans cet excellent article, dont nous retirons quelques bonnes pratiques :

  • Les textes justifiés doivent rester lisibles : on doit éviter de laisser de trop grandes espaces apparaître entre les mots, voire les lettres
  • Les longs textes doivent être fractionnés en petits paragraphes afin de respecter la règle 1 idée = 1 paragraphe. Les utilisateurs non-dyslexiques vous en seront également reconnaissants ! Il y a un mois, en interne, nous sommes tombés sur cet article et en avons plaisanté ensemble, tant il nous semblait illisible. Son contenu est peut-être très intéressant, mais nous ne le saurons jamais. Nous sommes exténués d'avance à l'idée de le lire.
  • Les polices sans empattements doivent être privilégiées. Les empattements, ce sont les petites "queues" qui ornementent les extrémités des lettres de certaines polices d'écriture. En anglais, on parle de serifs. Une police sans empattements est généralement plus lisible et se déchiffre avec plus de netteté.
  • Pour mettre du texte en valeur, il est préférable de le grasser plutôt que de le mettre en italique.

18) Utiliser un outil pour détecter des problèmes de contraste sur une page

Certaines maladies oculaires (comme la DMLA) ont un impact sur la sensibilité au contraste. Il faut donc veiller à ce que l'interface soit suffisamment contrastée pour être utilisable par les personnes concernées.

Pour effectuer ces tests, nous avons utilisé l'extension Google Chrome Color Contrast Analyzer, qui s'appuie sur les WCAG (Web Content Accessibility Guidelines).

Cet outil scanne une page web (ou un morceau choisi de cette page) et affiche en blanc les contours délimitant des zones suffisamment contrastées.

Le résultat n'est pas très attrayant, mais il est assez parlant. Sur cette page du site de la BCI (Banque Calédonienne d'Investissement), un bouton n'a pas été détecté, ce qui signifie que le contraste entre le vert du bouton et le blanc de son texte n'est pas assez élevé.

L'écran est affiché en grisé, seuls les contours s'affichent clairement, en blanc.

Evaluation des tests : une réflexion en passant

Un aspect un peu frustrant de ce type de test est qu'il est difficile d'évaluer la pertinence d'un tel outil quand on ne souffre pas soi-même d'une maladie affectant la sensibilité au contraste. Passe-t-on à côté d'autres problèmes ? Au contraire, verse-t-on dans la surqualité ? Pour cette fois, il nous faudra faire confiance à la notoriété des WCAG...

C'est d'ailleurs une remarque que l'on peut généraliser à un grand nombre d'outils d'accessibilité... Et de nombreuses entreprises ont cette réflexion, qui choisissent d'embaucher des testeurs ou bêta-testeurs pour trouver les bugs d'accessibilité les plus authentiques possibles.

Vivien Shotwell, sur Twitter, lance un appel pour recruter des bêta-testeurs aveugles.

19) Trouver 5 experts en accessibilité à suivre sur Twitter

  • Jenny Lay-Flurry (@jennylayfluffy), CAO (chief accessibility officer) chez Microsoft
  • Marco Zehe (@MarcoInEnglish), ingénieur en qualité et en accessibilité chez Mozilla, et aveugle de naissance
  • @goetsu, directeur général et expert accessibilité numérique chez Temesis, société de conseil et de formation sur la qualité et l'accessibilité des sites et des applications web
  • @webaxe, un compte très actif sur les techniques d'accessibilité
  • @googleaccess, le compte de l'équipe d'accessibilité de Google

20) Ecrire une checklist pour tester rapidement l'accessibilité

Nous pensons que les tests suivants permettent déjà d'avoir un bon aperçu de l'accessibilité d'une page, en un temps assez court.

  • Désactiver les images dans le navigateur et vérifier que la page web reste compréhensible
  • Vérifier que les images signifiantes (et tout particulièrement les images cliquables) ont un attribut "alt" qui permet de savoir ce qu'elles représentent
  • Vérifier que les images purement décoratives (puces, décoration de bouton...) ont un attribut "alt" vide ou nul afin de ne pas polluer le contenu de la page
  • Vérifier que des liens d'évitement existent.
  • Vérifier que les liens d'évitement sont accessibles dans un ordre cohérent.
  • Vérifier qu'un daltonien peut saisir les mêmes informations qu'une personne pouvant voir les couleurs
  • Vérifier que le contraste est suffisant
  • Vérifier que les boutons sont bien des objets "button"
  • Vérifier qu'aucun texte important (et a fortiori aucun titre) n'est "emprisonné" dans une image
  • Vérifier que les vidéos et les contenus audio ont une transcription

21) Observer le focus qui se fait sur une page web lorsqu'on tape sur la touche de tabulation

Des liens d'évitements, ou liens de navigation interne, sont parfois présents sur les pages web. Ce sont des raccourcis qui permettent d'accéder directement à la navigation, au contenu, au moteur de recherche ou tout autre élément important que le concepteur du site web aura voulu rendre plus facilement accessible.

Concrètement, l'utilisateur malvoyant ou non-voyant arrive sur le site web et appuie sur la touche de tabulation pour entendre, grâce au lecteur d'écran, les options qui s'offrent à lui. Dès qu'une option répond à son besoin, il clique sur la touche Entrée et a ainsi raccourci son chemin de navigation.

Un exemple sur le site d'Alsacréations : une fois la page chargée, on appuie une fois sur la touche de tabulation et un menu de liens d'évitement apparaît.

Les liens d'évitement s'affichent proprement, même pour un utilisateur voyant.

Pour en savoir plus sur l'attribut HTML tabindex, se référer à la doc de la fondation Mozilla.

23) Trouver des informations sémantiques manquantes (par exemple des headers, liens et boutons)

Nous avons été surpris de voir comme il est courant de tomber sur des sites sans titre principal (balise h1). Pour n'en citer qu'un, le site d'Air Calédonie.

Il est pourtant important de proposer une hiérarchie de titres cohérente pour faciliter la navigation des personnes utilisant un lecteur d'écran.

24) S'enquérir des aspects juridiques de l'accessibilité

En France, l'obligation légale d'accessibilité web ne concerne pour l'heure que les administrations étatiques et les grandes entreprises. Elle est formalisée par l'article 47 (mis à jour en 2016 par l'article 106) de la loi du 11 février 2005 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées.

Il est étrange de voir que l'amende ne peut excéder les 5000 euros par an et par applicatif. En effet, il n'est pas déraisonnable de penser qu'un projet de mise en conformité pourrait coûter plus cher que cela. Si l'on décortique la loi comme l'a fait Opqast, on se rend compte également qu'un site peut très bien éviter la sanction en déclarant qu'il n'est pas conforme, mais que des mesures seront prises afin qu'il le soit.

Après décodage, on voit donc qu'il reste donc de la route à faire pour rendre l'accessibilité obligatoire.

25) Etudier la démonstration "Avant / Après" du W3C

Cette démo est disponible ici. Elle propose à l'utilisateur d'observer alternativement le mauvais exemple et la vue optimisée.

L'exemple à éviter est un site web d'apparence ordinaire.

Visuellement, quelques détails changent entre les deux versions.

Très concrète, cette présentation permet d'identifier rapidement, par contraste ou grâce aux annotations, les mauvaises pratiques. Par exemple, en se basant sur les écran ci-dessus, on se rend compte rapidement qu'utiliser des caractères typographiques pour dessiner des symboles (ici, une flèche) expose potentiellement les utilisateurs de lecteurs d'écran à des séries insensées de mots telles que "tiret, tiret, tiret, chevron fermant".

Cela laisse aussi penser que l'utilisation de smileys, de plus en plus populaire y compris sur les sites d'entreprises, présente un risque pour l'accessibilité.

Cette page du site de site de la SNCF contient un smiley.

26) Rapporter un problème d'accessibilité sur un site web & 29) Trouver 3 anomalies d'accessibilité

La Province Sud... et de 1 !

La fonctionnalité de liens d'évitement, dont nous parlions précédemment, est présente par défaut sur bon nombre de templates, encore faut-il le savoir pour éventuellement adapter le lien interne...

Revenons sur le site de la Province Sud... un lien d'évitement est disponible, mais d'une part il est en anglais contrairement au reste du site, d'autre part il ne renvoie vers aucune barre de navigation. Il pointe vers l'ancre "main-menu", qui n'existe pas sur la page. Dommage !

Le lien d'évitement affiche le texte anglais "Jump to navigation".

Il s'agit d'un bug d'accessibilité parce que dans ce cas, le lien d'évitement ne fournit pas un raccourci mais une impasse.

La douane de Nouvelle Calédonie... et de 2 !

Comme souvent en accessibilité, un bug bloquant qui repose sur un tout petit détail. Sur le site de la douane, une image de nautile se présente comme un portail de liens.

Les liens s'organisent en cercle le long de l'image de nautile.

Chaque lien englobe une petite image (une pastille rouge). Et chacune de ces images a un texte alternatif nul. Le lecteur d'écran lit donc, lorsque l'on parcourt cette page : "Lien, lien, lien, lien, lien, lien". Pas très parlant !

Le code HTML se révèle peu propice à l'accessibilité.

C'est un bug d'accessibilité car le manque d'informations concernant ces liens pénalise l'utilisateur ne se servant pas de son écran. Dans le meilleur des cas, l'utilisateur trouvera l'information qu'il recherche en passant un temps laborieux à parcourir chacun des mystérieux liens. Dans le pire des cas, découragé, il abandonnera.

L'OPT... et de 3 !

On voit bien, sur le site de l'OPT, qu'un premier appui sur la touche de tabulation fait apparaître un lien "Aller à la navigation". Celui-là fonctionne sans problème. Cliquer dessus nous amène directement au bandeau de navigation où se trouvent les onglets "Téléphone", "Internet", "Courrier"...

Le lien d'évitement s'affiche en haut à gauche de la page.

On remarque que ce lien correspond au tout premier contenu présent dans la balise body du DOM.

Si l'on se fie à ce qu'on voit dans le code HTML, le lien qui se trouve juste après dans le DOM semble inviter l'utilisateur à accéder directement au contenu... Question à 1000 francs pacifiques : un deuxième appui sur la touche de tabulation permettra-t-il d'y accéder directement ?

La réponse est... non !

Le focus se fait sur le lien Twitter qui se trouve dans une barre latérale dédiée aux liens vers les réseaux sociaux. Pourquoi cela ? Parce que l'attribut tabindex, que l'on voit dans le code ci-dessus, a été défini à "1" sur les boutons de cette barre.

Comme ces boutons apparaissent plus loin dans le DOM que le lien "Aller à la navigation", le focus est fait sur eux après ce lien. Mais comme leur tabindex est plus petit que celui du lien "Aller au contenu", le focus est d'abord fait sur eux, puis sur ce lien.

Il est probable que la barre de partage sur les réseaux sociaux ait été intégrée au site web après coup, sans que le code de ce module (en l'occurrence un module Drupal) ait été personnalisé. Un élément corrobore cette hypothèse : le site web du Gouvernement de la Nouvelle Calédonie, également en Drupal 7, utilise en effet ce même module, et l'attribut tabindex des différents boutons y est également renseigné à "1".

On retrouve le même bout de code sur le site du gouvernement que sur le site de l'OPT.

Il s'agit d'un bug d'accessibilité, parce qu'il est très improbable qu'un utilisateur malvoyant ou aveugle ait envie de partager sur Facebook une page dont il n'a pas encore lu le contenu.

27) Apprendre à utiliser le lecteur d'écran de son téléphone portable

Nous avons choisi l'application Google TalkBack, qui figure parmi les plus populaires de sa catégorie. Si l'on se fie à l'étude réalisée par WebAIM (l'éditeur de WAVE), 17,8% des personnes utilisant un lecteur d'écran l'auraient sélectionné. L'application arrive derrière VoiceOver, l'équivalent pour iPhone.

A l'issue d'un court didacticiel, on peut se lancer ! Toucher l'écran permet de lire les informations qui s'y trouvent, toucher deux fois permet de cliquer. Pour scroller, il faut utiliser deux doigts au lieu d'un. Le menu général de TalkBack peut être appelé en traçant un L sur l'écran. Ce menu propose des options telles que "Lire à partir du haut de la page", "Répéter le dernier énoncé", "Copier le dernier énoncé dans le presse-papiers"...

Finalement, l'intégration est tellement bien faite que nous pouvons aisément réaliser quelques actions de lecture sur diverses applications.

28) Télécharger un document texte et chercher ses problèmes d'accessibilité

De même que les pages web, les documents texte peuvent être plus ou moins accessibles. Prenons par exemple le livre blanc Accessibility is not a feature, de Sapient. Toutes les images signifiantes (c'est-à-dire non purement décoratives) contiennent un texte alternatif, ce qui préserve l'intégrité du message délivré par le document. Quant au pied de page, qui contient des informations sur le document, il est conçu pour ne pas être lu par le lecteur d'écran, car cela rendrait le propos incompréhensible.

Ce n'est pas le cas d'un autre livre blanc, Le Guide de l'open data pour les communes, publié en juin 2016. Dès les premières pages, on constate deux bugs d'accessibilité : premièrement, la lecture systématique du pied de page par le lecteur d'écran, d'autre part le sommaire que NVDA (pour NonVisual Desktop Access) est amené à lire d'une drôle de façon : "Qu’est-ce qu’une donnée personnelle, une donnée sensible ? Quatre-vingt-quatre points 13."

 

30) Evaluer la complexité du contenu d'un site web avec l'application Hemingway

Cette application est conçue pour les contenus en anglais. Non seulement elle détecte les phrases trop longues, mais elle propose des alternatives aux tournures trop lourdes (adverbes, voie passive). Pour certains mots, le site propose des synonymes plus usuels.

En français, le service en ligne Cordial propose des fonctionnalités similaires en plus d'une correction orthographique.

Conclusion

Au cours de ce défi, tels des caméléons, nous avons essayé d'explorer un maximum de situations de handicap. De cette plongée dans le monde de l'accessibilité, nous ramenons de précieux axes pour évaluer la qualité des logiciels d'une manière nouvelle, une boîte à outils de logiciels de test, mais aussi une plus grande empathie pour les utilisateurs. En effet, une idée s'est imposée à nous chemin faisant : l'accessibilité concerne beaucoup plus d'utilisateurs qu'on le pensait au premier abord. Chaque utilisateur, à des niveaux qui lui sont propres, tire profit des mesures d'accessibilité que prennent les sites web. Raison de plus pour commencer à implémenter les bonnes pratiques. Au boulot !

Autres articles sur le thème de l'accessibilité

Malvoyance - vis ma vie numérique avec Marie-Françoise Pierre

30 days of accessibility testing

Un avis ? Un commentaire ?

Cet espace est pour vous.