Accessibilité frontend en entreprise : mettez-la dans le design system

Cinquante équipes construisent cinquante écrans, et chacune y met sa propre boîte de dialogue, sa propre liste déroulante et sa propre façon d'afficher une erreur. Puis un audit arrive, et le même bug clavier doit être corrigé cinquante fois. Dans une app d'entreprise, l'accessibilité se gagne ou se perd dans les composants partagés, bien avant l'audit.

En Europe, elle n'est plus facultative non plus. L'Acte européen sur l'accessibilité (avec une exception pour les microentreprises) s'applique aux services bancaires aux consommateurs et aux services de commerce électronique fournis aux consommateurs après le 28 juin 2025. Pour les services bancaires aux consommateurs, l'annexe I demande que les méthodes d'identification, les signatures électroniques, la sécurité et les services de paiement soient « perceptibles, utilisables, compréhensibles et robustes ».

Les quelques concepts qui comptent

WCAG 2.2 AA comme objectif. MDN présente WCAG 2.2 comme « la version la plus récente des règles ». Le niveau AA est un bon objectif d'équipe parce qu'il est assez concret pour être testé. Pour les formulaires bancaires, un critère compte plus que la plupart des autres : le 3.3.4 (AA) demande que l'envoi de données financières « puisse être annulé, vérifié ou confirmé », par exemple avec une étape où l'utilisateur relit et corrige avant que l'envoi ne soit définitif. Une étape de confirmation de virement, c'est de l'accessibilité, pas seulement une bonne UX.

D'abord le HTML natif, ensuite . Le guide d' dit que les éléments natifs « intègrent plusieurs modèles d'interaction standard » et qu'il « faut réutiliser directement ces éléments natifs quand c'est possible ». Quand vous avez besoin d'un widget que le HTML n'a pas, MDN le dit clairement : avec ARIA, « c'est à vous d'imiter en script le comportement équivalent du navigateur ». Un rôle est une promesse que vous devez tenir dans le code.

Clavier et focus. Pour une boîte de dialogue modale : le focus entre dedans à l'ouverture, Tab reste à l'intérieur, Échap la ferme, et à la fermeture le focus « doit revenir là où il était avant d'entrer dans la boîte de dialogue ». Dans une , c'est le changement de route que l'on oublie : le guide d'Angular conseille de mettre à jour le focus sur NavigationEnd et d'éviter que le focus retombe sur body.

Formulaires et erreurs. C'est dans les longs formulaires réglementés que les utilisateurs abandonnent. La checklist WCAG de WebAIM le dit simplement : une erreur de saisie « est clairement identifiée », et un message d'état important « doit être annoncé aux utilisateurs de lecteurs d'écran » même quand le focus n'est pas dessus. En pratique : un vrai <label> par champ, des erreurs avec role="alert", et sur les longs formulaires un récapitulatif avec un lien vers chaque champ.

Le porte le tout. Un seul sélecteur de date accessible vaut mieux que cinquante corrections. La bibliothèque partagée est l'endroit où les , le contraste et le comportement au clavier se décident une seule fois. Le d'Angular fournit les briques (cdkTrapFocus, LiveAnnouncer), et le guide renvoie désormais vers pour les modèles headless comme le , le menu et les onglets. Côté React, ce travail revient à votre bibliothèque de composants ; choisissez-la pour sa prise en charge du clavier.

Corrigez-le une fois dans le composant, ou corrigez-le dans chaque écran, pour toujours.

Tester : des outils et des personnes. Les contrôles automatiques en CI attrapent les erreurs faciles sur chaque . MDN est clair sur leur limite : « Vous ne pouvez pas compter sur les seuls outils automatiques pour repérer les problèmes d'accessibilité de votre site. » Un passage au clavier et au sur les parcours principaux trouve le reste.

Quand choisir quoi

Construire ou acheter les widgets difficiles : achetez ou adoptez (CDK, Angular Aria, une bibliothèque React mature) pour le combobox, le sélecteur de date et la grille de données ; ne construisez que ce qui est propre à votre métier.
role="alert" ou un service de : role="alert" pour une erreur à côté d'un champ ; LiveAnnouncer pour quelque chose qui s'est passé ailleurs (« Virement envoyé »).
Automatique ou manuel : les deux, toujours. L'automatique sur chaque pull request, le manuel sur les parcours qui intéressent la loi : connexion, paiement, signature.

Sur Atlas Bank

Le fichier de règles d'Atlas Bank contient cette ligne : « Un changement de style ne change jamais le parcours. Les libellés, les noms des boutons et les messages role=alert sont ce que lisent les tests d'URL ; gardez-les, et les tests passent sans changement. » L'accessibilité et les tests partagent le même contrat.

