Accessibilite Svelte : guide RGAA complet

1. Introduction : les forces de Svelte pour l'accessibilité

Svelte occupe une position unique dans l'écosystème JavaScript en matière d'accessibilité. Contrairement à React, Vue ou Angular qui s'appuient sur un runtime et un DOM virtuel, Svelte compile vos composants en code JavaScript vanilla au moment du build. Cette approche a des conséquences directes et positives sur l'accessibilité.

La première force de Svelte est son système d'avertissements compile-time. Le compilateur analyse votre markup et détecte automatiquement des violations d'accessibilité courantes : images sans attribut alt, gestionnaires de clic sans équivalent clavier, éléments statiques avec des gestionnaires d'événements. Ces avertissements apparaissent directement dans votre terminal et votre éditeur, avant même que le code n'arrive en production.

La deuxième force est l'absence de DOM virtuel. Svelte manipule directement le DOM réel, ce qui signifie que les technologies d'assistance (lecteurs d'écran, plages braille) interagissent avec le même DOM que celui que Svelte génère. Il n'y a pas de couche d'abstraction supplémentaire qui pourrait créer des incohérences entre l'état visuel et l'arbre d'accessibilité.

La troisième force est la taille minimale du JavaScript généré. Svelte produit des bundles significativement plus petits que les autres frameworks, ce qui réduit le temps de chargement et le temps d'interaction (TTI). Pour les utilisateurs de technologies d'assistance, un TTI bas signifie que le contenu est utilisable plus rapidement, un critère important pour les personnes en situation de handicap cognitif.

Enfin, le système de réactivité déclarative de Svelte (via les runes $state, $derived et $effect en Svelte 5) facilite la mise à jour dynamique des attributs ARIA et des live regions, essentiels pour les applications interactives accessibles.

2. Erreurs courantes d'accessibilité en Svelte

Malgré les atouts de Svelte, de nombreux développeurs commettent des erreurs d'accessibilité récurrentes. Voici les plus fréquentes et leurs conséquences sur la conformité RGAA.

Ignorer les avertissements a11y du compilateur

C'est l'erreur la plus répandue. Le compilateur Svelte affiche des avertissements de type a11y-* mais ces avertissements ne bloquent pas la compilation. De nombreux développeurs les ignorent ou les désactivent avec des commentaires sans résoudre le problème sous-jacent. Chaque avertissement ignoré est une non-conformité potentielle au RGAA.

Blocs sans live regions

Les blocs conditionnels Svelte (, ) ajoutent et retirent des éléments du DOM. Quand un message d'erreur, une notification ou un résultat de recherche apparaît via un bloc , les lecteurs d'écran ne sont pas automatiquement informés du changement. Sans attribut aria-live sur un conteneur parent, le contenu dynamique reste invisible pour les utilisateurs de technologies d'assistance.

Transitions sans prefers-reduced-motion

Les directives transition:fade, transition:fly et transition:slide sont élégantes mais ne respectent pas automatiquement la préférence prefers-reduced-motion du système d'exploitation. Pour les personnes souffrant de troubles vestibulaires, des animations non désactivables peuvent provoquer des nausées ou des vertiges, en violation directe du critère RGAA 13.8.

bind:this sans gestion du focus

La directive bind:this permet d'obtenir une référence directe à un élément DOM, mais les développeurs oublient souvent d'utiliser tick() avant d'appeler .focus(). Comme Svelte regroupe les mises à jour DOM de manière asynchrone, appeler focus() immédiatement après un changement d'état peut échouer silencieusement car l'élément n'est pas encore dans le DOM. Cela résulte en une perte de focus qui désoriente les utilisateurs naviguant au clavier.

3. Avertissements a11y du compilateur Svelte

Le compilateur Svelte intègre plus d'une vingtaine de vérifications d'accessibilité. Voici les plus importantes et comment les corriger pour être conforme au RGAA.

a11y-click-events-have-key-events

Cet avertissement se déclenche quand un élément a un gestionnaire onclick mais pas de gestionnaire clavier équivalent. Les utilisateurs qui ne peuvent pas utiliser une souris doivent pouvoir déclencher la même action au clavier.

a11y-no-static-element-interactions

Cet avertissement apparaît quand un élément HTML statique (div, span, etc.) a des gestionnaires d'événements sans rôle ARIA. Un <div> avec un onclick n'a aucune sémantique pour les technologies d'assistance.

a11y-missing-attribute

Le compilateur détecte les attributs obligatoires manquants pour l'accessibilité, notamment alt sur les images et title sur les iframes.

Autres avertissements importants

• a11y-autofocus : déconseille l'attribut autofocus qui déplace le focus de manière inattendue
• a11y-no-noninteractive-tabindex : interdit tabindex sur les éléments non interactifs sans rôle
• a11y-role-has-required-aria-props : vérifie que les éléments avec un rôle ARIA ont les attributs requis
• a11y-hidden : signale les éléments interactifs cachés avec aria-hidden
• a11y-label-has-associated-control : vérifie que les labels sont associés à un champ de formulaire
• a11y-media-has-caption : exige des sous-titres sur les éléments vidéo

Pour voir la liste complète des avertissements, exécutez npx svelte-check dans votre projet. Intégrez cette commande dans votre pipeline CI pour empêcher les régressions d'accessibilité.

4. Live regions avec les déclarations réactives

Les live regions ARIA permettent aux lecteurs d'écran d'annoncer les changements de contenu sans que l'utilisateur ait à naviguer jusqu'à l'élément modifié. En Svelte, la réactivité native rend l'implémentation particulièrement élégante.

Le point clé est que le conteneur aria-live doit être présent dans le DOM avant que le contenu ne change. Ne placez jamais l'attribut aria-live à l'intérieur d'un bloc conditionnel.

Annonce de résultats de recherche

Notifications et messages d'erreur

Utilisez aria-live="assertive" pour les messages urgents (erreurs, alertes) et aria-live="polite" pour les mises à jour informatives (résultats, confirmations). Le rôle alert implique déjà aria-live="assertive" mais l'attribut explicite renforce la compatibilité avec tous les lecteurs d'écran.

5. Gestion du focus avec bind:this et tick()

La gestion du focus est essentielle pour les utilisateurs naviguant au clavier ou avec un lecteur d'écran. En Svelte, deux outils sont fondamentaux : bind:this pour obtenir une référence DOM et tick() pour attendre la mise à jour du DOM.

Ouvrir une modale et déplacer le focus

Focus après suppression d'un élément

La règle est simple : chaque fois que vous modifiez le DOM de manière significative (ouverture de modale, ajout ou suppression d'éléments, changement de vue), assurez-vous que le focus est déplacé vers un endroit logique. Sans cela, le focus peut être perdu ou revenir en haut de la page, ce qui désoriente complètement les utilisateurs de technologies d'assistance.

6. Transitions accessibles et prefers-reduced-motion

Les transitions Svelte (transition:fade, transition:fly, transition:slide) ne respectent pas automatiquement la préférence système prefers-reduced-motion. Vous devez le gérer vous-même pour être conforme au RGAA (critère 13.8).

Détecter la préférence utilisateur

Fonction utilitaire réutilisable

À noter : Svelte 5 ne fournit pas de store intégré pour prefers-reduced-motion. Utilisez window.matchMedia('(prefers-reduced-motion: reduce)') dans un $effect pour réactiver la valeur dans un $state, comme montré dans l'exemple ci-dessus.

7. Formulaires accessibles avec les bindings Svelte

Les bindings Svelte (bind:value, bind:checked, bind:group) facilitent la gestion de l'état des formulaires, mais ne dispensent pas de respecter les règles d'accessibilité HTML. Chaque champ doit avoir un label associé, des messages d'erreur liés et une validation accessible.

Formulaire complet accessible

Points essentiels pour la conformité RGAA des formulaires Svelte :

• Chaque champ doit avoir un <label> avec un for correspondant à l'id du champ (critère RGAA 11.1)
• Les champs obligatoires doivent être signalés avec aria-required="true"
• Les erreurs doivent être liées au champ via aria-describedby et aria-invalid
• L'attribut autocomplete doit être présent pour les champs de données personnelles
• Les messages d'erreur doivent avoir role="alert" pour être annoncés par les lecteurs d'écran

8. Routage SvelteKit et gestion du focus

SvelteKit utilise un routage client-side qui ne déclenche pas de rechargement complet de la page. Sans gestion explicite, le focus reste sur l'élément qui a déclenché la navigation (souvent un lien dans le menu), ce qui oblige les utilisateurs de lecteur d'écran à renaviguer à travers toute la page pour trouver le nouveau contenu.

afterNavigate pour le focus

Liens d'évitement

Annonce des changements de page

SvelteKit gère certains aspects de l'accessibilité du routage par défaut (comme le reset du focus sur le body), mais pour une conformité RGAA complète, il est recommandé de gérer explicitement le focus vers le contenu principal et d'annoncer les changements de page via une live region.

9. Actions Svelte pour l'accessibilité réutilisable

Les actions Svelte (use:directive) sont un mécanisme puissant pour encapsuler des comportements DOM réutilisables. Elles sont idéales pour les patterns d'accessibilité qui doivent être appliqués à plusieurs composants.

Action focus trap (piège de focus)

Action announce (annonces lecteur d'écran)

Utilisation des actions

Les actions Svelte offrent un avantage majeur : elles se nettoient automatiquement quand l'élément est retiré du DOM (via la méthode destroy). Cela évite les fuites de mémoire et les gestionnaires d'événements orphelins, un problème courant dans les autres frameworks.

10. Critères RGAA clés pour Svelte

Voici les critères RGAA les plus impactés par les spécificités de Svelte et SvelteKit. Pour chaque critère, nous indiquons le risque de non-conformité et les points de vigilance spécifiques au framework.

11. Outils recommandés

Voici les outils essentiels pour vérifier et maintenir l'accessibilité de vos applications Svelte.

12. Checklist accessibilité Svelte

Utilisez cette checklist pour vérifier l'accessibilité de vos composants et pages Svelte. Elle couvre les points spécifiques au framework en complément d'un audit RGAA complet.