Sept erreurs d’accessibilité (2ème partie)

Par Christian Heilmann

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 :

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 ?

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 ?

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 ?

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 ?


http://www.digital-web.com/articles/seven_accessibility_mistakes_part_2/

Fiche technique

À propos de l'auteur

lang="en">Christian Heilmann
est un contributeur de Digital Web Magazine. La plupart de ses
publications sont écrites dans le métro, en voyageant
à travers Londres, parce qu’il n’y a simplement rien d’autre
à y faire. Un jour il aimerait remettre son propre livre
à ceux qui sont coincés là.

Articles du même auteur

Articles similaires

Voici la liste des dix articles les plus récents en rapport avec cet article :

Tous niveaux

Accessibilité

© 2001-2024 Pompage Magazine et les auteurs originaux - Hébergé chez Nursit.com ! - RSS / ATOM - About this site