Accessibilité Web : pourquoi les normes du W3C sont souvent ignorées

Publié: 2022-03-11

Le terme du jour est l'accessibilité du Web - à mon avis, l'un des aspects les plus souvent mal compris et mal appliqués de la conception Web. L' idée fausse commune est que l'accessibilité est conçue uniquement pour les personnes handicapées. En effet, tout le monde bénéficie de contenus accessibles , et votre audience augmentera en accédant à des contenus accessibles sur différentes plateformes ou de différentes manières, car ils pourront utiliser vos contenus avec moins de contraintes.

Malheureusement, de nombreux développeurs Web ne rendent pas leur contenu accessible et ne suivent pas les directives d'accessibilité Web. ainsi, de nombreuses personnes éprouvent des difficultés inutiles à utiliser leurs conceptions et à profiter du contenu. Dans des cas extrêmes, certains groupes d'utilisateurs ne peuvent pas du tout utiliser efficacement un tel site Web.

La création de contenu accessible devrait être une seconde nature pour tout développeur, concepteur ou créateur de contenu, de la même manière que la prise en compte des rampes, des escaliers et des ascenseurs l'est pour un architecte qui conçoit un nouveau bâtiment.

Examinons de plus près ce qui se cache dans les coulisses et pourquoi tant de développeurs semblent ignorer les normes d'accessibilité Web sans raison valable.

1. Que signifie « conception accessible » ?

Un contenu accessible est un contenu que tout le monde peut utiliser . Nous ne connaissons pas tous les aspects de la façon dont les utilisateurs accèdent à notre contenu, nous devons donc concevoir en pensant à l'accessibilité à l'avance.

Comme je l'ai souligné plus tôt, cela ne concerne pas les personnes handicapées, qui représentent environ 15 % de la population mondiale. Dans la vraie vie, les utilisateurs finissent souvent par ne pas consommer de contenu et interagir avec les appareils exactement de la même manière que prévu lors du développement. Un contenu accessible est également requis pour des raisons juridiques dans de nombreuses juridictions. Lisez « Facteurs juridiques et politiques dans le développement d'une analyse de rentabilisation de l'accessibilité Web pour votre organisation » pour plus d'informations sur la conformité en matière d'accessibilité.

Envisagez les scénarios suivants tout en pensant au contenu accessible pour les utilisateurs qui peuvent être :

