Le 28 février dernier, je me posais une série de questions ici-même sur l’accessibilité des sites web. Comme bon nombre de disciplines sur le web, je me disais qu’il suffisait d’appliquer les bonnes pratiques d’accessibilité collectées ici ou là sur le web.
Or depuis j’ai eu la chance d’assister à la formation “Expert AccessiWeb en évaluation de l’accessibilité des sites web”. Enfin je n’ai assisté qu’à la première partie de la formation, la suite est prévue fin mars.
Tout ça pour dire que mes interrogations se sont largement dissipées, je vous délivre point par point les réponses que j’ai obtenues.
1. L’accessibilité fait-elle obstruction à l’esthétique ? Et donc est-elle un frein à la créativité ?
J’avais tendance à croire qu’effectivement il était difficile d’allier créativité et accessibilité. Je pense désormais que si on intégre les contraintes d’accessibilité dans le processus de création, l’esthhétique n’en pâtira pas spécialement. Le graphisme est une discipline comportant également des règles qu’il vaut mieux respecter si l’on veut aboutir à une bonne composition. Comme le support web a son lot de contraintes (de taille, de mise en page, de typographie), l’accessibilité a également les siennes.
2. Comment intégrer les critères d’accessibilité dans le processus de création, hormis le critère de contraste des couleurs ?
L’accessibilité affecte la création sur essentiellement deux points :
3. L’utilisation de javascript est-elle limitée pour des raisons d’accessibilité ?
Encore une idée reçue mais il est vrai qu’il est alors nécessaire de bien penser l’application web. Par exemple, ne pas oublier de rendre les actions javascript sur la souris également accessibles par le clavier, soit concrètement doubler ses fonctions onclick avec des onkeydown et ses fonctions onmouseover avec des onfocus.
4. L’accessibilité ne bride-t-elle pas les sites en Ajax ?
Il existe toujours une solution, essayez par exemple d’utiliser votre compte Gmail en désactivant javascript, et vous serez étonné de voir que ça fonctionne. En gros, il faut éxécuter côté serveur ce que l’on fait avec javascript côté client.
5. En pratique, les contrôles javascript sur les formulaires sont-ils considérés inaccessibles ?
Les contrôles javascript ne sont pas antiaccessibles, il faut simplement comme cité précédemment doublé ses contrôles côté serveur.
6. L’accessibilité est-elle un objectif ou un devoir ? ou doit-on plutôt se fixer comme objectif d’atteindre le plus haut niveau d’accessibilité possible ?
La première partie de cette question relève plus d’un problème politique sociale. Je répondrais simplement que le droit à l’information tout comme la liberté d’expression ne doivent pas être réservées à certaines catégories de populations. Il n’existe aucune justification à l’exclusion. Rendre les sites web accessibles serait donc un devoir. Il va sans dire donc qu’il faut autant que possible atteindre le plus haut niveau d’accessibilité.
7. Des concessions à l’accessibilité sont-elles possibles et lesquelles ?
Oui et les trois niveaux d’accessibilité définis par le WCAG (niveau A – niveau AA – niveau AAA) sont là pour prioriser les critères d’accessibilité.
8. Quel est le coût en termes de temps de dévelopement, et donc en termes financiers des nouvelles contraintes imposées par le souci d’accessibilité ?
Cela est très variable, je dirais que pour un site sans contenu multimédia, si l’on adopte les bonnes pratiques de codages à la source, la rallonge de temps est d’environ 10 à 20%. Pour les contenus plus riches (flash, vidéo, son) cela peut engendrer un surcoût énorme (sous-titrer les vidéo, faire une version texte d’un contenu sonore…)
Il ne me reste plus qu’à rendre mon site accessible ;)