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. Vous pouvez constater que l'écriture d'un code HTML expressif et sémantique vous offre une grande accessibilité avec très peu d'efforts, car de nombreux éléments standards intègrent à la fois la sémantique et le comportement d'assistance.
Dans cette leçon, nous allons aborder 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. Dans une page simple avec de nombreuses commandes, mais peu de contenu, vous pouvez facilement la parcourir pour trouver ce dont vous avez besoin. Toutefois, sur une page comportant beaucoup de contenu, telle qu'une entrée Wikipédia ou un agrégateur d'actualités, il n'est pas pratique de tout lire du haut vers le bas. Vous avez besoin d'un moyen de parcourir efficacement le contenu.
Les développeurs croient souvent à tort que les lecteurs d'écran sont fastidieux et lents à utiliser, ou que tout élément à l'écran doit être sélectionnable 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 d'en-têtes pour localiser les informations. La plupart des lecteurs d'écran permettent d'isoler et d'analyser facilement 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, rappelons un point précédent: l'ordre des commandes DOM est important, non seulement pour l'ordre de mise au point, mais aussi pour l'ordre des lecteurs d'écran. En testant les 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 qu'un lecteur d'écran perçoit est donc directement basé sur l'ordre DOM. Cela signifie qu'une structure de titre appropriée est plus importante que jamais.
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 utilisé pour désigner les titres"
- La section 2.4.1 mentionne la structure de titre comme technique de contournement des blocs de contenu.
- 2.4.6 décrit en détail comment écrire des en-têtes utiles
- 2.4.10 indique que "les sections de contenu sont désignées à l'aide d'en-têtes, 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 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, il peut s'agir d'un bon moyen d'intégrer des en-têtes lorsque la conception visuelle ne nécessite pas ou n'a pas de place pour un titre visible.
Autres options de navigation
Bien que les pages avec des titres de qualité aident les utilisateurs de lecteurs d'écran à naviguer, il existe d'autres éléments qu'ils peuvent utiliser pour se déplacer sur une page, tels que des liens, des commandes de formulaire et des points de repère.
Les lecteurs peuvent utiliser la fonctionnalité de rotor du lecteur d'écran (un moyen facile d'isoler et d'analyser une liste d'en-têtes de page) pour accéder à une liste de liens sur la page. Parfois, comme dans un wiki, il existe de nombreux liens. Le lecteur peut donc y rechercher un terme. Ainsi, les appels sont limités aux liens qui contiennent réellement le terme, plutôt qu'à chaque occurrence de ce terme sur la page.
Cette fonctionnalité n'est utile que si le lecteur d'écran parvient à trouver les liens et que le texte de ces liens est pertinent. Par exemple, voici quelques tendances courantes qui rendent les liens difficiles à trouver.
- Balises d'ancrage sans attributs
href. Souvent 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 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 appliquez-lui un style approprié.
- Images utilisées comme contenu de lien. Parfois nécessaires, les images liées peuvent être
inutilisables pour les lecteurs d'écran. Pour vous assurer que le lien est correctement exposé aux technologies d'assistance, assurez-vous que le texte de l'attribut de l'image est
alt.
Un texte de lien de mauvaise qualité est un autre problème. Les textes cliquables tels que "en savoir plus" ou "cliquez ici" ne fournissent aucune information sémantique sur la destination du lien. Utilisez plutôt un texte descriptif tel que "En savoir plus sur le responsive design" ou "voir ce tutoriel sur les canevas" pour aider les lecteurs d'écran à fournir un contexte pertinent sur les liens.
Le rotor peut également récupérer une liste de contrôle de formulaire. À l'aide de cette liste, les lecteurs peuvent rechercher des éléments spécifiques et y accéder directement.
Les lecteurs d'écran commettent souvent l'erreur de prononciation. 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 entier ou lire du 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 très habitués à cette bizarrerie et en prennent en compte.
Certains développeurs tentent d'améliorer cette situation en fournissant du texte réservé au lecteur d'écran et 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 se sert d'une plage braille, le mot est mal orthographié, ce qui génère davantage de confusion. Les lecteurs d'écran permettent d'épeler des mots à voix haute. Laissez-le donc au lecteur pour contrôler son expérience et décider quand c'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ères 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 l'intégration de styles (ce que vous devriez faire avec CSS).
Les éléments structuraux sémantiques remplacent plusieurs blocs div répétitifs et offrent un moyen plus clair et plus descriptif d'exprimer de manière intuitive la structure de la page aux auteurs et aux lecteurs.