Accessibilité, comment concevoir pour tous ?

Oubliée de nombreuses réalisations, l’accessibilité numérique, abrégée A11y, est en passe de devenir la norme grâce à la législation. Une révolution avenir pour de nombreuses personnes exclues du numérique et pour l’amélioration des siteweb.

Sommaire

• Pourquoi s'intéresser à l'accessibilité
• Les handicaps et les situations de handicaps
• Concevoir pour tous (design)
• Les contrastes
• Les polices
• Les composants
• Couleur et information
• Bruit Visuel
• Gestes d'utilisatons
• Moyens de contacts
• Penser les contenus pour tous
• Les contenus inclusifs
• Rédaction
• Messages d'erreurs
• Mise en forme
• Multimédia
• Informations téléchargeables
• l’accessibilité numérique, une histoire de code
• Les états focus
• Zone cliquable
• Étiquettes et champs
• Limitation de temps
• Responsive
• Les alternatives textuelles aux images
• Les animations
• Les balises sémantiques HTML5
• Les balises Aria
• Vérifier l’accessibilité du dispositif
• Tests automatisés
• Tests d'usages
• Listes de vérification
• Vérifier l’accessibilité du dispositif

Pourquoi s'intéresser à l'accessibilité

• L'accessibilité concerne 12 millions de personnes en France
• Se mettre en conformité : loi du 11 février 2005, Directive (UE) 2019/882
• Les mesures d'accessibilité, améliorent l’expérience utilisateur de tous
• L’accessibilité est un vecteur d'innovation
• S'engager pour l’égalité des droits des personnes handicapées à l'accès au numérique

Les handicaps et les situations de handicaps

Pour apprendre à concevoir pour tous, il est nécessaire de comprendre les différents handicaps. Il existe 7 familles de handicaps :

• Cognitif, altération des processus cérébraux permettant d’acquérir et de traiter des informations. On y retrouve les troubles DYS, de déficit de l’attention, l'hyperactivité et les troubles du spectre autistique.
• Mental, il se traduit par des difficultés de réflexion, de conceptualisation, de communication et de décision. La Trisomie 21 et le syndrome x fragile sont des handicaps mentaux
• Les handicaps Psychiques sont caractérisés par des efforts permanents pour s’adapter et entrer en relation avec les autres ou des difficultés de concentration. Pathologies : Névrose, Troubles obsessionnels compulsifs, phobies, addictions, dépression.
• Moteur, Ces personnes rencontrent des difficultés à se déplacer, conserver ou changer de position, effectuer certains gestes : Troubles musculo-squelettiques, rhumatisme, Lombalgie, malformation, paralysie.
• Visuel, perte de l’acuité visuelle pouvant aller jusqu’à la cécité : myopie, presbytie, rétinite, daltonisme, Glaucome, malvoyance, non-voyance, cataracte.
• Auditif, difficultés ou impossibilité à percevoir et localiser, les sons et la parole. Acouphène ou surdité légère à profonde, perte auditive totale
• Maladie invalidante, restriction d’activités en matière de mobilité ou de quantité de travail à fournir, en durée ou en intensité. Hypertension, insuffisance cardiaque, diabète, maladies professionnelles, allergie, cancer, épilepsie...

Pour les handicaps visuels et moteurs, il existe des technologies d’assistance : La synthèse vocale, la plage braille, l'eye tracking, le zoom par défaut réglé à 200% et la navigation clavier. Pour rendre compatible un dispositif numérique à tous, il faut prendre en compte les particularités des différents handicaps et des technologies d'assistances qu'ils utilisent.

Les handicaps ne sont pas seulement permanents, ils peuvent être également temporaires, liées à une situation ou à l'âge. Par exemple, si on ne prend pas en compte les critères de contraste des textes, une personne malvoyante ou une personne qui utilisent son téléphone en plein soleil ne pourront pas lire les contenus d'une application ou d'un site.

Le navigateur Firefox ou l’extension Web diasbility simulator permettent de percevoir le site à travers certains handicaps comme la perte de contraste, la non-perception des couleurs, Parkinson, la dyslexie et les troubles de l'attention.

Concevoir pour tous (design)

Les contrastes

Un point important de la prise en compte de la situation de handicap visuel est la gestion des contrastes. Il se calcule avec 3 éléments : la taille du texte ou de l’icône, sa couleur et la couleur de fond. Des sites et outils comme Who Can Use ou l’extension Contrast pour Figma vous permettent de les tester avant la production des interfaces.

Les polices

