Les Web Components et l'accessibilité

Les Web Components (composants web) représentent une avancée dans le développement web moderne, permettant la création de composants réutilisables et encapsulés. Cependant, l’utilisation du Shadow DOM introduit des complexités pour garantir l’accessibilité.

Depuis près de quatre ans, nous développons des Web Components et avons bénéficié de plusieurs audits. Nous partagerons nos retours d’expérience et les défis rencontrés pour les rendre accessibles.

L’objectif est de sensibiliser les développeurs et développeuses, et les auditrices et auditeurs, aux enjeux spécifiques du Shadow DOM et de promouvoir des pratiques de développement plus inclusives.

Nous examinerons comment certains outils d’audit actuels peuvent être adaptés pour mieux évaluer l’accessibilité des Web Components, souvent en raison de leur incapacité à pénétrer le Shadow DOM.

Nous discuterons également de l’application des critères de test du RGAA et des ajustements possibles pour mieux répondre aux besoins des nouvelles technologies. Nous avons d’ailleurs déposé un dossier de pré-inscription pour participer aux travaux d’évolution du RGAA, afin de contribuer activement à l’amélioration de ce standard.

Transcript

1. Les Web Components et l'accessibilité Paris Web 26 septembre 2025
2. Intro Qui sommes-nous ? Simon Duhem Architecte front-end Nicolas Jouanno Daniel Lead front-end Paris Web — Les Web Components et l'accessibilité 2
3. Intro Que faisons-nous ? Core UI Design System mg-components Paris Web — Les Web Components et l'accessibilité 3
4. Les Web Components
5. Les Web Components Qu'est-ce qu'un composant ? Un composant est une brique d'interface autonome. Regroupe structure, style et comportement. Il facilite la réutilisation et la maintenance du code. Paris Web — Les Web Components et l'accessibilité 5
6. Les Web Components Qu'est-ce que les Web Components ? Paris Web — Les Web Components et l'accessibilité 6
7. Les Web Components Historique des Web Components 2011 : Proposés par Google. 2014 : Spécifications officielles publiées. 2016 : Adoption progressive dans les navigateurs modernes. Aujourd'hui : Standard mature, en évolution constante. Paris Web — Les Web Components et l'accessibilité 7
8. Les Web Components Les clés des Web Components Un standard web natif pour créer des composants personnalisés et encapsulés. Indépendants des frameworks. Compatibles avec tous les navigateurs modernes. Trois technologies clés : Custom Elements Shadow DOM Templates HTML Paris Web — Les Web Components et l'accessibilité 8
9. <paris-web></paris-web> Permettent de créer ses propres balises HTML avec un comportement spécifique. Le nom doit contenir un tiret ( - ). S'utilisent comme n'importe quel élément du DOM. Doivent être enregistrés via customElements.define() . Les Web Components Custom Elements Paris Web — Les Web Components et l'accessibilité 9
10. <paris-web> #shadow-root <p>Contenu encapsulé</p> </paris-web> Permet d'encapsuler le style et le code d'un composant. Crée une frontière entre le contenu interne et le reste du document. Les styles définis à l'intérieur ne s'appliquent pas à l'extérieur, et ceux de l'extérieur n'affectent pas l'intérieur. Deux modes : open : accessible via .shadowRoot en JavaScript. closed : inaccessible depuis l'extérieur. Les Web Components Shadow DOM Paris Web — Les Web Components et l'accessibilité 10
11. <template id="paris-web-template"> <p>Hello Paris Web!</p> </template> Contient du HTML. N'est pas affiché. On l'insère dans le Shadow DOM via JavaScript. Les Web Components Templates Paris Web — Les Web Components et l'accessibilité 11
12. Les Web Components Exemple de composant <template id="paris-web-template"> <p>Hello Paris Web!</p> </template> <script> class ParisWeb extends HTMLElement { constructor() { super(); const template = document.getElementById('paris-web-template'); const content = template.content.cloneNode(true); const shadow = this.attachShadow({ mode: 'open' }); shadow.appendChild(content); } } customElements.define('paris-web', ParisWeb); </script> <paris-web></paris-web> Paris Web — Les Web Components et l'accessibilité 12
13. Lit Stencil import { Component, h } from '@stencil/core'; @Component({ tag: 'paris-web', shadow: true, }) export class ParisWeb { render(): HTMLElement { return <p>Hello Paris Web!</p>; } } Les Web Components Librairies Paris Web — Les Web Components et l'accessibilité 13
14. Les Web Components Pourquoi les Web Components ? Un standard du W3C qui reste stable dans le temps. Des composants réutilisables partout, peut importe le framework. Paris Web — Les Web Components et l'accessibilité 14
15. Shadow DOM & Accessibilité : quand l'encapsulation brise les liens ARIA
16. Shadow DOM & Accessibilité Le contexte : notre approche atomic design <label for="input">Nom</label> <input type="text" id="input" aria-describedby="aide erreur" /> <span id="aide">Format attendu</span> <span id="erreur">Champ requis</span> Les liens ARIA fonctionnent parfaitement Paris Web — Les Web Components et l'accessibilité 16
17. Shadow DOM & Accessibilité Mais quand on passe aux Web Components... <!-- Maintenant : chaque élément devient un composant --> <mg-label for="input">Nom</mg-label> <mg-input id="input" aria-describedby="aide erreur"></mg-input> <mg-help-text id="aide">Format attendu</mg-help-text> <mg-message id="erreur">Champ requis</mg-message> Logique parfaite... en théorie Paris Web — Les Web Components et l'accessibilité 17
18. Shadow DOM & Accessibilité Le problème révélé <p id="info">Remplissez le formulaire et cliquez sur le bouton pour envoyer le formulaire</p> <my-button aria-describedby="info">Envoyer</my-button> Paris Web — Les Web Components et l'accessibilité 18
19. Shadow DOM & Accessibilité VISUEL Le contenu est bien rendu visuellement Paris Web — Les Web Components et l'accessibilité 19
20. Shadow DOM & Accessibilité VoiceOver "Envoyer, bouton" Attendu : "Envoyer, Instructions importantes, bouton" Paris Web — Les Web Components et l'accessibilité 20
21. Shadow DOM & Accessibilité Le Shadow DOM isole chaque composant ! Paris Web — Les Web Components et l'accessibilité 21
22. Shadow DOM & Accessibilité Pourquoi ça ne marche plus ? <p id="info">Remplissez le formulaire et cliquez sur le bouton pour envoyer le formulaire</p> <my-button aria-describedby="info"> #shadow-root (open) <button><slot></slot></button> "Envoyer" </my-button> Le <p> porte l' id="info" L'attribut aria-describedby="info" est sur le host de <my-button> Le focus est sur l'élément <button> dans le Shadow DOM Paris Web — Les Web Components et l'accessibilité 22
23. Shadow DOM & Accessibilité Solution 1 : Encapsuler complètement la logique ARIA <my-button description="Remplissez le formulaire et cliquez sur le bouton pour envoyer le formulaire">Envoyer</my-button> <template id="mg-button-template"> <p id="info"></p> <button aria-describedby="info"> <slot></slot> <!-- Description interne, cachée visuellement mais lisible par screen readers --> </button> </template> <script> class MyButton extends HTMLElement { [...] connectedCallback() { // Remplit la description avec la prop/attribut "description" this.shadowRoot.querySelector("#info").textContent = this.getAttribute("description"); } } </script> Paris Web — Les Web Components et l'accessibilité 23
24. Shadow DOM & Accessibilité DOM <my-button description="Remplissez le formulaire et cliquez sur le bouton pour envoyer le formulaire"> #shadow-root (open) <p id="info">Remplissez le formulaire et cliquez sur le bouton pour envoyer le formulaire</p> <button aria-describedby="info"><slot></slot></button> "Envoyer" </my-button> Paris Web — Les Web Components et l'accessibilité 24
25. Shadow DOM & Accessibilité Résultat : Fonctionne parfaitement VoiceOver : Envoyer, Remplissez le formulaire et cliquez sur le bouton pour envoyer le formulaire, bouton Paris Web — Les Web Components et l'accessibilité 25
26. Shadow DOM & Accessibilité Solution 2 : Le host comme élément ARIA <p id="info">Remplissez le formulaire et cliquez sur le bouton pour envoyer le formulaire</p> <my-button aria-describedby="info">Envoyer</my-button> <template id="mg-button-template"> <slot></slot> </template> <script> class MyButton extends HTMLElement { [...] connectedCallback() { this.setAttribute('role', 'button'); // Le host devient le bouton this.setAttribute('tabindex', '0'); this.addEventListener('keydown', (e) => { // Gestion du clavier if (e.key === 'Enter' || e.key === ' ') { this.click(); } }); } } </script> Paris Web — Les Web Components et l'accessibilité 26
27. Shadow DOM & Accessibilité DOM <p id="info">Remplissez le formulaire et cliquez sur le bouton pour envoyer le formulaire</p> <my-button role="button" aria-describedby="info"> #shadow-root (open) "Envoyer" </my-button> Paris Web — Les Web Components et l'accessibilité 27
28. Shadow DOM & Accessibilité Résultat VoiceOver : Les attributs ARIA fonctionnent (restitution : "Envoyer, Remplissez le formulaire et cliquez sur le bouton pour envoyer le formulaire, bouton") Plus de travail pour recréer le comportement natif On perd aussi le rendu natif navigateur Paris Web — Les Web Components et l'accessibilité 28
29. Shadow DOM & Accessibilité A retenir Stratégie hybride selon le contexte : Composants simples : Privilégier les éléments natifs Logique complexe : Encapsuler dans le Shadow DOM Toujours : Tester avec les lecteurs d'écran Le Shadow DOM n'est pas l'ennemi de l'accessibilité... Il nous force juste à être plus rigoureux ! Paris Web — Les Web Components et l'accessibilité 29
30. Shadow DOM & Accessibilité Les Web Components améliorent l'accessibilité Centralisation de la logique: corriger une fois = corrigé partout Uniformiser le comportement des champs Protéger avec l’encapsulation : pas d’effets de bord Favoriser l’inclusion Paris Web — Les Web Components et l'accessibilité 30
31. Les audits
32. Les audits Quand le RGAA est clair <mg-button size="large">Non valide!</mg-button> <mg-input-select width="full" items="..."></mg-input-select> 10.1.2 Dans chaque page web, les attributs servant à la présentation de l’information ne doivent pas être présents dans le code source généré des pages. Cette règle est-elle respectée ? Paris Web — Les Web Components et l'accessibilité 32
33. Les audits Quand le RGAA est moins clair 7.5 Dans chaque page web, les messages de statut sont-ils correctement restitués par les technologies d'assistance ? Pour l'auditeur, le rôle devait être sur le <mg-alert> et non pas dans le Shadow DOM. Le cas de test du critère : Retrouver dans le document les messages qui valent pour message de statut. Pour chacun de ces messages, déterminer la nature de l'information dont est porteur le message : Si le message… Paris Web — Les Web Components et l'accessibilité 33
34. Les audits Les outils d'audit Ne prennent pas en compte le Shadow DOM Nu Html Checker Assistant RGAA Web Developer detectAutocomplete Prennent en compte le Shadow DOM : HeadingsMap WCAG Contrast checker Paris Web — Les Web Components et l'accessibilité 34
35. Les audits Essentiels mais à faire évoluer Utiles pour nos audits Indispensables pour gagner du temps Mais pas toujours adaptés à certains projets Ils doivent évoluer pour mieux prendre en compte les Web components Paris Web — Les Web Components et l'accessibilité 35
36. Conclusion
37. Conclusion Pourquoi ne pas adapter le RGAA aux Web Components ? Les Web Components sont un standard récent, qui doit coexister avec des spécifications historiques du RGAA. Nous avons déposé un dossier pour participer aux prochaines versions du RGAA, afin d'apporter notre expertise sur les Web Components. Paris Web — Les Web Components et l'accessibilité 37
38. Merci Des questions ? Paris Web — Les Web Components et l'accessibilité 38