defer de la balise <<script> pour IE : JavaScript: Defer ExecutionLe 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 ;)
Dave Shea a qui l’on doit le fameux CSS Zen Garden nous délivre ses bons conseils pour faire face aux difficultés de mise en page avec les CSS.
Un must !
L’accesssibilité, dont il est désormais admis qu’elle constitue une avancée dans la manière de délivrer l’information sur le web, soulève un certains nombre de questions :
Dans la série j’ai décidé de ne plus laisser la place aux lignes de codes hasardeuses, je me suis plongé dans les textes qui font office de bibles en matière de CSS, à savoir :
En effet, j’ai, comme on dit, appris sur le tas, c’est-à-dire la plupart du temps fureté sur internet toutes les bonnes sources disponibles. J’en profite pour rendre hommage aux sites qui m’ont le plus influencés qui sont dans le désordre “pompage.net” et sa mailing-liste “pompeurs”, openweb, et un peu plus tard, alsacréations. Je ne saurais être exhaustif de peur d’en oublier mais j’ai appris l’essentiel grâce à ces trois sources incontournables du web francophone.
Néanmoins comme dit l’adage, rien ne vaut un bon bouquin, j’ai donc décidé de rattraper mon retard en lisant ces trois livres anglosaxons de référence cités plus haut. Car il faut l’avouer, nos amis anglosaxons ont une certaine longueur d’avance en ce domaine, même si nos éminents webdesigners francophones sont d’un niveau exceptionnel. Je pense à Tristan Nitot, Laurent Denis, Eric Daspet, Denis Boudreau, Raphael Goetter, Emmanuel Clément, Stéphane Deschamps, Karl Dubost parmi les plus illustres (à mon sens bien sûr).
Au cours de ces lectures, j’ai donc pris note de quelques notions qui me semblaient jusqu’alors floues, voire totalement ignorées. Voici donc les principales :
<?xml version="1.0" encoding="utf-8"?> fait passer Internet Explorer en mode Quirks, à éviter donc !csshover.htc est un patch javascript qui permet de rétablir la pseudo-classe :hover sur toutes les balises html pour IE dans ses versions antérieurs ou égales à 6. En effet, IE, comme à son habitude, fait son petit caprice et n’offre le support pour cette pseudo-classe que pour l’élément <a>. Chose dommageable notamment pour la construction de menus déroulants utilisant des listes imbriquées. Bonne nouvelle IE 7 semble rétablir la chose, ouf !
En attendant, l’utilisation du csshover.htc de Peter Nederlof permet de régler le problème pour IE6 et inférieurs.
Il suffit de faire référence dans la feuille de style comme suit :
body {behavior:url(csshover.htc)}Notez que ce patch javascript se dissimule sous un fichier d’extension “htc” et fonctionnera donc même si javascript est désactivé. Si c’est pas beau ça !!!
Notez également que ce patch rétabli la transparence des PNG sous IE.
Les références :
Généralités :
Des Formulaires accessibles :
Typographie :
Les liens et l’accessibilité :
Le cas des accesskeys :
Accessibilité et javascript :
Accessibilité des PDF :
Liste de questions cherchant solutions :
Pour contrecarrer de nombreux problèmes de mise en page liés à l’absence de layout sur certaines divisions, la lecture de cet article est fortement recommendée : On having layout. Il s’agit d’un work in progress puisque mis à jour au gré des évolutions de IE.
Article complet, bien documenté et agrémenté des lignes de codes qu’il vous faut connaître, sa lecture fera de vous un pro de la mise en page pour IE. Indispensable !
Sa traduction en français : Le concept de hasLayout dans IE/Win
Prototype :
Prototype, la bibliothèque javascript de référence, et aussi la plus répandue sur le web, est malheureusement peu documentée. Il faut se tourner vers les retours d’expériences de développeurs qui partagent leurs connaissances. Voici quelques adresses utiles :
Prototype a tendance a enflé avec les versions, procurez-vous la version light : prototype.lite.js
Scriptaculous :
Votre site respecte-t-il les standards du web ? Si vous répondez favorablement aux 88 questions de cette checklist publiée par Russ Weakley, le 13 août 2004, et que l’on peut retrouver en version française sur le site elanceur.org, alors vous avez les clés de l’excellence, vous êtes au top !!
Bon je retourne au boulot ;)