Liste de contrôle WCAG 2.2 AA pour les produits SaaS et les applications web

Un produit SaaS présente deux surfaces d’accessibilité : le site marketing qui le vend et l’application que les gens utilisent tous les jours. Le site marketing échoue de la même façon que n’importe quel site web, avec un contraste insuffisant, des textes alternatifs manquants et des formulaires sans étiquette. L’application ajoute ses propres problèmes : des parcours de connexion qui bloquent les gestionnaires de mots de passe, des boîtes de dialogue qui piègent le focus clavier, une navigation monopage que les lecteurs d’écran ne remarquent pas, des tableaux de données et des graphiques sans texte, du glisser-déposer sans alternative, et des sessions qui expirent sans avertissement. Cette liste de contrôle parcourt le niveau AA des WCAG 2.2 selon les parties d’un produit SaaS typique.

Points clés

• Les WCAG 2.2 sont devenues une recommandation du W3C en octobre 2023 et ont ajouté neuf critères de succès, dont six de niveau A ou AA (W3C (s’ouvre dans un nouvel onglet)).
• Selon le critère Authentification accessible (3.3.8, AA), une connexion ne peut pas dépendre de la mémorisation ou de la retranscription d’un mot de passe, sauf si l’on peut le coller ou utiliser un gestionnaire de mots de passe (W3C (s’ouvre dans un nouvel onglet)).
• Les cibles interactives doivent mesurer au moins 24 × 24 pixels CSS, ou disposer d’assez d’espace autour d’elles (2.5.8, AA) (W3C (s’ouvre dans un nouvel onglet)).
• Les messages comme « Enregistré » ou « 3 résultats » doivent parvenir aux lecteurs d’écran sans déplacer le focus (4.1.3, AA) (W3C (s’ouvre dans un nouvel onglet)).
• Les acheteurs des entreprises et du secteur public demandent souvent un rapport de conformité en matière d’accessibilité (Accessibility Conformance Report, ACR), généralement rédigé sur le modèle VPAT de l’Information Technology Industry Council (ITI (s’ouvre dans un nouvel onglet)).

Pourquoi l’accessibilité compte-t-elle davantage pour un SaaS que pour un site vitrine ?

Les gens utilisent un produit SaaS pendant des heures, souvent parce que leur employeur l’a choisi. Un obstacle sur une page marketing fait perdre un visiteur ; un obstacle dans le produit peut empêcher quelqu’un de faire son travail. C’est pourquoi les grands clients, les universités et les organismes publics interrogent de plus en plus souvent sur l’accessibilité avant d’acheter, et pourquoi la réponse doit couvrir l’application, pas seulement le site web.

C’est aussi important parce que les tests automatisés ne détectent qu’une partie du problème. Des outils comme axe-core trouvent les échecs dans le balisage, comme les étiquettes manquantes et le contraste insuffisant. Ils ne peuvent pas dire si une boîte de dialogue renvoie le focus au bon endroit, si les données d’un graphique sont disponibles sous forme de texte, ni si un parcours peut être mené à bien au clavier. Une application a besoin à la fois de vérifications automatisées et de tests manuels.

Comment rendre l’inscription et la connexion accessibles ?

C’est pour l’authentification que les WCAG 2.2 ont ajouté la nouvelle exigence la plus importante pour le SaaS.

