Retour au Blog
Angular Development4 novembre 20268 min de lecture

L'accessibilité a maintenant des échéances légales. Ce que les développeurs changent vraiment

DR

Doug Ribeiro

8 min de lecture

Quand j'ai activé l'ensemble complet des règles d'accessibilité de templates d'Angular sur les templates de MailHive, la première exécution a signalé 140 violations dans un produit qui fonctionnait et avait des tests. C'est normal : les violations s'accumulent partout où rien n'échoue quand on en ajoute une. Je les ai mises en baseline et je les résorbe depuis, jusqu'à 24 aujourd'hui. Pour un nombre croissant d'équipes, ce genre d'arriéré est maintenant une exposition juridique en plus d'un problème de qualité.

J'ai écrit séparément sur le minimum WCAG du point de vue du designer. Cet article, c'est le côté développeur : ce que les règles couvrent vraiment, et ce qui change dans votre dépôt dès lundi. Je suis développeur et pas avocat, alors servez-vous de ceci pour savoir quoi demander, et obtenez un vrai avis juridique pour votre propre entreprise.

Qui est vraiment concerné

Les gros titres donnent l'impression que tous les sites web sont maintenant illégaux. C'est plus restreint que ça, et ça dépend d'où vous vendez et de qui vous êtes.

  • Union européenne : l'European Accessibility Act (Acte européen sur l'accessibilité) s'applique depuis le 28 juin 2025. Pour le web, il couvre des services comme le commerce électronique et les services bancaires aux consommateurs. Les fournisseurs de services qui sont des microentreprises, c'est-à-dire moins de 10 personnes et au plus 2 millions d'euros de chiffre d'affaires ou de total du bilan, sont exemptés. Le texte s'articule autour des services fournis aux consommateurs, pas du lieu où se trouve l'entreprise, donc si vous vendez ces services à des consommateurs de l'UE depuis l'extérieur de l'UE, partez du principe que vous êtes concerné.
  • Canada : les modifications de 2025 sur l'accessibilité numérique apportées aux Accessible Canada Regulations (Règlement canadien sur l'accessibilité, SOR/2025-255) s'appliquent au secteur public fédéral et aux entreprises privées sous réglementation fédérale, comme les banques, qui comptent 100 employés ou plus. Les télécoms, les radiodiffuseurs et la plupart des transporteurs sont en grande partie exclus pour ce qui est du volet destiné au public. Les pages web du secteur public fédéral sont attendues pour le 5 décembre 2027, et celles des grandes et moyennes entreprises pour le 5 décembre 2028. L'obligation envers le public couvre les pages créées ou mises à jour à partir de ces dates, dans la mesure du possible. Les entreprises de 99 employés ou moins ne sont pas visées. Les provinces ont leurs propres lois, comme l'AODA en Ontario.
  • États-Unis : la règle du Titre II de l'ADA couvre les gouvernements des États et les administrations locales. Une interim final rule d'avril 2026 a reporté les échéances à avril 2027 pour ceux qui desservent 50 000 personnes ou plus, et à avril 2028 pour les plus petits. Les entreprises privées sont une autre affaire, largement tranchée par les litiges fondés sur l'ADA et non par une règle comme celle-ci.

La cible technique est proche dans les trois cas. La règle américaine nomme WCAG 2.1 AA. La norme canadienne et la norme de soutien de l'UE reposent sur EN 301 549. L'édition retenue par le Canada intègre actuellement WCAG 2.1 AA, et elle est référencée avec ses modifications successives, donc elle suit les éditions plus récentes. Deque rapporte que la v4.1.1, avec WCAG 2.2 AA, a été publiée en septembre 2026. Alors construisez selon WCAG 2.2 AA. Ça couvre les critères 2.1, mais EN 301 549 ajoute ses propres exigences, alors vérifiez-les aussi si ces règles s'appliquent à vous.

La plupart des erreurs sont banales, et c'est une bonne nouvelle

Le WebAIM Million 2026 a trouvé des échecs WCAG détectables sur 95,9 % du million de pages d'accueil les plus visitées, avec une moyenne de 56,1 erreurs par page. La partie utile : 96 % de toutes les erreurs détectées tombent dans six catégories.

  • Texte à faible contraste : 83,9 % des pages d'accueil.
  • Texte alternatif d'image manquant : 53,1 %.
  • Libellés de champs de formulaire manquants : 51 %.
  • Liens vides : 46,3 %.
  • Boutons vides : 30,6 %.
  • Langue du document manquante : 13,5 %.

