Sept erreurs d’accessibilité (2ème partie)
Cet article comporte une première partie qui fait aussi l'objet d'une publication sur Pompage.
Cet article en deux parties traite des raisons qui font que certains produits n'arrivent pas à être accessibles. La semaine dernière (NdT : en fait, le mois dernier sur Pompage), nous avons discuté des trois premières erreurs, sur les sept promises, que j'ai pu avoir l'occasion de rencontrer dans mon travail, à savoir :
- Erreur #1 : Croire en des produits sans les avoir testés. Ce n'est pas drôle de découvrir au milieu d'un développement que le CMS n'aide pas vraiment à créer un balisage propre, ou que l'application utilisée crache des contrôles qui sont uniquement utilisables avec une souris.
- Erreur #2 : Prendre trop de responsabilités. Parfois nous donnons l'impression au client que tout ce qu'il a à faire pour créer un produit accessible est de croire en nous ! Nous devrions aider le client à comprendre que lorsque qu'il s'agit de la maintenance du produit, l'accessibilité est autant de sa responsabilité que de la nôtre.
- Erreur #3 : Prévoir uniquement le pire des scénarios. Trop souvent, nous voyons l'accessibilité comme le fait de faire un design pour le plus petit dénominateur, gardant ainsi en vie le mythe selon lequel les produits accessibles doivent être laids et approximatifs.
Cette semaine nous allons enchaîner avec quatre scénarios supplémentaires et voir comment les éviter. Si vous avez des contraintes budgétaires ou de relations client, ces idées pourront au moins vous inspirer pour pousser ce dernier dans la direction d'un développement centré sur l’utilisateur ou vous donneront des munitions lors des réunions.
Les sept erreurs d'accessibilité : 4-7
Erreur #4 : Partager les problèmes avec le visiteur
C’est très tentant de juste laisser tomber et d’arrondir le plus possible les angles pour rendre le client heureux. Si le client utilise seulement Internet Explorer, pourquoi s’embêter à tester pour les autres navigateurs ?
Vous voulez protéger votre site du spam, des faux e-mails et du vol de contenu. Mais pourquoi les visiteurs devraient supporter ça et entrer des choses qu'ils voient - ou ne peuvent pas voir - dans des images pour soumettre une demande, alors que tout ceci ne fait vraiment rien pour leur propre protection ? Tout ce que génère un ordinateur est piratable par un autre ordinateur en y consacrant du temps et du coeur - y compris un CAPTCHAs qui est supposé être anti-piratage.
Pourquoi vos visiteurs devraient-ils passer à travers plusieurs étapes d'un processus d'inscription pour vous poser une question ? C'est votre problème si vous recevez du spam - pas le leur. Oui, c'est frustrant pour l'espiègle occasionnel et cela vous donne une chance de préciser un dispositif d'aide comme votre section FAQ, mais cela veut aussi dire que les visiteurs qui ont réellement besoin de vous contacter doivent passer par un nombre d'étapes beaucoup plus important que ce qu'ils devraient. Combien de fois avez-vous raccroché le téléphone, frustré, après avoir écouté toutes les options sur un système automatique ?
Il est bien plus important d'offrir aux visiteurs un moyen de communiquer - cela montre que vous avez une oreille ouverte pour les soucis et les problèmes. Cela couvre également vos arrières si quelqu'un se plaint qu'il n'y avait aucun moyen de vous contacter. Dans certains pays, les requis légaux forcent à avoir un moyen simple de communiquer sur chaque page du site. Chaque site web allemand doit avoir un « Impressum », c'est à dire une liste de moyen pour contacter la société.
Un autre souci dont j'entends souvent parler est la protection des graphiques et du texte empêchant les téléchargements. Dès que c'est sur le web, les voleurs intelligents arriveront à l'avoir. Les scripts pour empêcher les clics droit, les images recouvertes avec un Gif à fond transparent, et les animations Flash qui se répètent ne sont pas de véritables mesures de sécurité. Vous rendez seulement la tâche plus compliquée pour les visiteurs qui ont besoin du clic droit de la souris ou qui n'ont pas Flash installé.
Qu'est ce que cela signifie pour le développement ?
- Ne promettez pas de Javascript - ou des mesures de protection basées sur les CSS - de telles choses n’existent pas. C’est ennuyeux pour les visiteurs normaux et ce n’est qu’un désagrément pour les pirates malicieux.
- Coachez les clients sur l’importance des canaux de communication. Un site web est avant tout là pour délivrer du contenu, mais aussi une invitation à communiquer. Le nombre de demandes devenant de bons prospects est une mesure de votre succès en tant que partenaire d’affaires.
- Trouvez des solutions au spam du côté serveur plutôt que de rendre la tâche plus difficile aux visiteurs pour contacter votre client.
Erreur #5 : Essayer de résoudre des problèmes qui sont en dehors de notre zone de compétences
Il est tentant d'utiliser des techniques de script côté client, comme le Javascript, pour contourner les points faibles des agents utilisateurs. Un des outils qui sont constamment débattus est l'icône de redimensionnement des polices. Il est impressionnant dans les présentations clients et les clients vont vous contacter parce que leurs concurrents l'utilisent sur leur site (j'en ai plein avec les administrations locales).
Les gadgets de taille de police sont généralement des boutons libellés A, A-, A+, et A++ ou small font, medium font et large font. Les plus ironiques d'entre eux ne grandissent pas avec la police du navigateur mais utilisent des images de 10×10 pixels avec un type gris clair sur un fond gris encore plus clair. Comment une personne qui a besoin d'un texte large peut-elle seulement les trouver ?
D'autres dépendent de scripts client au lieu d'utiliser une solution de script côté serveur. Vous pouvez les faire fonctionner assez facilement pour tout le monde et changer la police sans rafraîchir la page avec un agent utilisateur qui permet l'utilisation d'un langage de script.
Dans tous les cas, toutes ces techniques simulent ce que des systèmes extérieurs à votre site devraient et font déjà beaucoup mieux. Une police plus grande n'est pas un requis du site - ceci concerne le système d'exploitation dans son ensemble et reste le problème des éditeurs de systèmes d’exploitation et de navigateurs.
Plus on utilise des artifices concernant les problèmes de mauvais agents utilisateurs, moins les utilisateurs seront tentés de les remplacer par d'autres qui sont meilleurs. Un site web avec une taille de texte raisonnable et pas de taille de police fixe peut être utilisé par les visiteurs en utilisant les contrôles avec lesquels le navigateur est livré. Si les options de contrôles d'un navigateur sont cachées dans les sous-sols de celui-ci, derrière une porte qui dit : « Attention au léopard », alors les visiteurs qui ont vraiment besoin d'une police plus large n'utiliseront probablement pas ce navigateur ou ils trouveront d'autres moyens pour contourner le problème. Si vous voulez vraiment aider les gens, expliquez-leur comment ils peuvent changer la taille de la police dans différents navigateurs sur votre page Accessibilité. Vous avez bien assez de soucis avec votre site ; n'essayez pas d'améliorer les produits d'autres personnes en plus de ça. La conception de navigateurs est une histoire bien différente.
Qu'est ce que cela signifie pour le développement ?
- Ne soyez pas trop excité par les gadgets et le pouvoir de changer l'agent utilisateur via des technologies côté client. Souvenez-vous qu'il y a plein de personnes différentes et pleins d'agents utilisateurs différents.
- Ne dupliquez pas ce que l'agent utilisateur offre déjà. Dans de nombreux navigateurs, je peux ajouter mes favoris, imprimer et changer la taille du texte avec des éléments de l'interface utilisateur (comme des boutons) et des raccourcis clavier. Si vous voulez aider les visiteurs qui n'ont pas autant de bon sens du web, ajoutez une section Aide qui explique comment changer la taille de la police. Cela dit, ne vous attendez pas à ce que beaucoup de personnes lisent cette section - ceux qui ont réellement besoin d'un texte plus grand devront parvenir sur votre site d'une façon ou d'une autre, et savent donc déjà comment faire.
- Si vous avez vos propres gadgets, fabriquez-les à l'épreuve des balles. Ils doivent fonctionner sans script client et s'agrandir avec les réglages du navigateur.
- Si vous voulez offrir aux visiteurs une chance de customiser votre site, faites le proprement. Offrez un moyen pour changer le layout, ajouter ou effacer des sections de contenu, changer l'emplacement de la navigation et offrir d'autres caractéristiques de portail ou d'intranet.
- Soyez conscients que les réparations rapides concernant des inconsistances ou des problèmes communs de navigateurs sont là pour durer demain et les jours d'après. Il semble que les développeurs soient rapides à ajouter des choses, mais peu enthousiastes à les enlever. Combien de fois rencontrez-vous un lien « Cliquez pour ajouter aux Favoris » qui fonctionne uniquement avec MSIE ?
Erreur #6 : Cacher ou écraser des améliorations d'accessibilité/utilisabilité
Il y a peu d'améliorations de l’accessibilité qui changent drastiquement le rendu visuel du site, et parfois il n’y a même pas besoin de ces améliorations. Une des améliorations qui peuvent être nécessaire et qui causent de furieuses discussions dans les petits comités ainsi que dans les mailing listes est le lien « passez au contenu ».
Ces liens aident le visiteur à passer plusieurs sections répétitives de la page - comme ces 30 liens avant la première ligne de contenu. Ils sont très utiles pour les utilisateurs aveugles mais aident aussi ceux qui sont dépendants d'un accès par le clavier ou qui surfent avec un dispositif de petit écran comme les téléphones ou les PC portables.
Un « passez au contenu » de petite taille et aligné sur la droite, plutôt que caché dans la CSS, ne mange donc pas de pain. Plus qu'une bannière de compatibilité WAI-AAA dans le pied de page, cela montre que votre client s'intéresse réellement aux besoins de ses visiteurs.
C'est la même chose pour les champs de formulaires, les légendes, les labels et les bords que certains navigateurs ajoutent autour du lien actif. Oui, ça n'est pas forcément sexy, mais ils ont une raison d'être. Les champs de formulaires permettent à chaque utilisateur de facilement saisir que les champs sont une unité logique.
Les liens ont différents états, et il y a beaucoup de sens à définir différents aspects visuels pour ces états. Je me demandais toujours à quoi servait l'état actif et je pensais qu'il était seulement visible pour un moment jusqu'à ce que la page liée se charge ou que mon script trouve enfin l'action appropriée. Ce que je ne savais pas, c'est que l'agent utilisateur place l'état actif sur le dernier lien visité lorsque vous cliquez sur le bouton retour de votre navigateur ou lorsque vous pressez les raccourcis clavier équivalents. Logique, non ?
Qu'est ce que cela signifie pour le développement ?
- Assurez-vous que toutes les améliorations concernant l'accessibilité que vous ajoutez, peuvent être utilisées par ceux qui en ont besoin. Les liens d'évitement ne sont pas là juste pour les utilisateurs de lecteurs d'écran.
- Même si cela ne semble pas pertinent au premier coup d’œil, il y a des raisons pour lesquelles les navigateurs présentent les champs de formulaires et les liens de la façon dont ils le font. Si vous voulez les ignorer et vous passer de ces « horribles bords sur le hover », vous feriez mieux d’avoir une très bonne raison pour cela et faire quelques tests d’utilisabilité avec de vrais humains. Les développeurs de navigateurs font cela.
- À chaque fois que vous essayez d'améliorer l'apparence d'un formulaire, vous perdez le bénéfice d'une reconnaissance instantanée. Vos changements ont donc vraiment intérêt à valoir le coup.
Erreur #7 : Satisfaire votre client - pas leurs clients
Le temps où le client ne connaissait rien du tout au web et croyait tout ce qu'on lui disait est - bien assez tristement - passé. Des années de vendeurs de logiciels, de magazines, de développeurs web du dimanche ou de relations familiales, disant à nos clients que le design web est aussi facile que de cliquer avec une souris, ont rendu notre job bien plus difficile qu'il ne devrait l'être.
Les clients adorent les visuels et sont beaucoup plus enclins à s'embarquer dans un menu déroulant lissé plutôt que dans un plan du site extraordinairement organisé avec un exemple de contenu qui aide succinctement le visiteur à trouver ce qu'il cherche dans un laps de temps aussi court que possible.
Les clients ne sont par contre plus trop enclins à trop dépenser ces temps-ci et veulent des résultats tangibles aussi rapides que possible. Les ateliers, les formations, les sessions d'information sur l'architecture, les exercices de triage de carte d'utilisabilité ainsi que les analyses de compétitivité sont pleins de choses qui diminuent le temps passé à développer, car vous ne codez rien qui n'a été proprement pensé. Malheureusement, toutes ces activités ne produisent rien qui soit réellement « là » et sont, pour cette raison, très difficiles à vendre ou à insérer dans un budget déjà très serré. La vitesse du web semble donner l'impression que développer pour lui, doit être aussi rapide que de l'utiliser. Certains clients pensent que faire une présentation qui ressemble à une application web, c'est presque la moitié du job qui est faite.
C'est très tentant de juste laisser tomber et d’arrondir le plus possible les angles pour rendre le client heureux. Si le client utilise seulement Internet Explorer, pourquoi s'embêter à tester pour les autres navigateurs ? Si le temps et le budget sont déjà serrés, pourquoi ne pas abandonner le support pour les utilisateurs non-Javascript dans les applications web ? Après tout, d'autres sites le font aussi !
Ce qui est triste là-dedans, c'est que cela fonctionne, le client est heureux, il n'y a presque pas de retour négatif des visiteurs et vous pouvez rester dans les temps et dans le budget. Un succès financier complet. Mais les utilisateurs du produit méritent mieux. Ils semblent être une bande assez tolérante, mais ceux qui sont gênés ne se plaignent pas - ils s’en vont.
C'est l'erreur la plus difficile à éviter et je ne peux pas vous donner une solution pour cela. Les clients sont bien plus proches de nous que les utilisateurs finaux. Nous avons besoin d'exemples où le développement centré sur l'utilisateur amène plus d'argent et fait croître immensément une société sans provoquer son éclatement à la fin de sa période de croissance. Si vous avez des histoires de succès comme ça, coûte que coûte, partagez-les !
Qu'est-ce que cela signifie pour le développement ?
- Essayez de ne pas vous attacher à chaque idée que le client veut implémenter. Vous n'êtes pas un maître d'hôtel, mais un expert embauché pour faire un travail correct.
- Assurez-vous de connaître des exemples qui impressionneront les clients et d'avoir à portée de main le matériel qui explique pourquoi ça ne serait pas une bonne idée de l'implémenter dans leur produit.
- N'agissez pas impulsivement. Expliquez que tout changement nécessite des tests et l'avis d'autres personnes dans la société - les analystes d'affaires, les architectes techniques, les designers, les développeurs web, etc. Fournissez des budgets et des plannings pour le travail d'implémentation avant de le commencer.
- Ayez un nombre très limité de personnes qui discuteront directement avec le client. Idéalement, il devrait y avoir un seul point de contact dédié, qui délègue les tâches à l'équipe. Avec trop de lignes de communication ouvertes, quelqu’un va promettre l'implémentation d'un changement, sans prévenir l'équipe ou sous-estimer la charge réelle de travail que ce changement va causer. Les enfants connaissent ce truc - si papa dit non, essayer avec maman !
- Commencez un catalogue rassemblant des designs réussis centrés sur l'utilisateur pour tous vos projets. Vous devriez pouvoir en implémenter quelques morceaux dans chacun d'entre eux et assembler un bon portfolio à montrer dans le futur à de nouveaux prospects.
http://www.digital-web.com/articles/seven_accessibility_mistakes_part_2/