Les polices de corps et de titre doivent être choisies pour garantir une bonne lisibilité. Il faut sélectionner des polices de corps avec une aperture ouverte et une hauteur d'X élevé : Open sans, Lato, Merriweather, Lora. Les polices comme Futura, Helvetica ont une hauteur d'X (taille des minuscules) trop basse et une aperture trop fermée (lettre qui se referme sur elle-même).
Les typographies complexes comme les scripturales et les condensées sont également à éviter pour garantir une bonne lisibilité.

Les composants

Les composants n'ont pas les mêmes degrés d’utilisabilité pour les personnes en situation de handicap. Les captchas, alerte temporaire, les infos bulles, animation et carrousel automatique doivent être proscrits.

Les intitulés

Les intitulés des titres et des éléments interactifs doivent être explicites. Un bouton "en savoir plus" devrait se nommer "Voir toutes les plantes". Ces intitulés génériques n'ont pas un assez bon niveau de guidance pour une expérience optimisée pour les handicaps cognitifs. Les technologies d’assistances pour les nonvoyants permettent de naviguer de lien en lien ou de titre en titre. Pour rendre cet usage possible, passez d'un nom générique à des intitulés explicites qui clarifient les destinations et les fonctions de ces éléments interactifs.

Couleur et information

La couleur est un bon vecteur de transition de l'information. On met les erreurs en rouge, les informations de succès en vert. Toutefois, certaines personnes ont une perception de la couleur différente comme Daltoniens. Si dans un formulaire les champs incorrects sont seulement mentions par une bordure rouge, ils ne seront pas en capacité de les identifier. Pour pallier ces cas, l’information doit être doublée d'un texte ou d'un visuel.

Bruit Visuel

Les personnes autistes peuvent avoir une hypersensibilité au toucher, aux odeurs, au son et à une exposition à une stimulation visuelle forte. Sélectionner une palette de couleurs plus douce et éviter les animations trop brutes et répétitives.

Gestes d'utilisations

Certains utilisateurs ne pourront pas réaliser des gestes que peut imposer une interface. Pincer pour zoomer une carte, glisser des documents dans une zone de la page ou encore utiliser un sous-menu s'ouvrent au survol. Concevoir pour tous, c'est anticiper ces limitations en proposant des designs utilisables par tous ou en ajoutant des alternatives comme un bouton importer des documents.

Moyens de contacts

Tout le monde ne peut pas téléphoner, s'exprimer oralement et entendre son interlocuteur. Proposer comme seul recours un numéro de téléphone n'est pas une solution inclusive. Les numéros d'urgence comme le 112 proposent une alternative textuelle pour les personnes sourde. Elles peuvent écrire aux urgences avec le 114. Fournir une variété de méthode de contact est une bonne pratique : numéro de téléphone, email, messagerie instantané, voie postale.

Penser les contenus pour tous

Les contenus inclusifs

Les informations peuvent être orientées de manière à inclure la diversité des publics : renseigner si lieux sont accessibles PMR, si les activités proposées sont disponibles pour des personnes avec certains handicaps.

Rédaction

Les phrases et les paragraphes courts sont plus faciles à lire. Pour raccourcir ces textes, éviter les propositions subordonnées relatives - les "qui ..." ou les "que ...". Ils ont tendance à créer des phrases très longues. Limiter ou expliquer le jargon, les abréviations et les anglicismes pour faciliter la compréhension des propos.

Messages d'erreurs

Les erreurs sont fréquentes dans les parcours de navigation. De source diverse leurs résolutions ne sont pas toujours aisée. Rédiger ces messages de manière explicite et en donnant des éléments de résolutions sont des bonnes pratique pour limiter les abandons.

Mise en forme

Les contenus doivent être présentés de manière linaires. Varier la mise en forme en fonction du contenu simplifie l'appropriation des propos : photos, diagrammes, tableaux de données, illustrations.

Multimédia

Pour les éléments multimédia comme les vidéos et audios, prévoir des sous-titres et une transcription textuelle pour les personnes malentendantes et celles qui ne peuvent utiliser le son dans leur environnement. L'outil de sous-titrage Nikse permet de les rédiger en ligne ou sur un logiciel.

Informations téléchargeables

Les informations transmises par le téléchargement d'un document Pdf, Word, Excel, ect. Peuvent poser des problématiques d'accessibilités. Une page Web bien écrite permet aux personnes malvoyantes de bénéficier du tagage Html pour la parcourir facilement. Si vous devez partager des informations d'un document, intégrer-les directement dans une page Web.