• Autorisez le collage et les gestionnaires de mots de passe (3.3.8, AA). Ne bloquez pas le collage dans les champs de mot de passe ou de code, et utilisez autocomplete="username", autocomplete="current-password" et autocomplete="one-time-code" pour que les navigateurs et les gestionnaires de mots de passe puissent les remplir.
• Évitez les énigmes comme seul moyen d’accès. Un CAPTCHA qui demande de retranscrire un texte déformé ou de résoudre une énigme est un test de fonction cognitive. Proposez une alternative, et préférez des vérifications qui ne demandent aucune action de l’utilisateur (W3C (s’ouvre dans un nouvel onglet)).
• Étiquetez chaque champ (1.3.1 et 3.3.2, A). Utilisez un <label> visible relié à son champ ; le texte indicatif (placeholder) disparaît dès que l’on tape et n’est pas une étiquette.
• Signalez les erreurs par du texte (3.3.1, A) et suggérez des corrections (3.3.3, AA). « Le mot de passe doit comporter au moins 12 caractères » aide ; une bordure rouge seule n’aide pas.
• Ne demandez pas deux fois la même chose (3.3.7, A). Si une inscription en plusieurs étapes a déjà demandé le nom de l’entreprise ou une adresse, préremplissez-la ou permettez de la sélectionner au lieu de la ressaisir.
• Gardez l’aide au même endroit (3.2.6, A). Si vous proposez un chat, un lien d’aide ou des coordonnées de contact, placez-les à la même position relative sur chaque page du parcours.

Quels modèles de formulaires et d’erreurs causent le plus d’échecs ?

C’est dans les formulaires que se trouvent la plupart des échecs des applications. L’enquête 2026 de WebAIM portant sur un million de pages d’accueil a relevé des étiquettes de formulaire manquantes sur 51 % d’entre elles (WebAIM (s’ouvre dans un nouvel onglet)), et les applications comptent bien plus de formulaires que les pages d’accueil.

• Donnez à chaque champ un nom accessible par programmation, et regroupez les commandes liées, comme les boutons radio, avec <fieldset> et <legend>.
• Signalez les erreurs là où les gens les remarqueront : déplacez le focus vers un récapitulatif des erreurs en haut du formulaire, ou vers le premier champ non valide, et reliez chaque élément du récapitulatif à son champ.
• Indiquez les champs obligatoires par du texte, pas uniquement par la couleur (1.4.1, A).
• N’envoyez pas le formulaire et ne changez pas de contexte quand quelqu’un se contente de sélectionner une option (3.2.2, A) ; attendez une action explicite.

Comment les boîtes de dialogue, les menus et les fenêtres contextuelles doivent-ils se comporter ?

C’est dans les composants personnalisés que la prise en charge du clavier et des lecteurs d’écran se brise le plus souvent. Le guide des pratiques de création WAI-ARIA (ARIA Authoring Practices Guide) décrit le comportement attendu pour chaque modèle (W3C (s’ouvre dans un nouvel onglet)).

• Boîtes de dialogue : déplacez le focus dans la boîte de dialogue à son ouverture, gardez la touche Tab à l’intérieur tant qu’elle est ouverte, fermez-la avec Échap et renvoyez le focus à la commande qui l’a ouverte. Utilisez l’élément natif <dialog> ou role="dialog" avec aria-modal="true" et un nom.
• Aucun piège au clavier (2.1.2, A) : on doit pouvoir quitter chaque composant au clavier.
• Un focus visible (2.4.7, AA) qui n’est pas caché derrière des en-têtes fixes, des bandeaux cookies ou des widgets de chat (2.4.11, AA, nouveau dans la version 2.2).
• Info-bulles et fenêtres contextuelles (1.4.13, AA) que l’on peut fermer avec Échap, survoler sans qu’elles disparaissent, et qui restent affichées jusqu’à leur fermeture.
• Raccourcis à une seule touche (2.1.4, A) : si l’appui sur une touche de lettre déclenche une action, permettez de désactiver ou de redéfinir les raccourcis, ou ne les activez que lorsque le composant concerné a le focus.

Comment gérer la navigation dans une application monopage ?

Dans une application monopage (single-page app), l’URL change sans chargement de page : les lecteurs d’écran risquent donc de ne rien annoncer.

• Mettez à jour le titre du document à chaque changement de route, pour que chaque vue ait un titre descriptif (2.4.2, A).
• Déplacez le focus vers le titre principal de la nouvelle vue, ou annoncez le changement dans une région live polie ; des frameworks comme Next.js intègrent un annonceur de route à cet effet.
• Conservez un parcours du focus logique (2.4.3, A) : après la suppression d’un élément, le focus doit aller vers un voisin pertinent, et non revenir en haut de la page.
• Fournissez un moyen de contourner la navigation répétée (2.4.1, A), comme un lien d’évitement ou des régions (landmarks).