Impossible de bien entendre. 360 millions de personnes dans le monde souffrent d'un handicap auditif. Le contenu audio doit avoir des transcriptions et la vidéo doit avoir des sous-titres.
Impossible de bien voir. On estime que 285 millions de personnes sont malvoyantes dans le monde : 39 millions sont aveugles et 246 ont une basse vision. Les utilisateurs malvoyants utilisent des lecteurs d'écran (qui lisent le contenu à l'aide de la synthèse vocale), des écrans braille actualisables (le contenu de l'écran apparaît sur l'écran braille et l'utilisateur peut naviguer et interagir avec son appareil à l'aide des touches de l'écran) ou -mode contraste.
Affecté par la dyslexie. Les personnes atteintes de dyslexie éprouvent des difficultés à lire et à comprendre le contenu, en particulier, par exemple, le texte justifié ou tout en majuscules.
Souffrant de limitations physiques. Tout le monde ne peut pas utiliser tous les appareils. Par exemple, la navigation dans le contenu doit être disponible non seulement pour les utilisateurs de souris, mais également pour les utilisateurs qui ne peuvent pas utiliser de souris.
Utilisation d'appareils mobiles. Adaptez votre contenu aux petits écrans. Permet à l'utilisateur de zoomer ou d'augmenter la taille de la police.

2. Comment assurer une bonne accessibilité Web

Les gens utilisent des façons très différentes de naviguer et de consommer du contenu. Certains utilisateurs ont besoin d'être pris en charge par des outils logiciels supplémentaires qui les aident à accéder plus facilement au contenu. Ces outils, connus sous le nom de technologies d'assistance, vont des lecteurs d'écran aux écrans tactiles et aux pointeurs de tête.

Cependant, votre application et la technologie d'assistance doivent communiquer entre elles. Tout ce qui est écrit en HTML n'est pas entièrement compréhensible pour les technologies d'assistance. Afin d'aider à "traduire" le contenu d'un "langage technique" vers un langage plus lisible par l'homme, des normes d'API d'accessibilité supplémentaires ont été créées.

Ce schéma d'accessibilité Web de base devrait vous donner une meilleure idée du fonctionnement des technologies d'assistance.

Pour illustrer son fonctionnement, regardons un exemple de code simple :

 <a href="#” class=”button”>Delete</a>

Ce code simple, pour les personnes qui utilisent le lecteur d'écran, ne signifie pas grand-chose. Il est même trompeur et ne se lit que comme un lien avec le texte " Supprimer ". Afin d'aider les utilisateurs à comprendre quel type de méthode est utilisé pour effectuer l'action, nous pouvons utiliser les attributs ARIA (Assistive Rich Internet Applications) (spécifiés à https://www.w3.org/TR/wai-aria/) pour remplacer le rôle d'origine. Nous modifions la signification d'un lien vers un bouton en ajoutant l'attribut role="button" . De cette façon, les lecteurs d'écran le liront comme un bouton et non comme un lien. Ce qui est plus approprié.

En bref, attribuez ARIA :

Donne ou améliore la sémantique des éléments non sémantiques ou autres sémantiques,
Garantit que le contenu dynamique (en direct) est toujours accessible.
Fournit le rôle pour décrire le type de widget défini (menu, élément d'arborescence, curseur, indicateur de progression, etc.).
Fournit le rôle pour décrire la structure de la page Web (en-têtes, régions et tableaux).
Fournit l'état des widgets (coché, a un popup, etc.).
Fournit des propriétés pour le glisser-déposer qui décrivent les sources de glisser et les cibles de dépôt.

Qu'est-ce que l'accessibilité dans la conception Web ?

Chaque fois que vous concevez un contenu, pensez à deux choses : comment le contenu est perceptible et comment il est exploitable . Examinons quelques exemples pour illustrer l'accessibilité dans la conception Web.

Disons que vous allez concevoir un élément déroulant de sélection personnalisé. Voici les éléments à prendre en compte lors de la conception de l'élément :

Marquez différents états : activé, désactivé, en lecture seule.
Marquez l'élément lorsqu'il obtient l'état focus/survol.
Marquez chaque élément d'option lorsqu'il obtient l'état focus/survol.
Assurez-vous que le contenu est toujours lisible lorsque seul le texte est agrandi jusqu'à 200 %.
Assurez-vous qu'il y a suffisamment de contraste entre le texte et son arrière-plan. Il aide les personnes ayant une vision moyennement basse ou sur des appareils dans des conditions d'éclairage extrêmes, par exemple, exposés à la lumière directe du soleil ou sur un écran à faible luminosité, à lire le contenu.

Un autre exemple pourrait être la sélection d'une couleur pour décrire un état. Voici les éléments à prendre en compte lors de la conception d'une section où l'utilisateur pourra choisir une couleur :

Il y a des gens qui ont du mal à distinguer certaines couleurs. Donc vert ne veut pas dire vert pour tous vos visiteurs. Pour résoudre ce problème, ajoutez une description pour chaque couleur décrivant l'objectif.
Marquez chaque élément lorsqu'il obtient l'état focus/survol.
Assurez-vous qu'il y a suffisamment d'espace entre les éléments pour que chaque élément puisse être facilement activé, par exemple, sur les appareils avec une fenêtre d'affichage plus petite.

3. Test d'accessibilité : par où commencer ?

Il n'y a pas qu'un seul moyen de vérifier et de s'assurer que le contenu Web est entièrement accessible. Plusieurs techniques doivent être utilisées afin de vérifier et de résoudre les problèmes d'accessibilité. Vous pouvez commencer par définir les problèmes , les solutions et les priorités .

Définir les problèmes

Lorsque vous travaillez sur des problèmes d'accessibilité, essayez toujours de créer un ticket par problème avec un titre clair. Cela devrait simplifier la compréhension du problème et aider à définir une priorité.

Mauvais exemple : l'utilisateur ne peut pas utiliser le clavier sur la page.

Bon exemple : Impossible d'utiliser la navigation au clavier dans le menu principal.

Le mauvais exemple conduit à une affaire qui sera assez difficile à clore en peu de temps. Les discussions sur plusieurs sujets peuvent également commencer dans la section des commentaires, car le titre du ticket est trop générique.

Le bon exemple pointe exactement le problème et se concentre uniquement sur une chose : la navigation au clavier dans le menu principal.

Hiérarchiser les problèmes d'accessibilité Web

Les priorités sont importantes car elles définissent quels problèmes doivent être résolus en premier. Par exemple, WCAG est divisé en trois niveaux de conformité : A, AA, AAA, ce qui signifie que vous devez commencer à partir d'un niveau minimum A, mais cela ne signifie pas automatiquement que les niveaux AA et AAA sont simplement " agréables à avoir". Tous les niveaux sont importants, et il est important de ne pas prioriser en supposant que le niveau A seul est suffisant.

Cependant, les niveaux WCAG (ou toute autre directive) peuvent parfois être assez difficiles à comprendre et afin de simplifier un peu, vous pouvez également envisager les définitions de priorité suivantes :

Critique – Problèmes qui empêchent les utilisateurs d'utiliser une application. Aucune solution de contournement disponible.
Majeur – Problèmes qui rendent l'utilisation d'une application difficile et/ou désorientante, mais ne bloquent pas la capacité d'un utilisateur à terminer l'opération.
Mineur - Problèmes ennuyeux mais qui n'entravent pas l'utilisation, ou améliorations qui pourraient être apportées à l'application.
Info – Ne respecte pas les meilleures pratiques. Recommandations générales d'amélioration.

Solutions

Aucune des directives - par lesquelles j'entends WCAG, Section 508 ou ADA - ne vous donnera une solution directe en termes de code technique sur la façon dont un problème spécifique doit être résolu. Ils ne définissent que le comportement attendu. Cependant, WCAG a également défini des procédures de test qui devraient aider à comprendre comment reproduire le problème et il existe un groupe communautaire de surveillance WCAG automatisée, une communauté W3C qui se concentre sur le développement de règles fiables pour les tests d'accessibilité Web, à la fois automatisés et semi-automatisés.

Un exemple pour la technique WCAG G4 ("Autoriser le contenu à être mis en pause et redémarré là où il a été mis en pause") :

Procédure de test

Sur une page avec un contenu mobile ou défilant,

Utilisez le mécanisme fourni dans la page Web ou par l'agent utilisateur pour mettre en pause le contenu en mouvement ou défilant.
Vérifiez que le déplacement ou le défilement s'est arrêté et ne redémarre pas tout seul.
Utilisez le mécanisme fourni pour redémarrer le contenu en mouvement.
Vérifiez que le mouvement ou le défilement a repris à partir du point où il s'était arrêté.

Résultats attendus

Les numéros 2 et 4 sont vrais.

Comme nous pouvons le voir, il n'y a pas de solutions techniques, mais un comportement attendu défini. La façon dont les développeurs Web l'implémentent dépend d'eux.

Directives d'accessibilité Web et normes W3C

Le respect des normes Web de base devrait être votre point de départ :

Le plus courant est le Web Content Accessibility Guidelines connu sous le nom de WCAG. WCAG 2.0 est « une norme technique stable et référençable. Il comporte 12 lignes directrices organisées en 4 principes : perceptible, exploitable, compréhensible et robuste. Pour chaque ligne directrice, il existe des critères de réussite testables, qui se situent à trois niveaux : A, AA et AAA. »
Techniques pour WCAG 2.0 est un guide complet pour les auteurs de contenu Web.
W3C Media Accessibility User Requirements — Ce document présente les exigences d'accessibilité des utilisateurs handicapés en ce qui concerne l'audio et la vidéo sur le Web.
Loi sur l'accessibilité des communications et de la vidéo du XXIe siècle — La CVAA est divisée en deux grands titres ou sections. Le titre I traite de l'accès aux communications pour rendre les produits et services utilisant le haut débit entièrement accessibles aux personnes handicapées. Le titre II de la loi sur l'accessibilité innove pour faciliter le visionnage des programmes vidéo à la télévision et sur Internet par les personnes handicapées.
Section 508 — exigences d'accessibilité pour les technologies de l'information et de la communication (TIC) qui s'appliquent à tous les organismes fédéraux lorsqu'ils développent, achètent, entretiennent ou utilisent des technologies électroniques et de l'information.
Accessibilité du site Web en vertu du titre II de l'Americans with Disabilities Act (ADA) - Vous y apprendrez comment les exigences de non-discrimination du titre II de l'ADA s'appliquent aux sites Web des États et des administrations locales.

Test d'accessibilité Web : comment savoir si mon contenu est accessible ou non ?

Voici des points de contrôle de base qui devraient vous aider à rendre votre contenu Web plus accessible dès la première étape :

Validez votre HTML. Assurez-vous que la structure HTML ne contient pas d'erreurs, car les technologies d'assistance peuvent avoir des problèmes pour interpréter le contenu de la page.
Testez avec un clavier seul. Assurez-vous que tous les éléments actionnables sont accessibles uniquement à l'aide du clavier. En outre, vous devez également pouvoir effectuer toutes les actions à l'aide d'un clavier, par exemple, soumettre un formulaire.
Testez avec des outils de test d'accessibilité et des validateurs. Utilisez des outils qui analysent et vérifient les erreurs d'accessibilité potentielles.
Contenu dynamique. Avertissez les utilisateurs de lecteurs d'écran des changements dynamiques, par exemple lorsque les résultats de la recherche ont changé.
Ne comptez pas sur les couleurs pour décrire le sens. Utilisez la couleur avec la description, par exemple, [boîte jaune] avertissement.
Ne supprimez pas le contour lors de la mise au point. Il s'agit d'une fonctionnalité généralement supprimée à l'aide du outline: 0; Ne faites pas cela, car les utilisateurs du clavier perdront l'orientation sur la page. Vous pouvez envisager de supprimer le contour du focus pour les utilisateurs qui n'utilisent pas le clavier, mais fournissez toujours un contour du focus pour les utilisateurs du clavier.
Messages d'erreur. Indiquez toujours à l'utilisateur comment corriger une erreur. Ne vous contentez pas d'indiquer que les données ne sont pas valides.
Ordre de tabulation. Assurez-vous que la navigation par onglets respecte les conventions établies dans l'interface utilisateur graphique. Au minimum, il doit suivre le sens de lecture de la langue par défaut de l'application. En anglais, par exemple, l'ordre de lecture est de haut en bas, de gauche à droite ; en arabe, c'est de haut en bas, de droite à gauche.
Zoom. Assurez-vous que le contenu de la page est toujours lisible tout en zoomant le texte jusqu'à 200 %.
Désactivez les images. Êtes-vous toujours en mesure d'utiliser la page de manière confortable ? Existe-t-il des textes alternatifs pour toutes les images ?
Lecteur d'écran. Testez pour voir si vous pouvez lire et parcourir le contenu à l'aide d'au moins un lecteur d'écran, par exemple, VoiceOver, Windows Narrator ou NVDA.
Mode contraste élevé. Vérifiez si le contenu est toujours lisible lors du passage en mode contraste élevé.
Taille de police. Assurez-vous que la taille de la police sur la page n'est pas inférieure à 10 pixels.

4. Erreurs courantes dans l'accessibilité du Web

L'erreur la plus courante est de ne pas identifier les exigences d'accessibilité avant le développement . Malheureusement, plus tard l'accessibilité fera partie du développement, plus il sera difficile de mettre en œuvre des solutions.

Voici une liste de certaines des erreurs les plus courantes commises par les développeurs lors de la mise en œuvre de l'accessibilité :

Aucune possibilité de naviguer dans le contenu en utilisant uniquement un clavier .
Utilisation abusive de la propriété CSS outline. Dans la plupart des cas, outline: 0; est utilisé, ce qui signifie que le contour autour de chaque élément actionnable n'est plus visible. Ne pas utiliser le outline: 0; ou outline: 0 !important; . L'utilisateur perdra la possibilité de voir l'élément actuellement ciblé lors de la navigation dans le contenu, à moins qu'il n'y ait une autre alternative à cela, par exemple, en utilisant la propriété CSS border .
Perdre le focus de l'élément actuel, par exemple, en raison de manipulations DOM ou de l'utilisation de la méthode blur() . Cela se produit souvent pour les applications d'une seule page.
Aucune notification pour les utilisateurs de lecteur d'écran que quelque chose a changé, par exemple, le contenu a été téléchargé à l'aide de l'API XMLHttpRequest et de nouvelles modifications sur l'interface utilisateur ont été rendues, mais l'utilisateur n'a pas été averti. Cela se produit souvent avec des applications d'une seule page.
Sélecteur de date inaccessible. Dans de nombreux cas, des sélecteurs de dates inaccessibles sont utilisés. Les utilisateurs ne peuvent pas naviguer dans les options du calendrier à l'aide du clavier.
Utiliser des extensions qui prétendent résoudre automatiquement les problèmes d'accessibilité . Utilisez-les avec précaution et vérifiez les résultats. Leur utilisation abusive peut créer plus de problèmes que de solutions.
Ajout à l'attribut tabindex de l'élément avec un numéro d'index supérieur à 0. Le but de l'utilisation de tabindex avec un index supérieur à 0 est principalement de "corriger" le chemin de navigation. Cependant, pensez plutôt à changer la structure HTML afin d'obtenir le chemin naturel de navigation. Le manipuler à l'aide tabindex peut entraîner des problèmes de maintenance et un chemin de navigation imprévisible.
Mauvaise hiérarchie des titres. Malheureusement, on le voit encore assez souvent, mais la hiérarchie des en-têtes n'est pas correctement construite, par exemple, <h1> , <h5> et <h2> . Les utilisateurs de lecteurs d'écran utilisent des en-têtes pour naviguer dans les sections et une structure inappropriée est déroutante car il est difficile de comprendre le contexte.
Support à contraste élevé manquant. Il y a des gens qui utilisent leur logiciel en mode contraste élevé. Assurez-vous que votre contenu est toujours perceptible.
Utilisation d'une solution CAPTCHA inaccessible. Malheureusement, tous les CAPTCHA que je connais sont soit inaccessibles, soit très difficiles à utiliser.
Animations trop nombreuses et/ou impossibles à mettre en pause. La lecture automatique de vidéos, de publicités ou de carrousels d'images est très gênante.
Gros morceaux de texte. Texte condensé dans un très grand bloc unique, sans espaces, virgules ou points. Très difficile à lire. Le fractionnement en plus petits morceaux, plus de paragraphes et de sous-titres aide à mieux organiser le contenu du texte.
Problèmes de zoom. Assurez-vous que le contenu est toujours lisible et navigable lorsque vous effectuez un zoom jusqu'à 200 %.
Miser sur les couleurs. Très souvent, l'état d'un élément n'est marqué que par une couleur, par exemple, un état d'avertissement n'est marqué que par une puce jaune ; cette couleur n'est pas perçue de la même manière pour les daltoniens.
Petites cibles cliquables/appuyables. Les zones cliquables/appuyables sont souvent trop petites. L'agrandir permet aux utilisateurs de les activer plus facilement.

Mais comment puis-je améliorer l'accessibilité Web ?

Définir les enjeux est une chose. Le réparer en est une autre et très souvent pas aussi simple qu'il n'y paraît. En effet, les implémentations de l'API d'accessibilité ne sont pas cohérentes et nous devons parfois trouver des solutions de contournement ou même accepter le fait que quelque chose ne fonctionnera pas du tout lorsque nous essaierons de résoudre le problème.

En termes d'outils, il n'existe pas d'outil unique capable de vérifier toutes les combinaisons possibles, mais pour commencer, ces outils devraient aider :

Service de validation du balisage W3C - Juste pour être sûr que le contenu HTML ne contient pas d'erreurs. Si la structure HTML contient des erreurs, la sortie est imprévisible et ne peut pas être traitée correctement, en particulier par différentes technologies d'assistance.
https://www.w3.org/WAI/ER/tools/ — Une liste de programmes ou de services en ligne qui vous aident à déterminer si le contenu Web respecte les directives d'accessibilité.
Et mon outil, ASLint https://www.aslint.org/, vous aide à trouver les problèmes d'accessibilité.

Gardez toujours à l'esprit qu'aucun outil d'accessibilité ne peut remplacer les tests manuels , car tous les scénarios ne peuvent pas être entièrement ou pas du tout automatisés, par exemple, vérifier le rapport de contraste de luminance sur les éléments avec position: fixed; .

Concentrez-vous sur les problèmes qui bloquent l'utilisation de votre application, par exemple, l'utilisateur est incapable de naviguer dans le menu à l'aide du clavier.

Pourquoi il est important de rendre le contenu accessible

Tout le monde veut diffuser son contenu le plus largement possible. L'accessibilité aide dans ce domaine, à plusieurs niveaux, allant de l'atteinte d'un public plus large à l'amélioration de l'expérience utilisateur pour tous les utilisateurs. De plus, l'accessibilité n'est pas seulement pour ce que vous pourriez traditionnellement considérer comme des personnes handicapées. Qu'il s'agisse d'une personne qui vieillit et qui subit les changements physiques qui l'accompagnent, d'une personne qui fait du jogging par une journée ensoleillée et qui a besoin d'un réglage automatique du contraste sur son téléphone, ou d'un parent aux mains pleines de sacs à provisions qui souhaite envoyer un SMS par la voix, accessible la technologie est la technologie que tous les utilisateurs peuvent utiliser de temps à autre.

En prime, l'effet positif est que le contenu accessible qui répond pleinement aux normes WCAG 2.0 est plus facile à explorer et à comprendre par les moteurs de recherche, ce qui peut avoir un effet significatif sur le classement d'un site. Ainsi, une conception accessible peut générer du trafic supplémentaire vers le site Web.

Enfin, voici quelques statistiques dont vous devez tenir compte :

Plus d' un milliard de personnes dans le monde souffrent d'un certain type de handicap.
Vieillissement de la population. Entre 2015 et 2030, le nombre de personnes âgées de 60 ans ou plus dans le monde devrait augmenter de 56 %, passant de 901 millions à plus de 1,4 milliard.
La conception universelle est essentielle. La conception universelle fait référence à un large éventail d'idées et de pratiques pour produire des services, des produits et des environnements qui sont intrinsèquement accessibles et utilisables par des personnes de toutes capacités.
Types de handicaps : Il existe cinq grandes catégories de handicaps, notamment les handicaps visuels, moteurs, de la parole, cognitifs et auditifs.

Nous avons tous besoin de services de qualité. Délivrons-les aussi .