The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.
Vers des livrables plus accessibles 🚀
Au chapitre des erreurs les plus courantes figurent : les textes présentant des contrastes insuffisants, images sans alternatives textuelles, les champs de formulaires sans étiquette (bien souvent confuses et peu explicites) et bien d'autres ! Revenons sur chacune d'entre-elles, et tentons de clarifier les choses afin de produire des livrables plus accessibles.
Les contrastes de textes sont définis selon un ratio qui donne facilement la migraine. Nous pouvons cependant retenir que le seuil d’acceptabilité de ce ration dépend de la taille du texte concerné. Sachez simplement que le seuil d'acceptabilité de ce ratio est différent selon la taille du texte en question.Il existe une quantité d'outils pour vous aider à le déterminer, en renseignant la couleur du texte et celle du fond sur lequel il repose. Vous pouvez par exemple vous orienter vers le Contrast Checker de WebAIM. Mais vous avez la possibilité de le vérifier sans même quitter votre navigateur, puisque les outils de déboggage vous communiquent cette information également. Vous n'avez vraiment aucune excuse pour ne pas vous y mettre 😏
Pour le corps de texte, un contraste de 4.5:1 entre l’arrière-plan et le contenu de premier-plan (généralement du texte) permettra d'être en conformité avec les recommandations WCAG. Pour les textes de grande taille, le contraste permettant d'être en conformité est réduit à 3:1. Les informations définissant ce qui est considéré ou non comme texte de grande taille peuvent être confuses au sein des WCAG. Mais notre référentiel français, le RGAA (Référentiel Général d'Amélioration de l'Accessibilité), mentionne la valeur de 24 pixels dans le critère de test 3.2.3.
Les images utilisées, à travers la balise img, se doivent toutes de porter un attribut alt. Cet attribut pourra être renseigné ou laissé vide selon qu'il porte de l'information nécessitant d'être retranscrite aux lecteurs d'écran et autres technologies d'assistance.Pour ce qui est des images utilisées en tant que fond (par le biais des feuilles de style et la déclaration background-image), elles ne devraient en aucun cas comporter du texte. Il est pourtant encore très courant de voir des bannières sur lesquelles trônent des textes stylisés sans qu'aucune alternative cohérente ne soit proposée.Petit détour au sujet des alternatives textuelles : leur rédaction peut être un exercice périlleux. Il s'agit de décrire l'image en fonction de son contexte, pour souligner ce qu'elle apporte en plus au contenu auquel elle est liée. Si elle est purement décorative (exemple d'une image d'archive en illustration) et sans véritable plus-value, sans doute ne mérite-t-elle pas d'être renseignée (attribut alt laissé vide). A noter qu'il n'est sans doute pas du ressort du développeur / intégrateur de déterminer le contenu de cet attribut. Les équipes éditoriales sont vraisemblablement plus à même d'en déterminer la valeur.
L'ensemble des champs de vos formulaires se doivent de porter une étiquette permettant d'en identifier la fonction. La manière la plus simple de procéder reste sans doute de passer par le couple d'attribut id et for sur les balises input et label respectivement.
Les champs de formulaire sont associés à leur label respectif par l'intermédiaire de leurs attributs. Ces labels, s'ils ne sont pas visibles pour des raisons esthétiques, seront cachés de manière à rester accessibles par le biais d'une classe utilitaire CSS (Cascading Style Sheets).
Aussi, il n'est pas rare de voir des interfaces sur lesquelles les labels ont tout bonnement été retirés par gain de place ou figurant en lieu et place du placeholder (à l'image de ce qu'on peut retrouver sur le design system Google Material).
Si vous décidez de les retirer pour des raisons esthétiques (discutables), assurez-vous au moins de les laisser accessibles dans la source HTML du document. Pour ce faire, vous pouvez faire usage d'une classe .visually-hidden pour les cacher visuellement tout en les conservant pour les lecteurs d'écran pour qui la fonction du champ peut ne pas être aussi évidente.
Faire usage des placeholders peut également être problématique car ils peuvent donner l'impression que le champ est renseigné. Par ailleurs, ils ne sont plus visibles dès lors qu'une valeur est renseignée, ce qui peut aussi poser souci pour les personnes souffrant de troubles de la mémoire à court terme par exemple.
Les lecteurs d'écran permettent de lire le contenu de différentes manières. Parmi ces modes, l'un des plus appréciés reste généralement par type de contenus. Et notamment par titres.
En optant pour une structure de titres cohérente, vous faciliterez grandement la navigation au sein des différents contenus. Mais qu'entendons-nous exactement par cohérent ?
D'un point de vue sémantique, cohérent signifiera selon une suite logique : pas de titre de niveau 3 (h3) sans titre de niveau 2 le précédant (h2). D'un point de vue éditorial, le titre devra clairement décrire la section qu'il introduit. Et toute la difficulté est là : il s'agit de trouver le bon équilibre entre le ton que l'on souhaite parfois adopter et l'information à véhiculer. Assurez-vous d'être compris avant toute chose. Certaines références peuvent en effet ne pas être comprises de tout le monde.
Enfin, on est parfois tenté de ne pas nommer les choses parce qu'une section est clairement identifiable de par l'espace qu'elle occupe à l'écran. Mais une fois encore, cela ne vaut que pour les personnes en mesure de scanner visuellement le document. Alors qu'il soit visible ou non, faites usage d'un titre et structurez votre document autant que possible (paragraphe, listes à puces...) !
Les landmark regions font référence à des rôles portés par les différentes sections d'un document permettant d'en délimiter les contours. Avant le HTML 5, nous n'avions d'autre manière de segmenter notre document qu'en faisant usage de la balise générique div.
Il était alors courant de renseigner les rôles ARIA directement sur ces balises, neutres et sans valeur sémantique, afin d'en définir la fonction.
Les lecteurs d'écran permettent la restitution du contenu par le biais d'une synthèse vocale. Si le contenu est dans une langue différente de la langue par défaut, cette restitution risque d'être difficilement compréhensible.Veillez donc à renseigner l'attribut lang sur la balise html de votre document. Notez que cet attribut peut aussi s'appliquer sur toute autre balise. Vous pouvez déclarer une langue différente sur une citation (blockquote), un simple mot via une balise générique span, de manière à améliorer la compréhension du contenu.
La première règle ARIA : ne pas faire usage d'ARIA. Comme évoqué précédemment, le HTML aujourd'hui, pour peu qu'il soit utilisé comme il se doit, est généralement déjà porteur de l'information nécessaire à la bonne restitution du contenu. Je dis bien généralement, car comme pour tout, il y a des exceptions. On s'attendrait à ce que tous les éléments proposés nativement par la plateforme et les navigateurs soient accessibles, mais dans les faits, ce n'est pas toujours le cas. De quoi frustrer un peu plus l'intégrateur / développeur que vous êtes peut-être !Mais revenons-en à ARIA... Faire usage de ces attributs est à double tranchant. Mieux vaut savoir où l'on met les pieds, si j'ose dire. L'étude mentionnée en préambule stipule à ce sujet qu'un plus large usage de ces attributs est directement corrélé à un nombre plus important d'erreurs.Malgré tout, pour les interfaces les plus riches en termes d'interaction, le HTML tourne parfois un peu court (du moins à l'heure actuelle). Et il est effectivement nécessaire de faire usage d'ARIA pour décrire davantage la finalité de certains composants riches, avec lesquels nous avons pris l'habitude d'interagir (modal, dropdown...).Des composants riches que nous ne réinventons qu'assez rarement en tant que développeurs puisqu'il est plus souvent question de s'en remettre à une bibliothèque. Mais il nous revient immanquablement d'en auditer la qualité, aussi bien en termes de maintenance, de sécurité, que d'accessibilité.
Pour l'utilisateur·trice d'un lecteur d'écran (qui le plus souvent va parcourir un document par type de contenu), une suite de liens avec pour seul intitulé "En savoir plus" n'en dit pas long sur sa destination.On est souvent tenté par ce genre de raccourci afin de rendre nos interfaces légères et aérées. Pour celui ou celle en mesure de scanner le document, il est assez évident de déterminer à quel contenu un lien est associé.C'est évidemment moins le cas pour les usagers d'un lecteur d'écran. Différentes techniques vous permettent de rester accessible malgré tout, tout en restant concis. Et il en va évidemment de même pour les liens et boutons ne portant tout bonnement aucune étiquette mais une simple icône. Pour les lecteurs d'écran, c'est problématique, tout le monde n'a pas le même référentiel concernant les icônes !
🧑🔧 Conclusion 👩🔧
Voici donc pour les erreurs les plus courantes. Il y aurait quantité d'autres choses à évoquer en supplément. Et nous y reviendrons sans doute plus en détail dans d'autres articles. Mais vous voilà armés de l'essentiel pour faire du web un espace d'ores et déjà plus accessible.
A noter qu'il a souvent été question de recommandations issues des WCAG au fil de cet article. Mais comme évoqué, nous avons aussi notre référentiel nommé le RGAA en France.
Celui-ci demeure sans doute plus digeste et compréhensible (surtout pour les non anglophones 🥖🥐). Il s'appuie par ailleurs sur ces mêmes recommandations issues du WC3 (World Wide Web Consortium). Et c'est lui qui pose les jalons pour les audits auxquels sont soumis les services publics et les entreprises dont le chiffre d'affaires ne permet pas de s'exempter de l'obligation d'accessibilité. Alors, si vous avez le souhait de bien faire, je ne peux que vous encourager à y jeter un oeil 👀
Web Content Accessibility Guidelines (WCAG)
RGAA
.svg)
