Cette page a été traduite par l'API Cloud Translation.

Sémantique et navigation dans les contenus

Le rôle de la sémantique dans la navigation sur les pages

Alice Boxhall

Dave Gash

Meggin Kearney

Vous avez appris les affordances, la sémantique et la façon dont les technologies d'assistance utilisent l'arborescence d'accessibilité afin de créer une expérience utilisateur alternative pour leurs utilisateurs. Vous pouvez voir que l'écriture de code HTML expressif et sémantique vous offre de nombreux l'accessibilité avec très peu d'effort, puisque de nombreux éléments standard ont à la fois une sémantique et un comportement de soutien intégrés.

Dans cette leçon, nous aborderons des notions moins évidentes, aux utilisateurs de lecteurs d'écran, en particulier en ce qui concerne la navigation. Dans une page simple avec mais avec peu de contrôle, il est facile de parcourir la page dont vous avez besoin. Mais sur une page riche en contenu, comme une entrée Wikipédia ou un site d'actualités il n'est pas pratique de tout lire de haut en bas, vous besoin d'un moyen de naviguer efficacement dans le contenu.

Les développeurs croient souvent à tort que les lecteurs d'écran sont fastidieux et lents ou que tout ce qui est affiché à l'écran soit sélectionnable pour la 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 les lecteurs d'écran ont des moyens simples d'isoler et d'analyser une liste d'en-têtes de page, un fonctionnalité importante appelée rotor. Voyons comment utiliser les en-têtes HTML efficacement pour prendre en charge cette fonctionnalité.

Utiliser efficacement les en-têtes

Tout d'abord, reprenons un point précédent: l'ordre DOM ce qui est important, non seulement l'ordre de sélection mais pour l'ordre du lecteur d'écran. Lorsque vous testez les lecteurs d'écran comme VoiceOver, NVDA, JAWS et ChromeVox, vous trouverez la liste des titres l'ordre DOM plutôt que l'ordre visuel.

Cela est vrai pour les lecteurs d'écran en général. Comme les lecteurs d'écran interagissent avec l'arborescence d'accessibilité, qui repose sur l'arborescence DOM, l'ordre qu'un lecteur d'écran perçoit est donc directement basé sur l'ordre DOM. Ce signifie qu'il est 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. WebAIM checklist fait référence à plusieurs reprises à cette technique.

1.3.1 mentionne "Le balisage sémantique est utilisé pour désigner les titres"
2.4.1 mentionne la structure des titres comme technique permettant de contourner les blocs de contenu
2.4.6 présente quelques détails pour 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"

Il n'est pas nécessaire que tous les titres soient visibles à l'écran. Wikipédia, par exemple, utilise une technique place délibérément des titres en dehors de l'écran pour les faire accessible uniquement 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'adapter les 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 de bons en-têtes aident les utilisateurs de lecteurs d'écran à naviguer, il existe Les autres éléments qu'ils peuvent utiliser pour se déplacer sur une page, comme les liens, les formulaires des contrôles et des points de repère.

Les lecteurs peuvent utiliser la fonction de rotor du lecteur d'écran (un moyen facile d'isoler et analyser une liste d'en-têtes de page) pour accéder à une liste de liens sur la page. Parfois, comme sur un wiki, il y a de nombreux liens, de sorte que le lecteur peut rechercher un dans les liens. Cela permet de limiter les appels aux liens qui contiennent 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 le lien le texte est significatif. Par exemple, voici quelques modèles courants qui créent des liens difficiles à trouver.

Des balises d'ancrage sans attribut href Souvent utilisés sur une seule page applications, ces liens cibles causent des problèmes pour les lecteurs d'écran. Vous pouvez Pour en savoir plus, consultez cet article sur les applications monopages.
Boutons intégrés avec des liens. Le lecteur d'écran risque interpréter le contenu comme un lien et la fonctionnalité du bouton est perdue. Pour dans ce cas, remplacez la balise d'ancrage par un vrai bouton et appliquez-lui un style en conséquence.
Images utilisées comme contenu du lien. Parfois, les images associées peuvent être inutilisable pour les lecteurs d'écran. Pour garantir que le lien est correctement exposé technologie 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. Texte cliquable, comme "En savoir plus" ou « cliquer sur 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 canevas tutoriel" 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 écran le lecteur pourrait prononcer "Udacity" ou lire un numéro de téléphone comme une un grand entier, ou lire un texte en majuscules comme s'il s'agissait d'un acronyme. Fait intéressant, les utilisateurs de lecteurs d'écran sont assez habitués à cette bizarrerie et l'abordent la considération.

Certains développeurs essaient d'améliorer cette situation en fournissant des lecteurs d'écran uniquement du texte écrit phonétiquement. Voici une règle simple concernant l'orthographe phonétique: ne le faites pas. cela ne fait qu'aggraver le problème ! Par exemple, si un utilisateur utilise une plage braille, le mot est mal orthographié, ce qui augmente le nombre la confusion. Les lecteurs d'écran permettent d'épeler les mots à voix haute. 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 HTML éléments emblématiques.

Le HTML5 a introduit de nouveaux éléments qui aident à définir la structure sémantique 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'utilisation d'un style intégré (ce que vous devriez faire quand même avec CSS).

Les éléments de structure sémantique remplacent plusieurs blocs div répétitifs. offrent une manière plus claire et plus descriptive d'exprimer la structure de la page de manière intuitive ; pour les auteurs et les lecteurs.