Bonjour,
Ah. Voilà précisément l'une des raisons pour lesquels j'ai souhaité la création de ce salon. Ta
première question est aussi la
première vraie question à se poser 
AJAX pose de nombreux problèmes d'accessibilité et d'ergonomie, sur lesquels il y a encore aucun recul. Selon la manière dont il est utilisé (tableau volontairement noirci) :
- prévoir le fonctionnement alternatif sans javascript... mais aussi avec javascript mais sans XMLHTTPRequest . Voire également le comportement avec javascript, AJAX etc... mais sans souris, tout bêtement.
- nécessité de tester systématiquement sur le plus large éventail possible de navigateurs et de versions de navigateurs, afin de savoir précisément qui sera exclu et comment se comporte la solution de repli adoptée
- signalétique de l'interface utilisateur à inventer, pour que l'utilisateur sache immédiatement qu'il n'est pas sur une page Web au comportement "normal", et qu'il doit adopter de nouveaux réflexes. En particulier : signaler ce qui est cliquable, signaler les "zones neutres" où cliquer pour "soumettre".
- En reprenant l'approche de la WCAG2.0, on pourrait dire qu'AJAX crée constament un nouveau
contexte de navigation, et que l'utilisateur doit au moins en être averti. En revanche, il est totalement faux de postuler qu'on peut remplacer la
simplicité d'apprentissage par la
simplicité d'usage au prix d'une plus grande tolérance de l'utilisateur envers ses propres erreurs, comme le prétend
John Rhodes, repris dans le web francophone par
Fred Cavazza.
- mise en page qui "bouge", ce qui désoriente ou qui perturbe l'attention. Un contenu inséré à la volée, par exemple, ne doit pas provoquer de déplacements massifs du reste de la page... Il ne doit pas non plu s'insérer à un endroit inattendu, perturber l'action en cours de l'utilisateur, ou tout simplement s'afficher hors de la zone de visualiation suite à une utilisation imprudente de CSS (plus fréquent qu'on ne le croierait).
- très médiocre interaction avec le scroll, et pire avec la molette. Entre le moment où l'utilisateur a déclenché une action et celui où elle se manifeste, l'utilisateur peut avoir eu toutes sortes d'idées farfelues. Notemment celle de scroller parce que quelque-chose d'autre a attiré son attention. AJAX requiert parfois un utilisateur très très sage, qui ne fait que ce qu'on (ne lui a pas/lui a) expliqué qu'il pouvait faire.
- lenteur des traitements javascripts massifs sur des clients de faible capacité ou simplement occupé en même temps à autre chose.
- incitation à surutiliser GET au détriment de POST. Problèmes de sécurisation.
- incompatibilité avec les moteurs de recherche et indexation nulle ou médiocre d'un contenu AJAX
- impossibilité d'utilisation hors-connection
- impossibilité d'utiliser l'historique du navigateur
- impossibilité de conserver en signet l'état précis de la page
- relations conflictuelles avec les habitudes de l'utilisateur d'onglets
- etc.
Il y a donc beaucoup de points à examiner pour chaque application AJAX.
Plus précisément, maintenant : dans certaines applications, où le fonctionnement d'AJAX n'est pas totalement transparent et non -obstructif, je crois de plus en plus qu'il faut donner à l'utilisateur la possibilité de passer en mode "SANS AJAX" (pour tout ou partie des fonctionnalités de la page, mais sans avoir à désactiver localement javascript).
Voir par exemple notre version bêta de
Mon-Opquast où nous avons utilisé AJAX de différentes manières : nous travaillons actuellement sur ce point, pour la fonctionnalité d'édition des tableaux de suivis de qualité...
Il est finalement dommage qu'AJAX ait été introduit (ou plutôt mis au goût du jour) par Google, qui ne pouvait le faire que sur le mode "vous rentrez dans ma cible commerciale et ça passe. Sinon, tant pis." C'était un départ très handicapant, qu'il s'agit de rattraper dans les usages de cette technique...
Modifié par Laurent Denis (07 Jan 2006 - 10:49)
)
