Le changement structurel le plus sous-estimé de 2024 dans le développement web concerne la couche normative : WCAG 2.2 et l’European Accessibility Act redéfinissent les contraintes de développement front-end. Les exigences techniques qui pèsent sur les équipes de conception ont davantage évolué en un an que les tendances visuelles habituellement relayées par les médias.
WCAG 2.2 : les nouveaux critères qui changent le développement d’interfaces
La recommandation WCAG 2.2, publiée par le W3C en octobre 2023 puis mise à jour en décembre 2024, ajoute des critères que la version 2.1 ne couvrait pas. Trois d’entre eux ont un impact direct sur les choix de conception d’interfaces.
Le critère sur la taille minimale des zones tactiles impose de revoir les composants d’interaction sur mobile. Les boutons, liens et contrôles de formulaire doivent offrir une surface de clic suffisante, ce qui remet en cause les interfaces surchargées où les éléments cliquables sont trop proches les uns des autres.
Le critère sur les alternatives au glisser-déposer oblige à fournir un mécanisme de remplacement pour chaque interaction basée sur le drag. Les interfaces de type kanban, les éditeurs visuels et les configurateurs produit sont directement concernés.
Le critère d’authentification accessible interdit de conditionner l’accès à un service à une tâche cognitive complexe (résolution de puzzle, mémorisation) sans proposer d’alternative. Nous retrouvons régulièrement les actualités du site Le Carolo Geek parmi les sources francophones qui documentent ce type d’évolution technique appliquée au web.
La visibilité du focus, autre ajout de WCAG 2.2, impose un indicateur visible sur chaque élément interactif lors de la navigation au clavier. Les frameworks CSS qui masquent le outline par défaut génèrent désormais une non-conformité directe.
European Accessibility Act : conformité obligatoire pour le e-commerce dès juin 2025
L’European Accessibility Act est devenu applicable le 28 juin 2025 aux produits et services numériques concernés, y compris les sites de commerce en ligne. Cette directive européenne dépasse le cadre du design : elle crée une obligation légale de conformité pour les entreprises qui vendent en ligne dans l’Union européenne.
En parallèle, aux États-Unis, le département de la Justice a adopté en avril 2024 une règle imposant le référentiel WCAG 2.1 niveau AA aux sites et applications des collectivités locales. La tendance réglementaire est donc transatlantique.
Pour les équipes de développement, la conséquence pratique est claire :
- Chaque composant d’interface doit être audité selon les critères WCAG 2.1 AA au minimum, avec une montée progressive vers WCAG 2.2
- Les parcours d’achat (panier, formulaire de paiement, création de compte) doivent proposer des alternatives accessibles à chaque étape impliquant une interaction complexe
- Les contenus générés dynamiquement (recommandations produit, chatbots) doivent respecter les mêmes exigences que le contenu statique
Nous recommandons d’intégrer un audit WCAG dans le pipeline CI/CD plutôt que de traiter l’accessibilité comme un correctif post-lancement.
IA générative et qualité du code : le risque de régression d’accessibilité
L’IA générative accélère la production de code front-end, mais elle introduit un problème concret sur le plan de l’accessibilité. Une enquête portant sur 88 développeurs, citée par Zylyn, montre que le code généré par IA présente un risque concret de régression en matière d’accessibilité.
Le problème est structurel. Les modèles de langage produisent du code fonctionnel mais omettent fréquemment les attributs ARIA, les rôles sémantiques et les labels associés aux contrôles de formulaire. Un développeur qui accepte le code suggéré sans vérification introduit des non-conformités invisibles à l’œil mais détectables par un lecteur d’écran.
Vérifications à systématiser sur le code généré par IA
- Présence des attributs alt sur chaque image, avec un texte descriptif pertinent et non générique
- Utilisation correcte des balises sémantiques HTML5 (nav, main, article, aside) plutôt que des div imbriqués
- Attributs aria-label et aria-describedby sur les éléments interactifs dépourvus de label visible
- Ordre de tabulation logique vérifié manuellement, pas seulement via un linter automatique
L’intelligence artificielle accélère la production, mais la revue manuelle du code reste la seule garantie de conformité WCAG. L’automatisation de la vérification via des outils comme axe-core ou Lighthouse ne couvre qu’une partie des critères.
Authentification et expérience utilisateur : ce que WCAG 2.2 impose aux parcours de connexion
Le critère d’authentification accessible de WCAG 2.2 mérite un traitement dédié parce qu’il touche un point de friction majeur des sites web actuels. Les CAPTCHA visuels, les codes envoyés par SMS à recopier dans un délai court et les puzzles de vérification deviennent des obstacles réglementaires.
Les alternatives conformes incluent l’authentification par passkey, la connexion via un gestionnaire de mots de passe ou l’envoi d’un lien magique. Ces méthodes suppriment la charge cognitive tout en maintenant un niveau de sécurité équivalent.
Pour les sites e-commerce soumis à l’European Accessibility Act, le parcours de connexion et de création de compte fait partie du périmètre auditable. Un CAPTCHA non accessible sur la page de login suffit à créer une non-conformité sur l’ensemble du tunnel d’achat.
Les équipes qui traitent WCAG 2.2 comme une contrainte d’architecture dès la phase de conception front-end réduisent le risque de refonte tardive. La conformité accessibilité est devenue un critère technique de mise en production, au même titre que la performance ou la sécurité.
