Je suis tombé un jour sur le site OpenWeb. Il m'a fait prendre connaissance à quel point un Web ouvert et des outils respectueux de ses Standard sont indispensables. A l'époque, Internet Explorer 6 était le seul navigateur vraiment utilisé. Un jour, j'ai découvert un nouveau navigateur, il n'était certes qu'en version beta, mais il semblait prometteur. Depuis ce jour là il ne m'a jamais quitté, ce navigateur s'appelle Firefox.
Quel est le rapport avec le titre de mon article ? Tout simplement que cette histoire date maintenant d'il y a 5 ans, et qu'Internet Explorer 6 lui date de 2001 (8 ans deja !). Quand on parle du Web, on parle de nouvelles technologies, et le marketing se veut Web 2.0, pourtant IE6 est encore là, paradoxal non ?
La plupart des développeurs actuels veulent se débarrasser d'Internet Explorer 6, mais s'il est encore présent n'est-ce pas finalement de leur faute ?
Tout n'est pas si simple. Il faut voir plusieurs cas de figure.
Il est fréquent d'associer Javascript à une technologie non accessible, mais l'inaccessibilité d'un site n'est pas dû à Javascript mais à l'utilisation que l'on en fait.
Fervent défenseur du progressive enhancement, je me suis vite retrouvé face à une difficulté : si on décide de laisser une sous-navigation affichée via CSS et qu'on la masque via Javascript, cette sous-navigation sera affichée pendant quelques millisecondes avant de se masquer, provoquant un flash visuel disgracieux, c'est également le cas pour tous nos modules que nous essaierons de rendre accessible via cette méthode.
Le problème vient du fait que la fonction onload() de Javascript (ou la fonction ready() de jQuery) ne s'exécute qu'après le chargement du DOM, donc le contenu s'affiche avant que Javascript n'ait le temps de le masquer.
Il existe cependant un solution à ce problème : détecter si Javascript est activé avant l'affichage de la page.
Après l'article visant à protéger les emails du spam tout en essayant de proposer une solution alternative accessible à l'internaute ne pouvant exécuter Javascript, voici l'article qui a pour but de proposer un formulaire accessible tout en restant le moins contraignant possible.
Pour commencer, faisons l'état des lieux.
La problématique : les robots remplissent de manière automatique les champs du formulaire de contact (ou tout autre formulaire) pour nous soumettre leurs liens indésirables. Nous allons donc tenter d'y remédier, tout en essayant de ne pas nuire à l'utilisateur.
Ce billet est consacré à une réflexion ancestrale, une utopie inaccessible : comment protéger nos mails du spam via le lien mailto, tout en restant accessibles aux lecteurs d'écran et aux navigateurs ayant Javascript désactivé ?
Plusieurs solutions existent pour protéger son email :
Encoder l'url via Javascript, mais ça pose un problème d'accessibilité aux personnes ne l'ayant pas activé.
Transformer l'email en image via un script côté serveur, le même problème se pose au niveau des personnes ne pouvant lire les images.
La fameuse utilisation du "email[at]nomail[dot]com", qui pose un problème d'accessibilité cognitive.
Avant de rentrer proprement dans des problématiques techniques plus avancées, je souhaitais vous décrire mes bases de travail pour commencer tout nouveau projet. Attention, je ne vous propose pas un énième framework HTML extraordinaire fait maison. Ces fichiers ne sont qu'un condensé de recherche que j'ai mené tout au long de ces dernières années et qui correspondent exactement à mes besoins actuels, c'est donc avant tout du sur-mesure.
