Accessibilité : rendre un site utilisable par tous

On entend généralement par accessibilité « la possibilité pour les personnes en situation de handicap d'utiliser un service ». La définition est exacte et elle est boite, parce qu'elle présente l'accessibilité comme une concession : on rendrait service à une catégorie de personnes, et le produit resterait ce qu'il est.

La conséquence de cette lecture

On corrige ce qui gêne visiblement : on ajoute des textes alternatifs sur les images, on agrandit les zones de clic, on met une couleur plus contrastée sur les boutons. On laisse le reste, parce que le reste ne se voit pas quand on n'est pas concerné : les incohérences de navigation, les champs de formulaire sans étiquette, les messages d'erreur qui disparaissent avant d'avoir pu être lus.

L'autre définition

L'accessibilité est une qualité du produit, au même titre que la vitesse ou la sécurité. Elle ne s'adresse pas « aux handicapés » mais à qui que ce soit, dans une situation donnée : un écran de formulaire lu sous la pluie, dans un train, avec 2 % de batterie, par quelqu'un qui a mal au poignet, sur un téléphone qu'il n'a pas choisi, avec un lecteur d'écran activé par erreur et jamais éteint depuis.

Le mobile corrige les deux tiers des problèmes d'accessibilité d'un site. Non pas parce qu'il est « pour les handicapés », mais parce qu'un écran tactile de 6 pouces et une connexion dégradée sont la condition normale de millions de personnes qui se disent perfectly capable de regarder une page web.

Pourquoi cette différence change le résultat

Un budget « conformité RGAA » produit une checklist cochée et un site médiocre. Un budget « qualité produit » produit des tests sur des tâches réelles, et découvre des bugs que personne n'avait vus : un label qui n'est pas relié à son champ, une modale qui piège le focus, un message d'erreur qui ne dit pas quoi corriger.

La question à poser en début de projet

Pas « la page est-elle accessible ? » mais : quelles tâches doit pouvoir accomplir un utilisateur dans cette situation, et qu'est-ce qui l'en empêche aujourd'hui ? La première question appelle un audit. La seconde appelle un travail, et elle trouve ce que l'audit ne voit pas.

La WCAG 2.2 organise ses exigences autour de quatre principes — Perceivable, Operable, Understandable, Robust — déclinés en principes-directeurs, puis en critères de succès, puis en techniques qui ne sont que des exemples de mise en œuvre.

Perceivable — l'information doit être-IT disponible

• Ce qui est uniquement visuel a besoin d'un équivalent.
• Ce qui est uniquement sonore a besoin d'un équivalent.
• L'interface s'adapte au contraste et au zoom, sans perte de contenu.
• Les relations entre les éléments (un label, un titre) sont exposed, pas seulement dessinées.

Operable — l'interface se manipule

• Tout est faisable au clavier, sans piège ni délai.
• Aucun geste exige un seul point de contact : le balayage n'est pas la seule voie.
• Le contenu ne clignote pas plus de trois fois par seconde.
• Les titles donnent le contexte : une page qui s'ouvre dans un nouvel onglet l'annonce.

Understandable — c'est compréhensible

• La langue de la page est déclarée, y compris les passages dans une autre langue.
• Chaque page a un titre qui la décrit dans le contexte du site.
• Les erreurs sont identifiées en texte et décrites, pas signalées par une couleur seule.
• L'aide contextuelle est disponible quand c'est nécessaire.

Robust — ça résiste à l'interprétation

• Le code est valide et les rôles sont exposés : les technologies d'assistance savent ce qu'est un bouton, un champ, un titre.
• Le nom, le rôle et la valeur de chaque composant sont programmatiquement déterminables.

Les trois niveaux de conformité, et pourquoi le second compte

Les critères sont classés de A à AAA par niveau d'exigence. La quasi-totalité des obligations légales et des cahiers des charges demande le niveau AA.

