Accessibilité Web : où la plupart des municipalités échouent

Dans nos audits de sites Web municipaux, une tendance claire se dégage : les mêmes défaillances d'accessibilité reviennent encore et encore, dans des communautés de toutes tailles et de tous budgets. Les problèmes sont constants et (c'est la partie encourageante) la plupart sont simples à corriger une fois que vous savez où regarder.

L'accessibilité Web consiste à veiller à ce que chaque résident puisse accéder en ligne à l'information et aux services que votre municipalité offre, quelles que soient ses capacités. En vertu de l'Accessible BC Act et de ses équivalents dans les autres provinces, c'est aussi de plus en plus une obligation légale. Voici les lacunes que nous observons le plus souvent.

Texte alternatif manquant ou dénué de sens sur les images

C'est la défaillance d'accessibilité la plus courante sur les sites Web municipaux, et l'une des plus simples à corriger. Chaque image de votre site Web a besoin d'un attribut alt qui décrit le contenu ou la fonction de l'image. Les lecteurs d'écran s'appuient sur ce texte pour transmettre l'information visuelle aux personnes qui ne peuvent pas voir l'image.

Le problème n'est habituellement pas que le texte alternatif soit complètement absent; la plupart des systèmes de gestion de contenu génèrent au moins un attribut alt vide. Le problème est que le texte alternatif, lorsqu'il existe, est souvent dénué de sens. Nous voyons régulièrement des textes alternatifs comme « IMG_2847.jpg », « photo » ou simplement le nom de fichier de l'image. Aucun de ces textes n'indique à une personne utilisant un lecteur d'écran ce que l'image montre. Une photo du maire annonçant un nouveau parc devrait avoir un texte alternatif qui décrit exactement cela, et non le nom de fichier généré automatiquement par l'appareil photo.

