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

2 commentaires

Attention ! Cet article a été écrit en 2021. Son contenu a peut-être besoin d’une mise à jour. Complétez votre veille avec des articles plus récents, par exemple en consultant les nouveautés de notre blog accessibilité numérique, ou en lançant une recherche pour trouver des articles similaires, mais à jour.

Voici la seconde partie de la transcription de notre conférence « Et si on laissait les utilisateurs et les utilisatrices personnaliser l’interface ? », dont la première partie a été publiée la semaine dernière.

Bonne lecture !

Demain : vers une standardisation de la personnalisation des interfaces

Le handicap cognitif dans la norme

Pour comprendre comment la prise en compte des handicaps cognitifs par le numérique a évolué, il faut aller voir ce qu’il se passe dans les normes et référentiels. Les WCAG 2.0 et le RGAA 3 proposaient déjà des critères qui prennent en charge le handicap cognitif, les troubles du langage et de l’attention.

Par exemple, le critère simple A 13.8, que l’on retrouve aujourd’hui dans le RGAA 4, demande à ce que les contenus en mouvement ou clignotants puissent être arrêtés par l’utilisateur ou l’utilisatrice. On peut également citer le critère 13.14, de niveau triple A (AAA), qui existait dans le RGAA 3 :

« Dans chaque page web, chaque texte qui nécessite un niveau de lecture plus avancé que le premier cycle de l’enseignement secondaire a-t-il une version alternative ? »

Mais on peut également citer le critère 13.9 du RGAA 3, de niveau triple A (AAA), qui demandait l’explicitation des expressions inhabituelles et du jargon. Pour rappel, les critères d’accessibilité sont répartis en trois niveaux A, double A (AA) et triple A (AAA).

Le niveau légal d’accessibilité est le niveau AA, qui regroupe l’ensemble des critères A et AA. Les critères triple A, quant à eux, ne font pas partie de l’obligation légale, et sont donc rarement pris en compte.

Les handicaps cognitifs sont donc faiblement pris en compte par les normes d’accessibilité, a fortiori maintenant que les critères AAA ont été supprimés du RGAA 4, alors qu’ils sont toujours présents dans WCAG 2.1. Avec la mise à jour WCAG 2.1, publiée en juin 2018, on a vu apparaître deux nouveaux critères qui traitent des troubles du langage :

Ces deux nouveaux critères ont les mêmes attentes : en effet, dans les deux cas, il est demandé que la fonction de chaque composant (contrôle de formulaire, structure de document, icône, etc.) puisse être déterminée par un programme informatique.

Techniquement, il va s’agir d’ajouter des éléments de description, des attributs et des propriétés à ces composants, afin qu’un agent utilisateur (navigateur, technologie d’assistance) puisse les exploiter. Pour l’heure, il est important de noter que ces deux critères ont des portées différentes :

  • le critère 1.3.5 Input purpose (AA) dans WCAG 2.1 et le critère 11.13 du RGAA 4 ne concernent que les champs de formulaires ;
  • le critère 1.3.6 Identify purpose (AAA) dans WCAG 2.1, non transposé dans le RGAA 4, s’applique à l’ensemble des composants de l’interface, y compris la structure du document, les icônes, etc.

Bénéfice nº1 : adapter les interfaces aux capacités langagières de chaque personne

L’identification des composants demandée par les normes d’accessibilité numérique doit ainsi permettre aux navigateurs (ou technologies d’assistance) d’utiliser ces informations pour présenter le contenu d’une page selon des modalités définies par l’utilisateur/l’utilisatrice.

Cette présentation adaptée diffère de celle définie par l’éditeur du site ou de l’application – et c’est normal. Par exemple, à la manière d’une personne malvoyante qui aura défini une taille de police par défaut pour tous les sites web qu’elle consulte, une personne avec un trouble du langage peut spécifier de remplacer l’étiquette textuelle d’un champ de saisie d’un email par une icône qu’elle est en mesure de reconnaître.

Troubles du langage

Sous l’appellation « troubles du langage », on rassemble un ensemble de troubles qui touchent les mécanismes de production d’un message, ainsi que les mécanismes de réception et compréhension d’un message reçu.

Cela peut aller de la simple difficulté à l’incapacité complète à comprendre le langage verbal, oral et/ou écrit. Les conséquences sont différentes selon le moment où elles interviennent dans la chaîne de compréhension ou production d’un message. Par exemple :

  • des difficultés ou une incapacité à reconnaître visuellement ou oralement les lettres ou mots, provoquées par un défaut au moment de la réception du stimulus ;
  • des difficultés à comprendre le message reçu, car les fonctions en charge de la compréhension du langage sont atteintes.

