Percevoir : alternatives, structure, contraste

Percevoir : l'information doit exister en dehors de l'image

1. Texte alternatif : écrire ce que l'image apporte, pas ce qu'elle montre

   Le critère 1.1.1 (niveau A) exige que chaque image porteuse d'information ait une alternative textuelle. La difficulté n'est pas l'attribut : c'est de décider quoi écrire.

   Les trois questions qui décident de tout

   1. L'image est-elle décorative ? Si elle ne porte aucune information, elle prend un attribut alt="" et rien d'autre. Une bordure, une flèche décorative, un fond de section : c'est décoratif.
   2. Que apporte-t-elle que le texte voisin ne dit pas déjà ? Si le texte à côté décrit déjà l'information, l'alternative doit être brève ou vide.
   3. Que se passe-t-il si l'image ne se charge pas ? C'est le meilleur test : l'alternative doit alors rester compréhensible.

   Les trois erreurs qui reviennent

   • Le préfixe automatique — « image de », « photo de », « Capture d'écran de ». Un lecteur d'écran lit « image de » avant chaque illustration, cent fois par page, et l'information utile arrive après ce bruit.
   • La description du fichier — « DSC_4821.png ». Elle n'a aucun sens hors du poste de travail.
   • La phrase vide de contenu — « un graphique ». Un graphique de quoi ? Si l'alternative ne permet pas de comprendre la donnée, elle doit être remplacée par une description du contenu, ou par une table de données accessible.

   Les images porteuses d'information sont plus fréquentes qu'on ne croit

   Au-delà des photographies, il y a : les graphiques (le cas le plus coûteux, et le plus souvent absent), les diagrammes, les schémas d'interface dans une procédure, les logos porteurs de sens quand ils lorsqu'ils portent un lien, les formules en image, les captures d'écran de code. Une capture de code sans alternative est un contenu inaccessible : le texte qu'elle porte n'existe que comme image.

   Le cas des images purement décoratives qui sont quand même annoncées

   Une icône décorative répétée devant chaque titre de menu produit un menu lu comme « icône image Accueil, icône image Formations ». Le alt="" n'est pas un oubli : c'est ce qui rend le menu lisible. Et l'icône ne doit pas être retirée du HTML, seulement de l'annonce vocale.

   Pour les graphiques : trois niveaux de réponse

   1. Alternative courte : la conclusion en une phrase — « les ventes baissent de 40 % entre mars et juin ».
   2. Description longue : la structure de la donnée, si elle est simple.
   3. Table de données accessible en complément ou à la place du graphique, quand la donnée est chiffrée et que le lecteur doit pouvoir la parcourir.

   Le piège classique : un graphique sans alternative textuelle est un critère 1.1.1 non respecté et une perte d'information pour tout le monde, y compris les personnes voyantes qui utilisent un agrandissement. Ce n'est pas un problème d'accessibilité, c'est un problème de conception.

2. Structure : nommer les niveaux et exposer les relations

   Le critère 1.3.1 (niveau A) — « information et relations » — est celui qui catches plus de sites que tous les autres réunis. Il demande que les relations visuelles entre contenu soient présentes dans le code.

   La hiérarchie de titres est un contracts, pas un style

   Un titre de niveau h3 sans h2 au-dessus n'est pas un détail aesthetic : il casse la navigation par titres, qui est la fonction d'assistance la plus utilisée sur un document long. Les lecteurs d'écran permettent de sauter d'un titre à l'autre, de remodeler la page en liste de titres, et de revenir à sa position après une recherche. Tout cela repose sur la hiérarchie des niveaux.

   La règle : un seul h1 par page, qui nomme le sujet, puis h2 pour les sections, h3 pour les sous-sections. Un saut de niveau est presque toujours un oubli de structure, et il se voit immédiatement.

   Les listes qui ne sont pas des listes

   Une suite de paragraphes séparés par des puces dessinées en CSS est annoncée comme une suite de paragraphes. Le lecteur d'écran ne dit pas « liste de 5 éléments », il lit cinq blocs sans signal. Pour un utilisateur qui navigue de titre en titre ou qui écoute en diagonale, la liste disparaît.

   Le cas spécifique des tableaux

   Un tableau de données est un tableau sémantique, avec caption, en-têtes de colonnes déclarés, et la relation entre les cellules. Un tableau dessiné pour la mise en page — le fameux « tableau pour diviser en deux colonnes » — est une catastrophe pour la lecture linéaire : l'ordre de lecture suit l'ordre du code, pas l'ordre visuel.

   Et il faut savoir qu'une mise en page réactive (mobile) qui transforme un tableau en cartes empilées destroys la relation entre les cellules si le balisage n'a pas été conçu pour. Les options sont connues : garder la structure de tableau et faire défiler horizontalement, ou associer explicitement chaque cellule à son en-tête.

   Lier les champs à leurs étiquettes

   Un champ de formulaire doit avoir une étiquette programmatiquement liée, par for / id. Un texte posé visuellement au-dessus du champ, sans lien dans le code, est invisible pour la technologie d'assistance : elle annonce « champ de saisie », sans dire lequel. Sur un formulaire de six champs, le résultat est un formulaire inutilisable.

   Les repères et les points de repère

   Navigation principale, contenu principal, pied de page : ce sont des repères, et les déclarer (header, nav, main, footer) permet à l'utilisateur de sauter directement à ce qui l'intéresse. C'est le critère 1.3.1 appliqué à la structure de page, et c'est ce qui fait la différence sur un site de commerce avec vingt liens de navigation avant le contenu.

