Development #36909
New utils mixin & class: sr-only (screen-reader-only)
0%
Description
Dans la majorité des framework CSS, on retrouve une class dédiée à masquer visuellement un élément tout en le laissant lisible par les lecteurs l'écran et les bots. Ce qui n'est pas le cas de display: none, les bots et lecteurs d'écrans l'ignore.
Cette class est habituellement appelée
sr-onlyou.visually-hidden
Elle permettrait d'améliorer facilement l'accessibilité du front de publik.
Par exemple sur les steps forms
<span class="marker">
<span class="sr-only">Étape<span>
{{ forloop.counter }}
<span class="sr-only">sur<span>
{{ page_labels|length }}
</span>
La version @mixin permettrait de masquer conditionnellement l'élément.
Fichiers
Demandes liées
Historique
Mis à jour par Thomas Jund il y a plus de 4 ans
- Fichier 0001-SCSS-utils-add-sr-only-utils-mixin-class-36909.patch ajouté
- Tracker changé de Support à Bug
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Thomas Jund il y a plus de 4 ans
- Fichier
0001-SCSS-utils-add-sr-only-utils-mixin-class-36909.patchsupprimé
Mis à jour par Thomas Jund il y a plus de 4 ans
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Solution proposée à Solution validée
Ajouter un commentaire pour dire que tout ça semble peut sembler excessif mais que c'est "the industry accepted way to achieve a screenreader only element (the industry obviously ignoring lynx)" ?
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Solution validée à Solution proposée
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Solution proposée à Solution validée
oops
Mis à jour par Thomas Jund il y a plus de 4 ans
Frédéric Péters a écrit :
Ajouter un commentaire pour dire que tout ça semble peut sembler excessif mais que c'est "the industry accepted way to achieve a screenreader only element (the industry obviously ignoring lynx)" ?
Les utilisateurs de lynx, ne sont-ils pas aussi aveugle à tout style graphique? Et par ce fait n'est-il pas préférable d'être aussi explicite à leur égard ?
Mis à jour par Frédéric Péters il y a plus de 4 ans
(ma partie entre parenthèses pouvait être ignorée)
Mais rien à voir, je regardais à nouveau et .sr_only ne devrait pas être .sr-only ?
Mis à jour par Thomas Jund il y a plus de 4 ans
Bonne question!
On en revient à la convention de nommage.
Je vais avancer sur une proposition concrète.
Mis à jour par Frédéric Péters il y a plus de 4 ans
En fait je ne voulais pas dérailler la discussion de fond du nommage avec des détails, mais ne bloquons pas là-dessus, définissons déjà qu'on n'utilise pas d'underscores.
Mis à jour par Frédéric Péters il y a environ 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
J'ai poussé, avec sr-only comme nom de classe,
commit 9b37bd3edb7242ff976b4cc84959f2ed6acaa8e8
Author: Thomas JUND <tjund@entrouvert.com>
Date: Mon Oct 14 16:22:00 2019 +0200
scss: utils: add sr-only utility mixin & class (#36909)
Mis à jour par Thomas Jund il y a environ 4 ans
ok. J'en avais pas encore eu l'utilité et ne voulais pas chargé le core d'un truc pas utilisé.
Mis à jour par Thomas Jund il y a environ 4 ans
- Lié à Bug #40826: supprimer déclaration css .sr-only de .gru-nav-button ajouté
Mis à jour par Frédéric Péters il y a environ 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée