Niveau A, AA ou AAA : quel standard WCAG viser pour un site public en France ?

En tant que chef de projet web dans le secteur public ou une grande entreprise, la question de la conformité à l’accessibilité numérique est inévitable. La législation française, via le Référentiel Général d’Amélioration de l’Accessibilité (RGAA), impose des obligations claires. Mais face aux niveaux A, AA, et AAA, la stratégie à adopter peut sembler floue. Beaucoup se contentent de suivre la recommandation de base : viser le niveau AA. Cette approche, bien que correcte sur le papier, occulte une réalité de terrain bien plus complexe. Le RGAA, qui est la transposition française des directives internationales WCAG, n’est pas une simple checklist technique à cocher.

L’erreur la plus commune est de considérer l’accessibilité comme une couche de vernis technique appliquée en fin de projet. On lance un audit automatisé, on corrige les erreurs signalées et on pense avoir fait le travail. Or, cette vision est non seulement réductrice, mais aussi dangereuse. Elle mène à des sites « conformes » en apparence, mais inutilisables en pratique pour les personnes en situation de handicap. Mais si la véritable clé n’était pas d’atteindre un score, mais de comprendre la philosophie derrière les règles ? Et si le niveau AA n’était pas une destination, mais une étape dans une démarche d’amélioration continue centrée sur l’utilisateur ?

Cet article propose une approche d’auditeur certifié : dépasser la lettre de la loi pour en saisir l’esprit. Nous analyserons pourquoi l’accessibilité est un enjeu stratégique majeur, nous déconstruirons les mythes autour des outils automatiques et des solutions techniques comme ARIA, et nous fournirons des clés concrètes pour bâtir une expérience numérique réellement inclusive. L’objectif n’est pas de viser un niveau, mais de construire un service public numérique qui fonctionne pour tous.

Pour naviguer à travers ces enjeux complexes, cet article est structuré pour vous guider pas à pas, du « pourquoi » stratégique aux « comment » techniques les plus courants. Voici les points que nous allons aborder.

Pourquoi rendre votre site accessible vous ouvre un marché de 12 millions de français ?

Avant d’entrer dans la technique, il est crucial de comprendre l’enjeu humain et économique de l’accessibilité numérique. On l’associe souvent à une contrainte légale, mais c’est avant tout une opportunité stratégique. En France, le sujet est loin d’être anecdotique. Selon une publication officielle, près de 14,5 millions de personnes de 15 ans ou plus (28 %) ont une limitation fonctionnelle, qu’elle soit visuelle, auditive, motrice ou cognitive. Ignorer l’accessibilité, c’est donc délibérément exclure une part significative de la population de vos services en ligne.

Cette exclusion a un coût direct. Une étude montre que 71 % des clients ayant des besoins spécifiques quittent un site jugé difficile d’accès, et que 82 % d’entre eux sont prêts à payer plus cher ailleurs pour une meilleure expérience. Pour un service public, la conséquence n’est pas une perte de chiffre d’affaires, mais une rupture de l’égalité d’accès aux droits, ce qui est encore plus grave. Rendre un site accessible n’est donc pas une dépense, mais un investissement dans l’égalité et l’efficacité de l’action publique.

L’impact positif va bien au-delà des personnes en situation de handicap permanent. Une conception accessible bénéficie à tous : un sous-titrage de vidéo est utile dans un environnement bruyant, des contrastes élevés améliorent la lisibilité en plein soleil, et une structure claire aide les utilisateurs pressés ou fatigués. En adoptant les principes du RGAA, vous ne répondez pas seulement à une obligation, vous améliorez la qualité globale et l’expérience utilisateur de votre service pour l’ensemble des citoyens.

Comment un aveugle navigue-t-il sur votre site et pourquoi votre menu est invisible pour lui ?

Pour un utilisateur voyant, la structure d’une page est visuelle : menus, titres, colonnes, pieds de page. Pour une personne non-voyante utilisant un lecteur d’écran (comme NVDA ou Jaws), cette structure doit être sémantique. Le logiciel ne « voit » pas la page, il lit le code HTML sous-jacent et le vocalise. Si ce code est mal structuré, le site devient un labyrinthe incompréhensible. Un menu de navigation, par exemple, peut être totalement invisible s’il n’est pas balisé correctement.

Concrètement, l’utilisateur d’un lecteur d’écran ne lit pas la page de haut en bas. Il utilise des raccourcis clavier pour « sauter » de titre en titre (H1, H2, H3…), de lien en lien, ou pour naviguer par « régions » (landmarks). Ces régions sont des balises HTML5 comme <nav> pour la navigation principale, <main> pour le contenu principal, ou <footer> pour le pied de page. Si votre menu est une série de <div> génériques sans rôle sémantique, le lecteur d’écran ne peut pas l’identifier comme un menu. L’utilisateur ne saura même pas qu’il existe.

L’invisibilité peut aussi venir de détails techniques. Un menu qui apparaît au survol de la souris est souvent inutilisable pour quelqu’un qui navigue au clavier. De même, une icône de recherche sans texte alternatif ou un lien « Cliquez ici » ne donnent aucune information sur leur fonction. Pour un lecteur d’écran, un site bien conçu est un site prévisible et explicite. Voici quelques éléments fondamentaux pour une navigation non-voyante réussie :

• Un lien d’évitement : Placé au tout début du code, il permet de sauter directement au contenu principal sans devoir écouter toute l’en-tête à chaque chargement de page.
• Une structure de titres logique : Les niveaux de titres (H1, H2, H3…) doivent être hiérarchiques et ne jamais être utilisés à des fins purement stylistiques.
• Des landmarks HTML5 : Utiliser <header>, <nav>, <main>, <aside>, et <footer> pour délimiter les grandes zones de la page.
• Des états explicites pour les composants interactifs : Pour un menu déroulant, utiliser aria-expanded pour indiquer s’il est ouvert ou fermé, et aria-current="page" pour marquer la page active.

Lighthouse ou Axe : que détectent vraiment les robots et que laissent-ils passer ?

Face à la complexité du RGAA, la tentation est grande de se reposer sur des outils d’audit automatisés comme Lighthouse (intégré à Chrome) ou l’extension Axe. Ces outils sont précieux pour un premier diagnostic : ils scannent le code et signalent rapidement des erreurs évidentes. Ils peuvent vérifier la présence d’un attribut alt sur une image, l’existence d’un titre de page ou certains problèmes de contraste de couleurs. Obtenir un score de 100/100 en accessibilité sur Lighthouse est une bonne première étape qui signifie que vous avez évité les erreurs les plus grossières.

Cependant, il est crucial de comprendre le « piège du 100% ». Un score parfait ne garantit absolument pas la conformité RGAA, et encore moins l’utilisabilité du site. En réalité, une analyse comparative montre que Lighthouse teste seulement environ 30% des critères d’accessibilité. Les robots sont limités par nature : ils peuvent vérifier la présence d’un élément, mais pas sa pertinence. Par exemple, un outil peut voir qu’une image a une alternative textuelle (attribut `alt`), mais il ne peut pas juger si cette alternative décrit correctement l’image ou si elle est vide et inutile. Il peut vérifier qu’un bouton est cliquable, mais pas s’il est logiquement atteignable au clavier.

Cette limitation explique en partie les chiffres décevants de l’accessibilité des services publics en France. Même avec des obligations légales claires, l’observatoire du respect des obligations d’accessibilité numérique révèle que seulement 6,5 % des 244 démarches en ligne essentielles atteignent un taux de conformité de 100%. Cela prouve que la conformité ne peut pas être déléguée à un robot. Elle exige une évaluation manuelle et contextuelle par un expert qui simule l’usage des technologies d’assistance et évalue la logique des parcours utilisateurs. Les outils automatiques sont des aides, pas des auditeurs.

Quand utiliser ARIA (et surtout quand ne pas l’utiliser) pour enrichir votre HTML ?

Lorsque les développeurs cherchent à corriger les lacunes d’accessibilité, notamment pour des composants d’interface complexes (onglets, accordéons, modales), ils se tournent souvent vers ARIA (Accessible Rich Internet Applications). ARIA est un ensemble d’attributs HTML qui permet d’ajouter des informations sémantiques au code pour le rendre plus compréhensible par les technologies d’assistance. Bien utilisé, ARIA peut être une solution puissante. Mal utilisé, il devient un véritable poison pour l’accessibilité.

La première règle d’or d’ARIA est : ne pas utiliser ARIA si un élément HTML natif fait déjà le travail. Par exemple, au lieu de créer un bouton avec une balise <div> et d’y ajouter role="button", il faut toujours privilégier la balise <button>. L’élément natif embarque par défaut tout le comportement attendu (activation avec la barre d’espace et la touche Entrée, gestion du focus, etc.), ce qu’un <div> ne fait pas. Sur-utiliser ARIA est une cause fréquente de « dette d’accessibilité » : on pense améliorer les choses, mais on crée de nouveaux problèmes. L’analyse du WebAIM Million 2024 est sans appel : elle révèle que les pages utilisant ARIA présentent en moyenne 34,2% d’erreurs supplémentaires par rapport à celles qui n’en utilisent pas.