l’accessibilité numérique, une histoire de code

Les états focus

Prévoir un état focus visible pour l'ensemble des éléments interactifs. Ces indicateurs sont essentiels à une bonne navigation au clavier, notamment pour les handicaps moteurs.

	a:focus-visible,
	button:focus-visible,
	select:focus-visible,
	textarea:focus-visible,
	summary:focus-visible,
	input:focus-visible {
		outline-offset: 2px;
		outline: #224477 2px solid;
		border-radius: 4px;
		transition: none;
		}

Zone cliquable

Réaliser des zones cliquables larges pour les éléments interactifs, de sorte qu'ils soient facilement atteignables pour les handicaps moteurs.

Étiquettes et champs

Les champs de formulaire sans étiquettes sont un problème fréquent et critique. Les personnes malvoyantes utilisent une synthèse vocale. Elle énonce le type des éléments et leurs noms. Si ce dernier n'est pas renseigné, il leur est difficile de savoir si c'est un champ de recherche, d'inscription à une newsletter ou de connexion à un compte.

Dans certains cas, comme pour choisir un mot de passe, des instructions sont données. Parfois après la saisie (à éviter) et parfois en dessous des champs. Ces indications doivent se citer en amont du champ de formulaire.

Un cas propre aux champs de choix de mot de passe est la mémorisation de ce que l'on a écrit. La fonctionnalité « Afficher » permet aux utilisateurs de connaître ce qu'ils ont écrit, le mémoriser et de se rassurer sur leur saisie.

Limitation de temps

Sur certain site les sessions sont limitées dans le temps : 15 minutes pour remplir un formulaire, 20 min avant que le panier soit perdu ou encore déconnexion du compte au bout de 30 minutes. Ces limites temporelles empêchent les personnes atteintes de trouble de l'attention et les personnes qui utilisent des technologies d’assistance à réaliser leurs achats et rechercher d’information en ligne. Elles vont avoir besoin de plus de temps pour réaliser une tâche qu'une personne valide.

Responsive

C'est une bonne pratique depuis de nombreuses années, le responsive consiste à adapter chaque élément d'une page pour qu'il s'affiche au mieux quelle que soit la taille de l'écran de l'utilisateur. Elle est d'autant plus importante pour les personnes malvoyantes qui utilisent un zoom avancé - jusqu'à 300% - pour pouvoir lire ce qui s'affiche à l'écran.

Les alternatives textuelles aux images

Les textes alternatifs aux images sont essentiels pour les personnes non voyantes. Elles leur permettent de comprendre les éléments visuels des pages comme les photos et icônes. Il faut à chaque image un attribut Alt qui doit être remplis si l'image n'est pas uniquement décorative. Pour compléter ces balises, il faut être concis et se concentrer sur ces éléments de l'image :

• Les personnes
• Les lieux
• Les objets
• Les actions
• Les émotions

Les animations

Les usagers peuvent être déranger par la présence d'animations. Les navigateur on accès au choix des utilisateur quant à l'utilisation des animation. Pour prendre en compte la préférence, il faut utiliser la règle media reduced motion et y placer toutes les animations css du site.

  @media (prefers-reduced-motion: reduce) {
		.monAnimation, .uneAutreAnimation {
			animation: none;
			}
		}
	

Les balises sémantiques HTML5

Les pages web sont composées de balises. Elles permettent d'ajouter des éléments de toutes sortes : images, paragraphe, lien, titre, champ texte, vidéo...
Pour regrouper et organiser ces éléments dans les pages, il existe des balises, la dernière version du langage apporte une sémantique aux régions des pages.

Pour les éléments d'une page

• H1, H2, H3, H4, H5, H6 pour tous les titres d'une page
• a (lien) pour tous les éléments interactifs vers des pages ou des parties de pages
• button pour valider un formulaire, ouvrir des modales, déplier des éléments et pour les autres éléments interactifs
• input pour tous les formulaires : case à cocher, champs texte, bouton radio, etc.
• p Pour les paragraphes et les textes de contenus
• ul, ol Pour les listes d'éléments et les listes d'éléments ordonnées

Pour les zones d'une page

• nav Pour les éléments de navigations : fil d'Ariane, menu, pagination
• header le haut de page
• footer le pied de page
• section pour les différentes sections d'une page
• aside pour les sections qui ne sont pas en rapport direct avec le contenu de la page : Les contenus similaires suggérés
• article pour regrouper un ensemble d'informations liées : une statistique et son texte

Les balises Aria

