Checklist d'accessibilité web

Pourquoi cette règle ?

Si le contraste n'est pas suffisamment élevé, le texte est difficile à lire.

Cette règle s'applique aussi aux composants d'interface non textuels qui sont porteurs d'information (par exemple une pastille d'alerte ou le SVG de l'icône ouvrant le menu).

Comment vérifier ?

Utiliser un vérificateur de contrastes en ligne comme celui de coolors, utiliser un plugin Figma ou utiliser une extension web comme WCAG color contrast checker qui vérifie toute la page d'un coup.

Aller plus loin

Pourquoi cette règle ?

Si la couleur est la seule source d'information, les personnes ayant du mal à différencier certaines couleurs risquent de manquer cette information.

C'est par exemple le cas pour un champ de formulaire dont la bordure devient rouge (et rien d'autre) quand il est en erreur, ou pour les courbes d'un graphique qui sont uniquement différentiables par leur couleur.

Comment vérifier ?

Passer l'écran en mode noir et blanc (sur Mac activer le filtre des couleurs dans les options d'accessibilité). Ou installer l'extension colorblindly avec l'option "Monochromacy". Puis vérifier que les éléments d'interface sont toujours visibles et compréhensibles.

Aller plus loin

Pourquoi cette règle ?

Avoir une hiérarchie des titres pertinente visuellement (comprendre titre principal de la page, sous-titres, titres de sections, etc.) permet aux utilisateur·rices de se repérer plus facilement dans la page.