Les valeurs par défaut des composants, les design tokens et les règles de lint peuvent prévenir la plupart de ces erreurs. C'est donc un endroit où un petit effort de développement fait bouger de vrais chiffres. Et il y a un autre chiffre à connaître : les pages avec ARIA avaient en moyenne 59,1 erreurs, contre 42 pour les pages sans. C'est une corrélation, puisque les pages complexes utilisent plus d'ARIA. Sortir ARIA en premier ajoute des façons de se tromper. Utilisez un vrai bouton.

Étape 1 : faire échouer les nouvelles violations dès aujourd'hui

Les règles statiques sont gratuites, rapides, et attrapent les problèmes avant même que le navigateur s'ouvre. Pour Angular, angular-eslint fournit une config d'accessibilité pour les templates. Pour React, l'équivalent est eslint-plugin-jsx-a11y.

javascript 
// eslint.config.js, inside tseslint.config(...), simplified
{
  files: ['**/*.html'],
  extends: [
    ...angular.configs.templateRecommended,
    ...angular.configs.templateAccessibility,
  ],
}

Sur une application existante, attendez-vous à un chiffre de cet ordre. N'en faites pas un projet de nettoyage, parce que ce projet perdra contre la prochaine fonctionnalité. Enregistrez les violations existantes avec les bulk suppressions d'ESLint, afin que seules les nouvelles fassent échouer le build. Les templates tiers copiés dans le dépôt, qui ne vous appartiennent pas, demandent aussi une décision : les exempter garde le build au vert, mais ils peuvent quand même bloquer un utilisateur, alors suivez-les. La baseline arrête l'hémorragie. Elle ne corrige rien : chaque entrée supprimée est un élément connu à résorber, pas un élément accepté. Résorbez-la, en commençant par les composants partagés, puis les parcours que les gens ne peuvent pas éviter, comme la connexion et le paiement. C'est comme ça que MailHive est passé de 140 à 24.

Étape 2 : tester la page rendue

Le lint voit les templates, pas le résultat. Le contraste dépend des styles calculés, et l'ordre des titres n'apparaît qu'à l'exécution. Axe trouve les deux, même si l'ordre des titres est une règle de bonnes pratiques, donc ajoutez le tag best-practice si vous la voulez. Il se branche sur la suite end-to-end que vous avez probablement déjà, et il est open source et gratuit.