Les balises HTML ne suffisent pas toujours à la mise en accessibilité des pages. Parfois, il faut expliciter, avec des balises Aria, le fonctionnement de ces éléments.

• aria-label="", pour donner un nom accessible aux éléments comme les tableaux, les champs sans label et les icônes interactives
• aria-hidden="true", pour masquer un élément d'un lecteur d'écran comme les icônes dont le texte présente la même information.
• Pour expliciter l'action des boutons, les attributs aria sont recommandés.
  • aria-haspopup="true" pour un bouton qui ouvre un menu, aria-haspopup="dialog" pour un bouton qui ouvre un volet ou une modale.
  • aria-expanded="false", pour signaler à l'utilisateur que cet élément est dépliable : menu, accordéons, contenu coupé
    . Ce dernier doit être utilisé avec aria-controls="id" pour le relier à l'élément déplié.
  • aria-pressed="true"​​, informe que le button est appuyé. Il peut être utiliser pour un bouton play/pause ou un bouton « j'aime ». Sa valeur par default, lorsqu’il n’est pas actif est false.
  • aria-selected="true"​​, informe que le button est sélectionné. Il peut être utiliser pour un menu de tabulation interne à une page, des boutons indiquant les tailles disponibles pour une paire de chaussure, etc. Sa valeur par default, lorsqu’il n’est pas actif est false.
• aria-modal="true"​​, Signal à la technologie d’assistance la présence d'une modales, cela permet d’éviter les "pièges aux claviers".
• aria-busy="true"​​, informe la technologie d’assistance un chargement en cours sur un élément".
• aria-live="polite"​​, identifie une zone où des modifications peuvent advenir et précise leurs degrés d'importances :
  
  
  • polite : changement classique
  • assertive : changement très important, signalé en priorité
  • off : n'informe pas du changement
• aria-atomic="true"​​, annonce l'ensemble de la région ou s'est effectué le changement. La valeur false ou l'absance d'attribut annoce seulement la ou les balises modifiées. d’assistance un chargement en cours sur un élément".
• role=""​, Pour donner un sens sémantique aux éléments HTML, exemple de valeur :
  • feed Pour flux de contenu, comme les fils d’actualités
  • search Pour les champs de recherche
  • dialog Pour les modales et les volets
  • alert Pour les messages d'erreurs ou les alertes élevées
  • status Pour des messages d'informations neutres, par exemple le bandeau promo en haut des pages de site ecommerce.
  Dans les cas ou la sémantique HTML5 suffit, il ne faut pas la doubler avec les roles.

Vérifier l’accessibilité du dispositif

Tests automatisés

Avant la mise en ligne de la solution, il est recommandé de tester les pages et fonctionnalités produites. Les outils comme le très visuel Wave pour les navigateurs permettent en un coup d'œil se rendre compte des écarts aux exigences du dispositif (problèmes de contrastes, champs sans étiquettes, peu de structures sémantiques, pas de texte alternatif, manquement dans l'ordre des tabulations). L'outil de Microsoft Accessibility insights produit un résultat similaire.

Comme tous les outils automatisés, il arrive qu'ils génèrent des faux positifs ou qu'ils ne soient pas capables de juger de la pertinence d'un descriptif d'image ou d'une balise Aria manquante, d'une zone cliquable suffisante, etc. C'est Pourquoi il est recommandé d’utiliser en plus l’inspecteur HTML des navigateurs.

Tests d'usages

Avec Voice Over pour Mac Os ou NVDA pour Windows. On peut réaliser des tests d'immersion pour relever des incohérences, des problématiques d'usage à la synthèse vocale et à la navigation clavier que l'on n'aurait pas relevé avec les outils automatisés.

Listes de vérification

Pour vérifier la conformité des différentes interfaces, il existe des listes de case à cocher basé sur les référentiels pour vérifier chacun de leurs critères.
L'outil Ara développé par l'état se concentre sur les critères du RGAA. Si vous travaillez davantage avec la norme internationale WCAG, il existe la checklist réalisée par la WebAIM.

Se mettre en conformité

• Respecter les critères d'accessibilités du RGAA en version 4.
  Attention, les solutions de type widget comme FACIL'iti ne permettent pas d’obtenir une expérience accessible et une mise en conformité de votre site.
• Ajouter la mention "Accessibilité : X conforme" et un lien de la déclaration d’accessibilité sur la page d'accueil.
• Publier un schéma pluriannuel de la stratégie de mise en accessibilité.
• Proposer une alternative à l'usage classique du service numérique et une méthode de recours.