ARIA est utile pour des cas précis, principalement pour décrire le rôle, l’état et les propriétés de composants dynamiques qui n’ont pas d’équivalent en HTML standard. Par exemple, l’attribut aria-expanded="true/false" est essentiel pour indiquer si un menu d’accordéon est déplié ou replié. Mais cet état doit être mis à jour dynamiquement via JavaScript. Ajouter un attribut statique ne sert à rien et peut même induire l’utilisateur en erreur. L’utilisation d’ARIA demande une compréhension fine de son impact et une rigueur dans son implémentation.

Décorative ou Informative : comment rédiger une alternative textuelle pertinente ?

L’alternative textuelle, définie par l’attribut alt d’une image, est l’un des piliers de l’accessibilité web. C’est ce texte qui est lu par les lecteurs d’écran pour décrire une image à un utilisateur non-voyant. C’est aussi ce qui s’affiche si l’image ne se charge pas. Pourtant, la rédaction d’un bon « alt » est un exercice souvent mal compris, résumé à tort à « il faut mettre quelque chose ». La question n’est pas de décrire l’image, mais de transmettre sa fonction et l’information qu’elle véhicule dans son contexte.

La première distinction à faire est entre l’image informative et l’image décorative. Une image décorative n’apporte aucune information essentielle à la compréhension du contenu. Il peut s’agir d’une icône purement illustrative à côté d’un titre, d’une ligne de séparation ou d’une photo d’ambiance. Dans ce cas, l’alternative textuelle doit être vide (alt=""). Laisser l’attribut vide est crucial : cela indique au lecteur d’écran d’ignorer complètement l’image. Si l’attribut alt est absent, certains lecteurs d’écran liront le nom du fichier de l’image (« IMG_4567.jpg »), créant un bruit inutile et perturbant pour l’utilisateur.

Une image informative, quant à elle, contient une information que le texte environnant ne donne pas. La rédaction de son alternative dépend de son rôle :

• Image simple : Décrivez brièvement ce que l’image montre et l’information qu’elle apporte. Exemple pour une photo d’un produit : alt="Smartphone bleu avec trois capteurs photo alignés verticalement."
• Image-lien : L’alternative ne doit pas décrire l’image, mais la destination du lien. Si un logo d’entreprise renvoie à la page d’accueil, l’alternative doit être alt="Accueil - Nom de l'entreprise".
• Image complexe (graphique, infographie) : L’attribut alt doit donner une description concise du sujet du graphique. Une description détaillée et complète des données doit être fournie dans le texte de la page ou via un lien adjacent pointant vers une page de transcription.

Évitez les redondances comme « image de… » ou « photo de… ». Le lecteur d’écran annonce déjà qu’il s’agit d’une image. Allez droit au but. Une bonne alternative est un acte d’empathie : elle permet à tous les utilisateurs d’accéder au même niveau d’information, quelle que soit leur manière de consulter la page.

Langage clair et structure prévisible : comment aider les utilisateurs avec des troubles de l’attention ?

L’accessibilité numérique ne concerne pas uniquement les handicaps sensoriels ou moteurs. Elle englobe aussi les troubles cognitifs et de l’attention (TDAH, troubles « dys », etc.). Pour ces utilisateurs, un site surchargé, un jargon administratif complexe ou une navigation imprévisible peuvent constituer des barrières infranchissables. Améliorer cet aspect de l’accessibilité repose sur deux piliers : le langage clair et une structure de page cohérente.

Le langage clair, ou FALC (Facile à Lire et à Comprendre), consiste à privilégier des phrases courtes, un vocabulaire simple et une voix active. Pour un service public, c’est un enjeu majeur. Le jargon administratif est par nature exclusif. Remplacer « procéder à l’instruction du dossier » par « étudier votre demande » n’est pas un appauvrissement du langage, mais une marque de respect envers l’usager, lui permettant de comprendre immédiatement ce qui est attendu de lui. Cette simplification bénéficie à tous, y compris les personnes dont le français n’est pas la langue maternelle ou les usagers simplement stressés par une démarche administrative.

La structure prévisible, quant à elle, vise à créer un environnement numérique rassurant. Cela signifie que les éléments de navigation (menu, fil d’Ariane, moteur de recherche) doivent se trouver au même endroit sur toutes les pages. Les liens et les boutons doivent avoir une apparence cohérente et leur comportement doit être prévisible. Une structure de page bien aérée, avec des titres clairs, des paragraphes courts et des listes à puces, facilite le balayage visuel et aide l’utilisateur à se concentrer sur l’essentiel sans se sentir submergé par l’information.

