Meilleures pratiques d'accessibilité à l'échelle mondiale
Vous pensez peut-être que les meilleures pratiques d'accessibilité se concentrent sur les éléments de page à l'intérieur de l'élément body . Bien que cela soit vrai, il y a quelques autres points d'intérêt qui se trouvent ailleurs, à savoir l'élément head .
Passons en revue quelques problèmes de page globaux à surveiller lors des tests d'accessibilité.
Langue de la page
Parfois, il peut être difficile de comprendre le mot prononcé par quelqu'un d'une autre partie du monde en raison des accents ou des inflexions locales. Il en va de même lorsque nous servons un contenu écrit dans une langue différente de celle de l'utilisateur final qui s'appuie sur la voix pour annoncer ledit contenu.
Afin de s'assurer que la technologie d'assistance est capable de prononcer le contenu avec l'accent et l'inflexion appropriés, la langue du contenu du document HTML doit être définie. Cela se fait en ajoutant l'attribut lang à l'élément html , qui est généralement le deuxième élément d'un document après la déclaration doctype.
<html class="..." lang="en"> <!-- ... --> </html> Avec l'attribut lang défini avec le code de langue approprié, le contenu sera lu à haute voix avec l'accent localisé approprié.
Autre contenu internationalisé dans le contenu
Dans le cas où le contenu est écrit dans une langue autre que la langue principale, vous pouvez utiliser le même modèle pour produire l'accent correct par la technologie d'assistance.
Par exemple, si vous aviez une fonctionnalité de basculement de langue, un lien pour "English" et un autre pour "Français", vous devrez envelopper le lien de basculement pour la langue non locale de la page actuelle avec l'attribut lang . Ou, définir l'attribut lang directement sur le lien fonctionnerait également.
<a href="/fr" lang="fr">Français</a>
L'accessibilité c'est aussi l'internationalisation
Critères de réussite WCAG
Cela revient à 3.1.1 Langue de la page qui stipule :
"Le langage humain par défaut de chaque page Web peut être déterminé par programmation."
Balise méta de la fenêtre d'affichage
Dans le passé, si une personne malvoyante avait besoin d'agrandir la fenêtre de son navigateur mobile ou de bureau afin de lire plus clairement le contenu, cela se traduirait traditionnellement par une mauvaise expérience de défilement en 2 dimensions ; avoir à faire défiler horizontalement ainsi que verticalement afin de consommer le contenu.
Le défilement 2D n'est pas seulement un irritant pour la plupart des gens, il introduit également un nouveau niveau de difficulté pour toute personne ayant une déficience motrice ou quelqu'un qui se fie uniquement au clavier pour naviguer ; cela nécessite de passer de l'utilisation de la Tab / Space pour lire le contenu verticalement, aux touches fléchées pour lire horizontalement, et vice-versa.
De nos jours, lorsque quelqu'un zoome sur son navigateur pour agrandir le contenu, les règles de mise en page et de style définies dans les requêtes média CSS se chargent à mesure que le niveau de zoom augmente. En d'autres termes, lorsque le contenu est zoomé, la personne de l'autre côté de l'écran découvrira la mise en page "mobile" éliminant le besoin de défilement horizontal, ce qui se traduit par une expérience utilisateur positive. Cela est dû en partie à l'inclusion de la balise meta viewport :
<meta name="viewport" content="width=device-width, initial-scale=1" />
Cela indique au navigateur de définir la largeur du contenu sur la largeur de l'appareil lui-même et de redimensionner ce contenu à 1 lors du chargement.
Si la mise en page du site a été développée avec les meilleures pratiques de conception réactive, cela suffirait à supprimer tout défilement 2D pour qu'un utilisateur de zoom puisse consommer confortablement le contenu.
Empêcher le zoom
Il est possible d'empêcher le zoom de la fenêtre d'affichage à l'aide de cette balise meta. C'est le contraire de créer une expérience accessible. Évitez d'utiliser les attributs suivants :
-
maximum-scale=1.0; -
user-scalable=no;
Critères de réussite WCAG
Cela revient à 1.3.3 Caractéristiques sensorielles qui stipule :
"Le contenu peut être présenté sans perte d'informations ou de fonctionnalités, et sans nécessiter de défilement en deux dimensions."
Validateur HTML
Un code HTML valide est essentiel pour tout site Web ou application solide et de qualité. Il représente l'expérience de base de vos utilisateurs et la façon dont les navigateurs, ainsi que la technologie d'assistance, liront et interpréteront votre contenu. Cela permet également de générer une expérience utilisateur cohérente sur tous les appareils.
Assurez-vous de tester le balisage généré par votre site Web ou votre application Web via le vérificateur W3 Nu HTML pour vous assurer que les meilleures pratiques sont utilisées.
Critères de réussite WCAG
Cela revient à 4.1.1 Parsing qui stipule :
"Dans le contenu implémenté à l'aide de langages de balisage, les éléments ont des balises de début et de fin complètes, les éléments sont imbriqués selon leurs spécifications, les éléments ne contiennent pas d'attributs en double et tous les identifiants sont uniques, sauf lorsque les spécifications autorisent ces fonctionnalités."
Attribut de titre
L'attribut title est un attribut HTML global qui fournit une "info-bulle" comme du texte lorsque l'élément appliqué est survolé à l'aide de la souris. Cela peut sembler être une méthode pratique pour ajouter un contexte supplémentaire, mais en réalité, cela peut créer quelques problèmes d'accessibilité :
- Le texte du
titlen'est disponible que par survol de la souris, laissant de côté les utilisateurs voyants au clavier ou à la dictée vocale. - Le texte affiché au survol peut interférer avec la lecture d'autres textes à proximité pour les personnes malvoyantes qui ont besoin d'un logiciel de zoom
- Les lecteurs d'écran peuvent annoncer le nom accessible (la partie visible ou le texte) de l'élément en plus du texte du
title, créant une expérience redondante ou trop verbeuse - Selon la configuration, les lecteurs d'écran peuvent ignorer complètement le contenu de l'attribut de
title
La recommandation générale est d' éviter d'utiliser complètement l'attribut title . Si vous avez besoin d'une info-bulle pour une interface utilisateur spécifique, considérez ce qui suit :
- Définissez le contenu potentiel de l'info-bulle en texte brut entre parenthèses
- Ajustez l'interface utilisateur afin d'éviter d'avoir besoin d'une info-bulle
- Créer une info-bulle personnalisée et accessible
Une exception
Une exception à cela est lorsqu'il s'agit de fournir une description pour les éléments iframe . Les lecteurs d'écran doivent donner un contexte à l'utilisateur sur ce à quoi sert l' iframe et l'un des moyens les plus simples d'y parvenir est d'inclure un attribut de title . Il n'a pas besoin d'être quelque chose d'extraordinaire, juste un "avertissement" sur le contenu de l' iframe .
La raison pour laquelle il s'agit d'une exigence est de par sa nature même, les éléments iframe représentent du contenu tiers intégré à la page. Par conséquent, les lecteurs d'écran doivent "intervenir" dans le cadre avant que son contenu puisse être découvert.
Par exemple, pour saisir une iframe avec VoiceOver, l'utilisateur rencontrera d'abord l' iframe via le curseur virtuel ( Ctrl + Opt et flèche Right ), puis devra appuyer sur Ctrl + Opt + Shift et flèche Down .