Ajax et moi.

Accessibilité et interface enrichie sont-ils faits pour s’entendre ?
On entend beaucoup parler depuis quelques temps d’accessibilité d’un côté et de « client riche » de l’autre, autrement dit d’interfaces web rafraîchies à la sauce Ajax and Co. Mais les deux sont-ils faits pour s’entendre ? J’ai testé pour vous sur un gros projet d’intranet métier.

Ajax-killer

Premier paradoxe : Alors qu’Ajax amène en théorie une fluidité nouvelle dans les échanges client-serveur (par des requêtes http cachées, comme avec Flash), on est vite confronté à un problème de volume. Car si cette technique est en théorie robuste si elle est bien codée, à l’usage on se heurte vite à un gros mur : le navigateur.
S’appuyant sur une utilisation intensive des CSS et du DOM, Ajax sollicite BEAUCOUP (trop ?) le navigateur. Vos belles listes dynamiques vont vite s’essoufler, quand elles ne vont pas buguer : affichage en vrac, perte de styles, instabilité, sans parler des bugs de compatibilité avec les navigateurs un peu en retard d’un métro pour ce qui est de l’implémentation des standards… D’où en général une implémentation coûteuse en temps.

Deuxième paradoxe : ces composants présentent une ergonomie tellement révolutionnaire qu’elle en devient perturbante pour l’utilisateur, qui a du mal à s’y retrouver avec ces nouvelles fonctions. Au final ce sont les fonctions améliorant la gestion de l’espace dans la page qui s’avèrent les plus agréables. Vous savez, les collapse/expand tous bêtes qui existent depuis des années. La profusion de fonctions sur certains composants se révèle contre-productive.
Tant que ces nouveaux outils n’auront pas été assimilés par les utilisateurs, mieux vaut signaler un champ enrichi de fonctions Ajax par un icône spécifique ou une couleur de champ particulière. Tout bête, mais le désengorgement des hotlines tient parfois à peu de choses.

Troisième paradoxe : Alors qu’on associe communémment le Web 2.0 et l’accessibilité, il s’avère que les fonctions « riches » génèrent la plupart du temps un code tout à fait… »inacessible ». Cela peut poser de gros problèmes, de référencement en premier lieu. Pas forcément une bonne idée pour un site public, donc. Curieux que des outils censés nous faciliter la vie aillent à l’encontre des standardisations (fort saines) amenées par l’accessibilité.

Morale de l’histoire : pour tirer pleinement partie de ce qu’apporte Ajax, il faut y consacrer beaucoup de temps, mais savoir résister à la tentation de rentabiliser le temps passé en mettant tout et n’importe quoi à la sauce Ajax. En d’autres termes, le mieux est – en matière d’interface web – l’ennemi du bien.


Publié

dans

par

Étiquettes :

Commentaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *