Transcription de conférence « Et si on laissait les utilisateurs et les utilisatrices personnaliser l’interface ? » — première partie

Début 2020, nous avons créé la conférence « Et si on laissait les utilisateurs et les utilisatrices personnaliser l’interface ? », qui se situe à mi-chemin entre design UX et développement web. Nous l’avons donnée à deux reprises : à Touraine Tech puis au DevFest Brest.

Même si cela semble maintenant remonter à une éternité, nous partageons aujourd’hui la transcription de cette conférence pour deux raisons. D’une part, il y est question d’accessibilité numérique à travers un prisme particulier, et plutôt inhabituel : les handicaps cognitifs et mentaux.

Penser l’accessibilité numérique pour les personnes qui sont concernées par ces handicaps-là nous passionne, même si – ou parce que – c’est un sujet encore relativement méconnu. Outre la découverte des besoins des personnes ayant un handicap cognitif ou mental, cette conférence propose aussi d’envisager l’accessibilité numérique comme source d’innovation technologique, émanant de celles et ceux qui en ont l’usage.

D’autre part, sauf erreur de notre part, cette conférence n’a pas été enregistrée. En publiant les slides et maintenant la transcription de cette conférence, nous entendons partager nos recherches avec un plus large public, dans l’espoir que cela alimente d’autres travaux.

Voici donc la première partie de cette transcription. Comme cette conférence est très riche, la seconde partie fait l’objet d’un autre article.

Bonne lecture !

Les handicaps cognitifs et mentaux recouvrent une très grande variété de déficiences et de besoins, en général mal connus, et peu abordés dans notre milieu professionnel.

Pourtant, ces besoins ouvrent des perspectives créatives innovantes en matière de design et de développement centrés utilisateurs.

Raison d’être de cette conférence

Handicaps concernés

Pour les personnes présentant un handicap mental, intellectuel ou cognitif, ou des difficultés d’apprentissage, l’utilisation du numérique peut être un véritable défi.

Ces troubles ont en effet des conséquences importantes sur la lecture, la compréhension et l’utilisation des contenus web.

Les déficiences cognitives et intellectuelles vont questionner les problématiques de décodage et de compréhension des contenus. Cela exige une approche et des solutions qui vont bien au-delà des problèmes d’accessibilité posés par les déficiences sensorielles et physiques [1].

Voici de quoi il s’agit, en particulier :

  • Troubles du décodage, et troubles de l’acquisition et la manipulation du langage écrit :
    • Dyslexie, dysorthographie ;
  • Troubles de la compréhension écrite et orale :
    • Paralysie cérébrale,
    • Dysphasie.
  • Troubles de l’attention avec ou sans hyperactivité ;
  • Troubles de la mémoire à court, moyen ou long terme :
  • Troubles de la parole :
    • L’aphasie est la perte partielle ou totale de la faculté de s’exprimer, et de comprendre le langage qu’il soit parlé ou écrit.
    • Sclérose latérale amyotrophique, Maladie de Charcot : la dégénérescence induite par ces maladies entraîne une incapacité physique à parler (partielle ou totale).
  • Déficiences intellectuelles ;
  • Troubles du spectre autistique.

Ajoutons à cela que les capacités cognitives tendent à diminuer avec le vieillissement.

Besoins sur le web et sur mobile