Comment rendre accessibles les tableaux de bord, les tableaux de données et les graphiques ?

• Tableaux : utilisez un vrai balisage <table> avec <th> et scope pour les en-têtes, ainsi qu’une légende (1.3.1, A). Les grilles construites avec des éléments <div> nécessitent le modèle de grille ARIA complet, bien plus difficile à réussir.
• Graphiques : donnez à chaque graphique une alternative textuelle qui énonce l’essentiel, et proposez les données sous forme de tableau (1.1.1, A). Ne comptez pas uniquement sur la couleur pour distinguer les séries (1.4.1, A) ; ajoutez des libellés ou des motifs.
• Contraste : le texte doit atteindre 4.5:1 (1.4.3, AA), et les lignes des graphiques, les icônes et les bordures des champs 3:1 par rapport à leur arrière-plan (1.4.11, AA). Vérifiez le mode sombre séparément. Notre vérificateur de contraste des couleurs teste n’importe quelle paire de couleurs.
• Messages d’état (4.1.3, AA) : « Enregistré », « Envoi terminé » et le nombre de résultats doivent utiliser role="status" ou une région live, pour que les lecteurs d’écran les entendent sans perdre leur position.

Que changent les nouveaux critères des WCAG 2.2 pour les applications web ?

Les WCAG 2.2 ont aussi supprimé le critère 4.1.1 Analyse syntaxique, qui n’a plus d’effet concret sur l’accessibilité (W3C (s’ouvre dans un nouvel onglet)).

Et les délais d’expiration, la mise en page et le zoom ?

• Expiration de session (2.2.1, A) : prévenez les gens avant l’expiration d’une session et permettez-leur de la prolonger par une action simple, sauf si la limite de temps est essentielle ou dépasse 20 heures. Enregistrer le travail en cours évite le pire.
• Redistribution (1.4.10, AA) : le contenu doit fonctionner sur une largeur de 320 pixels CSS (l’équivalent d’un zoom à 400 % sur un écran de 1280 pixels) sans défilement dans deux directions ; les tableaux de données et les contenus similaires sont exemptés.
• Espacement du texte (1.4.12, AA) : augmenter l’interligne et l’espacement des lettres ne doit pas tronquer le texte, ce que font souvent les conteneurs à hauteur fixe.
• Orientation (1.3.4, AA) : ne bloquez pas l’application en mode portrait ou paysage, sauf si c’est essentiel.

Qu’est-ce qu’un ACR, et en avez-vous besoin ?

Un rapport de conformité en matière d’accessibilité (Accessibility Conformance Report, ACR) documente la façon dont un produit satisfait chaque critère d’accessibilité : pris en charge, partiellement pris en charge ou non pris en charge, avec des remarques. La plupart sont rédigés sur le modèle VPAT publié par l’Information Technology Industry Council, qui existe en éditions pour les WCAG, les normes américaines de la Section 508 et la norme européenne EN 301 549 (ITI (s’ouvre dans un nouvel onglet)).

Les agences fédérales américaines doivent acheter des technologies accessibles en vertu de la Section 508 (Section508.gov (s’ouvre dans un nouvel onglet)), et les organismes publics de l’UE se réfèrent à la norme EN 301 549 : les produits B2B vendus à ces clients se voient donc souvent demander un ACR lors des appels d’offres. Un ACR honnête, qui liste les lacunes connues, est plus utile aux acheteurs qu’un ACR qui revendique une prise en charge complète. Il doit reposer sur des tests du produit, y compris des tests manuels ; une analyse automatisée ne suffit pas à le remplir.