3. Contraste, couleur et zoom : la lisibilité qui se mesure

   Le contraste du texte (critère 1.4.3, niveau AA)

   Les seuils sont vérifiés avec les WCAG 2.x :

   • Texte de taille normale (moins de 18 pt, ou 14 pt en gras) : ratio d'au moins 4,5:1.
   • Texte de grande taille (18 pt et plus, ou 14 pt en gras et plus) : ratio d'au moins 3:1.

   Un point de méthode qui évite des heures perdues : un texte placé sur une image ou un dégradé n'a pas de ratio calculable, seulement un contraste local. Il faut alors contrôler la zone réellement occupée par le texte, ou ajouter un fond, ou — plus simplement — ne pas poser de texte sur une image.

   Le contraste des éléments non textuels (1.4.11, niveau AA)

   Introduit par la WCAG 2.1 : les bords de champs de formulaire, les indicateurs de focus, les icônes porteuses de sens, les graphiques doivent avoir un ratio d'au moins 3:1 avec ce qui les entoure. Cette règle attrape beaucoup de champs de formulaire, dont la bordure est souvent #ddd sur fond blanc : presque aucun ne passe.

   La couleur ne doit pas être seule porteuse de sens

   Un champ d'erreur encirclé en rouge, un texte en rouge, une icône rouge : si le signal est uniquement la couleur, il disparaît pour une personne daltonienne. Le signal doit être doublé par un texte (« Erreur : ce champ est obligatoire »), une icône identifiable, ou un motif.

   Le zoom et l'espacement (1.4.10 et 1.4.12, niveau AA)

   À 400 % de zoom — l'équivalent d'un écran de téléphone en paysage — le contenu doit rester lisible sans défilement horizontal en deux dimensions. Concrètement : pas de largeur fixe en pixels, pas de texte en taille absolue dans une zone trop petite, et des tableaux qui laissent la place au défilement plutôt que de comprimer les colonnes.

   Le critère 1.4.12 va plus loin et impose que l'espacement du texte puisse être augmenté — hauteur de ligne, espacement entre lettres et entre mots, espacement des paragraphes — sans perte de contenu ni de fonctionnalité. Les unités relatives pour les tailles de police suffisent généralement à le satisfaire.

   Le texte justifié et les listes de liens

   Le texte justifié à la ligne force des espaces irréguliers qui rendent la lecture difficile pour certaines personnes dyslexiques ou en cas de strabisme. Ce n'est pas un critère WCAG, c'est une bonne pratique de lisibilité. De même, une liste de liens — un bloc de liens dont aucun n'a de sens hors contexte — est un critère échoué en Understandable (2.4.4) : le lien doit dire où il mène.

4. Ce qui se joue en double sensory

   Les informations purement sonores et purement visuelles demandent un équivalent (1.2.x). Trois cas à traiter systématiquement.

   Les images animées et les contenus en mouvement

   Une animation clignotante ou un défilement automatique peut provoquer une crise pour certaines personnes (critère 2.3.1, niveau A, sur trois clignotements par seconde). Le correctif est la possibilité de suspendre tout mouvement automatique de plus de cinq secondes — carrousels, défilement de texte, lecture vidéo en arrière-plan.

   La vidéo est un cas particulier : elle doit avoir une transcription ou une piste de sous-titres. Le sous-titrage des dialogues ne suffit pas — les informations purement sonores (le ton d'une alarme, un bruit qui signale un danger) doivent aussi être décrites.

   Les contenus audio et vidéo seuls

   Un contenu audio sans transcription exclut de fait les personnes sourdes et malentendantes, et pénalise durablement tout le monde dans un environnement bruyant — un train, une cuisine, un open space. La transcription n'est pas une mesure d'accessibilité, c'est une mise à disposition de contenu. Sur un site de formation, elle a une valeur pédagogique immédiate.

   Le mouvement : ce qui est en jeu

   Les animations de défilement et les effets de parallaxe provoquent des sensations de nausée et de désorientation. La WCAG ne les interdit pas, mais exige un mécanisme pour les neutraliser. Le geste « réduire les animations » présent dans les réglages système — et la règle prefers-reduced-motion côté CSS — est la mise en œuvre directe de cette exigence.