Rôle de la sémantique dans la navigation sur les pages
Vous avez découvert les affordances, la sémantique et la façon dont les technologies d'assistance utilisent l'arborescence d'accessibilité pour créer une expérience utilisateur alternative pour leurs utilisateurs. Comme vous pouvez le constater, écrire du code HTML sémantique expressif offre une grande accessibilité avec très peu d'effort, car de nombreux éléments standards intègrent à la fois la sémantique et le comportement secondaire.
Dans cette leçon, nous allons aborder certaines sémantiques moins évidentes qui sont très importantes pour les utilisateurs de lecteurs d'écran, en particulier en ce qui concerne la navigation. Sur une page simple contenant de nombreuses commandes, mais peu de contenu, il est facile de parcourir la page pour trouver ce dont vous avez besoin. Toutefois, sur une page contenant beaucoup de contenu, comme une entrée Wikipédia ou un agrégateur d'actualités, il n'est pas pratique de tout lire de haut en bas. Vous avez besoin d'un moyen de parcourir efficacement le contenu.
Les développeurs ont souvent l'idée fausse que les lecteurs d'écran sont pénibles et lents à utiliser, ou que tout ce qui s'affiche à l'écran doit pouvoir être sélectionné pour que le lecteur d'écran puisse le trouver. Ce n'est souvent pas le cas.
Les utilisateurs de lecteurs d'écran s'appuient souvent sur une liste de titres pour trouver des informations. La plupart des lecteurs d'écran permettent d'isoler et d'analyser facilement une liste de titres de page, une fonctionnalité importante appelée rotor. Voyons comment utiliser efficacement les titres HTML pour prendre en charge cette fonctionnalité.
Utiliser efficacement les titres
Tout d'abord, répétons un point précédent: L'ordre DOM est important, non seulement pour l'ordre de mise au point, mais aussi pour l'ordre du lecteur d'écran. Lorsque vous testez des lecteurs d'écran tels que VoiceOver, NVDA, JAWS et ChromeVox, vous constaterez que la liste des titres suit l'ordre DOM plutôt que l'ordre visuel.
C'est le cas pour les lecteurs d'écran en général. Étant donné que les lecteurs d'écran interagissent avec l'arborescence d'accessibilité, et que l'arborescence d'accessibilité est basée sur l'arborescence DOM, l'ordre perçu par un lecteur d'écran est donc directement basé sur l'ordre DOM. Par conséquent, il est plus important que jamais de structurer les titres de manière appropriée.
Dans la plupart des pages bien structurées, les niveaux de titres sont imbriqués pour indiquer les relations parent-enfant entre les blocs de contenu. La checklist WebAIM fait référence à plusieurs reprises à cette technique.
- 1.3.1 mentionne "Le balisage sémantique est utilisé pour désigner les en-têtes"
- 2.4.1 mentionne la structure des titres comme une technique permettant de contourner les blocs de contenu.
- La section 2.4.6 fournit certains détails sur la façon de rédiger des en-têtes utiles.
- 2.4.10 indique que "les sections de contenu individuelles sont désignées à l'aide de titres, le cas échéant".
Tous les titres ne doivent pas être visibles à l'écran. Wikipedia, par exemple, utilise une technique qui place délibérément certains titres en dehors de l'écran pour les rendre uniquement accessibles aux lecteurs d'écran et aux autres technologies d'assistance.
<style>
.sr-only {
position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;
}
</style>
<h2 class="sr-only">This heading is offscreen.</h2>
Pour les applications complexes, cela peut être un bon moyen d'intégrer des titres lorsque la conception visuelle n'exige pas ou n'a pas de place pour un titre visible.
Autres options de navigation
Bien que les pages comportant de bons titres aident les utilisateurs de lecteurs d'écran à naviguer, d'autres éléments peuvent leur permettre de se déplacer sur une page, y compris les liens, les boutons de formulaire et les repères.
Les lecteurs peuvent utiliser la fonctionnalité de rotor du lecteur d'écran (un moyen simple d'isoler et d'analyser une liste de titres de page) pour accéder à une liste de liens sur la page. Parfois, comme sur un wiki, il existe de nombreux liens. Le lecteur peut donc rechercher un terme parmi ceux-ci. Cela limite les appels aux liens qui contiennent réellement le terme, plutôt que chaque occurrence du terme sur la page.
Cette fonctionnalité n'est utile que si le lecteur d'écran parvient à trouver les liens et que leur texte est pertinent. Par exemple, voici quelques modèles courants qui rendent les liens difficiles à trouver.
- Balises d'ancrage sans attributs
hrefSouvent utilisées dans les applications monopages, ces cibles de lien posent problème pour les lecteurs d'écran. Pour en savoir plus, consultez cet article sur les applications monopages. - Boutons implémentés avec des liens. Le lecteur d'écran interprète alors le contenu comme un lien, et la fonctionnalité du bouton est perdue. Dans ce cas, remplacez la balise d'ancrage par un bouton réel et donnez-lui un style approprié.
- Images utilisées comme contenu de lien. Parfois nécessaires, les images liées peuvent être inutilisables par les lecteurs d'écran. Pour vous assurer que le lien est correctement exposé aux technologies d'assistance, assurez-vous que l'image comporte un texte d'attribut
alt.
La mauvaise qualité du texte des liens constitue un autre problème. Le texte cliquable, tel que "En savoir plus" ou "Cliquez ici", ne fournit aucune information sémantique sur la destination du lien. Utilisez plutôt un texte descriptif, comme "En savoir plus sur le responsive design" ou "Voir ce tutoriel sur le canevas", pour aider les lecteurs d'écran à fournir un contexte pertinent sur les liens.
Le rotor peut également récupérer une liste de commandes de formulaire. À l'aide de cette liste, les lecteurs peuvent rechercher des éléments spécifiques et y accéder directement.
La prononciation est une erreur courante des lecteurs d'écran. Par exemple, un lecteur d'écran peut prononcer "Udacity" comme "oo-dacity", lire un numéro de téléphone comme un grand entier ou lire du texte en majuscules comme s'il s'agissait d'un acronyme. Fait intéressant, les utilisateurs de lecteurs d'écran sont très habitués à cette particularité et en tiennent compte.
Certains développeurs tentent d'améliorer cette situation en fournissant un texte réservé aux lecteurs d'écran orthographié phonétiquement. Voici une règle simple pour l'orthographe phonétique : ne le faites pas. Cela ne fait qu'aggraver le problème. Par exemple, si un utilisateur utilise un écran braille, le mot sera mal orthographié, ce qui entraînera davantage de confusion. Les lecteurs d'écran permettent d'épeler les mots à voix haute. Laissez-le donc au lecteur de contrôler son expérience et de décider quand cela est nécessaire.
Les lecteurs peuvent utiliser le rotor pour afficher une liste de repères. Cette liste aide les lecteurs à trouver le contenu principal et un ensemble de repères de navigation fournis par des éléments de repère HTML.
HTML5 a introduit de nouveaux éléments qui aident à définir la structure sémantique de la page, y compris header, footer, nav, article, section, main et aside. Ces éléments fournissent spécifiquement des indices structurels sur la page sans forcer de style intégré (ce que vous devez faire avec CSS de toute façon).
Les éléments structurels sémantiques remplacent plusieurs blocs div répétitifs et fournissent aux auteurs et aux lecteurs une manière plus claire et plus descriptive d'exprimer intuitivement la structure de la page.