Le 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. 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 aborderons une sémantique moins évidente qui est très importante 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. Mais sur une page riche en contenu, telle qu'une entrée Wikipédia ou un agrégateur d'actualités, il n'est pas pratique de lire tout le contenu du haut vers le bas. Vous avez besoin d'un moyen de naviguer efficacement dans le contenu.
Les développeurs ont souvent l'idée fausse selon laquelle les lecteurs d'écran sont fastidieux et lents à utiliser, ou que tout le contenu à l'écran doit être sélectionnable pour que le lecteur d'écran le trouve. Ce n'est souvent pas le cas.
Les utilisateurs de lecteurs d'écran s'appuient souvent sur une liste d'en-têtes pour localiser les informations. La plupart des lecteurs d'écran disposent de moyens simples d'isoler et d'analyser une liste d'en-têtes de page, une fonctionnalité importante appelée rotor. Voyons comment utiliser efficacement les en-têtes HTML pour prendre en charge cette fonctionnalité.
Utiliser efficacement les en-têtes
Tout d'abord, reprenons un point précédent: l'ordre du DOM, non seulement pour l'ordre de sélection, 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.
Cela est vrai pour les lecteurs d'écran en général. Étant donné que les lecteurs d'écran interagissent avec l'arborescence d'accessibilité et que celle-ci est basée sur l'arborescence DOM, l'ordre perçu par un lecteur d'écran est donc directement basé sur l'ordre du DOM. Il est donc plus important que jamais d'avoir une structure de titres appropriée.
Dans la plupart des pages bien structurées, les niveaux de titre 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"
- La section 2.4.1 mentionne la structure des titres comme technique permettant de contourner des blocs de contenu
- La section 2.4.6 fournit certains détails pour rédiger des en-têtes utiles.
- La section 2.4.10 indique que "les sections de contenu individuelles sont désignées à l'aide de titres, le cas échéant".
Il n'est pas nécessaire que tous les titres soient visibles à l'écran. Wikipédia, par exemple, utilise une technique qui place délibérément certains titres en dehors de l'écran pour les rendre spécifiquement accessibles uniquement aux lecteurs d'écran et à d'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'adapter les en-têtes lorsque la conception visuelle ne nécessite pas ou n'offre pas de place pour un titre visible.
Autres options de navigation
Bien que les pages avec des en-têtes appropriés aident les utilisateurs de lecteurs d'écran à naviguer, ils peuvent utiliser d'autres éléments pour se déplacer sur une page, comme les liens, les commandes de formulaire et les points de repère.
Les lecteurs peuvent utiliser la fonctionnalité de rotor du lecteur d'écran (un moyen simple d'isoler et de scanner une liste d'en-têtes 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 permet de limiter les appels aux liens qui contiennent réellement le terme, et non à 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.
- Des balises d'ancrage sans attribut
hrefSouvent utilisées dans les applications monopages, ces cibles de liens causent des problèmes aux lecteurs d'écran. Pour en savoir plus, consultez cet article sur les applications monopages. - Boutons intégrés avec des liens. En effet, le lecteur d'écran interprète le contenu comme un lien, et le bouton ne fonctionne plus. Dans ce cas, remplacez la balise d'ancrage par un bouton réel et définissez un style approprié.
- Images utilisées comme contenu du lien. Parfois nécessaires, les images liées peuvent être inutilisables par les lecteurs d'écran. Pour garantir que le lien est correctement exposé à la technologie d'assistance, assurez-vous que l'image contient un texte d'attribut
alt.
La mauvaise qualité du texte des liens constitue un autre problème. Les textes cliquables tels que "En savoir plus" ou "Cliquez ici" ne fournissent aucune information sémantique concernant la destination du lien. Utilisez plutôt un texte descriptif tel que "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 sous la forme d'un grand nombre entier ou lire un texte en majuscules comme s'il s'agissait d'un acronyme. Il est intéressant de noter que les utilisateurs de lecteurs d'écran sont assez habitués à cette particularité et prennent en compte cette particularité.
Certains développeurs essaient d'améliorer cette situation en fournissant un texte écrit phonétique uniquement pour les lecteurs d'écran. Voici une règle d'orthographe phonétique simple : ne l'utilisez pas, cela ne fait qu'aggraver le problème. Si, par exemple, un utilisateur utilise une plage braille, le mot ne sera pas orthographié correctement, 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 points de repère. 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 le style intégré (ce que vous devriez faire de toute façon avec CSS).
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.