typescript 
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('checkout has no detectable WCAG A or AA violations', async ({ page }) => {
  await page.goto('/checkout');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

Commencez par vos trois parcours les plus importants, et testez chacun dans ses états importants, par exemple avec les messages d'erreur affichés. Axe ne voit que ce qui est à l'écran au moment où il s'exécute.

Étape 3 : accepter ce qu'aucun outil n'attrapera

La propre étude de Deque, portant sur plus de 2 000 audits, a trouvé que les tests automatisés couvraient environ 57 % des problèmes en volume. C'est le chiffre d'un fournisseur, et un chiffre flatteur pour lui, alors prenez-le comme le haut de la fourchette. Même ainsi, quelque chose comme quatre problèmes sur dix ont besoin d'une personne. Un outil peut vous dire qu'une image a un texte alternatif. Il ne peut pas vous dire que ce texte n'a aucun sens. Il peut vous dire qu'un bouton a un nom, pas que le focus est allé à un endroit logique après un clic.

Dans une single-page app, les échecs manuels se regroupent aux mêmes endroits. Vérifiez-les à la main, au clavier seulement, avant qu'une fonctionnalité soit déclarée terminée :

  • Changement de route : le focus se déplace vers le nouveau contenu et le titre de la page change. Dans une SPA, le focus ne se déplace pas tout seul, et Angular ne met à jour le titre que si vous en définissez un sur la route. Un utilisateur de lecteur d'écran peut ne recevoir aucun signal que quelque chose s'est passé.
  • Dialogues : le focus entre, reste dedans, et revient au déclencheur à la fermeture. Le module a11y d'Angular CDK et l'élément dialog natif avec showModal règlent tous les deux l'essentiel. N'écrivez pas le vôtre, sauf s'ils ne couvrent pas votre cas.
  • Erreurs de formulaire : l'erreur est liée à son champ avec aria-describedby et elle est annoncée après la soumission. Une bordure rouge n'annonce rien.
  • Mises à jour dynamiques : un toast ou un compteur de résultats a besoin d'une live region. Avec Angular, LiveAnnouncer dans le CDK s'en charge.
  • Widgets personnalisés : toute div avec un gestionnaire de clic. Atteignez-la avec Tab, essayez de l'utiliser avec Entrée et Espace, et vérifiez que vous voyez où est le focus.

Les tests au lecteur d'écran sont la couche suivante. NVDA est gratuit sur Windows et VoiceOver est livré avec les Mac et les iPhone. Mon article sur WCAG couvre ces combinaisons, alors je ne les répéterai pas. Mettez d'abord le passage au clavier dans votre definition of done. Ça prend quelques minutes et ça trouve beaucoup de choses.

N'achetez pas votre conformité avec un overlay

Un script d'une ligne qui promet la conformité est une réponse tentante à une échéance légale. En avril 2025, la Federal Trade Commission américaine a finalisé une ordonnance obligeant accessiBe à payer 1 million de dollars pour avoir affirmé que son plugin pouvait rendre n'importe quel site web conforme aux WCAG. L'ordonnance interdit ce genre d'affirmations sans preuves. Un overlay s'exécute par-dessus le code qui a le problème. Corrigez le code.

Ce qui est aussi concerné, et que les développeurs oublient

  • Les PDF et les documents. Pour le secteur public fédéral et les entreprises de 500 employés ou plus, les règles canadiennes couvrent les documents téléchargeables, alors vérifiez votre générateur de factures.
  • Les déclarations d'accessibilité. Le Canada les exige chaque année du secteur public fédéral et des entreprises de 500 employés ou plus, et l'UE a ses propres obligations d'information pour les services. Découvrez qui en est responsable dans votre entreprise avant qu'on vous pose la question.
  • La formation et les registres. Les règles canadiennes exigent une formation pour les personnes qui travaillent sur les technologies numériques, et la conservation des registres pendant quatre ans. Ce n'est pas votre travail à vous seul, mais soulevez la question.
  • Les widgets tiers. Votre iframe de paiement, votre bulle de chat et votre bannière de consentement font partie de la page que votre utilisateur doit traverser.

Le premier sprint que je lancerais

  • Jour 1 : activez les règles de lint, mettez les violations existantes en baseline, et faites échouer les nouvelles.
  • Jour 2 : corrigez d'abord les composants partagés. Un seul composant de bouton ou de champ corrigé règle d'un coup tous ses usages.
  • Jour 3 : ajoutez axe à vos tests end-to-end pour vos trois parcours principaux.
  • Jour 4 : faites un passage au clavier seulement sur ces parcours, et consignez ce que vous trouvez comme des bugs, avec une sévérité.
  • Jour 5 : ajoutez le passage au clavier à votre definition of done, et demandez à votre entreprise laquelle de ces lois s'applique à elle.

Le lint et axe ne vous rendent pas conforme. Ils vous empêchent d'empirer. Le reste demande une personne.

Références

AccessibilityWCAGAngularReactTesting

Articles Connexes

UX/UI Design10 min de lecture

Accessibilité WCAG : le minimum que tout designer doit connaître

Un guide pratique de la conformité WCAG 2.2 AA couvrant le contraste de couleurs, la navigation clavier, les labels ARIA et les tests de lecteur d'écran, de la mise en place d'un design system chez Strongest Families à la livraison de fonctionnalités conformes en accessibilité chez BMO.

AI & Development7 min de lecture

Dette de vérification : l'IA a rendu l'écriture du code bon marché, pas la confiance

Un seuil de couverture peut avoir l'air strict et n'appliquer rien. L'IA augmente le volume de code, alors prouver que chaque vérification peut échouer compte plus qu'en ajouter de nouvelles.

Angular10 min de lecture

Applications bilingues au Canada : défis techniques et UX

Construire des applications bilingues EN/FR au Canada va bien au-delà de la traduction. Voici les patterns techniques et les décisions UX qui comptent vraiment quand on développe pour les deux langues officielles.