Si les troubles du langage peuvent être isolés, ils sont le plus souvent conjugués à d’autres troubles cognitifs (comme la dysphasie ou la dyslexie), ou encore conjugués à d’autres troubles dans des atteintes plus complexes, et souvent associés à des troubles moteurs (paralysie cérébrale) et/ou à un retard mental (syndrome de Down).

Néanmoins, un trouble du langage n’est pas toujours associé à un retard mental. Pour les personnes ayant un trouble du langage, les difficultés posées par le numérique vont se situer à peu près partout :

  • la consultation : difficultés pour comprendre le contenu même du site ou de l’application, très souvent parce que le niveau de lecture requis est trop élevé (vocabulaire et syntaxe complexe, expressions figurées, etc.). Le RGAA 3 prenait en compte ces problématiques avec des critères de niveau triple A, par exemple avec la mise à disposition d’un texte en version FALC (Facile à lire et à comprendre) ;
  • la navigation : difficultés pour se repérer dans des systèmes de navigation, par exemple en ne trouvant pas la bonne entrée dans un menu, à cause d’un défaut de compréhension des intitulés, des signes et des messages ;
  • l’interaction, la participation : difficultés pour remplir un formulaire par exemple, car les consignes et les étiquettes sont difficilement compréhensibles.

Systèmes de communication alternatifs

On l’a vu, certaines personnes handicapées ont recours à des technologies d’assistance pour interagir avec le numérique, comme un lecteur d’écran ou un système de commande vocale par exemple. Dans le cas des atteintes langagières, les personnes concernées ont souvent recours à la Communication Alternative Améliorée (CAA – Argumentative/augmentative and alternative communication).

Sous cette appellation, on rassemble toute forme de communication non verbale utilisée pour compléter ou remplacer la production et la compréhension du langage. Les personnes touchées par un trouble du langage vont utiliser la CAA pour communiquer avec leur entourage. Leur entourage pourra également se servir de ces systèmes de communication pour mieux se faire comprendre.

On distingue deux systèmes de communication améliorée : sans assistance technique, et avec assistance technique.

Systèmes sans assistance technique

Les systèmes de communication sans assistance sont des formes indépendantes, qui ne nécessitent aucun support pour être utilisées. Par exemple :

  • les langues des signes (Langue des signes française, Langue parlée complétée) ;
  • les expressions du visage ;
  • les vocalisations ;
  • les gestes ;
  • et tout ce qui entre dans le cadre de la communication non verbale (posture, micro-expressions, etc.).
Systèmes avec assistance technique

Les systèmes de communication avec assistance, quant à eux, sont des systèmes qui nécessitent du matériel pour être utilisés, par exemple :

  • un livre ;
  • une langue idéographique (Bliss) ;
  • le système PECS (Système de Communication par Échange d’Images) ;
  • une carte de communication (c’est-à-dire un ensemble de symboles figurés) ;
  • un ensemble de photographies ou de dessins ;
  • une tablette ;
  • un générateur de synthèse vocale ;
  • des logiciels, etc.
Les systèmes idéographiques
Langue idéographique Bliss.
Exemple de symboles issus de la langue idéographique Bliss.
Les systèmes de communication avec échanges d’images
Exemple de PECS
Exemple de PECS (Picture Exchange Communication System). Un PECS permet de construire des phrases simples à l’aide d’images. Source : Small PECS Communication Notebook – Amazon
Les cartes de communication

Exemple de carte de communication.
Exemple de carte de communication. Source : Wikimédia.
Tableau de symbole de communication non verbale.
Tableau de symbole de communication non verbale. Source : Wikimédia.

Les synthétiseurs vocaux
GoTalk 9+ Lite Touch
Exemple de générateur de synthèse vocale, le GoTalk 9+ Lite Touch.

Bénéfice nº2 : aide à la concentration et à la prise de décision

Les troubles du langage sont rarement isolés, et sont souvent accompagnés d’autres troubles, comme les troubles de l’attention. Les troubles de l’attention se caractérisent par :

  • l’incapacité à maintenir son attention focalisée sur une tâche ;
  • l’incapacité à terminer une tâche ;
  • une hypersensibilité à la distraction ;
  • de l’impulsivité : difficulté à attendre, et besoin d’agir rapidement.

