Sept erreurs d’accessibilité (1ère partie)
Cet article comporte une deuxième partie qui fait aussi l'objet d'une publication sur Pompage.
Il y a plusieurs raisons à la publication de produits web inaccessibles. Une des raisons, dont nous avons discuté dans mon dernier article, est que certains clients n'ont rien à faire de l'accessibilité. Leurs raisons font sens si vous vous mettez à leur place. Une autre raison est due aux erreurs du développeur. Faire des erreurs est naturel. En supporter les conséquences et apprendre de nos erreurs est ce qui nous rend meilleur développeur et une meilleure personne.
Voici les principales erreurs que j'ai rencontrées durant toutes mes années en tant que développeur web professionnel. Si nous gardons un oeil ouvert sur celles-ci dans le futur, nous créerons certainement, sans beaucoup de mal, des produits web plus accessibles et plus beaux tout en rendant nos clients et nos visiteurs heureux.
J'ai offert à la fin de chaque description des petits trucs pour comprendre comment éviter ces erreurs. Les suivre ne sera pas toujours possible dans les limites de votre budget, ou peut requérir une relation plus mature avec vos clients, mais ça ne coûte rien de les garder en tête. Aucune avancée vers un design réalisé pour l'utilisateur final en gardant en tête les idées du client, n’est une perte de temps.
Les sept erreurs d'accessibilité : 1-3
Erreur #1 : Croire à des produits sans avoir les avoir testé
De nombreux outils d'édition, d'applications et outils de gestion de contenu proclament qu'ils créent des sites compatibles aux standards et compatibles
à la norme d’accessibilité AAA. La plupart ferment tout simplement les balises, mettent en minuscule les éléments générés par les éditeurs WYSIWYG et forcent les attributs alt pour les images. Rien de tout ça n'est une mauvaise idée, mais ça n'est pas suffisant.
Le HTML valide n'est pas nécessairement sémantiquement correct ou logique -- seuls les humains peuvent déterminer cela. Comprenez-moi bien, il y a plein d'outils incroyables ici. Mais ce ne sont juste que des outils, des machines qui ne peuvent comprendre les finalités des interactions humaines. Les machines ne peuvent déterminer si le rendu a du sens, quelque soit leur niveau de sophistication. Au milieu d'un projet vous pourriez bien découvrir que le CMS a une erreur majeure qui était judicieusement cachée dans le site de demo (l'exemple qui me vient en tête est la compatibilité UTF-8 pour les sites internationaux).
Qu'est ce que cela signifie pour le développement ?
- Prévoyez un bon moment pour la formation des développeurs sur le produit (dans le cas d'un IDE (Environnement de Design Intégré), c'est un investissement primordial).
- Evitez les documents erronés et tout ce qui va avec. Faites de ces documents une part obligatoire du projet pour l'équipe de maintenance et les nouveaux membres de l'équipe.
- Forcez les tests utilisateurs dans le processus de déploiement. Cela peut être aussi fait par un éditeur formé s'il n'y a pas assez de temps pour un cycle de test complet .
Erreur #2 : Prendre trop de responsabilités
Soyons honnêtes. Un site web ne restera jamais dans les limites fixées par le plan original. Les sites web ont une tendance à croître de manière organique et ça c'est le truc vraiment cool. Si vous ne voulez pas être l'unique responsable de la réalisation de tous les changements (ce qui est le plus souvent le cas, à moins que vous ayez un client vraiment très confiant ou vraiment très riche, pour vous payer pour votre temps), vous devrez vous assurer que le client connait tous les tenants et les aboutissants du projet.
Vous présenter vous-même au client comme le super héro de l'accessibilité qui combat le crime la nuit dans un costume sexy est le moyen le plus sûr pour échouer. Le problème n'est pas que le client ne vous fasse pas confiance -- ils seront heureux de se débarrasser de cette responsabilité. Le problème est que vous serez impliqué dans les querelles internes de la société et que vous en assumerez toute la responsabilité.
Un scénario typique : Le département marketing arrive avec un texte totalement inaccessible parce qu'il est relié à une image dépendante (probablement issue d'une campagne publicitaire d'un autre médium comme l'impression ou la télé). Le chef de projet vous remet son texte. Vous expliquez les problèmes et il vous dit que c'est vraiment, vraiment ce que le marketing veut et vous demande comment régler le problème. Vous lui expliquez et il oublie le tout ou un petit détail lorsqu'il en parle au département marketing. De sorte que vous vous retrouvez désormais à jouer au téléphone arabe en finissant par passer beaucoup de temps à répéter ce que vous avez dit auparavant sans pouvoir avancer.
Les faits :
- Le client veut un produit web.
- Le client veut des clients, des lecteurs, des auditeurs ou visiteurs, heureux.
- Le client peut très facilement tout changer pour des raisons très variées.
La solution logique est d’attirer le plutôt possible l’attention du client sur les accrocs d'accessibilité, et de se mettre d'accord pour rester dans les limites (qui ne sont pas aussi strictes que ça) lors du maintient du produit.
Cela couvrira aussi vos arrières si votre client se retrouve face à un procès. Votre devise devrait être, “Nous vous aidons à assurer l'accessibilité”, et pas “Nous rendons votre site Web accessible.”
Qu'est ce que cela signifie pour le développement ?
- Prévoyez des ateliers et des formations sur l'accessibilité avant de commencer à développer.
- Trouver un champion dans la société du client qui prendra les responsabilités concernant les standards d'accessibilité. Il y a toujours quelqu'un qui veut sortir du lot, et c'est une chance, l'accessibilité est une question légale.
- Produire de la documentation sur les mesures d'accessibilité et sur les moyens de les conserver au travers des changements de design.
- Ayez une partie du contrat claire et concise qui précise que l'accessibilité du contenu après la livraison du projet initial (le jour où vous sortez prendre un verre pour fêter ça) est de la responsabilité du client. Chaque ajout supplémentaire de votre part devra être facturé à part. Cette menace de coûts supplémentaires fera que le client poussera ses employés à vous écouter de manière plus attentive. Discutez avec votre équipe juridique pour tourner ça comme si cela permettait au client d'économiser de l'argent et de le protéger - le juridique est une arme très puissante.
- Assurez-vous de faire ce que vous prêchez. Votre contenu initial et votre code se doivent d'être immaculés. Les erreurs seront copiées et il sera difficile d'expliquer à un client que vos conseils étaient mauvais.
Erreur #3 : Prévoir uniquement le pire des scénarios
Il peut arriver que nous, développeurs, pleins d'altruisme pour les handicapés, nous perdions de vue l'image générale. Mais l'accessibilité concerne tout le monde, sans distinction de capacité ou de situation géographique. Pour nombre d'entre nous, l’accès par le clavier, la reconnaissance vocale ou même les utilisateurs de lecteurs d'écran sont des choses auxquelles nous n'avions même jamais pensé auparavant. Maintenant nous nous sentons coupables et nous voulons tout faire pour eux, en contrecarrant avec acharnement tout ce qui pourrait rendre l'utilisation des lecteurs d'écran impossible.
Le vilain petit secret ici est que de nombreux développeurs web ont pleins de mythes en tête à propos des lecteurs d’écran. Testez-en un, ou demandez aux personnes qui dépendent des technologies d’assistance, comment elles les utilisent, ce dont elles ont réellement besoin et ce qu’elles veulent.
Il n’y a tout simplement aucun moyen d’anticiper la constellation des habiletés, des matériels et des connaissances qui se trouvent de l’autre côté de l’écran, et en coupant au plus petit dénominateur commun, vous n'arriverez pas à rendre le site accessible, utilisable et agréable pour la majorité des visiteurs. Vous perpétuerez aussi le mythe selon lequel les sites accessibles doivent être approximatifs et laids.
Les requis minimaux pour un site accessible sont :
- Un HTML sémantiquement correct, logique et valide.
- Un contenu qui fait du sens lorsqu'il est lu ou entendu.
- Un texte alternatif pour tout contenu visuel.
- Des titres et des liens qui ont un sens hors du contexte.
Ces bases sont les fondations de votre site. Si tout ce que vous ajoutez en plus de cela ne diminue pas les fonctionnalités de cette fondation, vous êtes alors dans le vrai.
Ce qu'il faut éviter :
- Un contraste peu élevé dans les graphismes et dans la CSS.
- Des combinaisons de couleur qui ne sont pas facilement distinguables pour les daltoniens.
- Une police trop petite ou qui ne peut pas être redimensionnée.
- Le chevauchement d'éléments qui deviennent illisibles avec une police plus grande.
Si vous voulez ajouter un JavaScript sexy pour autoriser des fonctionnalités de glisser-déposer ou de menus déroulants, ça ne pose pas de problème non plus. Assurez-vous simplement que le JavaScript s'applique seulement si l'agent utilisateur est compatible. Encore mieux, faites-en une option et offrez un moyen de le désactiver pour une interface plus simple.
Qu'est ce que cela signifie pour le développement ?
- Assurez-vous d'abord que les basiques fonctionnent et montrez au client à quel point le site fonctionne bien dans des environnements différents.
- Essayez d'introduire l'idée d'améliorations progressives. Ne commencez pas avec des visuels, mais plutôt des squelettes non stylés.
- Utilisez des outils qui permettent aux éditeurs d'écrire leur copie en dehors de toute application visuelle. Cela peut être un template Word propre ou un simple outil de publication comme WordPress.
- Montrez à quel point couvrir les bases de l'accessibilité aide tout le monde - naviguez sur le site avec un téléphone cellulaire ou un PDA.
- N'oubliez pas de rappeler à quel point les moteurs de recherche aiment les bons contenus.
- Ne sous-estimez pas le pouvoir des CSS et du JavaScript comme outil d’utilisabilité. Etant un utilisateur de Javascript, j'aime bien voir s'il y a problème avant le rechargement de la page entière.
- Développez avec l'accessibilité en tête. Un bon design graphique ne donne pas seulement le ton, mais permet aussi à l'utilisateur de trouver beaucoup plus facilement ce qui est important sans qu'il n'ait à y réfléchir de trop.
- Développez avec la flexibilité en tête. Les sites web doivent pouvoir grandir du point de vue de l'architecture de l'information et du point de vue de l'espace à l'écran. Evitez de remplir tous les espaces. Un de ces jours, des liens de navigation seront changés ou seront ajoutés, ou alors la copie sera traduite dans une langue avec des mots plus longs.
La semaine prochaine je parlerais des quatre autres erreurs d'accessibilité que j'ai pu rencontrer :
- Partager les problèmes avec le visiteur.
- Essayer de régler des problèmes qui sont en dehors de votre cercle de compétences.
- Cacher ou mettre au second plan les gains d’accessibilité/d’utilisabilité.
- Etre complaisant avec les mauvais clients.
http://www.digital-web.com/articles/seven_accessibility_mistakes_part_1/