Le javascript, technologie standard d'interaction entre les internautes et les pages Web, a souvent été associé à une barrière pour l'accessibilité des sites. Pourtant, ce n'est plus la technologie qui est en cause mais son utilisation. Son utilisation a évolué au fil des années mais le résultats est plus que mitigé.

Au début des années 2000 : le DHTML

Pendant longtemps, javascript n'étant pas reconnu ou implémenté de la même manière dans les tous les navigateurs. Son utilisation se limité donc à quelques actions simples.

L'avènement du DHTML a donné une autre dimension aux pages Web. Le dynamisme apporté au page est bien sur une avancé majeur en terme d'ergonomie. Cependant, du fait de son aspect novateur à l'époque, il n'existait pas ou peu d'outils pour les personnes en situation de handicap capable d'interagir correctement avec ce nouveau type d'interface.

Les liens de type <a href="javascript:mon_action();return false;">...</a>

était monnaie courante. Un utilisateur naviguant à l'aide de logiciels spécialisés pour combler leur handicap ne pouvait pas utiliser ces actions.
A l'époque, les outils tel que Jaws ou Lynx se basé sur la structure HTML d'une page et non sur sa structure DOM.

L'arrivé du javascript non-obstrusif

Conscient des problèmes posés par le DHTML, de nombreux frameworks javascript sont apparut pronant le javascript non-obstrusif. Cette technique consiste à ne plus injecter le code directement dans le HTML mais soit dans un script externe (soit en fin de page, soit dans un fichier externe). Le code aura alors la charge de venir modifier un code HTML propre.

On trouve cette manière de faire dans jQuery et Mootools.

/*
Exemple de javascript non obstrusif avec jQuery
*/
$(document).ready(function() {
    $('a[rel=external]').each(function(link) {
        // ...
    }
}

On a donc un HTML propre qui dans le meilleur des cas est accessible, avec une surcouche de javascript qui vient modifier le DOM.

Prise en compte du DOM dans les aides techniques

Parallèlement, les différentes aides techniques ont bien compris qu'il ne pouvait se baser uniquement sur la structure HTML d'une page mais qu'elle devait bien entendu prendre en considération toutes la partie applicative fournit par javascript. Concrètement, un lecteur d'écran tel que Jaws interprète le javascript. Une page accessible est à la fois une page qui propose une structure HTML cohérente et un état du DOM cohérent.

Un javascript destructeur ?

Le problème est qu'aujourd'hui les principaux scripts ou framework javascript ont un mode de fonctionnement qui détruit l'accessibilité d'une page.

Prenons l'exemple d'un nuage de tag réalisés à l'aide de Mootools et son composant pour les toolstips.

On a un code HTML, on ne peut plus propre.

<ul>
  <li><a href="Étiquette 1 (14 articles)">Étiquette 1</a></li>
  <li><a href="Étiquette 2 (12 articles)">Étiquette 2</a></li>
  ...
  <li><a href="Étiquette n (27 articles)">Étiquette 27</a></li>
</ul>

Pour avoir les jolies Tooltip, Mootools, dans son mode par défaut, fonctionne de la manière suivante :

• Suppression du contenu du title
• Injection dans un ilot de donnés en fin de page
• Positionnement relatif par rapport au liens

La structure de la page dans le DOM a changé. Les titles ont disparus comme le montre l'exemple suivant.

<ul>
  <li><a href="...">Étiquette 1</a></li>
  <li><a href="...">Étiquette 2</a></li>
  ...
  <li><a href="...">Étiquette 27</a></li>
</ul>

Le fait qu'on ai un HTML bien conçu donne un sentiment d'impunité. Mais, le mal est fait. Un utilisateur de Jaws sera dans l'obligation de désactiver le javascript pour avoir accès à l'information.

Finalement, dans le temps il fallait interpréter javascript pour comprendre les pages, maintenant que cela est possible, il faut désactiver javascript. Le monde à l'envers. Ce n'est pas tant le javascript non intrusif qui est en cause mais plutôt l'utilisation qui en faites.