De plus, les troubles de l’attention peuvent être associés à une hyperactivité motrice, mais ce n’est pas systématique (Trouble du Déficit de l’Attention avec ou sans hyperactivité : TDA/TDAH).

C’est pourquoi il est essentiel de permettre aux personnes ayant des TDA ou TDAH de réduire la charge cognitive en limitant les choix possibles au strict minimum pour maximiser leurs chances de réussir une tâche donnée. Par exemple, il est possible d’identifier dans le code le degré d’importance de chaque composant d’interface, et de permettre ensuite aux utilisateurs et aux utilisatrices la possibilité de supprimer les éléments identifiés comme distrayants, pour simplifier l’interface et les aider à se concentrer sur ce qui a vraiment de l’importance.

Les navigateurs web fonctionnent déjà comme ça ! En effet, le « mode consultation » permet de réduire la charge informationnelle en proposant un affichage allégé et minimaliste de n’importe quel site web. Firefox, par exemple, possède un mode « lecture ». Ce mode se base sur la structure HTML du site affiché, et en particulier, sur l’utilisation des balises article et section, sur la longueur des paragraphes, etc.

Affichage par défaut du site de la Haute Autorité de Santé.
Affichage simplifié.
Affichage simplifié du même site, avec le mode lecture de Firefox.

Ce mode de consultation permet de retirer du champ visuel tous les éléments qui pourraient distraire les utilisateurs et utilisatrices ayant des TDA/TDAH : par exemple, une navigation trop encombrante, des publicités ou des images décoratives.

La méthode heuristique sur laquelle se base cette simplification reste cependant assez aléatoire, puisqu’elle se base sur des éléments HTML natifs, en dehors de toute indication sur leur importance réelle dans la compréhension du contenu.

Bénéfice nº3 : accompagner la saisie et réduire les erreurs de saisie

Pour aider les personnes ayant des troubles de la mémoire et de l’attention à remplir un formulaire, une méthode consiste à leur permettre de le remplir automatiquement, grâce à la mémoire des saisies précédentes, ou bien à l’aide d’un dictionnaire qu’elles ont renseigné au préalable (par exemple au moyen d’une extension navigateur comme Autofill Forms).

Le remplissage automatique permettant de limiter les manipulations et les erreurs de saisie, il peut donc servir à toutes les personnes en situation de handicap. Du fait de déficiences cognitives, certains utilisateurs et utilisatrices se fatiguent plus vite et/ou ont tendance à agir de manière impulsive.

Remplir les formulaires de manière automatique leur permet de limiter le risque d’erreur et donc de gagner du temps. Pour que ces outils de remplissage automatique fonctionnent, il faut que les champs de formulaire soient identifiés avec des attributs HTML spécifiques, par exemple l’attribut HTML autocomplete. Par exemple :

<code class="code">
<label for="youremail">Adresse email (exemple : <span lang="en">brian</span>@<span lang="en">inthekitchen</span>.com)</label>
<input id="youremail" autocomplete="email" type="email" />R)APYcW*i8)v^$t0rAgxzDXS
</code></div>

On l’a vu précédemment, l’attribut autocomplete en HTML5 permet de déterminer si un champ peut être rempli automatiquement ou non (valeurs on et off).

Technique d’implémentation : la sémantique

Afin de permettre à un programme informatique (programme, navigateur, technologies d’assistance etc.) d’identifier la nature, la fonction d’un composant d’interface, il faut pour le décrire avec des propriétés et valeurs identifiables. Cette volonté de décrire les contenus est quelque chose que vous connaissez sans doute déjà, notamment au travers du web sémantique.

Peut-être avez-vous déjà entendu parler des microformats : c’est un ensemble de valeurs normées, utilisables dans l’attribut HTML class et permettant de décrire les éléments (consulter la liste de ces classes).

Par exemple :

<p class="fn">Audrey Maniez</p>
<p class="org">Access42</p>
<p class="tel">09 72 45 06 14</p>

Il existait aussi des microdonnées, définies dans la spécification HTML5 (Microdata) ainsi qu’à travers le site Schema.org, ou encore le RDF (Ressource description framework) etc.

Le hic, c’est que la plupart de ces règles d’écritures ont pour objectif premier de décrire la structure et les contenus des pages web, non pas pour aider les utilisateurs/utilisatrices en situation de handicap, mais pour favoriser une indexation enrichie des sites par les moteurs de recherche.

