Écouter le Web, première partie : Penser l'accessibilité

Listening to the Web, Part One: Thinking in Accessibility

"Nous avons quelques inquiétudes quant à la façon dont certains contrôles de formulaire sont conçus. Ils devront être entièrement personnalisés afin de les rendre accessibles au clavier et correspondre à la conception. Cela signifie que plus de temps sera consacré à coder et à s'assurer qu'ils sont utilisable. Cela signifie également un temps de chargement légèrement plus long."

"Oui, d'accord, ça va. Fais juste en sorte que ça marche."

"Nous voulions également soulever des problèmes que nous avons rencontrés avec le contraste des couleurs du texte principal. Dans l'état actuel des choses, il sera difficile à lire pour certaines personnes qui pourraient avoir une basse vision…"

"Écoutez, nous ne nous soucions pas de l'accessibilité. Nous voulons juste que le site ressemble à ce qu'il a été conçu. Passons à autre chose."

Il s'agissait d'une conversation réelle, légèrement paraphrasée, que j'ai entendue entre mon agence de l'époque et une entreprise de design. J'étais terrassé.

On s'en fout ?

Pourquoi ne vous souciez-vous pas de vous assurer que quelque chose est utilisable par les gens ? Pourquoi concevoir quoi que ce soit ? Les gens ne sont-ils pas la raison pour laquelle nous faisons ce que nous faisons ?

Avant le lancement de ce projet, nous avons fait tout ce que nous pouvions. Le site était en grande partie utilisable, mais de nombreux problèmes subsistaient, dont le moindre n'était pas que cette approche ne démontrait pas une pensée inclusive.

J'ai réalisé à ce moment-là qu'aucun savoir-faire technique ne pouvait convaincre les gens de la nécessité d'assurer une expérience utilisateur accessible. Comme la plupart des choses, la création de sites Web accessibles est un processus qui commence par un changement de mentalité.

Aperçu

J'ai écrit cette série d'articles dans le but d'initier les lecteurs, et en particulier les développeurs, aux bases du travail dans l'accessibilité. C'est un souvenir de mon expérience personnelle au cours des dernières années, d'apprentissage et de croissance en tant que développeur avec l'accessibilité au premier plan de mon esprit.

Nous allons commencer par le tout début : penser à l'accessibilité. Les développeurs pensent souvent aux lecteurs d'écran lorsqu'ils pensent à l'accessibilité, alors explorons ce domaine. Nous verrons qui utilise les lecteurs d'écran, pourquoi et comment. Ensuite, nous retrousserons nos manches et nous nous mettrons au travail.

Nous examinerons le HTML sémantique , les aspects des éléments et comment choisir des éléments accessibles qui fournissent une sémantique appropriée. Nous allons plonger dans la façon dont les gens utilisent les lecteurs d'écran , les commandes que chaque développeur devrait connaître, et nous conclurons l'affaire en examinant les problèmes et les correctifs sur un site de démonstration.

Plus important encore, j'espère qu'après avoir lu ceci, vous verrez comment les compétences techniques ne sont pas la fin mais le moyen de servir une vision plus large : celle de la sensibilisation, de l'inclusivité et de l'empathie.

La pleine conscience est la clé

Considérez ceci : lorsque vous conduisez une voiture, il est crucial de faire attention à votre environnement. Pour être un bon conducteur, vous devez tenir compte des autres conducteurs, des cyclistes, des panneaux de signalisation et des piétons. Sans cette considération pour les autres, vous risquez d'avoir des ennuis assez rapidement.

Dans le même ordre d'idées, en tant que concepteurs et développeurs, vous contribuez à assurer une expérience utilisateur positive pour tous lorsque vous êtes attentif aux personnes et aux différentes façons dont elles utilisent et interagissent avec votre site Web.

Lors de la conception, si vous considérez quelqu'un dans une région éloignée du monde avec une faible vitesse de connexion, vous vous assurerez que le site et tous ses actifs se chargeront rapidement et fonctionneront de manière optimale. Si vous considérez quelqu'un faire des recherches et apprendre sur un sujet à l'aide d'un appareil portable, vous serez sûr de concevoir une interface utilisateur qui prend en charge une large gamme de tailles et d'orientations d'écran d'appareil. Si vous considérez quelqu'un qui est aveugle, malentendant ou qui a de la difficulté à comprendre le texte écrit sur une page, vous allez coder et structurer le contenu d'une manière qui aidera à transmettre un sens et un but aux personnes qui utilisent et dépendent de la technologie d'assistance. pour découvrir le Web.

Ce qui se passe réellement, c'est que lorsque vous commencez à penser et à développer pour les personnes handicapées, vous finissez par améliorer la convivialité d'un site pour tout le monde (par exemple, les personnes utilisant des navigateurs obsolètes ou des appareils portables plus anciens).

Tenir compte des capacités des personnes et faire preuve d'empathie et de compassion vous aide à piloter votre workflow de développement et vos meilleures pratiques d'une manière qui profite à tous.

Qui écoute ?