Deux réflexes à éviter : viser AAA pour se distinguer, et descendre à A pour livrer plus vite. AAA contient des critères très exigeants (durée de vie des messages d'erreur, pas de texte clignotant, niveau de contraste renforcé) qui ne rapportent presque rien au produit. À l'inverse, ignorer les critères A d'Operable — le clavier, la navigation — revient à livrer un site inutilisable pour une partie consistente des utilisateurs, et c'est bien plus grave qu'un manque de contraste sur un lien secondaire.

L'accessibilité n'est pas une bonne pratique volunteer en France : pour un certain nombre d'acteurs, c'est une obligation légale assortie de sanctions.

Le cas général

La loi n° 2005-102 du 11 février 2005 pour l'égalité des droits et des chances de participation à la vie sociale impose aux services publics, aux établissements publics et aux entreprises privées obéissant à des obligations de service public une obligation d'accessibilité de leurs services de communication au public en ligne. Le principe retenu est celui de la conformité progressive : un schéma d'amélioration est attendu, avec un calendrier.

La déclaration d'accessibilité

Point le plus souvent manqué : ce n'est pas seulement rendre le site accessible, c'est publier une déclaration d'accessibilité. Elle doit indiquer l'état de conformité constaté, le contenu et les méthodes de l'évaluation, les écarts identifiés et leur justification, et la voie de recours en cas de difficulté. Elle doit être révisée périodiquement et à chaque évolution majeure du site.

Le RGAA n'est pas la WCAG

Le RGAA (Référentiel général d'amélioration de l'accessibilité, Dinum) est la déclinaison française du WCAG : il en reprend les principes en 106 critères, chacun accompagné des tests correspondants. Il permet une évaluation reproductible là où la WCAG laisse le choix des techniques.

À la date de ce cours, la version en vigueur est le RGAA 4.1.2. La version 5 est en cours de rédaction pour une publication attendue fin 2026. Travailler avec le 4.1.2 n'est donc pas un travail provisoire : le RGAA 5 précisera ou complétera les critères du 4.1.2 sans les infirmer, et les audits réalisés avant cette publication resteront valables dix-huit mois.

La conséquence pratique pour un projet

Si l'acteur est concerné par l'obligation légale, il n'y a pas d'arbitrage possible entre conformité et calendrier : il y a un risque contentieux. Si le projet est un produit commercial qui vise la France, largument « accessibilité = coût » ne tient pas, parce que la sanction existe et que les grands donneurs d'ordre l'exigent dans leurs propres cahiers des charges.

Les outils d'audit automatique ont une place, et il faut savoir précisément laquelle : ils détectent environ un quart des problèmes environ. Les trois quarts restants relèvent du jugement humain.

Ils sont fiables sur ce qui est calculable

• Images sans alternative ou avec une alternative vide ou inutile : fiable.
• Contraste insuffisant calculé sur les couleurs déclarées : fiable.
• Champs de formulaire sans étiquette reliée : très fiable.
• Attributs ARIA invalides ou contradictoires : fiable.
• Rôles sans nom accessible (bouton icône sans texte) : fiable.

Ils sont aveugles sur ce qui est intentionnel

• Un texte alternatif présent mais mauvais — il passe le contrôle automatique et décrit l'image d'une façon fausse ou inutile.
• Un parcours cohérent ou non : l'outil vérifie des éléments isolés, jamais l'enchaînement des tâches.
• Un message d'erreur utile ou non : il vérifie que le texte existe, pas qu'il indique quoi corriger.
• Un ordre de tabulation qui correspond à l'ordre visuel : c'est une erreur fréquente et invisible pour l'outil.
• Le langage : un texte écrit dans une langue approximative passe.

Ce que « absence de rapport » ne prouve pas

Un audit automatique qui renvoie zéro erreur ne prouve pas que la page est conforme : il prouve qu'aucun des défauts qu'il sait détecter n'a été trouvé. Entre les deux, il y a la majorité des problèmes qui font mal à un vrai utilisateur. Un audit automatique sans vérification manuelle n'est pas un audit, c'est un filtre.

La place qui revient au test manuel

Elle n'est pas dans « corriger les avertissements », qu'un outil fait déjà. Elle est dans deux gestes uniquement humains : naviguer au clavier, ce qui révèle les pièges de focus et les désordres de tabulation, et tester des tâches réelles sur un écran de téléphone vrai en 3G, ce qui révèle les problèmes de contraste, de taille de cible et de temps de réponse que le zoom desktop masque.

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.

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.

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.

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.