Cache-cache CSS

Et j’ai beau trouver ça idiot — masquer du texte pour certains utilisateurs et pas pour d’autres, ça me paraît incohérent avec l’accessibilité — c’est un besoin récurrent.

Il existe de nombreuses façons de faire, que je ne détaillerai pas ici. Depuis quelques années, lorsque je le peux, j’utilise celle de Thierry Koblentz pour Yahoo! qui est décrite sur le blog technique de Yahoo! sur le blog de Thierry. C’est de loin la plus complète, et la seule à ma connaissance à supporter la direction de texte de droite à gauche.

Mais elle n’est pas exempte de problème, désormais.

Propriété dépréciée

La « magie » de cette solution repose sur la propriété clip. Elle est simple à comprendre et très efficace. Seul bémol : clip est déprécié par le module CSS masking de niveau 1.

Pas de souci. La technique basée sur clip date un peu, il est normal qu’elle tombe en désuétude. La nouvelle spécification recommande l’utilisation de clip-path pour remplacer clip. Ce qui nous laisse pantois, puisque le support de clip-path est encore tout à fait relatif. Nous devons conserver clip et ajouter clip-path en guise d’amélioration progressive.

Cependant la syntaxe est différente également. Après quelques recherches, Yvain Liechti a proposé la version la plus courte pour obtenir le résultat attendu :

clip-path: inset(50%);

Banco. Un problème résolu !

Le texte ratatiné

J. Renée Beach a signalé que la propriété width: 1px; avait des effets négatifs sur le rendu du texte et par conséquent sa vocalisation par un lecteur d’écran.

La solution proposée est à la fois logique et simple : empêcher le texte de passer à la ligne et ainsi garantir que les espaces entre les mots sont conservés.

Une seule propriété suffit :

white-space: nowrap;

Et voilà, second problème résolu.

La totale

Voilà la version finale que je propose actuellement :

.sr-only {
  border: 0 !important;
  clip: rect(1px, 1px, 1px, 1px) !important;
  -webkit-clip-path: inset(50%) !important;
    clip-path: inset(50%) !important;
  height: 1px !important;
  margin: -1px !important;
  overflow: hidden !important;
  padding: 0 !important;
  position: absolute !important;
  width: 1px !important;
  white-space: nowrap !important;
}

Avertissement

Normalement, vous ne devriez utiliser ceci que pour du texte. Autrement dit, il ne devrait jamais y avoir d’élément capable de recevoir le :focus dans un élément masqué de la sorte. Cela pourrait conduire à des comportements étonnants, puisque le navigateur cherchera à positionner le scroll à l’endroit où est placé le :focus.

Cependant, si l’élément masqué peut lui-même recevoir le :focus, il nous faut pouvoir l’afficher de nouveau. C’est généralement le cas pour les liens d’évitement. Lisez la technique G1 des WCAG pour en savoir plus.

Pour ce genre de cas, Bootstrap propose une classe supplémentaire pour remettre à zéro nos valeurs de masquage.

C’est à mon avis la meilleure façon de faire — et étant donné les changements apportés sur la classe de masquage, cette seconde classe doit être revue elle aussi. Voici ma version :

.sr-only-focusable:focus,
.sr-only-focusable:active {
  clip: auto !important;
  -webkit-clip-path: none !important;
    clip-path: none !important;
  height: auto !important;
  margin: auto !important;
  overflow: visible !important;
  width: auto !important;
  white-space: normal !important;
}

Code et traduction

Vous pouvez retrouver ces classes à plusieurs endroits :

• sur CodePen ;
• dans un Gist.

Qu’en dites-vous ?

Version anglaise

Kitty Giraudel m’a fait l’honneur de traduire cet article en anglais et le publier sur son blog. Merci !

Modifications

Les lecteurs d’écran sur mobile

19 octobre 2016

Ayant besoin de tests sur cette version pour vérifier qu’elle n’introduit pas de régressions, Johan Ramon m’a remonté un bug étrange sur VoiceOver. En creusant un peu avec Sylvain Pigeard, il nous est apparu que position: static posait problème lors de la prise de focus d’un lien ayant la classe .sr-only-focusable.

Nous étions contents, lorsqu’en cherchant à avertir l’équipe de Bootstrap nous sommes tombés sur un ticket ouvert récemment qui implique également TalkBack. Patrick H. Lauke, en investiguant, a décelé de nombreuses incohérences dans la gestion du focus entre les diverses technologies d’assistance sur mobile. Il a ainsi ouvert des tickets un peu partout :

• Narrator, le lecteur d’écran intégré à Windows 8, Windows 10 et Windows Phone ;
• TalkBack, le lecteur d’écran intégré à Android, interfacé avec Chromium ;
• Firefox, qui tend à s’interfacer le mieux possible avec tous les lecteurs d’écran ;
• Webkit, le moteur de rendu de Safari ;
• Webkit, encore.

L’état des lieux est assez sombre : les liens d’évitement ne marchent globalement pas sur les interfaces tactiles lorsqu’on utilise un lecteur d’écran. Ô joie.

Le référencement naturel

19 octobre 2016

Steve Faulkner — du Paciello Group — a posé la question au forum de support pour webmasters de Google : les contextes supplémentaires pour utilisateurs malvoyants ont-ils un effet négatif sur le positionnement dans les résultats de recherche ?

Réponse courte : non Cependant étant donné que ce texte n’apparaît pas de prime abord il est considéré comme du contenu secondaire et a donc un très faible impact sur le positionnement, et c’est une excellente chose puisque cela dissuade d’en abuser.

Les débordements inopinés

18 janvier 2019

De multiples problèmes de débordements ont été observés, notamment sur Chrome, lorsque les éléments masqués sont contenus dans un élément avec overflow: auto;. Le problème est résolu dans Boosted en ajoutant margin: -1px;.