18079 sujets

Questions générales et questions de débutants

Accessibilité et CSS/JS : bonnes pratiques ?

Bonjour à tous,

Je développe actuellement une interface interactive en JavaScript, et je me pose pas mal de questions sur l'accessibilité — en particulier quand il s'agit de manipuler dynamiquement le DOM ou d'utiliser des animations CSS.

Je suis tombé sur un article très clair sur le sujet sur MDN :

https://developer.mozilla.org/fr/docs/Learn_web_development/Core/Accessibility/CSS_and_JavaScript
Il donne de bonnes bases pour comprendre comment ces deux technologies peuvent impacter l’expérience utilisateur, notamment pour les personnes utilisant des lecteurs d’écran.

Mais j’aurais aimé aller un peu plus loin. Par exemple :

Y a-t-il des recommandations spécifiques concernant l’usage de display: none vs visibility: hidden pour masquer des éléments temporairement ?

Est-ce qu’il vaut mieux éviter certains types de transitions ou effets lorsqu’on vise une bonne compatibilité avec les technologies d’assistance ?

Et concernant les messages d’erreur/validation dynamiques, quel est le meilleur pattern pour rester accessible ?

Si certains d’entre vous ont des retours d’expérience ou des exemples concrets, je suis preneur !

Merci d’avance pour vos conseils ????

— Tristan
Modifié par tristanbailly83 (19 Jul 2025 - 06:55)
Modérateur
Salut et bienvenue sur le forum,

tristanbailly83 a écrit :

...
Y a-t-il des recommandations spécifiques concernant l’usage de display: none vs visibility: hidden pour masquer des éléments temporairement ?
...


L'utilisation de l'attribut aria-hidden est préférable.
Administrateur
Bonjour,

Ton lien MDN : très bonne ressource qui aborde beaucoup de sujets sans faire trop pour chacun !

Pour ce qui est de cacher, masquer, faire ignorer du contenu : il y a 2 aspects et ensuite plus de cas que ça.
- le contenu doit-il être représenté visuellement à l'écran ou non ? Ou encore hors viewport ou réduit à 1 pixel transparent mais quand même là pour les lecteurs d'écran.
- le contenu doit-il être restitué par les technologies d'assistance et en particulier les lecteurs d'écran ?

Le cas par défaut c'est bien entendu "le contenu est visible et restitué par les lecteurs d'écran".

L'inverse est "ni visible ni restitué aux lecteurs d'écran", caché à tout le monde donc. display: none; et visibility: hidden; peuvent être indifféremment utilisés. L'attribut HTML 5 hidden également (il y a un ` Smiley hidden { display: none; }` quelque part donc le résultat est le même).

Ensuite le cas "pas rendu visuellement mais encore restitué aux lecteurs d'écran". J'essaie d'appeler ça un texte masqué, qui se distingue du texte caché précédent (oui en français c'est un peu synonyme mais j'ai pas mieux pour décrire ces 2 concepts...).
C'est le pixel transparent (anciennement le contenu affiché hors écran / viewport mais faut plus faire ça) que l'on obtient avec une classe appelée par convention .visually-hidden ou .sr-only (wordpress.org l'appelerait .screen-reader-text ? Même chose). À n'utiliser que lorsqu'on sait ce qu'on fait, pour corriger un problème identifié et compris que l'on ne peut pas corriger autrement. Exemple un bouton qui visuellement n'est qu'une icône et on choisit d'ajouter un nom accessible à ce bouton via un texte masqué et non un attribut ARIA.
Le plus souvent, il n'y a pas besoin de préciser quoi que ce soit aux lecteurs d'écran seulement, en particulier pas besoin de leur préciser que le lien est un lien, l'image une image ou le bouton un bouton. Ils savent si on utilise un lien A, une image avec une alternative textuelle renseignée `alt="Description de l'image qui apporte une information"` ou un button / input type button ou submit ou reset.

Ensuite le cas "information visible mais on veut que ce soit ignoré par les lecteurs d'écran". C'est l'attribut `aria-hidden="true"` évoqué précédemment. Pareil, n'utiliser que si on sait pourquoi. Inutile par exemple d'ajouter cet attribut à une image décorative (celles avec un alt vide `alt=""` ou `alt`) car elles sont déjà ignorées par les lecteurs d'écran.

Ces 2 derniers cas sont détaillés chez Orange Accessibilité : https://a11y-guidelines.orange.com/fr/articles/masquage-accessible/
Des cas d'usages détaillés par J. Moynat https://www.lalutineduweb.fr/alternatives-textuelles-texte-masque-css/
Administrateur
a écrit :
Et concernant les messages d’erreur/validation dynamiques, quel est le meilleur pattern pour rester accessible ?

Pour les boîtes de dialogue par dessus le contenu, les Motifs de Conception ARIA Alert et Alert and Message Dialogs https://www.w3.org/WAI/ARIA/apg/patterns/
Et Dialog (Modal) si c'est implémenté sous forme de "popup / popin / modale" (la gestion du focus clavier, ce gros morceau Smiley rolleyes ).
Pour le cas particulier des notifications (dans un coin de l'écran et du DOM, qui disparaissent avant qu'on ait eu le temps de les lire, donc pas accessibles aux utilisateurs de loupe d'écran ni aux lecteurs d'écran), pas mal de ressources récentes que je n'ai pas encore eu le temps d'ouvrir mais la bonne piste est role="alert" au moins pour les lecteurs d'écran.
(edit : problématiques des loupes d'écran) Si le résultat d'une action n'est présent que dans un coin de l'écran loin de ce qui l'a provoqué, il y a un problème d'UX (enfin de conception / design si le terme t'es inconnu).

Pour les formulaires, entre autres aria-invalid="true" et aria-describedby pointant du champ vers le(s) message(s) d'erreur et d'aide.
2 ressources :
- https://disic.github.io/guide-integrateur/6-formulaires.html
- https://a11y-guidelines.orange.com/fr/articles/formulaires/part2/ (la partie 1 pour les bases affichage initial et donc avant l'erreur)
edit : oh Access&Use a aussi une fiche sur le sujet, la dernière. Site pas assez connu, qui présente pour chaque sujet le pourquoi : quels sont les problèmes rencontrés par les utilisateurs ?
Modifié par Felipe (20 Jul 2025 - 15:10)
Prévenir un modérateur
Répondre au sujet
Aller à