Les images décoratives qui ne véhiculent aucun contenu (textures d'arrière-plan, lignes de séparation, icônes purement décoratives) devraient avoir un attribut alt vide (alt="") afin que les lecteurs d'écran les ignorent entièrement. Le principe clé : chaque image a besoin soit d'une description significative, soit d'une instruction explicite d'être ignorée.

Contraste de couleurs insuffisant

Les WCAG 2.1 AA exigent un rapport de contraste minimal de 4,5:1 pour le texte normal et de 3:1 pour le grand texte. De nombreux sites Web municipaux ne respectent pas cette norme, en particulier sur les éléments de navigation, le texte de pied de page, le texte d'invite dans les champs de formulaire et le texte superposé à des images ou à des arrière-plans colorés.

Le texte gris pâle sur un arrière-plan blanc est le contrevenant le plus fréquent. Il paraît élégant dans une maquette de conception, mais il est véritablement difficile à lire pour les personnes ayant une basse vision, un daltonisme, ou pour quiconque consulte le site sur un écran de moindre qualité en plein soleil. Le correctif est simple : faites passer vos combinaisons de couleurs dans un vérificateur de contraste et ajustez-les jusqu'à ce qu'elles atteignent les rapports minimaux. Des outils comme le vérificateur de contraste de WebAIM font de cette tâche une affaire de cinq minutes pour n'importe quelle paire de couleurs.

Formulaires sans étiquettes appropriées

Les sites Web municipaux regorgent de formulaires : demandes de service, demandes de permis, formulaires de rétroaction, inscriptions à des événements. Pour les personnes voyantes, un champ de formulaire avec un texte d'invite visible indiquant « Saisissez votre courriel » semble parfaitement clair. Pour les personnes utilisant un lecteur d'écran, si ce champ n'a pas d'élément d'étiquette correctement associé, il peut être annoncé simplement comme « champ de texte », sans aucune indication de l'information attendue.

Chaque champ de formulaire a besoin d'un élément d'étiquette avec un attribut « for » correspondant, ou d'un attribut aria-label si une étiquette visible ne fait pas partie de la conception. Le texte d'invite ne remplace pas une étiquette : il disparaît dès que l'utilisateur commence à saisir et n'est pas annoncé de façon fiable par tous les lecteurs d'écran. C'est particulièrement important pour les formulaires complexes comme les demandes de permis, où des dizaines de champs doivent parfois être remplis correctement. Si une personne utilisant un lecteur d'écran ne peut pas déterminer ce que chaque champ exige, le formulaire est concrètement inutilisable.

Hiérarchie de titres manquante

Les éléments de titre (h1 à h6) créent un plan structurel de la page sur lequel les personnes utilisant un lecteur d'écran s'appuient pour naviguer. Une hiérarchie de titres correctement structurée permet à l'utilisateur de parcourir rapidement la page et de sauter à la section dont il a besoin, à la manière dont une personne voyante parcourt visuellement les titres et les sous-titres.

Les problèmes les plus courants : des pages sans élément h1, des niveaux de titre qui sautent (passant de h2 à h4), des titres utilisés purement pour le style visuel, et des pages où tout le texte est de la même taille sans aucun balisage de titre. Les pages municipales au contenu informationnel dense (règlements, procès-verbaux de conseil, descriptions de services) sont les pires contrevenantes. Corrigez la structure des titres et vous améliorez l'expérience pour les personnes utilisant un lecteur d'écran comme pour les moteurs de recherche.

Des PDF qui ne sont pas accessibles

C'est peut-être l'obstacle à l'accessibilité le plus répandu sur les sites Web municipaux. Les municipalités publient un volume énorme de contenu sous forme de documents PDF : ordres du jour des conseils, procès-verbaux de réunions, règlements, rapports, formulaires, cartes. La grande majorité de ces PDF ne sont pas balisés pour l'accessibilité, ce qui signifie que les lecteurs d'écran ne peuvent pas analyser leur structure ni lire leur contenu dans un ordre logique.

Les documents numérisés sont le pire des cas : ce sont essentiellement des images de texte, complètement invisibles pour les lecteurs d'écran. Mais même les PDF créés numériquement sont souvent inaccessibles s'ils n'ont pas été correctement balisés avec des titres, un ordre de lecture, du texte alternatif pour les images et une structure de tableau. La solution consiste soit à rendre les PDF accessibles à l'aide d'outils comme les fonctions d'accessibilité d'Adobe Acrobat, soit, mieux encore, à publier le contenu sous forme de pages Web HTML avec le PDF offert comme format secondaire. Le HTML est intrinsèquement plus accessible et plus facile à maintenir.

Défaillances de la navigation au clavier

Tous les utilisateurs ne naviguent pas avec une souris. Les personnes ayant un handicap moteur, les utilisateurs avancés du clavier et les personnes utilisant un lecteur d'écran s'appuient toutes sur la navigation au clavier. Chaque élément interactif de votre site Web (liens, boutons, champs de formulaire, menus déroulants, boîtes de dialogue modales) doit être accessible et utilisable au clavier seulement.

Les défaillances les plus courantes : les menus déroulants qui ne s'ouvrent qu'au survol de la souris, les boîtes de dialogue modales qui gèrent mal le focus du clavier, les contrôles personnalisés construits avec des div et des span plutôt qu'avec des boutons et des liens sémantiques, et l'absence d'indicateurs de focus visibles. Testez votre site en mettant votre souris de côté et en essayant d'accomplir des tâches courantes à l'aide des seules touches Tab, Entrée, Échap et flèches. Si vous restez coincé, vos utilisateurs du clavier le sont aussi.

Par où commencer

Vous n'avez pas besoin de tout corriger d'un coup. Commencez par les pages qui comptent le plus : votre page d'accueil, vos formulaires de demande de service, votre page de contact, vos pages de contenu les plus consultées. Effectuez une analyse automatisée à l'aide d'un outil comme axe ou WAVE pour repérer les gains faciles, puis traitez les problèmes de façon systématique. Dans les audits que nous menons, les outils automatisés ne font ressortir qu'une minorité des vrais problèmes. Pour le reste, vous avez besoin de tests manuels : navigation au clavier, tests avec lecteur d'écran et, idéalement, tests avec des personnes qui utilisent les technologies d'assistance.

L'accessibilité est une pratique continue. Intégrez-la à votre processus de publication de contenu, à vos revues de conception et à vos exigences envers les fournisseurs. Chaque amélioration que vous apportez est une amélioration pour de vrais résidents de votre communauté qui sont actuellement exclus de services auxquels ils ont pleinement droit.