Sept erreurs d’accessibilité (1ère partie)

Par Christian Heilmann

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 ?

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 :

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 ?

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 :

  1. Un HTML sémantiquement correct, logique et valide.
  2. Un contenu qui fait du sens lorsqu'il est lu ou entendu.
  3. Un texte alternatif pour tout contenu visuel.
  4. 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 :

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 ?

La semaine prochaine je parlerais des quatre autres erreurs d'accessibilité que j'ai pu rencontrer :

Deuxième partie

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-2014 Pompage Magazine et les auteurs originaux - Hébergé chez Nursit.com ! - RSS / ATOM - About this site