Avoir une hiérarchie des titres cohérente techniquement (comprendre ordre d'apparition dans le DOM des balises h1, h2, etc.) permet aux utilisateur·rices de technologies d'assistance (par exemple de lecteurs d'écran) de comprendre rapidement le contenu d'une page, et de naviguer simplement vers une section en particulier.

Enfin, si un texte a un style CSS de titre (par exemple un nom de section mis en avant par rapport au corps de texte), il doit être contenu dans une balise de titre HTML, pour que les personnes utilisant des technologies d'assistance puissent accéder rapidement à cette section.

Comment vérifier ?

Pour être pertinents, les titres doivent d'abord avoir un contenu textuel unique et explicite, pour qu'une personne naviguant au lecteur d'écran puisse aller vers la bonne section avec certitude.

Les balises h1, h2, etc. doivent respecter la hiérarchie h1 > h2 > h3 etc. sans sauter de niveau. Pour faire cette vérification, on peut utiliser l'extension web Headingsmap.

Techniquement, les textes ayant un style CSS de titre doivent être contenus dans une balise HTML h1, h2, etc.

Aller plus loin

Pourquoi cette règle ?

Les utilisateur·rices augmentent souvent la taille du texte pour améliorer la lisibilité. Même sur mobile, beaucoup d'utilisateur·rices paramètrent leurs appareils pour systématiquement augmenter la taille du texte.

Comment vérifier ?

Il y a une différence entre augmenter la taille du texte à 200% (ce qui est évalué par le RGAA), et zoomer une page jusqu'à 200%. Le plus sûr est de vérifier les deux systématiquement.

Puis vérifier que la page est toujours utilisable de la même manière qu'avec le zoom à 100%. Il faut que, malgré le zoom, les informations accessibles, et les fonctionnalités soient les mêmes qu'à 100%.

Aller plus loin

Pourquoi cette règle ?

Les utilisateur·rices doivent pouvoir utiliser le site testé sur différents appareils, et en particulier sur des tablettes ou des mobiles. Du mobile de 320px de large zoomé à 200% à l'écran géant, il est important de prendre en compte l'ensemble des tailles d'écran possibles.

Comment vérifier ?

Ouvrir l'inspecteur de code sur la page web : sur Mac Cmd + Maj + i ou clic droit puis "inspecter l'élément". Ensuite, faire varier la largeur de la barre latérale de l'inspecteur pour diminuer l'espace disponible du site web.

Pour toutes largeurs d'écran au-dessus de 320px, et pour toutes hauteurs d'écran au-dessus de 256px, les mêmes informations doivent être accessibles et les fonctionnalités doivent être les mêmes que sur n'importe quelle autre taille d'écran. Les informations ou éléments interactifs ne doivent pas sortir de l'écran.

Les dimensions 320px et 256px correspondent à un petit smartphone (qui peut être en format portrait ou paysage). Donc c'est soit l'un soit l'autre, et il n'est pas nécessaire de tester un écran qui aurait à la fois 320px de largeur et 256px de hauteur.

Aller plus loin

Pourquoi cette règle ?

Les utilisateur·rices peuvent avoir besoin d'augmenter l'espace entre les caractères du texte, entre les mots, entre les lignes ou entre les paragraphes pour mieux les lire.

Comment vérifier ?

(function () {
    const elements = document.querySelectorAll('*');
    for (const el of elements) {
        el.style.lineHeight = "1.5";
        el.style.letterSpacing = "0.12em";
        el.style.wordSpacing = "0.16em";
    }

    const paragraphs = document.querySelectorAll('p');
    for (const p of paragraphs) {
        p.style.marginBottom = "2em";
    }
})();

Ce script augmente les espacement de la page. Il faut alors que le site testé soit utilisable de la même manière qu'avant, et qu'aucune information n'ait disparue. Attention en particulier aux blocs qui ont une largeur fixe (comme certains champs de formulaire) qui risquent de voir disparaitre une partie de leur contenu textuel.

Aller plus loin

Pourquoi cette règle ?

Le title d'une page est le texte qui apparait en tant que nom de l'onglet dans le navigateur.

Ce texte constitue le nom de la page pour que les utilisateur·rices puissent identifier rapidement le contenu d'un onglet. C'est très utile aux utilisateur·rices de technologies d'assistance pour comprendre le contenu de la page quand elle s'ouvre (par exemple à la suite d'une redirection ou d'une navigation). Les lecteurs d'écran annoncent ce texte en premier quand on arrive sur la page.

À ne pas confondre avec les titres (headings) éventuels de la page qui sont, eux, inclus dans le contenu de la page et qui sont entourés de balises h1, h2, etc.

Comment vérifier ?

Pour voir le texte du title en entier, on peut passer la souris sur l'onglet dans la barre d'onglets du navigateur. On trouve aussi ce texte en entier dans la balise title incluse dans la balise head du code HTML : ouvrir l'inspecteur de code sur la page web : sur Mac Cmd + Maj + i ou clic droit, puis "inspecter l'élément", puis dans l'onglet "Elements".

Il faut non seulement que ce title existe, mais aussi qu'il indique clairement le contenu de la page.

Aller plus loin

Pourquoi cette règle ?

Certain·es utilisateur·rices naviguent et opèrent les sites web uniquement au clavier. Pour que ces personnes puissent utiliser le site testé de la même manière qu'un·e utilisateur·rice de souris, il faut que chaque élément interactif puisse être atteint et puisse être actionné en utilisant uniquement le clavier.

Comment vérifier ?

Aller plus loin

Pourquoi cette règle ?

Si l'ordre de navigation au clavier ne respecte pas un ordre cohérent (l'ordre le plus cohérent n'est pas systématiquement l'ordre de lecture classique), les utilisateur·rices peuvent se perdre dans la page, et interagir avec le mauvais élément.

Comment vérifier ?

Parcourir la page testée avec TAB et Maj + TAB et vérifier que l'ordre de la prise de focus des éléments interactifs est cohérent.

Aller plus loin

Pourquoi cette règle ?

Pour que les personnes naviguant au clavier se situent dans la page, et pour qu'elles sachent quel élément interactif est actionnable, il faut que l'élément portant le focus soit facilement identifiable. Le plus souvent, on reconnait cet élément à un contour externe.

Comment vérifier ?

Parcourir la page testée avec TAB et Maj + TAB et vérifier qu'on distingue toujours à l'écran quel élément est en focus.

Aller plus loin

Pourquoi cette règle ?

Certain·es utilisateur·rices parcourent les pages web en se déplaçant de bouton en bouton ou de lien en lien. Comment savoir alors à quoi sert un bouton "Cliquez ici", ou comment savoir vers quel lien "Lire plus" naviguer s'il y en a plusieurs sur la page ? Il est important que les boutons et liens soient compréhensibles par leur nom, hors de leur contexte visuel.

Aussi, les utilisateur·rices de commande vocale ont besoin d'accéder à un bouton par son nom. Si celui-ci n'est pas unique, cette opération devient compliquée.

Enfin, pour les utilisateur·rices de lecteurs d'écran, si un lien a pour nom un URL tel que "http://www...", le lecteur va annoncer chaque caractère de l'URL, ce qui est long, souvent incompréhensible et facilement évitable.

Comment vérifier ?

Il faut s'assurer que tous les liens et boutons ont un nom (soit un texte visible, soit un texte annoncé par les lecteurs d'écran qui atteignent l'élément). Il faut que les noms soient compréhensibles hors de leur contexte et qu'ils soient uniques.

Aller plus loin

Pourquoi cette règle ?

Restituer automatiquement les messages d'erreur au moment où ils surviennent est essentiel pour que les utilisateur·rices de ces technologies comprennent l'erreur qui a été faite sans avoir besoin de naviguer dans la page jusqu'à l'endroit où l'erreur est affichée (souvent sous le champ mais parfois en bas du formulaire).

Lorsqu'un·e utilisateur·rice de lecteur d'écran navigue jusqu'à un champ en erreur, si le message d'erreur est lié techniquement au champ, l'erreur est annoncée par le lecteur d'écran. Si le lien technique n'est pas fait (et si, contrairement au point précédent, l'erreur ne vient pas d'avoir lieu), l'utilisateur·rice doit aller chercher dans le formulaire quel message d'erreur correspond à ce champ.

Comment vérifier ?

En testant avec un lecteur d'écran, remplir le champ de formulaire et lorsqu'une erreur survient sur un champ, s'assurer qu'elle est restituée immédiatement.

En naviguant avec le clavier et un lecteur d'écran de champ en champ avec TAB et Maj + TAB, si un des champs sur lequel le focus passe est en erreur, s'assurer que le lecteur d'écran restitue le texte de l'erreur.

Aller plus loin

Pourquoi cette règle ?

Les messages de notification qui apparaissent à l'écran après une action donnent souvent des informations essentielles aux utilisateur·rices. Les personnes utilisant des lecteurs d'écran ne peuvent pas lire ce message au moment où il est utile s'il n'est pas restitué.

Comment vérifier ?

En utilisant un lecteur d'écran, faire une action qui déclenche l'apparition d'une notification. Le contenu de celle-ci doit être restitué.

Aller plus loin

Pourquoi cette règle ?

Revenir sur l'onglet depuis lequel a été ouverte la page actuelle peut être laborieux pour les utilisateur·rices de lecteurs d'écran ou de clavier, alors que revenir sur la page précédente en restant dans le même onglet est plus simple.

Par défaut, les liens du web s'ouvrent dans le même onglet, il vaut donc toujours mieux être explicite quand le lien s'ouvre dans un nouvel onglet.

Comment vérifier ?

Les liens ouvrant un nouvel onglet doivent avoir un signe distinctif (par exemple une icône) qui est compréhensible visuellement comme étant un signe d'ouverture dans un nouvel onglet. Au lecteur d'écran, il faut qu'au nom accessible du lien soit accolé la mention "Nouvelle fenêtre" ou "Nouvel onglet" (souvent il s'agit du nom accessible de l'icône elle-même).

Aller plus loin

Pourquoi cette règle ?

Pour comprendre le rôle d'un champ de formulaire (visuellement ou via les technologies d'assistance), le champ doit être accolé à son étiquette (label), et il doit être lié techniquement à celle-ci.