Si vous vendez à des consommateurs de l’UE, l’Acte européen sur l’accessibilité peut aussi s’appliquer à votre façon de vendre en ligne ; notre guide sur l’EAA en explique le champ d’application. Ceci ne constitue pas un avis juridique.

Comment une équipe SaaS doit-elle tester l’accessibilité ?

1. Automatisez les bases. Exécutez axe-core ou un moteur similaire dans vos tests de bout en bout et sur le site marketing, et faites échouer les builds en cas de nouvelles violations. Notre test d’accessibilité gratuit exécute le même moteur sur n’importe quelle page publique.
2. Testez au clavier. Menez à bien vos principaux parcours, comme l’inscription, la création d’un enregistrement et la modification des paramètres, en utilisant uniquement Tab, Maj+Tab, Entrée, Espace, Échap et les touches fléchées.
3. Testez avec un lecteur d’écran. NVDA sur Windows et VoiceOver sur macOS et iOS sont gratuits. Vérifiez que les noms, les rôles, les états et les messages sont annoncés.
4. Zoomez et redimensionnez. Vérifiez un zoom du texte à 200 % et une fenêtre de 320 pixels de large.
5. Corrigez dans le design system. La plupart des échecs viennent de composants partagés ; corriger une fois un bouton ou une boîte de dialogue le corrige partout.

Foire aux questions

Les WCAG s’appliquent-elles aux parties d’une application web accessibles après connexion ?

Les WCAG s’appliquent à tout contenu web, y compris les pages protégées par une connexion. Qu’une loi impose à un produit donné de les respecter dépend de la juridiction et du client, mais les acheteurs qui posent des questions sur l’accessibilité parlent généralement du produit entier.

Une surcouche peut-elle rendre un produit SaaS accessible ?

Non. Les surcouches ne modifient pas le code sous-jacent des composants personnalisés, et c’est là que se trouvent les échecs des applications. Notre guide sur les surcouches d’accessibilité présente l’action de la FTC contre un grand éditeur de surcouches.

Quelle part des WCAG les outils automatisés peuvent-ils vérifier ?

Une partie seulement. Les règles automatisées détectent de façon fiable les noms et les étiquettes manquants et les échecs de contraste, mais de nombreux critères, comme un parcours du focus cohérent, un texte alternatif utile et des messages d’erreur compréhensibles, nécessitent le jugement d’une personne.

Quelle version des WCAG devons-nous viser ?

Le niveau AA des WCAG 2.2 correspond à la version actuelle. De nombreuses lois et règles d’achat public font encore référence aux WCAG 2.1 AA ; respecter les WCAG 2.2 AA revient aussi à respecter les WCAG 2.1 AA, à l’exception du critère Analyse syntaxique supprimé.

Devons-nous atteindre le niveau AAA ?

Le W3C ne recommande pas d’exiger le niveau AAA pour des produits entiers, car certains contenus ne peuvent pas satisfaire chaque critère AAA. Le niveau AA est l’objectif habituel.

Sources

• W3C : What's new in WCAG 2.2 (s’ouvre dans un nouvel onglet)
• W3C : Web Content Accessibility Guidelines (WCAG) 2.2 (s’ouvre dans un nouvel onglet)
• W3C : Understanding 3.3.8 Accessible Authentication (Minimum) (s’ouvre dans un nouvel onglet)
• W3C : Understanding 2.5.8 Target Size (Minimum) (s’ouvre dans un nouvel onglet)
• W3C : Understanding 4.1.3 Status Messages (s’ouvre dans un nouvel onglet)
• W3C : ARIA Authoring Practices Guide: Dialog (modal) pattern (s’ouvre dans un nouvel onglet)
• W3C : Inaccessibility of CAPTCHA (s’ouvre dans un nouvel onglet)
• ITI : Voluntary Product Accessibility Template (VPAT) (s’ouvre dans un nouvel onglet)
• GSA : Section508.gov (s’ouvre dans un nouvel onglet)
• WebAIM : The WebAIM Million (2026) (s’ouvre dans un nouvel onglet)