Sécurité et accessibilité

Accessibilité et RGAA dans une application ASP.NET Core : obligations et mise en pratique

Sécurité et accessibilité · Par la rédaction de Postback Notes · Publié le 2026-11-10

En France, l'accessibilité numérique des services publics en ligne est une obligation légale depuis 2005, et son périmètre s'est élargi depuis. Pour une équipe .NET, cela se traduit par un référentiel concret, le RGAA, dont une bonne partie des critères se règle dans les gabarits Razor et les formulaires. Voici le cadre, puis les corrections les plus rentables.

Qui est concerné

L'article 47 de la loi n° 2005-102 du 11 février 2005 impose l'accessibilité des services de communication au public en ligne. Selon le rappel du champ d'application publié par la direction interministérielle du numérique, l'obligation vise les personnes morales de droit public, les organismes privés chargés d'une mission de service public ou financés et contrôlés majoritairement par des acteurs publics, et les entreprises dont le chiffre d'affaires annuel moyen réalisé en France dépasse 250 millions d'euros. Les applications métier internes des administrations, intranets et extranets compris, entrent dans le champ : ce n'est pas qu'une affaire de site vitrine.

S'y ajoute la directive européenne 2019/882, dite « acte européen sur l'accessibilité », applicable depuis le 28 juin 2025, qui étend des exigences d'accessibilité à certains produits et services du secteur privé, notamment le commerce électronique et les services bancaires aux consommateurs (texte sur EUR-Lex). Si votre application ASP.NET Core sert un tel service, vérifiez avec votre service juridique si elle est visée.

Le RGAA en quelques chiffres

Le référentiel général d'amélioration de l'accessibilité, dans sa version 4.1.2 actuellement en vigueur, compte 106 critères répartis en 13 thématiques (images, cadres, couleurs, multimédia, tableaux, liens, scripts, éléments obligatoires, structuration, présentation, formulaires, navigation, consultation). Il traduit en tests vérifiables la norme européenne EN 301 549, elle-même alignée sur les WCAG 2.1 aux niveaux A et AA. Les critères et tests sont consultables en ligne, avec un glossaire précis. Une version 5 du RGAA est en cours de rédaction, annoncée pour la fin de l'année 2026 ; le site officiel précise que cela ne justifie pas de suspendre les travaux en cours.

Concrètement, un organisme soumis doit publier une déclaration d'accessibilité indiquant le taux de conformité mesuré lors d'un audit, les contenus non accessibles et un moyen de contact, ainsi qu'un schéma pluriannuel de mise en accessibilité. La mention « Accessibilité : non conforme », « partiellement conforme » ou « totalement conforme » doit apparaître dès la page d'accueil, en pratique dans le pied de page.

Dans le gabarit : langue, titre, lien d'évitement

Trois critères se règlent une fois pour toutes dans _Layout.cshtml. La langue par défaut de la page (critère 8.3) : <html lang="fr">, et un attribut lang sur tout passage dans une autre langue. Un titre de page présent et pertinent (critères 8.5 et 8.6) : chaque page définit ViewData["Title"], idéalement sous la forme « Action ou contenu – Nom de l'application », et le titre reflète l'état du formulaire (« Erreur – Demande de congé »). Enfin, un lien d'évitement vers le contenu principal (critère 12.7), premier élément focalisable de la page :

<body>
  <a class="evitement" href="#contenu">Aller au contenu</a>
  <header>…menu…</header>
  <main id="contenu" tabindex="-1">
    @RenderBody()
  </main>
</body>

Ce lien peut être masqué visuellement tant qu'il n'a pas le focus, mais il doit apparaître à la tabulation.

Formulaires : étiquettes, aides et erreurs reliées

La thématique « Formulaires » concentre une grande partie des non-conformités relevées en audit. Les Tag Helpers d'ASP.NET Core font une partie du travail : <label asp-for="Email"> génère un attribut for qui correspond à l'id produit par <input asp-for="Email">, ce qui satisfait l'exigence d'étiquette associée (critère 11.1). Le reste est à écrire (Tag Helpers dans les formulaires) :

<div class="champ">
  <label asp-for="Email">Adresse électronique (obligatoire)</label>
  <p id="email-aide" class="aide">Format attendu : nom@domaine.fr</p>
  <input asp-for="Email" autocomplete="email"
         aria-describedby="email-aide email-erreur"
         aria-invalid="@(ModelState["Email"]?.Errors.Count > 0 ? "true" : "false")" />
  <span asp-validation-for="Email" id="email-erreur"></span>
</div>

Attention aux messages de validation par défaut d'ASP.NET Core : sans personnalisation, ils sont en anglais et citent le nom technique de la propriété. Définissez ErrorMessage en français, rédigé pour l'utilisateur (« Indiquez une date au format jj/mm/aaaa »).

Tableaux de données

Les écrans de gestion regorgent de tableaux, héritiers des GridView. Un tableau de données doit avoir des cellules d'en-tête <th> correctement associées (attribut scope pour les cas simples) et un titre, de préférence par <caption>. À l'inverse, n'utilisez jamais un tableau pour la mise en page. Les boutons d'action répétés sur chaque ligne (« Modifier », « Supprimer ») doivent avoir un intitulé explicite hors contexte : ajoutez le nom de l'élément dans un texte masqué visuellement ou un aria-label qui reprend l'intitulé visible.

Contenus mis à jour sans rechargement

Quand une partie de la page change sans rechargement (message « Enregistré », compteur de résultats d'un filtre, chargement d'une liste), un utilisateur de lecteur d'écran n'en sait rien. Le RGAA demande que ces messages de statut soient restitués (critère 7.5) : placez-les dans une zone role="status" présente dès le chargement de la page, et changez son contenu. En Blazor, le composant FocusOnNavigate du modèle de projet déplace le focus sur le titre principal à chaque changement de page, ce qui reproduit le comportement d'une navigation classique (routage Blazor).

Couleurs et focus

Le texte doit présenter un contraste d'au moins 4,5:1 avec son arrière-plan, 3:1 pour les grands textes (critère 3.2), et l'information ne doit pas être donnée par la seule couleur : une ligne en rouge dans un tableau a besoin d'un libellé « En retard ». Ne supprimez jamais le contour de focus avec outline: none sans proposer un indicateur visible équivalent (critère 10.7) : c'est la seule façon, pour qui navigue au clavier, de savoir où il se trouve.

Vérifier

Les outils automatiques repèrent une partie seulement des problèmes : une alternative d'image présente mais absurde, ou un ordre de tabulation incohérent, leur échappent. Une routine réaliste pour une équipe de développement : parcourir chaque nouvel écran au clavier seul, l'écouter avec le lecteur d'écran libre et gratuit NVDA, puis faire auditer l'application selon la méthode du RGAA avant de publier la déclaration. Le site design.numerique.gouv.fr propose des ressources et des formations gratuites pour monter en compétence.

Références