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

Sémantique et navigation dans les contenus

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

Alice Boxhall

Dave Gash

Meggin Kearney

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. Vous pouvez constater que l'écriture d'un code HTML sémantique et expressif vous 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 de prise en charge.

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 comportant de nombreux éléments de commande, 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 que "Le balisage sémantique est utilisé pour désigner les titres".
2.4.1 mentionne la structure des titres comme une technique permettant de contourner les blocs de contenu.
2.4.6 présente quelques détails sur la rédaction de titres 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 dans un wiki, il existe de nombreux liens. Le lecteur peut donc rechercher un terme dans les liens. Cela limite les résultats aux liens qui contiennent réellement le terme, plutôt qu'à toutes les occurrences du terme sur la page.

Cette fonctionnalité n'est utile que si le lecteur d'écran peut trouver les liens et si le texte des liens est pertinent. Par exemple, voici quelques modèles courants qui rendent les liens difficiles à trouver.

Balises d'ancrage sans attributs href Souvent 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.
Bouton implémenté 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.

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, 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. Grâce à cette liste, les lecteurs peuvent rechercher des éléments spécifiques et y accéder directement.

Les lecteurs d'écran commettent souvent des erreurs de prononciation. 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 destiné uniquement 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 de prononcer les mots à voix haute. Laissez donc le lecteur contrôler son expérience et 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 les é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 offrent un moyen plus clair et plus descriptif d'exprimer intuitivement la structure de la page pour les auteurs et les lecteurs.