Accessibilité Web pour les développeurs: meilleures pratiques de codage

La définition formelle de la sémantique des éléments HTML se trouve dans le niveau de vie de HTML

En réalité la vie ce n'est pas si simple, bien sûr. Cela nous amène aux sections suivantes.

Suivez la spécification

Comme pour toute technologie fondamentale, Internet dispose de plusieurs organismes de normalisation. Le Consortium World Wide Web (W3C) en fait partie, et la Web Accessibility Initiative (WAI) en fait partie. En tant que développeurs, nous devons suivre les Directives pour l'accessibilité aux contenus Web (WCAG) développées par WAI, qui constituent la norme générale en matière d'accessibilité du Web.

Les pratiques de conception que j'ai décrites dans Partie II lors de l'examen des différents types d'incapacités sont décrits plus en détail dans WCAG. Il est important de noter que WCAG est un niveau de vie qui est activement amélioré. La version la plus récente au moment de la rédaction est la version 2.1.

WAI a développé Initiative d'accessibilité du Web – Suite d'applications Internet riche accessible (WAI-ARIA) – la norme technique pour la rédaction de notre code. En tant que développeurs, nous devons suivre cette spécification pour que les lecteurs d'écran fonctionnent correctement.

Par souci de concision, dans les paragraphes suivants, je ferai référence à WCAG et WAI-ARIA en tant que «spécification».

Test automatisé

une variété de scanners capables d'effectuer automatiquement des vérifications couvrant bon nombre des règles de conformité que nous devons respecter. Par exemple, la plupart des logiciels d'automatisation peuvent facilement rechercher des attributs et des éléments manquants, vérifier les contrastes de couleurs ou valider le code HTML. Une bonne pratique consiste à effectuer au moins une analyse trimestrielle de votre site. Et si vous êtes vraiment dédié, vous pouvez inclure cette étape dans votre processus CI et CD. Voici une liste de scanners de bonne qualité, sans ordre particulier:

Test manuel

Malheureusement, l'automatisation ne peut prendre qu'une petite partie de la situation globale. Si vous souhaitez obtenir des résultats significatifs, vous devez tester manuellement votre site. Le moyen le plus pratique d'effectuer un tel test consiste à fermer les yeux et à n'utiliser qu'un clavier et un lecteur d'écran pour effectuer diverses tâches sur le site Web que vous consultez.

C'est à ce moment-là que j'ai découvert à quel point l'accessibilité est difficile.

Navigation

Les yeux fermés, vous ne pouvez pas utiliser de souris. La navigation au clavier dans le noir est beaucoup plus difficile qu'avec une saisie visuelle. Beaucoup de vos solutions risquent de ne pas fonctionner aussi bien que vous l'espériez une fois que vous cessez de voir l'écran. Vous découvrirez probablement des scénarios que vous n'avez pas pris en compte. En résumé, il est très difficile d’offrir une bonne navigation sur le clavier.

Complexité auditive

Le marché des lecteurs à écran multiple est généralement très difficile à comprendre. Vous pouvez avoir du mal à comprendre ce que vous entendez. La raison en est que les lecteurs d'écran ne lisent pas simplement l'écran en utilisant la synthèse vocale. Leur tâche est plus ardue: ils doivent décrire l'interface utilisateur de manière suffisamment détaillée pour que vous compreniez sa structure. Les lecteurs d'écran ne sont bien compris que lorsque vous leur fournissez des constructions simples dans des scénarios simples. Vous devez donc travailler très dur pour simplifier l'architecture de l'information de votre site.

Incohérences

Chaque lecteur d'écran a sa propre interprétation subtile des spécifications et se comporte légèrement différemment selon les navigateurs. Vous rencontrerez de nombreuses zones grises où le respect des spécifications ne suffit pas pour que tous les lecteurs d'écran fournissent des résultats significatifs. Dans ces cas, votre implémentation doit faire un compromis qui fonctionne bien dans la plupart des combinaisons de lecteurs et de navigateurs.

Dans notre pratique, nous avons découvert quelques combinaisons qui fonctionnent bien à des fins de test:

Jaws

Jaws est l'un des lecteurs d'écran les plus anciens du marché. Cela signifie que c'est l'un des plus populaires. Il compte de nombreux utilisateurs, vous devez donc le prendre en charge. Mais son âge signifie également que Jaws doit prendre en charge de nombreux cas d'utilisation hérités. En conséquence, il est souvent peu conforme aux spécifications et difficile à utiliser. Dans notre pratique, nous avons constaté que Jaws fonctionnait mieux avec IE.

ChromeVox

ChromeVox est le dernier lecteur en date (à la date de rédaction de cet article) et, par conséquent, parfaitement conforme aux spécifications. . Son jeune âge signifie qu'il n'est toujours pas très populaire. Cela fonctionne mieux sur Chrome.

NVDA

NVDA est un autre nouveau lecteur respectant les spécifications. Il est très populaire et fonctionne mieux sur Firefox.

Conclusion sur le test manuel

Lorsqu'un lecteur fonctionne bien sur un navigateur en particulier, vous êtes certain que ses utilisateurs l'utiliseront principalement sur ce navigateur, bien qu'il n'existe aucun les règles et les scénarios possibles sont nombreux. Cependant, étant donné que nous travaillons généralement avec des ressources limitées, une bonne pratique consiste à se concentrer uniquement sur les combinaisons populaires décrites ci-dessus et à effectuer des tests souvent, au lieu de couvrir toutes les combinaisons possibles de lecteurs et de navigateurs, mais en le faisant moins souvent.

Déclarations avec données, voici un lien vers une enquête réputée sur les utilisateurs de lecteurs d’écran qui met en lumière l’adoption des lecteurs d’écran par les utilisateurs.

Le test par une tierce partie est le dernier

Il est conseillé de tester avec des personnes. avec des handicaps ou obtenir des commentaires d'accessibilité des clients. La meilleure pratique consiste à ne le faire qu'après avoir terminé vos devoirs avec des tests manuels et automatisés internes. Il est de notre responsabilité de nous assurer d’abord que leur expérience utilisateur n’est pas complètement brisée. Ce n’est qu’alors que vous pourrez obtenir un retour significatif de vos utilisateurs.

Conclusion

Il est difficile de développer pour l'accessibilité. Cela peut souvent donner l'impression d'essais et d'erreurs sans solution claire et universellement acceptée. Nous, membres de l'équipe de KendoReact comprenons la complexité de la situation. C'est pourquoi nous avons créé cette série de blogs. D'une certaine manière, nous sommes limités par la technologie disponible – même si en tant qu'ingénieurs, nous avons toujours travaillé avec des limites. Le logiciel n'a jamais été et ne sera jamais parfait. Tirer le meilleur parti des ressources disponibles est la marque d'un maître artisan.

Toute la série

• Partie 1: Introduction – Un article d'introduction sur l'accessibilité Web qui tente de déterminer en quoi consiste l'accessibilité et pourquoi. c'est important.
• Partie 2: Types d'incapacités et pratiques optimales d'adaptation pour eux . Ici, nous définissons plus précisément le problème en le décomposant en sections sur différents types de handicap, en suggérant des solutions individuelles.
• Partie 4: Davantage de meilleures pratiques et de ressources. Nous passons ici en revue plus de pratiques pour organiser notre flux de travail et explorons plus avant comment rendre cette tâche décourageante facile à gérer. (à venir)