Sessions expirées : comment permettre à l’utilisateur de prolonger son temps de lecture ?

Un critère du RGAA souvent négligé, car perçu comme relevant de l’UX ou de la sécurité, est la gestion des limites de temps. De nombreuses démarches en ligne, pour des raisons de sécurité, mettent fin à la session de l’utilisateur après une période d’inactivité. Si cette expiration se produit sans avertissement, elle peut être catastrophique pour l’accessibilité. Un utilisateur qui prend plus de temps pour lire, qui utilise un logiciel de dictée vocale pour remplir un formulaire ou qui a besoin d’une pause en cours de saisie peut voir tout son travail anéanti.

Le RGAA est très clair sur ce point : si une limite de temps est imposée, l’utilisateur doit avoir la possibilité de la désactiver, de l’ajuster ou de la prolonger. L’interruption brutale d’une session est particulièrement pénalisante pour les personnes naviguant au clavier ou avec des technologies d’assistance. Comme le souligne le portail MonParcoursHandicap, devoir recommencer une démarche complexe parce que la session a expiré sans avertissement peut rendre le service totalement inutilisable pour ces publics.

La solution ne consiste pas à supprimer toutes les limites de temps, mais à les rendre flexibles et transparentes. Une implémentation accessible doit respecter plusieurs principes :

• Avertissement préalable : L’utilisateur doit être prévenu au moins 20 secondes avant l’expiration, via un message clair et visible.
• Annonce aux technologies d’assistance : Cet avertissement doit être annoncé par les lecteurs d’écran. L’utilisation d’un attribut aria-live="polite" ou aria-live="assertive" sur le message d’alerte est une bonne pratique.
• Action de prolongation simple : Un bouton ou un lien facilement accessible (au clavier également) doit permettre de prolonger la session d’un simple clic.
• Sauvegarde des données : Dans l’idéal, les données déjà saisies par l’utilisateur devraient être sauvegardées automatiquement avant l’expiration, pour lui permettre de reprendre sa démarche sans tout perdre.

Gérer correctement l’expiration des sessions est un exemple parfait de la convergence entre une bonne expérience utilisateur (UX) et une accessibilité robuste. C’est une fonctionnalité qui bénéficie à tous les utilisateurs tout en étant absolument indispensable pour certains.

« Tout accepter » ou « Tout refuser » : comment designer un bandeau légal qui convertit ?

Le bandeau de consentement aux cookies est un cas d’école où deux réglementations se rencontrent : le RGPD (via la CNIL) et le RGAA. Un bandeau doit non seulement être conforme aux exigences de la CNIL (bouton « Tout refuser » au même niveau que « Tout accepter »), mais il doit aussi être entièrement accessible. Un bandeau non-conforme au RGAA peut piéger un utilisateur naviguant au clavier ou être totalement invisible pour un lecteur d’écran, rendant le consentement impossible et bloquant l’accès au site.

La double conformité CNIL-RGAA impose de concevoir ces bandeaux selon les standards d’accessibilité. Cela signifie que chaque élément interactif (boutons, liens, cases à cocher) doit être accessible au clavier. Le « focus », cet indicateur visuel qui montre quel élément est actuellement sélectionné, doit être clairement visible lors de la navigation avec la touche Tab. Pour les lecteurs d’écran, le bandeau doit être correctement structuré, par exemple en utilisant un rôle ARIA role="dialog" avec aria-modal="true" pour « piéger » le focus à l’intérieur de la modale tant qu’une action n’a pas été effectuée.

Un design accessible est aussi un design plus clair et plus honnête, ce qui peut paradoxalement améliorer la confiance et, potentiellement, les taux de consentement. Un bandeau qui respecte les critères de contraste, qui utilise un langage simple et dont les boutons sont clairement étiquetés et hiérarchisés est une marque de respect envers l’utilisateur.

En résumé, le bandeau cookies ne doit plus être vu comme une simple contrainte légale, mais comme le premier point de contact de l’expérience utilisateur. Le concevoir de manière accessible, c’est s’assurer que tous les citoyens, sans exception, peuvent exercer leur droit au contrôle de leurs données personnelles.

Pour passer de la théorie à la pratique, l’étape suivante consiste à évaluer la conformité d’un de vos parcours utilisateurs critiques, au-delà des scores automatiques, en simulant la navigation avec un lecteur d’écran ou uniquement au clavier.