COGA

C’est pourquoi a été créé au sein du W3C un groupe de travail nommé COGA (Cognitive and Learning Disabilities Accessibility). COGA travaille à la construction d’une documentation permettant de supporter les problématiques liées aux handicaps cognitifs, mentaux et psychiques : .

C’est à ce groupe de travail que l’on doit notamment la spécification Personalization Semantics Content Module 1.0 (working draft). Ce document définit un ensemble normé de propriétés et de valeurs à utiliser pour décrire les contrôles de formulaires, les symboles/icônes, ainsi que d’autres composants d’interface.

Pour élaborer cette spécification, COGA s’est basé sur la possibilité fournie par HTML de créer des attributs personnalisés avec le préfixe data. Nous allons voir quelques-unes des particularités d’un composant décrit à l’aide de cette spécification, tout en balayant les bénéfices utilisateurs des nouveaux critères WCAG que nous avons cités.

Exemples

Avec COGA, on va pouvoir définir :

  • des actions pour les boutons avec l’attribut data-purpose :
    <input type="submit" value="Envoyer le message" data-purpose="send" />
  • des destinations pour des liens avec l’attribut data-destination :

    <a href="index.html" data-destination="home">Accueil</a>
  • la nature des saisies attendues pour les champs de formulaire :

    <label for="youremail">Adresse email (exemple : <span lang="en">brian</span>@<span lang="en">inthekitchen</span>.com)</label> <input id="youremail" autocomplete="email" type="email" data-purpose="email" />

Il existe aussi un autre attribut HTML5 qui permet d’identifier les champs de formulaires, c’est autocomplete. Cet attribut reçoit les mêmes valeurs que la propriété data-purpose. La principale différence résidant dans le support des navigateurs et dans sa capacité d’auto-complétion.

  • le concept associé à un symbole avec l’attribut data-symbol : par exemple, cup of Tea. L’attribut data-symbol reçoit une ou plusieurs valeurs numériques qui correspondent à des symboles dans des librairies. Les nombres choisis sont ceux de la librairie Bliss ;
  • Le niveau d’importance d’un composant avec l’attribut data-simplification : <input data-simplification="critical" value="Envoyer le message" type="submit"/>
  • La nature d’un composant décoratif/distractif au moyen de l’attribut data-distraction : tml » title= »De la publicité » data-distraction= »sensory offer » />La valeur sensory indique que le contenu est en mouvement, et la valeur offer qu’il s’agit d’une publicité.

HTML5

En théorie, les navigateurs devraient mémoriser les valeurs saisies par l’utilisateur ou l’utilisatrice pour chaque champ de formulaire qui possède un attribut autocomplete, puis lui proposer de saisir ces mêmes valeurs par la suite, lorsque des champs similaires possédant les mêmes valeurs d’autocomplete sont présentés.

Il existe néanmoins des extensions de navigateur qui permettent de définir son propre dictionnaire de valeurs. Par exemple, l’extension Autofill Forms pour Firefox permet de saisir des règles de remplissage : pour un sélecteur CSS donné, remplir l’élément concerné avec telle valeur.

Exemple de réglages de l’extension Autofill dans Firefox.
Exemple de réglages de l’extension Autofill dans Firefox :

  1. Ligne 1 :
    • URL : *
    • Rule (QuerySelector) : input[autocomplete*='name']
    • Value : Jeanne Dupont
  2. Ligne 2 :
    • URL : *
    • Rule (QuerySelector) : input[autocomplete*='country']
    • Value : France
  3. Ligne 3 :
    • URL : *
    • Rule (QuerySelector) : input[autocomplete*='email']
    • Value : jdupont@access42.net

Néanmoins, comme nous l’avons déjà souligné, il s’agit d’une extension tierce avec toutes les barrières que cela implique : accès à l’extension, utilisation et paramétrage de l’extension, qui peuvent être des tâches complexes pour des personnes ayant justement un handicap mental ou cognitif.

Transposition dans le RGAA 4

Comme nous l’avons vu, le critère Input purpose, qui demande l’identification des champs de formulaires, a été transposé dans le RGAA 4 dans le critère 11.13. Ce critère met surtout l’accent sur sa finalité d’auto-complétion :

« La finalité d’un champ de saisie peut-elle être déduite pour faciliter le remplissage automatique des champs avec les données de l’utilisateur ? ».