Un après-midi, alors que je montais dans un bus public, j'ai remarqué un monsieur de l'autre côté de l'allée, tenant son téléphone à deux mains d'une manière particulière. Avec sa main gauche, le téléphone était tenu avec l'extrémité du haut-parleur pressée fermement contre son oreille. Sa main droite balayait fiévreusement et gesticulait des commandes dans l'appareil, se déplaçant si rapidement que je ne pouvais pas comprendre comment il était capable de donner un sens à tout cela. Peu de temps après, j'ai réalisé qu'il utilisait le logiciel de lecture d'écran intégré à son téléphone pour trouver et écouter le contenu du site Web ou de l'application. Être témoin de cela a été une révélation pour moi. L'expérience m'a montré comment certaines personnes consomment du contenu et à quel point il est important que les interfaces frontales soient bien équipées pour gérer divers types d'interactions utilisateur.

Dans un rapport de 2014 , la National Health Interview Survey (NHIS) a estimé que 22,5 millions d'Américains adultes « ont du mal » à voir, même lorsqu'ils portent des lunettes, ou sont incapables de voir du tout. Cela représente près de 10 % de la population, et un nombre important de ces personnes peuvent compter sur des dispositifs et des technologies d'assistance, certains utilisant des lecteurs d'écran, pour lire et naviguer sur le Web.

Les personnes qui utilisent un lecteur d'écran peuvent entendre ce qui s'affiche à l'écran grâce à une voix numérique lisant à haute voix le contenu et les éléments interactifs de la page. Il existe plusieurs types de personnes qui dépendent de la technologie des lecteurs d'écran, y compris celles qui ont une basse vision ou qui sont légalement aveugles. Certaines personnes ont des difficultés à lire un texte, tandis que d'autres ont besoin de lire le texte à haute voix pendant qu'elles font autre chose. Certaines personnes veulent juste écouter un long article de blog pendant qu'elles préparent le dîner ! En d'autres termes, les lecteurs d'écran ne sont pas uniquement utilisés par les personnes ayant des limitations visuelles.

Si l'on considère qu'au moins 10 % de la population bénéficierait de la technologie des lecteurs d'écran, le temps nécessaire pour apprendre et travailler avec un lecteur d'écran n'est pas du tout une perte. Cette connaissance fera de vous un atout majeur pour toute équipe de développement !

Intégrez l'accessibilité dès le départ

Lorsque j'ai commencé ma phase de planification de la façon dont je baliserais un nouveau design en tenant compte de l'accessibilité, toute ma vision du développement a changé. Je me suis assuré d'utiliser des commandes de navigateur natives et des en-têtes ordonnés logiquement, des couleurs qui passeraient les tests de contraste et un JavaScript discret qui a aidé à gérer le focus du clavier pour les interactions complexes.

HTML

Pendant les premiers jours d'un nouveau projet, après avoir étudié les fichiers de conception, pris des notes mentales sur ce qui avait du sens pour être des modules reproductibles et discuté avec les concepteurs, j'écrivais du HTML. Juste du HTML simple et clair sans cloches ni sifflets. Cela m'a fourni un endroit où je pouvais commencer à tester avec un lecteur d'écran pour des problèmes de base de bas niveau, des choses que je pouvais surveiller et corriger immédiatement. Je me suis assuré que tout avait la bonne sémantique et le bon contexte pour ce que les éléments étaient censés être.

CSS

Avec la structure HTML en place écrite sous forme de modules réutilisables d'un plus grand système de conception, j'irais et commencerais à ajouter des classes et à écrire le CSS afin de correspondre à la conception prévue. Lorsque les styles étaient ajoutés à un module, j'entrais à nouveau et testais les problèmes d'accessibilité. Je garderais un œil sur tous les éléments avec une propriété d'affichage, en prenant note pour m'assurer que les éléments visibles (ou non visibles) refléteraient cet état lors de l'interaction avec un lecteur d'écran. Je surveillerais également le positionnement des éléments. Les choses peuvent devenir incontrôlables assez rapidement, j'avais donc besoin d'être certain que l'ordre visuel du contenu correspondait à l'ordre qui serait trouvé lors de l'utilisation d'un lecteur d'écran. Ainsi, tout le monde obtiendrait le même ordre de lecture du contenu et éviterait toute possibilité de confusion.

Javascript

Cela peut surprendre certains lecteurs, comme moi-même lorsque j'ai commencé à apprendre le développement de l'accessibilité, que JavaScript joue un rôle important dans l'écriture d'interfaces accessibles. Cela est particulièrement vrai lors de la création de widgets dynamiques tels que des accordéons ou des fenêtres modales, ou peut-être de la mise en œuvre d'un menu de navigation caché pour les appareils à petit écran. En utilisant JavaScript, nous pouvons créer et injecter dynamiquement des éléments supplémentaires et ajouter les attributs requis pour transmettre davantage le sens et le but de nos interfaces utilisateur plus complexes. JavaScript est également utilisé pour gérer le focus du clavier pour tous les widgets personnalisés ou les interactions complexes.

Nous approfondirons un peu plus ces concepts dans la prochaine partie de la série, mais pour l'instant, le principal point à retenir est que nous devons garder les gens à l'esprit et tester les problèmes d'accessibilité à chaque étape du processus de développement. N'oublions pas que ce que nous faisons est pour les gens, pas pour d'autres designers ou développeurs. Dans la plupart des cas, même pas pour nous-mêmes.

Intégrez l'accessibilité dans chaque itération de développement. Testez tôt et souvent. Soyez attentif à votre public. En ajoutant ces petites étapes supplémentaires à votre flux de travail, vous vous assurerez que l'accessibilité est prête et disponible dès le départ.

Retour au blog