3 façons dont nous ne prenons pas l'accessibilité au sérieux

Vous avez entendu la blague, non? "Deux développeurs frontaux entrent dans un bar et découvrent qu'ils n'ont absolument rien de commun." Drôle, mais aussi une vérité frustrante reflétant un écart important.

Cet article explore trois perspectives communes sur l'accessibilité Web, mettant en évidence les ponts potentiels entre les utilisateurs et les développeurs / concepteurs. Notre objectif? Pour trouver un terrain d'entente pour un Web plus inclusif.

Acte 1: le dilemme du développeur

"Je ne comprends tout simplement pas comment les développeurs négligent l'accessibilité."

Prenons le point de vue du développeur. La création d'un site Web demande avec succès un vaste ensemble de compétences. Au-delà des principes fondamentaux (HTML, CSS, Aria, JavaScript), les développeurs jonglent avec d'innombrables autres tâches: gestion des packages, contrôle des versions, test (unité, intégration, régression visuelle, compatibilité du navigateur), les avis de code, le déploiement, la sécurité, la conception UX / UI, la conception réactive, la gestion des données ... La liste est sans fin.

C'est impressionnant combien les développeurs savent! Le nombre de personnes capables de créer des sites Web est une infime fraction de la population mondiale - un exploit vraiment remarquable. La satisfaction du code d'expédition avec succès, ce sentiment d'accomplissement, est incroyablement enrichissante.

Imaginez maintenant un expert en accessibilité soulignant les défauts de votre travail, ce qui implique que vous le faites "mal" depuis des années. La dissonance cognitive peut être choquante. Soudain, votre expertise durement gagnée est inadéquate et la prise de conscience que vous avez involontairement exclues les utilisateurs peuvent être profondément troublantes. Les réactions défensives sont compréhensibles.

Il est facile de voir pourquoi un développeur pourrait choisir d'ignorer l'accessibilité - c'est une confrontation douloureuse avec une insuffisance potentielle et la culpabilité des oublis passés.

Acte 2: La frustration de l'utilisateur

"Je me sens complètement invisible."

Les utilisateurs qui comptent sur les technologies d'assistance rencontrent souvent des sites Web inutilisables. Un mauvais contraste de couleur rend le texte illisible. Des éléments interactifs complexes (comme les boutons imbriqués) empêchent les actions de base, telles que le paiement des factures ou les achats en ligne. Les boutons déguisés en Divs deviennent inaccessibles à la navigation au clavier.

Cette frustration s'adresse souvent à ceux qui s'efforcent d'inclusivité, créant une boucle de rétroaction négative. Certains développeurs rejettent les préoccupations comme «impolis», tandis que d'autres luttent avec le fardeau émotionnel du travail d'accessibilité. Les utilisateurs se sentent ignorés, conduisant à un sentiment d'impuissance. Les poursuites deviennent souvent le seul recours, mais même alors, le changement peut être lent. La perception est qu'être vocal et affirmé est le seul moyen d'être entendu.

Acte 3: la contrainte du concepteur

"Je sais que le contraste des couleurs est désactivé, mais il se sent si restrictif de manière créative. Je déteste son apparence."

De nombreux concepteurs considèrent les directives d'accessibilité comme des limites à leur vision artistique. Ils voient une fausse dichotomie: un beau design par rapport à un design accessible.

Mais rappelez-vous: la conception Web n'est pas uniquement l'expression de soi; Il s'agit de créer des expériences utilisables pour tout le monde. Le défi est de trouver des conceptions à la fois esthétiquement agréables et entièrement accessibles. Ce n'est pas une situation non plus / ou une situation; Il s'agit de trouver des solutions innovantes qui répondent aux deux critères.

Recadrer la conversation

Les problèmes s'étendent au-delà de ces trois perspectives. Les chefs de projet hiérarchisent la livraison des fonctionnalités, certains développeurs expriment des attitudes dédaigneuses et d'autres attendent les mandats de navigateur avant de traiter l'accessibilité.

La solution? Nous devons intégrer l'éducation à l'accessibilité aux premiers stades de la formation des développeurs et des concepteurs. Pensez-y comme apprendre une langue étrangère - la connaissance de l'argot unique limite la communication. De même, les approches centrées sur JavaScript négligent souvent les caractéristiques de l'accessibilité inhérente du HTML.

Nous devons nous assurer que toutes les documents comprennent des exemples de code accessibles, les conceptions ont des annotations d'accessibilité et les conférences hiérarchisent les discussions d'accessibilité. Nos outils doivent être intrinsèquement accessibles. Ceci est la nouvelle norme minimale.

Qu'en est-il du code et des ressources existants? Nous ne pouvons pas nous attarder sur les erreurs passées, mais nous pouvons avancer avec compassion et curiosité. Nous sommes capables d'apprendre et d'améliorer. Nous avons déjà surmonté des obstacles techniques difficiles auparavant; L'accessibilité est un autre défi que nous pouvons requérir.

Étapes exploitables:

Auto-amélioration compatissante:

1. Suivez les personnes handicapées sur les médias sociaux pour apprendre de leurs expériences. Écoutez, apprenez et évitez les réponses argumentatives.
2. Mettez à jour vos connaissances. Prioriser le développement HTML-First, puis ajouter les fonctionnalités JavaScript. Suivre des cours axés sur l'accessibilité.
3. Utilisez un lecteur d'écran pour comprendre ses fonctionnalités et ses limites. Explorez les modes de texte uniquement, les paramètres vocaux, la navigation par en-têtes et les raccourcis clavier.

Bonus: contribuer aux projets d'outillage d'accessibilité.

Amélioration incrémentielle du code:

Traiter les bloqueurs d'accessibilité critiques:

1. Évitez les éléments interactifs imbriqués.
2. Assurez-vous que tous les champs d'entrée ont des étiquettes claires et associées.
3. Empêcher les pièges à clavier.
4. Fournir un texte Alt significatif pour toutes les images.
5. Supprimer les liens cassés ou inutiles.

Utilisez une liste de contrôle comme le projet A11Y comme point de départ.

Commencez aujourd'hui. Commencez où vous êtes. Le voyage vers un Web plus inclusif commence par une seule étape.

Photo d'en-tête en vedette de Scott Rodgerson sur unclash

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!