RGAA

RGAA : Référentiel français d’amélioration de l’accessibilité, qui décline les critères internationaux en tests concrets et vérifiables.

Entrée de la famille « Produit et UX » du glossaire. Elle s’adresse à un porteur de projet qui doit rédiger, comparer ou recetter, pas à un spécialiste du sujet.

Où intervient RGAA dans un projet

RGAA appartient au vocabulaire de la conception, celui des décisions prises avant la première ligne de code. Ce sont les moins chères à changer, et celles qui engagent le plus la suite.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

De la définition à la ligne de cahier des charges

Le cahier des charges doit fixer ce que recouvre « RGAA » en version 1 et ce qui attend la suite. Un périmètre non borné s’étend tout seul pendant la recette.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les rôles utilisateurs, et ce que chacun a le droit de faire.
• Les écrans concernés, listés, avec leur état vide et leur état d’erreur.
• Ce qui est explicitement hors périmètre de la version 1.
• Les contenus fournis par le client, et la date à laquelle ils arrivent.

Rien n’oblige à tout figer dès le premier jour. Ce qui reste ouvert doit alors être signalé comme tel, avec la date à laquelle la décision sera prise.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Comment le vérifier à la recette

À la recette, « RGAA » se juge sur le parcours complet, pas sur un écran isolé qui fonctionne en démonstration.

• Utiliser l’application sur un petit écran, d’une seule main.
• Parcourir l’écran principal au lecteur d’écran, au moins une fois.
• Comparer les maquettes validées au résultat livré, écran par écran.

Ces vérifications s’inscrivent au cahier de recette, avec un nom en face de chacune. Une case sans responsable reste vide.

Ce qui tourne mal le plus souvent

Ces erreurs ne viennent presque jamais d’un manque de compétence, mais d’un point qui n’a été écrit nulle part.

• Valider des maquettes sans avoir écrit les critères d’acceptation correspondants.
• Empiler les fonctionnalités en version 1 au lieu de sortir un périmètre défendable.
• Repousser l’accessibilité à plus tard, ce qui revient à refaire les écrans une seconde fois.
• Découper le projet en sprints sans jamais rien mettre entre les mains d’un utilisateur.
• Se contenter d’une réponse orale en réunion, jamais reprise dans le document contractuel.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Churn
• Wireframe
• User story
• Design system
• Rétention J7

Questions fréquentes

Que signifie « RGAA » ?

Référentiel français d’amélioration de l’accessibilité, qui décline les critères internationaux en tests concrets et vérifiables. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

Comment le vérifier à la recette ?

Avec un critère écrit avant le développement, formulé de façon à pouvoir être refusé. « L’écran doit être agréable » ne se recette pas. « La liste vide affiche tel message et tel bouton » se recette.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.