Le procédé Ajax ( Asynchronous JavaScript and XML) permet de lancer des requêtes client serveur sans avoir à recharger la page pour afficher les résultats.

L'objet utilisé est le désormais incontournable XMLHttpRequest, création de Microsoft, popularisé par Google dans son application de webmail.

La méthode est séduisante et a ouvert la voie au mélange subtil de réelles innovations et d'une bonne dose de marketing connue sous le terme Web 2.0.

Dés l'apparition des premières applications "Ajaxées", la problématique de l'accessibilité du procédé a été posée; notamment la manière dont les lecteurs d'écran et leurs utilisateurs allaient pouvoir intéragir avec la page.

En effet, économiser le rechargement de la page pour afficher des résultats ou effectuer des traitements pose un problème redoutable pour les lecteurs d'écran qui se résume aux deux questions :

Comment avertir l'utilisateur qu'une partie de la page a été modifiée et comment lui donner accès au nouveau contenu ?

Laurent Denis, dans un message sur le forum Alsacréations, avait qualifié ce procédé de manière très pertinente en soulignant que cela revenait à "modifier en permanence le contexte de navigation".

James Edwards, connu pour son menu DHTML conforme WCAG (c'est lui qui le dit), s'est livré à un test simple avec les principaux lecteurs d'écran du marché.

Le test consiste à utiliser un procédé Ajax pour modifier dynamiquement le contenu d'un paragraphe et de tenter d'informer l'utilisateur qu'un contenu de la page a changé et lui donner le nouveau contenu.

Le premier test ne fait rien et se contente d'observer la réponse des lecteurs d'écran à ce procédé.

Tous les lecteurs d'écran testés interprètent correctement le procédé javascript, le paragraphe est bien mis à jour, mais, comme on pouvait s'y attendre, aucun ne le lit.

La série des 5 tests suivants tentent de trouver un moyen de transmettre le nouveau contenu à l'utilisateur.

Plusieurs stratégies sont envisagées : tenter de redonner le focus sur l'élément mis à jour afin de provoquer sa lecture ou de le diffuser au moyen d'une boite de dialogue.

Aucun de ces 5 tests, qui font le tour des solutions "immédiatement disponibles", n'est concluant.

Pire, chaque lecteur d'écran adopte des comportements très différents interdisant d'imaginer trouver une solution simple et efficace.

En conclusion, ces tests montrent, qu'en l'état, il n'y a pas de solution pour faire fonctionner correctement un procédé Ajax avec un lecteur d'écran.

Sale coup pour toutes ces merveilleuses applications qui doivent laver plus blanc que blanc et révolutionner le web !

Oui et non, nous dit James Edwards :

Les lecteurs d'écran ne sont pas fait pour ça; il est donc normal que ça ne fonctionne pas.

On peut imaginer (IBM travaille sur le sujet avec Window Eyes et la fondation Mozilla, notamment) qu'une adaptation technologique résolve le problème.

Une solution existe, c'est l'item WCAG 6.3 : toujours prévoir une alternative au procédé Ajax qui travaillerait de manière classique à base de rechargement de page successif.

James Edwards imaginant même de devoir donner la possibilité d'utiliser l'une ou l'autre des versions de la page en fonction de ses besoins.

Ce très bon travail de tests vient confirmer ce qu'on savait déjà sur l'accessibilité des procédés Ajax et plus généralement sur la révolution Web 2.0 : une technologie jeune, encore immature et qui doit trouver les moyens de ses ambitions.

Les tests ont été menés avec Jaws, HPR, Windows eyes, Hal et Connect Outloud.

Une archive des tests est téléchargeable afin que chacun puisse expérimenter.

Pour en savoir plus

• AJAX and Screenreaders: When Can it Work? sur Sitepoint
• Accessibility of AJAX Applications sur Webaim
• Accessible DHTML sur Mozilla Developper