Les personnes concernées par ces déficiences ont des besoins particuliers par rapport aux interfaces numériques, notamment :

  • Pouvoir adapter les paramètres typographiques ;
  • Comprendre les textes écrits ;
  • Comprendre les bandes-son des vidéos ;
  • Comprendre les actions attendues (formulaires, boutons) ;
  • Pouvoir réduire les surcharges d’information ;
  • Pouvoir contrôler les contenus en mouvement (Il peut également être difficile de maintenir son attention face à des contenus en mouvement ou face à des changements de contextes imprévus [2].

Une difficulté intrinsèque

Parallèlement à ces besoins, l’utilisation du numérique représente une difficulté intrinsèque pour les personnes handicapées mentales ou cognitives.

En effet, on y utilise un langage souvent technique et une iconographie qui demandent à l’utilisateur ou à l’utilisatrice des habiletés de décodage et d’organisation de l’information.

De même, les interfaces actuelles, en particulier sur périphériques tactiles, requièrent des gestes particuliers qui demandent une motricité fine, mais aussi la capacité de se repérer dans l’espace et le temps.

Les interfaces mal adaptées à l’accessibilité peuvent donc être difficiles à utiliser pour certaines personnes, voire incompréhensibles et donc inutilisables faute d’adaptations.

En outre, on observe des manques dans les standards d’accessibilité pour répondre à ces différents handicaps :

  • Dans WCAG (Web Content Accessibility Guidelines, les Règles pour l’accessibilité des contenus web), la majeure partie des critères concernant les troubles mentaux ou cognitifs sont facultatifs, de niveau triple A (AAA) ;
  • Au niveau simple A et double A (AA), ces handicaps ont été sous-représentés jusqu’à présent par les normes et référentiels d’accessibilité (y compris WCAG 2.1 [3] et le RGAA 4 en France). Néanmoins, WCAG 2.2 propose de nouveaux critères qui prennent davantage en compte les besoins liés aux troubles cognitifs et intellectuels [4] ;
  • Il y a aussi des besoins utilisateurs spécifiques qui ne sont pas encore couverts par les standards, comme le reconnaît le W3C dans le document Cognitive Accessibility User Research (« This document provides a basis for subsequent work to identify gaps in current technologies »).

Nous développerons ces points dans la seconde partie de cette transcription, « Demain : vers une standardisation de la personnalisation des interfaces ».

Notre objectif

Néanmoins, on dispose déjà d’un certain nombre de critères et d’outils pour commencer à concevoir et à développer des interfaces qui prennent en compte les besoins des personnes handicapées mentales, cognitives ou intellectuelles.

Notre objectif est donc double.

  • Tout d’abord, nous souhaitons faire un tour d’horizon des mécanismes d’adaptation qui existent déjà pour répondre aux besoins des personnes handicapées cognitives ou mentales, en présentant leur variété ainsi que leurs limites.
  • Ensuite, nous vous présenterons les nouveaux critères d’accessibilité qui vont dans le sens d’une standardisation de la prise en compte de ces besoins, avec des exemples de code que vous pouvez mettre en œuvre dès à présent.

Il y a encore beaucoup de travaux en cours, mais tout ce que nous allons voir ensemble pourrait bien dessiner le futur de l’accessibilité et de l’expérience utilisateur.

Première partie – Aujourd’hui : ce qui existe déjà (et qui est déjà bien) (mais pas suffisant)

Mécanismes d’adaptation système

Des mécanismes d’adaptation existent déjà, ou sont pris en charge nativement, sur les ordinateurs.

Windows, macOS et Linux mettent à disposition 3 technologies d’assistance par défaut : la loupe d’écran, le clavier virtuel et le lecteur d’écran.

Loupe d’écran

La loupe d’écran est un système de zoom qui permet d’agrandir ce qui est affiché à l’écran pour faciliter la lecture et afficher moins d’éléments à la fois.

Elle sert aux personnes déficientes visuelles pour qui lire des textes trop petits est difficile, voire impossible, ou génère des migraines à la longue.

Tweet de Hellgy. La page web est affichée sans loupe d’écran.
La même page web est affichée avec la loupe d’écran réglée sur 200% dans Windows 10.

Clavier virtuel

Le clavier virtuel permet de remplacer le clavier physique, notamment pour les personnes qui ne peuvent pas du tout se servir de leurs mains.

Elles l’utilisent par exemple avec un système d’eye tracking, un contacteur au souffle ou d’autres types de contacteurs.

Clavier virtuel Windows 10.

Lecteur d’écran

Si le lecteur d’écran sert principalement aux personnes aveugles ou très malvoyantes, il est aussi utilisé par certaines personnes ayant un handicap cognitif.

Par exemple, des personnes ayant des difficultés de lecture peuvent se servir d’un lecteur d’écran : elles vont préférer que la synthèse vocale lise à leur place, en particulier les textes longs.

Navigateurs web

Les navigateurs web eux-mêmes peuvent être la première barrière à la navigation sur Internet pour les personnes handicapées mentales [5].

En effet, les navigateurs modernes sont des logiciels complexes avec de nombreuses entrées de menu qui, soit ne sont pas comprises, soit chargent la mémoire des utilisateurs et utilisatrices, compte tenu du nombre d’informations textuelles disponibles.

Néanmoins, les navigateurs offrent déjà des options de personnalisation qui peuvent répondre à certains besoins.

Personnalisation des couleurs

Par exemple, on peut changer les couleurs de texte et d’arrière-plan, la couleur des liens… pour les personnes déficientes visuelles dont la rétine perçoit mal les couleurs, et qui ont besoin de contrastes particuliers pour lire confortablement.

Personnalisation du texte (taille, police)

On peut aussi agrandir la taille du texte par défaut.

(C’est là où vous avez tout intérêt à intégrer vos CSS avec des unités relatives, comme em, rem, etc., même si ce n’est plus demandé par le RGAA 4.)

Par exemple : Marian Foley, responsable éditoriale pour le gouvernement britannique, ne peut lire confortablement que si le texte est en gros caractères et de couleur bleue sur fond pêche.

Mozilla Firefox permet notamment de configurer la couleur du texte, la couleur d’arrière-plan, la couleur des liens et la couleur des liens déjà visités.

Navigateurs adaptés

Outre les navigateurs web grand public, il existe aussi des navigateurs web spécialisés, adaptés à certains types de handicaps mentaux, cognitifs et intellectuels.

Malheureusement, ces navigateurs semblent peu répandus et difficilement accessibles, ou laissés bien souvent à l’état de prototype de recherche.

Néanmoins, pour notre culture générale de l’accessibilité, voici quelques exemples.

WebTrek

WebTrek est un navigateur payant, édité par une société privée. Parmi ses fonctionnalités notables, citons :

  • le lecteur d’écran intégré ;
  • la possibilité d’utiliser une photo tirée d’une page web comme très grand bouton de favoris sur l’écran d’accueil de l’utilisateur ou de l’utilisatrice ;
  • une page d’accueil avec des boutons illustrés permettant d’accéder en un clic à une sélection de contenus ;
  • l’accès à un moteur de recherche par images, basé sur Google.

WWAAC

Financé par la Commission européenne, WWAAC est un navigateur web alternatif conçu spécialement pour les personnes ayant des déficiences cognitives et/ou liées à la communication.

Voici ses fonctionnalités principales :

  • personnalisation de la page d’accueil : il est possible de la remplir avec les sites préférés de l’utilisateur ou de l’utilisatrice. Le bouton « Accueil » ramène toujours à cette page ;
  • lecteur d’écran intégré. L’utilisateur peut choisir de faire lire mot par mot, phrase par phrase, paragraphe par paragraphe, ou tout d’un coup, et autant de fois que l’utilisateur le souhaite. En plus, un cadre de couleur indique à l’utilisateur l’élément qui est lu en temps réel pour l’aider à se repérer ;
  • utilisation au choix avec un switch, deux switches, avec ou sans scan automatique (un curseur passe à travers tous les boutons de la page permettant à l’utilisateur de les activer avec son switch), avec une souris ou tout autre dispositif de pointage, ou bien via un clavier standard ou adapté ;
  • personnalisation des barres d’outils et des boutons du navigateur. Ils sont entièrement configurables (a priori par la personne accompagnant l’utilisateur ou l’utilisatrice). Il est possible de décider combien de boutons doivent apparaître à l’écran, leur taille, leur intitulé ou encore leur emplacement ;
  • fonctionnalité de résumé : création d’un résumé de la page web en cours de consultation en se basant sur le titre de la page, les titres HTML (h1, h2, etc.), les cadres et les liens contenus dans le site (sauf les liens intitulés « click here »).

Webwide

Webwide est un navigateur payant qui permet de linéariser et simplifier les sites aux mises en page complexes, et de remplacer leur contenu par des symboles.

La bibliothèque de symboles utilisée, Widgit Symbols, contient 35 000 mots. Certes, certains mots ne pourront jamais être transcrits par une image (par exemple : les noms propres ou le jargon), la combinaison de symboles, photographies et informations vocalisées rendent l’information bien plus accessible aux personnes empêchées de lire.

Note : Widgit propose aussi différents outils qui permettent d’écrire avec des mots systématiquement associés à un symbole, notamment SymWriter.

Leur compte Instagram présente de nombreux exemples de contenus pédagogiques adaptés à un public handicapé cognitif, par exemple cette recette de cuisine découpée pas à pas grâce à des symboles.

EdWeb

Développé par The School of Informatics de l’Université de Manchester, EdWeb [6] linéarise les contenus des pages web, pour que la page puisse être lue d’une traite de haut en bas.

Si ce navigateur adapté a été conçu initialement pour des personnes aveugles naviguant avec un lecteur d’écran, en particulier les novices, il est aussi apprécié par des personnes malvoyantes qui trouvent ça plus simple que consulter une page web classique lue avec une loupe d’écran, qui nécessite beaucoup d’allers-retours.

L’interface simplifiée d’EdWeb pourrait également convenir aux personnes ayant des handicaps mentaux ou cognitifs : en effet, elle présente un nombre très restreint de boutons, accompagnés d’une barre d’adresse affichée en très gros caractères.

Sur le web

CSS alternatives

Il est possible de définir plusieurs feuilles de styles dans l’en-tête head d’un document HTML, notamment des feuilles de styles alternatives à la feuille de style principale, à l’aide du mot-clé « alternate ».

Par exemple :

<link rel="alternate stylesheet" href="css/contrastes-inverses.css" type="text/css" title="Contrastes inversés" />

Dans Mozilla Firefox, on peut sélectionner telle ou telle feuille de styles depuis le menu « Affichage », puis le sous-menu « Style de la page ».

En théorie, cela permet aux personnes ayant besoin de personnaliser l’interface de pouvoir le faire.

Il est également possible de configurer une CSS personnalisée en passant par les dev tools du navigateur.

Limites des CSS alternatives

En pratique, il y a néanmoins trois limites de taille :

  • le choix de l’utilisateur ou de l’utilisatrice n’est pas persistant, et est réinitialisé dès que l’on rafraîchit la page ou que l’on change de page ;
  • le support navigateurs n’est pas homogène :
    • Internet Explorer n’a proposé cette fonctionnalité que depuis IE8. Accessible via « Affichage > Style de la page » [7],
    • Safari ne le supporte pas, pas plus que Chrome, dans lequel il faut passer par une extension. Cela rend les deux navigateurs non conformes sur le critère 1.7 des UAAG (User Agent Accessibility Guidelines), d’ailleurs.
  • ce n’est pas intuitif. Dans Firefox, il faut déjà savoir que cette fonctionnalité existe, et réussir à la trouver. Cela demande une certaine maîtrise de l’outil, et des capacités cognitives particulières (capacité de mémoriser le nom, le fonctionnement et l’emplacement de cette option).

Feuilles de styles utilisateur

Par ailleurs, certains agents utilisateurs offrent une autre solution, en permettant de charger sa propre feuille de style dans le navigateur.

Là encore, Firefox se distingue en offrant cette fonctionnalité nativement. Cependant, pour cela il faut aller modifier son profil technique dans le navigateur, ce qui peut représenter un immense obstacle pour des personnes qui ne sont pas geeks.

C’est un peu plus simple dans Safari, à qui il est possible de demander d’utiliser une feuille de styles personnalisée en permanence directement en modifiant les paramètres du navigateur.

Dans Safari : menu « Préférences » > onglet « Avancées » > option « Feuilles de style ».

Enfin, il existe des extensions, comme Stylish ou TamperMonkey, qui peuvent permettre d’utiliser une feuille de style personnalisée ou de créer la sienne.

Néanmoins, cela requiert là encore un certain nombre de connaissances techniques et de capacités cognitives.

Media queries et paramètres système

Contrastes augmentés ou renforcés

Depuis Windows 7, il est possible d’activer un mode « Contrastes augmentés » (high contrast) : s’il est activé, cela applique un thème de couleurs adapté à Windows, en réduisant le nombre de couleurs système au strict minimum, et avec des contrastes renforcés.

Il existe de nombreuses raisons qui peuvent pousser quelqu’un à activer le mode « Contrastes augmentés » :

  • lire plus facilement les éléments affichés à l’écran ;
  • réduire le bruit visuel pour mieux se concentrer sur ce qui a de l’importance ;
  • atténuer la fatigue oculaire ou la sensibilité à la lumière, prévenir les migraines ;
  • ou simplement par goût, pour se motiver.

Windows propose des thèmes tout prêts, mais les personnes qui en ont besoin peuvent aussi personnaliser les couleurs comme bon leur semble (qu’elles présentent un contraste conforme WCAG ou pas), notamment à l’aide du raccourci clavier Left Alt + Shift + Prt Scrn.

Côté CSS

Côté CSS, il est possible de détecter si ce paramètre est actif grâce à une media query non standard, introduite avec Windows 8 :

@media screen and (-ms-high-contrast: active) { /* All high contrast styling rules */ }
@media screen and (-ms-high-contrast: black-on-white) { /*  */ }
@media screen and (-ms-high-contrast: white-on-black) { /*  */ }

En théorie, cela devrait permettre d’adapter automatiquement un site web ou une web app aux préférences de contrastes réalisées par l’utilisatrice sur son ordinateur.

Mais attention : cette media query n’est plus supportée depuis Edge 18. Il est donc déconseillé de l’utiliser en production.

À la place, surveillons de près la spécification CSS 5, qui prévoit l’ajout d’une nouvelle media query « prefers-contrast », qui permet de détecter si l’utilisateur ou l’utilisatrice a configuré son système pour utiliser un contraste élevé. À l’heure actuelle, très peu d’agents utilisateurs implémentent cette fonctionnalité [8].

En savoir plus :

Démonstration

Voir une démonstration de la détection par media query du mode « Contrastes augmentés ». Dès que vous activez le mode « Contrastes augmentés » sur votre ordinateur, la slide change de couleur automatiquement.

Couleurs inversées

La media query inverted-colors, quant à elle, peut théoriquement être utilisée pour tester si l’agent utilisateur ou l’OS sont configurés pour inverser les couleurs.

Cependant, cela a des effets indésirables, car cela inverse également les images et les ombres (propriétés CSS text-shadow et box-shadow).

@media screen and (inverted-colors: inverted) {
 img { filter: invert(100%); }
 * { text-shadow: none !important; box-shadow: none !important; }
}

Pour intéressante que soit cette fonctionnalité, cette media query n’est supportée que par Safari 9.1 (depuis macOS X 10.7 Lion) et Safari sur iOS.

Capture d’écran des réglages de macOS, rubrique « Accessibilité », onglet « Affichage », option « Inverser les couleurs » cochée.

Et cela risque de ne pas évoluer avant un moment, étant donné que la standardisation de cette media query a été repoussée au niveau 5 de la spécification Media Queries, toujours en brouillon.

Démonstration

Voir une démonstration de la détection par media query du mode « Contrastes inversés », à tester sur macOS avec Safari. Dès que vous activez le mode « Contrastes inversés » sur votre ordinateur, la slide change de couleur automatiquement.

D’autres media queries

Il existe bien d’autres media queries servant à détecter les paramètres effectués sur l’OS par l’utilisateur ou l’utilisatrice :

Mais le support navigateurs de certaines de ces media queries est encore trop insuffisant aujourd’hui pour pouvoir s’en servir en production.

Cela ne suffit pas ni pour garantir une expérience utilisateur accessible, ni pour atteindre la conformité RGAA ou WCAG, en tout cas à ce jour.

En savoir plus :

Sur mobile : les applications mobiles et l’augmentation des paramètres utilisateur

Notons enfin que les systèmes d’exploitation (OS) mobiles mettent également à disposition des paramètres de personnalisation de l’interface côté utilisateur, ainsi que des méthodes pour récupérer ces préférences côté développement.

Sur iOS par exemple, il est possible de :

  • renforcer les contrastes des textes et des composants d’interface ;
  • réduire ou de supprimer la transparence des éléments affichés sur des aplats semi-transparents ;
  • réduire les animations et les mouvements ;
  • ajouter de la graisse sur tous les textes affichés à l’écran ;
  • mettre en évidence tous les éléments interactifs.

À l’avenir, peut-être que ce type de réglages sera pris en compte par défaut dans les phases de conception et de développement des applications mobiles, comme le suggère Peter Heery du TPGi dans l’article Short note on accommodating the users display preferences on iOS.

Proposer un sélecteur de styles

Même si plusieurs fonctionnalités sont déjà disponibles dans nos périphériques et nos navigateurs, on se rend donc compte que :

  1. rien ne fonctionne vraiment bien partout ;
  2. rien n’est homogène d’un OS à l’autre ou d’un navigateur à l’autre ;
  3. rien ne semble facile d’accès, a fortiori pour des personnes ayant des problèmes de compréhension, de lecture et d’habileté.

Face à ce constat, et aux besoins immédiats des personnes en situation de handicap, il faut bien commencer à prendre en charge nous-mêmes ces mécanismes d’adaptation de l’interface.

C’est ainsi qu’est né AccessConfig, un sélecteur de styles léger, gratuit et open source qui permet aux personnes en situation de handicap d’adapter votre site à leurs besoins.

Note : en anglais, « sélecteur de styles » se dit « style switcher ».

AccessConfig

En nous appuyant sur la technique WCAG G174 (Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast), nous avons créé chez Access42 AccessConfig.

Ce sélecteur de styles open source est configurable et visuellement personnalisable.

Il prend la forme d’un bouton à ajouter sur votre site web ou votre application web.

En activant ce bouton, une fenêtre modale s’affiche à l’écran et permet aux personnes qui en ont besoin de personnaliser l’affichage de l’interface, par exemple :

  1. renforcer ou inverser les contrastes ;
  2. annuler la justification des textes ;
  3. remplacer les images porteuses d’information par leur alternative ;
  4. remplacer les polices de caractères par une police adaptée, qu’ont l’habitude d’utiliser certaines personnes dyslexiques.

AccessConfig permet des gains utilisateurs importants à faible coût, en palliant certaines des limites propres aux autres solutions évoquées jusqu’à présent :

  1. c’est un outil conçu et développé avec l’accessibilité comme priorité absolue : AccessConfig est conforme WCAG 2.1 et RGAA 4 ;
  2. la présence d’un cookie permet de rendre les choix de l’utilisateur ou de l’utilisatrice persistants (cela résout la limite technique des CSS alternatives) ;
  3. AccessConfig est développé avec des technologies standards (HTML, CSS, JavaScript basique), qui garantissent une interopérabilité optimale ;
  4. il est 100 % personnalisable : adaptation possible à toute charte graphique, modification des intitulés, choix des options à afficher ;
  5. c’est un outil open source, donc il est possible de contribuer et de le faire évoluer ;
  6. il est gratuit, et est relativement rapide à mettre en œuvre.
À noter

AccessConfig ne se substitue pas aux réglages d’accessibilité du navigateur ou du système d’exploitation, mais les complète ou les remplace s’ils s’avèrent inefficaces.

Il peut permettre d’être conforme au critère de succès 1.4.3 Contrast (Minimum) de WCAG (technique G174).

Démonstration

Tester AccessConfig en cliquant sur le bouton « Paramètres d’accessibilité » situé en haut de notre page de test, puis tester les différentes options disponibles.

AccessConfig en action : options pour renforcer ou inverser les contrastes, augmenter l’interlignage, remplacer les images porteuses d’information par leur alternative texte, adapter la police de caractère avec une police adaptée à la dyslexie, et/ou supprimer la justification.
Limites

Les sélecteurs de styles comme AccessConfig présentent néanmoins certaines limites.

D’une part leur présence dépend du bon vouloir des éditeurs de sites et applis web. Les personnes en situation de handicap à qui ils peuvent servir ne les retrouvent pas systématiquement partout.

D’autre part la mise à jour de ce type d’outil est sporadique, car il s’agit souvent de projets gratuits et open source qui ne génèrent aucun ROI (retour sur investissement).

Enfin, côté UX, deux obstacles ont été identifiés :

  1. la signalétique de ce composant d’interface ;
  2. la métacognition des personnes à qui ce type d’outil peut servir.
Signalétique

Comment signaler la présence de cet outil d’adaptation de façon à ce qu’il soit facilement identifié par les personnes qui en ont besoin ?

Par défaut, la présence d’AccessConfig par un intitulé « Paramètres d’accessibilité », mais des tests utilisateurs ont révélé qu’il s’agit d’un vocabulaire technique qui peut poser des problèmes de compréhension.

De plus, des tests utilisateurs auprès de personnes aphasiques réalisés par un laboratoire de recherche anglais [9] ont révélé qu’il leur est plus facile d’identifier un composant d’interface s’il y a à la fois un intitulé et une icône.

Si la personne ne comprend pas la fonction du bouton, ni son icône ni son étiquette textuelle, il y a alors peu de chance pour qu’elle l’active.

Dans ce cas : quel intitulé serait plus parlant ? Et quel pictogramme choisir ?

Choisir un intitulé simplifié ou une iconographie adaptée n’est pas évident : il est impossible de simuler un handicap mental ou cognitif et de se « mettre à la place » des personnes concernées pour savoir si tel mot ou tel symbole serait plus facile à comprendre qu’un autre.

Toute démarche de simplification du langage doit nécessairement impliquer un échantillon de personnes présentant un handicap intellectuel.

Or, si les sélecteurs de styles commencent à se répandre sur le web, il existe une grande variété d’intitulés et de signalétiques différentes.

Bouton contenant un pictogramme représentant les handicaps visuels.

Deux boutons contenant respectivement une lettre A souligné, et une lettre A avec un contraste négatif.

Bouton contenant le texte « Changez les couleurs de fond et de texte ».

Bouton contenant le pictogramme « œil barré » et le texte « Accessibilité ».

On peut émettre l’hypothèse que cette disparité des signes devant permettre aux utilisateurs et utilisatrices concernées d’identifier rapidement la fonctionnalité ne leur rend la tâche que plus difficile encore, a fortiori pour des personnes ayant des difficultés à se repérer, à lire et à comprendre le fonctionnement d’une interface numérique.

Métacognition

La métacognition désigne la conscience de nos propres capacités et besoins.

Or, l’utilisation d’un outil comme un sélecteur de styles suppose que les personnes pour qui il a été conçu aient conscience de leurs propres besoins, et avant ça de leurs propres difficultés.

C’est un processus qui n’est ni évident ni systématique, en particulier pour des personnes ayant un handicap mental.

De fait, une utilisatrice concernée pourrait complètement passer à côté de ce type d’outil, et ne même pas le voir ou le percevoir parce qu’elle n’a pas forcément conscience qu’il pourrait l’aider.

À suivre

Ne manquez pas la seconde partie de cette transcription !

En parallèle, pour continuer votre veille sur ces problématiques, n’hésitez pas à nous suivre sur LinkedIn et Twitter. Merci et à bientôt !

Envie de vous engager pour l’accessibilité numérique ?

Vous avez de l’expérience en tant qu’intégrateur ou intégratrice, développeur ou développeuse, et souhaitez mettre votre expérience technique au service d’une cause importante ?

Vous êtes passionné·e par l’accessibilité numérique et souhaitez vous y consacrer à 100% ? Rejoignez-nous : Access42 recrute des consultant·es en accessibilité numérique !

N’hésitez pas à consulter l’offre d’emploi ou à la partager autour de vous, et à nous contacter si vous avez des questions. Nous avons hâte de faire votre connaissance !

Notes

[1Source : MIESENBERGER K., EDLER C., DIRKS S., BÜHLER C., HEUMADER P., User Centered Design and User Participation in Inclusive R&D, in Computers Helping People with Special Needs, 17th International Conference, ICCHP 2020, Lecco, Italy, September 9–11, 2020, Proceedings, Part I, p. 6

[2Source : LUSSIER-DESROCHERS D., DUPONT M. E., LACHAPELLE Y., LEBLANC T., Étude exploratoire sur l’utilisation de l’Internet par les personnes présentant une déficience intellectuelle (PDF, 70 ko), in Revue francophone de la déficience intellectuelle, 2011, 22, 41-50, cité dans le Guide sur le handicap mental édité par la DINUM, p. 6

[3cf. MANIEZ A., WCAG 2.1 : l’écriture d’une recommandation, 2018 : « les grands perdants (…) sont les critères relatifs au handicap cognitif (COGA), puisque seulement 36 % des critères proposés ont été conservés ». « Le handicap cognitif ne compte plus que 2 nouveaux critères de niveau simple A et 3 critères de niveau triple A. Encore une fois, le handicap cognitif est remisé au niveau triple A ».

[5Source : WEHMEYER M. L., SMITH S. J., PALMER S. B., DAVIES D. K., Technology use by students with intellectual disabilities : An overview. Journal of Special Education Technology, 2004, 19(4), 7-21, cité dans le Guide du handicap mental, op. cit., p. 8

[6Source : KLAUS J., MIESENBERGER K., BURGER D., ZAGLER W., Computers Helping People with Special Needs (Google Books, format PDF non accessible), 9th International Conference, ICCHP 2004, Paris, France, July 7-9, 2004, Proceedings, p. 1006

[9Source : GRELLMANN B., NEATE T., ROPER A., WILSON S., MARSHALL J., Investigating Mobile Accessibility Guidance for People with Aphasia (PDF, 1,2 Mo), in ASSETS ’18 Proceedings of the 20th International ACM SIGACCESS Conference on Computers and Accessibility, New York, 2018, pp. 410-413