Les de apps/atlas/src/styles/tokens incluent un rôle --color-focus, avec une valeur claire et une valeur sombre, et apps/atlas/src/styles/base/_document.scss met un focus ring par défaut sur chaque :focus-visible. npm run check:tokens échoue quand un composant hors du coin utilise une couleur brute au lieu d'un token.

Atlas montre aussi le manque. Sur la branche main, l'écran gelé de libs/legacy/transfers/src/lib/transfer.component.html affiche son erreur dans un simple <div class="alert alert-danger">, sans role. Le formulaire des bénéficiaires et le nouvel écran de virement du module 5 utilisent tous les deux role="alert". Les vieux recoins cachent de vieilles dettes.

Atlas vérifie déjà l'accessibilité de ses templates en CI (les règles d'accessibilité d' ; le coin legacy désactive label-has-associated-control). Ce qui lui manque encore : un contrôle sur la page rendue, comme axe dans les tests , et un contrôle du contraste des tokens. Ce seraient deux petits ajouts ; aujourd'hui, check:tokens vérifie où vivent les couleurs, pas si elles contrastent.

Ce que j'ai laissé de côté, et pourquoi

, , contraste des couleurs comme points séparés : ils font partie de « d'abord le HTML natif » et de « le design system porte le tout ».
Les overlays d'accessibilité. Une ligne : un script d'overlay ne corrige pas les composants en dessous, ce n'est donc pas un raccourci.

Dès lundi

Ouvrez la boîte de dialogue de votre design system et faites les quatre étapes clavier décrites plus haut. Puis faites la même chose avec votre écran le plus ancien.
Cherchez les messages d'erreur de formulaire sans role="alert" ni live region.
Si vous travaillez pour une banque ou une boutique dans l'UE, demandez qui est responsable des informations d'accessibilité que le service doit fournir. Si personne ne l'est, c'est la première décision.

Pour votre agent de code

Les règles de cet article, écrites pour un agent. Collez-les dans votre AGENTS.md, enregistrez-les comme , ou indiquez le fichier à votre agent.

Pour votre agent de code Télécharger le .md

# Accessibility rules for enterprise apps

Source: https://tt-tech.io/blog/enterprise-frontend-accessibility-design-system
For Angular and React frontends. Add to AGENTS.md or save as a skill. Your project's own rules win where they differ.

## Rules

1. Target WCAG 2.2 level AA.
2. Use native HTML elements first (`<label>`, `<dialog>`, native form controls). Use ARIA only for a widget HTML does not have.
3. When you add an ARIA role, implement in script the keyboard and behaviour the browser would give the native element. A role is a promise you keep in code.
4. Every modal dialog: focus moves inside on open, Tab stays inside (`cdkTrapFocus` in Angular), Escape closes, and on close focus returns to where it was before.
5. On a route change in a single-page app, move focus (in Angular, on `NavigationEnd`). Never let focus fall back to `body`.
6. In forms, give every field a real `<label>`, show field errors with `role="alert"`, and on long forms add an error summary that links to each field.
7. Announce something that happened elsewhere on the page ("Transfer sent") through a live region, `LiveAnnouncer` in Angular.
8. Submissions of financial data need a step where the user reviews and corrects before the submission is final (WCAG 3.3.4).
9. Fix accessibility in the shared design-system component, not in each screen. Focus rings, contrast and keyboard behaviour are decided there once.
10. For combobox, date picker and data grid, adopt a tested building block (Angular CDK, Angular Aria, or a mature React library chosen for its keyboard support). Build only what is specific to the domain.
11. Never add an accessibility overlay script as a fix. It does not fix the components underneath.
12. Run automated accessibility checks in CI, and never report a flow as accessible from automated checks alone. Login, payment and signature also need a manual keyboard and screen reader pass.

## Before you say done

- Run the project's accessibility lint (for example angular-eslint's template accessibility rules) and fix every new error.
- Search the diff for form error messages without `role="alert"` or a live region, and for `role=` attributes. For each role, name the code that implements its keyboard behaviour.
- For every new or changed dialog, list in the pull request where the code handles focus in, Tab, Escape and focus return.
- List the manual keyboard and screen reader checks still needed.

Sources

EUR-Lex, Directive (EU) 2019/882 on the accessibility requirements for products and services, 2019
MDN, Understanding the Web Content Accessibility Guidelines (WCAG)
WebAIM, WebAIM's WCAG 2 Checklist
Angular, Accessibility in Angular
MDN, ARIA
MDN, ARIA: dialog role
MDN, <dialog> HTML dialog element
MDN, Accessibility tooling and assistive technology