Il va s’agir d’ajouter un attribut autocomplete sur les champs qui attendent une donnée personnelle concernant l’utilisateur ou l’utilisatrice.

Les valeurs de l’attribut autocomplete sont normées : vous en trouverez la liste dans la note de glossaire « Liste des valeurs possibles pour l’attribut autocomplete » du RGAA.

Par contre, le RGAA 4 ne contenant plus les critères triple A (AAA) des WCAG, il n’y a actuellement pas d’équivalent dans le référentiel français du critère WCAG1.3.6 Identify purpose, qui demande à identifier l’ensemble des composants d’interface.

Il faut donc retenir que dans le cadre de l’obligation légale en France (niveau double A), de tout ce que nous avons parlé aujourd’hui, le seul élément obligatoire est d’identifier les champs de formulaires qui attendent des données personnelles de l’utilisateur ou de l’utilisatrice.

C’est le cas notamment des champs de type « nom », « e-mail » et « date de naissance » par exemple :

<label for="yourname">Votre nom</label>
<input id="yourname" type="text" autocomplete="name" data-purpose="name" />

<label for="youremail">Adresse e-mail (format attendu : nom@domaine.fr)</label>
<input type="email" id="youremail" autocomplete="email" data-purpose="email" />

<label for="bday">Date de naissance (format attendu : JJ/MM/AAAA)</label>
<input type="text" id="bday" autocomplete="bday" data-purpose="bday" />

Conclusion

L’avenir de l’accessibilité

L’avenir de l’accessibilité, c’est concevoir et développer des interfaces flexibles et résilientes, qui pourront subir des transformations dont on n’a pas encore idée. Et pour cause, certaines technologies d’assistance destinées à exploiter ces données n’existent pas encore. En effet, la spécification COGA n’est pas encore exploitée par exemple.

Mais les nouveaux critères WCAG sont justement là pour impulser cette nouvelle dynamique de l’accessibilité : l’adaptation des interfaces aux besoins des personnes en situation de handicap – et non l’inverse.

Pour en savoir plus

Si le sujet vous intéresse, voici des pistes pour creuser !

Par ailleurs, vous pouvez aussi consulter les slides de notre conférence. Du côté d’Access42, nous continuons à œuvrer chaque jour en faveur de l’accessibilité numérique en général, et à travers le prisme des handicaps mentaux, cognitifs et psychiques en particulier, notamment en publiant des ressources en français sur le sujet.

Alors n’hésitez pas à nous suivre sur Twitter et LinkedIn, et à vous abonner à notre newsletter pour enrichir votre propre veille sur l’accessibilité numérique. Merci et à bientôt !

Envie d’en faire plus pour l’accessibilité numérique ? Formez-vous avec Access42 !

Vous souhaitez améliorer l’accessibilité de vos sites et de vos applications ? Vous avez besoin d’approfondir vos connaissances en la matière ? Nos formations, adaptées à tous les métiers du numérique, vous permettront de monter rapidement en compétence.

Contactez-nous dès à présent pour obtenir plus de renseignements. Nos devis sont gratuits !

À propos

  • Audrey Maniez

    Co-gérante et experte accessibilité numérique

    Audrey Maniez est experte senior en accessibilité numérique, formatrice, directrice pédagogique et co-gérante d’Access42. Grâce à une maîtrise poussée des différentes normes d’accessibilité numérique, Audrey réalise des audits d’accessibilité et accompagne nos clients dans leur démarche de mise en conformité aux normes en vigueur. Formatrice chevronnée, Audrey anime nos formations les plus techniques. Par ailleurs, elle a encadré la traduction officielle en français des WCAG 2.1 publiée par le W3C, et encadre en ce moment celle des WCAG 2.2.

  • Marie Guillaumet

    Directrice de la communication

    Marie Guillaumet est à la fois experte accessibilité numérique et directrice de la communication au sein d’Access42. Forte de 15 ans d’expérience en tant que designer UX/UI et intégratrice web, elle a notamment créé notre programme de formation au design accessible, et continue de l’animer avec enthousiasme.

2 commentaires

Bonjour,
Merci pour cet article très riche et intéressant !
Je voulais simplement vous signaler que les liens vers les guides des troubles dys et du handicap mental ne fonctionnent pas : ils demandent d'abord de se connecter à Gitlab, puis, si on est connecté, renvoient une erreur 404 (page non trouvée).

Les commentaires sont désormais fermés, mais vous pouvez toujours nous contacter pour réagir à cet article !