L’accessibilité et la performance sont souvent traitées comme des disciplines distinctes, avec des spécialistes, des outils et des listes de contrôle différents. L’accessibilité consiste à rendre un site utilisable par les personnes en situation de handicap visuel, moteur, auditif ou cognitif ; la performance, à le rendre rapide et réactif. Pourtant, à y regarder de près, les deux disciplines poursuivent le même objectif : faire fonctionner le site pour tout le monde, et en particulier pour ceux qui l’utilisent dans des conditions différentes de celles pour lesquelles il a été conçu.
Un smartphone d’entrée de gamme, un réseau lent, un lecteur d’écran, une loupe, un bras dans le plâtre, un soleil qui rend l’écran illisible : autant de situations où un site lourd et instable devient difficile à utiliser, et où un site bien construit continue de fonctionner. Dans cet article, nous voyons où l’accessibilité et la performance se rejoignent, où un bon choix sert les deux, et où une optimisation de performance mal faite peut créer des obstacles.
Souvent les mêmes utilisateurs
Un premier point de contact, ce sont les personnes. Celles qui utilisent des technologies d’assistance n’ont pas toujours l’appareil le plus récent, et les lecteurs d’écran ajoutent une charge de travail propre : ils doivent reconstruire la structure de la page, suivre ses changements et les annoncer. Une page de milliers d’éléments et de beaucoup de JavaScript, déjà lente sur un smartphone de milieu de gamme, devient encore plus lente quand l’appareil doit aussi faire tourner un lecteur d’écran. De nombreuses personnes âgées, qui profitent d’une interface accessible, utilisent des appareils plus anciens et des connexions plus lentes.
Il y a ensuite le handicap situationnel, qui concerne tout le monde : utiliser son téléphone d’une seule main dans le tramway, lire en plein soleil, naviguer avec une connexion instable dans un train. Dans ces conditions, les pages lentes, les contenus qui bougent et les boutons qui ne répondent pas sont des obstacles pour tous. Concevoir pour les cas limites, dans les deux disciplines, améliore l’expérience de la majorité.
HTML sémantique : moins de code, plus d’accessibilité
Le point de rencontre le plus important est le HTML sémantique. Un bouton construit avec l’élément button est accessible au clavier, s’active avec Entrée et Espace, est annoncé correctement par les lecteurs d’écran, et n’a besoin d’aucune ligne de JavaScript pour tout cela. Le même bouton construit avec un div exige des attributs ARIA pour le rôle, un tabindex, des gestionnaires d’événements clavier et souris, et souvent une bibliothèque pour gérer le focus : plus de code à télécharger et à exécuter, et plus de risques d’erreur.
Il en va de même pour de nombreux composants courants. Un panneau repliable peut être construit avec details et summary, accessible et fonctionnel sans JavaScript ; une fenêtre modale avec l’élément dialog, qui gère le focus et la fermeture avec la touche Échap ; un menu déroulant de sélection avec select. Les bibliothèques de composants qui reconstruisent tout avec des éléments génériques et du JavaScript sont souvent à la fois plus lourdes et moins accessibles que les alternatives natives. Choisir les éléments du navigateur, quand ils existent, est le choix qui sert les deux disciplines.
<!-- Questions fréquentes : accessible et fonctionnel sans JavaScript -->
<details>
<summary>Quel est le délai de livraison ?</summary>
<p>Les commandes sont expédiées sous 24 heures ouvrées…</p>
</details>Une mise en page stable
Le CLS mesure les décalages inattendus du contenu, et c’est peut-être la métrique la plus directement liée à l’accessibilité. Pour une personne qui a un tremblement, qui utilise un système de pointage alternatif ou qui se déplace plus lentement, le temps entre la décision de toucher un élément et le toucher effectif est plus long, et un décalage dans cet intervalle conduit à toucher le mauvais élément. Pour qui utilise une loupe et ne voit qu’une petite portion de la page, un décalage fait perdre l’endroit où il en était de sa lecture. Pour les personnes ayant des difficultés cognitives ou d’attention, un contenu qui bouge est une source de confusion.
Les directives d’accessibilité demandent que l’interface soit prévisible et que les changements de contexte ne se produisent pas sans que l’utilisateur les ait demandés. Un CLS faible ne suffit pas à le garantir, car la métrique évalue l’ensemble des décalages et non le décalage isolé au mauvais moment, mais toutes les techniques pour le réduire, comme les dimensions explicites pour les images et les vidéos, l’espace réservé aux bandeaux et aux publicités, le contenu inséré en dessous plutôt qu’au-dessus de ce que l’utilisateur regarde, servent directement aussi l’accessibilité.
Réactivité et technologies d’assistance
L’INP mesure le temps de réponse aux interactions. Pour les personnes qui utilisent le clavier ou un lecteur d’écran, une interface qui répond lentement est encore plus problématique : sans retour visuel immédiat, ou avec un retour qui arrive après une demi-seconde, il est difficile de savoir si une commande a été reçue, et la tentation de la répéter produit des envois en double et des actions non voulues. Les tâches JavaScript longues qui ralentissent l’INP ralentissent aussi la mise à jour des informations que le navigateur fournit aux technologies d’assistance, qui risquent d’annoncer les changements en retard ou dans un ordre confus.
Les solutions sont les mêmes que celles vues à propos du thread principal : moins de JavaScript, un travail découpé en parties plus petites, un retour immédiat avant le traitement. À cela s’ajoute un aspect propre à l’accessibilité : le retour ne doit pas être seulement visuel. Une région aria-live qui annonce « Produit ajouté au panier » donne aux utilisateurs de lecteurs d’écran la même confirmation immédiate qu’une icône animée donne à ceux qui voient l’écran.
La réduction des animations
De nombreux systèmes d’exploitation permettent de demander des animations réduites, un réglage important pour les personnes souffrant de troubles vestibulaires, chez qui les grandes animations, les effets de parallaxe et le zoom peuvent provoquer nausées et vertiges. Le site peut la lire avec la media query prefers-reduced-motion et réduire ou supprimer les animations. C’est un choix d’accessibilité, mais il touche aussi la performance : moins d’animations, c’est moins de travail pour le navigateur, moins de scripts pour les gérer et, souvent, un contenu visible plus tôt.
@media ( prefers-reduced-motion: reduce ) {
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}Il en va de même pour les contenus qui bougent d’eux-mêmes : les carrousels qui défilent automatiquement et les vidéos d’arrière-plan qui démarrent à l’ouverture de la page. Les directives demandent qu’on puisse les mettre en pause ; du point de vue de la performance, ils comptent parmi les éléments les plus coûteux, comme nous l’avons vu dans l’article sur la vidéo et les Core Web Vitals. Renoncer à la lecture automatique, ou au moins respecter la préférence de réduction des animations en n’affichant qu’une image statique, sert les deux disciplines.
Le texte en tant que texte
Un texte inséré sous forme d’image, comme un titre dans une bannière, un tableau de prix exporté en graphique ou une infographie avec les chiffres clés, est un obstacle pour les personnes qui utilisent un lecteur d’écran, ne s’adapte pas à l’agrandissement du texte, ne peut pas être traduit automatiquement et pèse bien plus que le texte équivalent. Un vrai texte, dans les polices du site, est accessible, léger, net sur tous les écrans et indexable. Quand une image contenant du texte est inévitable, le texte alternatif doit en porter le contenu.
Les polices méritent une attention particulière. Une police qui arrive en retard, avec la règle font-display: block, laisse le texte invisible pendant plusieurs centaines de millisecondes : une perte de temps pour tous et un problème pour les personnes qui ont besoin de plus de temps pour lire. Avec font-display: swap, le texte apparaît immédiatement dans une police de repli, et l’utilisation des propriétés d’ajustement des métriques de police limite le décalage au moment de l’échange, comme on l’a vu dans l’article sur le subsetting des polices. Et il ne faut jamais désactiver le zoom avec user-scalable=no : c’était une pratique répandue pour supprimer le délai de toucher des anciens navigateurs mobiles, un problème que les navigateurs modernes ont résolu depuis des années.
Quand l’optimisation crée des obstacles
Toutes les optimisations ne sont pas neutres pour l’accessibilité. Certaines techniques répandues, appliquées sans précaution, peuvent la dégrader.
- Retarder le JavaScript jusqu’à l’interaction. De nombreux plugins ne chargent les scripts qu’au premier mouvement de souris, toucher ou défilement. S’ils ne prennent pas aussi en compte l’appui sur une touche, les personnes qui naviguent uniquement au clavier risquent de trouver des menus, des formulaires et des boutons qui ne fonctionnent pas, comme nous l’avons vu à propos du retardement du JavaScript. Il faut le vérifier en naviguant sur le site uniquement au clavier.
- Les façades. Un aperçu de vidéo ou de chat qui remplace le vrai composant doit être un vrai bouton, avec un libellé clair, accessible au clavier. Et quand le vrai composant est chargé, le focus doit s’y déplacer, pas se perdre.
- Supprimer le CSS inutilisé. Cela peut retirer les styles de focus, les styles du texte réservé aux lecteurs d’écran ou ceux des états déclenchés au clavier, que l’analyse automatique ne voit pas.
- Le chargement différé des contenus. Un contenu qui n’apparaît qu’au défilement peut être invisible pour les personnes qui naviguent avec un lecteur d’écran, lequel ne fait pas défiler la page comme le fait un utilisateur de souris. Le lazy loading natif des images n’a pas ce problème ; les solutions qui n’insèrent le texte que pendant le défilement, si.
- Les bandeaux de cookies. Un bandeau chargé tardivement et gardé compact pour des raisons de performance doit tout de même recevoir le focus quand il apparaît et être utilisable au clavier, comme l’explique l’article sur les bandeaux de consentement.
Single Page Applications et focus
Un cas particulier concerne les applications qui changent de page sans la recharger. Dans une navigation classique, le navigateur annonce le titre de la nouvelle page et ramène le focus au début du document. Dans une Single Page Application, si le code ne le fait pas explicitement, un utilisateur de lecteur d’écran peut ne pas remarquer que le contenu a changé et retrouver le focus sur un élément qui n’est plus visible. C’est un argument de plus en faveur des pages traditionnelles avec des outils modernes, comme le prerendering et les transitions entre documents, qui préservent le comportement accessible du navigateur.
Le cadre réglementaire
Pour de nombreuses organisations, l’accessibilité n’est plus seulement une bonne pratique. En Italie, les obligations d’accessibilité existent depuis des années pour l’administration publique, et avec la transposition de l’European Accessibility Act elles s’étendent à partir du 28 juin 2025 à de nombreux services privés destinés aux consommateurs, dont le e-commerce, avec quelques exclusions pour les microentreprises. La référence technique est constituée par les directives WCAG. La performance n’est pas une exigence explicite des textes, mais bon nombre des solutions qui l’améliorent, comme le HTML sémantique, la mise en page stable et le respect des préférences de l’utilisateur, contribuent aussi à la conformité.
Vérifier les deux
Lighthouse comprend une section consacrée à l’accessibilité à côté de celle sur la performance, et il vaut la peine de les consulter ensemble à chaque contrôle. Les contrôles automatiques ne couvrent toutefois qu’une partie des problèmes d’accessibilité, comme le contraste des couleurs, les textes alternatifs manquants et les libellés de formulaire. Le reste demande des tests manuels, et les plus simples sont à la portée de tous : naviguer sur le site uniquement au clavier, activer la préférence de réduction des animations, agrandir le texte à 200 %, essayer un lecteur d’écran sur les pages principales, utiliser le site sur un smartphone d’entrée de gamme avec une connexion lente. Ce sont les mêmes conditions dans lesquelles apparaissent les problèmes de performance.
En résumé
L’accessibilité et la performance servent les mêmes personnes et répondent à la même question : le site fonctionne-t-il pour ceux qui ne se trouvent pas dans des conditions idéales ? Le HTML sémantique réduit le JavaScript et rend les composants accessibles ; une mise en page stable évite des erreurs aux personnes qui se déplacent plus lentement ou utilisent une loupe ; la réactivité aide celles qui utilisent le clavier et les lecteurs d’écran ; la réduction des animations et le texte en tant que texte allègent les pages et les rendent plus faciles à utiliser.
En même temps, certaines optimisations de performance, si elles sont appliquées sans précaution, créent des obstacles : scripts différés qui ignorent le clavier, façades sans libellé, styles de focus supprimés. La règle est de vérifier chaque modification à travers les deux prismes. Un site rapide mais inaccessible, ou accessible mais lent, exclut quelqu’un ; un site construit en pensant aux deux est tout simplement un meilleur site, pour tout le monde.