Comment vérifier ?

Il faut d'abord que tous les champs de formulaire (checkbox, select, input de texte, input de date, etc.) aient une étiquette visible.

Si l'étiquette est bien liée techniquement au champ, le clic sur l'étiquette devrait placer le focus dans le champ en question.

Il est possible que le champ soit étiquetté par un texte ailleurs sur la page. Dans ce cas, cliquer sur ce texte ne place pas le focus dans le champ, et il faut vérifier que le lecteur d'écran annonce le texte en question quand l'utilisateur·rice focus le champ.

Quel que soit le type d'étiquette, celle-ci doit être restituée par le lecteur d'écran au moment où le champ est atteint.

Aller plus loin

Pourquoi cette règle ?

Pour aider au remplissage des formulaires, il faut indiquer clairement quels champs sont obligatoires.

Comment vérifier ?

Au lecteur d'écran, lorsqu'on atteint le champ obligatoire, la mention "obligatoire" doit être restituée après l'annonce de l'étiquette du champ. C'est le cas automatiquement quand le champ porte l'attribut required ou aria-required="true".

On peut préférer ajouter la précision en début de formulaire "Tous les champs sont obligatoires", et accoler la mention "optionnel" aux étiquettes des champs non-obligatoires.

Aller plus loin

Pourquoi cette règle ?

Certains champs de formulaire attendent un format spécifique pour que le formulaire soit valide. Quand c'est le cas il est important de le faire savoir aux utilisateur·rices en amont. Par exemple, un champ de date doit préciser s'il s'agit d'une date en "JJ/MM/AAAA" ou d'un autre format.

Comment vérifier ?

Visuellement le format doit être identifiable comme étant lié au champ qu'il concerne.

Si le format attendu n'est pas directement inclus dans l'étiquette du champ, il faut vérifier avec un lecteur d'écran que le format est restitué lorsque le champ est atteint. Par défaut, lorsque l'utilisateur·rice soumet un formulaire invalide, le navigateur repositionne immédiatement le focus dans le premier champ en erreur. Un·e utilisateur·rice peut donc être en focus dans le champ sans avoir pu consulter le contexte immédiat de celui-ci (indication du format). C'est pourquoi il faut vérifier que lors du focus du champ le format est restitué.

Il faut que le format soit accessible avant d'avoir commis la première erreur.

Aller plus loin

Pourquoi cette règle ?

Les éléments picturaux qui sont porteurs d'information doivent être accessibles à tous les utilisateur·rices de la même manière, même aux personnes utilisatrices de technologies d'assistance.

Les éléments picturaux uniquement décoratifs doivent être paramétrés pour être ignorés par les technologies d'assistance pour éviter d'interférer avec la restitution.

Comment vérifier ?

Parcourir les images, icônes et emoji au lecteur d'écran. S'ils sont porteurs d'information, leur description doit être restituée. S'ils sont décoratifs, ils ne doivent pas être annoncés du tout (même la restitution par défaut des images par les lecteurs d'écran "Image" ne doit pas être annoncée).

Il faut aussi vérifier que l'alternative est pertinente. Elle doit décrire le contenu visuel en restant simple, pour permettre aux utilisateur·rices de lecteurs d'écran d'opérer le site comme les autres utilisiateur·ices.

Aller plus loin