ASK : Un framework Ajax accessible

Posté par  . Modéré par Mouns.
Étiquettes :
0
28
oct.
2007
Internet
L'Ajax Source Kit, a.k.a ASK, est un framework Javascript orienté accessibilité. En effet, il a été développé avec l'objectif suivant :

"The purpose of ASK is to offer you a simple way to get content into your page on-the-fly through asynchronous JavaScript and XmlHttpRequest, without sacrificing accessibility or usability"

Ce qui peut se traduire par: « L'objectif de ASK est de vous offrir une solution simple pour actualiser votre page à la volée en utilisant Javascript et XmlHttpRequest, sans pour autant perdre en accessibilité ou en utilisabilité »

En effet, de plus en plus de sites se mettent à la mode « 2.0 » et sacrifient divers aspects :
  • Gestion des bookmarks ;
  • Gestion des fonctions suivant, précédent, rafraîchir ;
  • Accessibilité de certains navigateurs ;
  • Accessibilité pour les clients n'utilisant pas Javascript.

Il suffit de surfer quelques temps avec l'extension NoScript de Firefox pour vite s'apercevoir que tous les webmaistres n'envisagent pas le minitel 2.0 du même point de vue.

ASK est donc une manière élégante et légère (8 Ko) d'implémenter l'Ajax sur votre site, tout en limitant les sacrifices d'accessibilité.

NdM : la licence est précisée en entête du script. L'auteur a précisé qu'il n'avait pas approfondi la question de la licence et qu'il n'avait rien contre changer pour une licence open-source si cela avait un intérêt. D'autre part, l'intégration de ASK à votre site est relativement simple. Il suffit de :
  • Inclure ask.js dans votre page: ;
  • Ajouter deux choses aux liens que vous souhaitez faire agir dynamiquement :
    • La classe CSS ask ;
    • La classe CSS target-idOfTargetElement, où idOfTargetElement est l'ID de l'élément de la page que vous souhaitez mettre à jour

Un exemple de lien utilisant ASK, qui présentera le contenu dynamiquement dans l'élément target :
Get countries
ASK présente les fonctionnalités et restrictions suivantes :

Navigateurs supportés :
  • IE 5+
  • Firefox 1.0+
  • Safari 1.2+
  • Opera 8+

La fonctionnalité d'historique ne fonctionne pas avec les navigateurs suivants :
  • IE 5.0
  • Safari
  • Opera 8.0, pas du tout. Dans Opera 8.5+, le comportement n'est pas stable à 100% avec le bouton 'suivant'.

La fonctionnalité de bookmarking ne fonctionne pas avec les navigateurs suivants :
  • IE 5.0

Chapeau bas à l'auteur, Robert Nyman, qui en plus propose d'autres scripts intéressants :

Aller plus loin

  • # lien enrhumé

    Posté par  . Évalué à 3.

    Un exemple de lien utilisant ASK, qui présentera le contenu dynamiquement dans l'élément target :
    Get countries


    le lien n'est pas complet, ça ne marche pas!
    voici le vrai: http://www.robertnyman.com/ask/content.php?continents=true&a(...)


    Apparemment, ça marche bien avec Konqueror (3.5.8) aussi.

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: lien enrhumé

      Posté par  (site web personnel) . Évalué à -2.

      En effet si cela fonctionne avec Safari, ce serait idem pour Konqueror !
      • [^] # Re: lien enrhumé

        Posté par  . Évalué à 5.

        Ben non, ce n'est pas évident:
        l'historique ne marche pas avec Safari, en revanche il marche avec Konqueror.
        Ce n'est d'ailleurs pas très surprenant: Konqueror évolue en permanence tandis que Safari ne change qu'avec les nouvelle versions de MacOSX.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: lien enrhumé

        Posté par  (site web personnel) . Évalué à 2.

        Absolument pas !

        Il ya de vrais grosse différences entre les 2. Surtout niveau "chargement" (tout ce qui se passe en gros avant le "onload").

        En fait même Safari 3 entre la version Mac et Windows il y a des différences. Archetype semblerait ne pas fonctionner sur la version Mac (néanmoins on a très peu d'informations et pas de Mac pr debugger :'( ) alors qu'elle fonctionne comme un charme sur la version Windows.

        Sinon, personnellement je préfèrerais que les gens se concentrent sur l'intègration de moteur javascript (spider monkey, rhino ...) dans les navigateurs "accessibles" pour l'accessibilité plutôt que de se limiter dans ce qu'il font, alors qu'à part le chargement javascript, les applications peuvent facilement être accessibles ...

        Pour moi arrêter de faire du javascript car les navigateurs accessibles ne le supportent pas est débile :/

        P.S.: Je suis d'ailleurs tout à fait pret à aider un projet dans ce sens s'il en existe ! ;)
    • [^] # Re: lien enrhumé

      Posté par  . Évalué à 2.

      Le problème de lien est du à un problème dans le système de post de DLFP...
      J'ai ouvert une entrée dans le système de suivi pour cela:
      https://linuxfr.org/tracker/685.html

      pour résumer: a chaque fois que l'on post un message sur dlfp, on passe le contenu du message 'à la moulinette'(tm) (boutons vérifier, valider).
      Cette moulinette à l'avantage de supprimer toutes les balises que l'on ne souhaite pas et c'est très bien. Cependant, si je souhaite écrire une balise interdite en tant que texte, j'utilise alors les codes html des caractères, ainsi la balise n'est pas reconnue.
      Le problème c'est que les caractères encodés sont décodés par la moulinette, et donc interprété au deuxième passage (validation)...

      donc par exemple, pour réussir à afficher cette balise script, j'ai du la reéditer après l'étape de vérification pour remplacer les balises par leur code html correspondant juste avant la validation.
      <script type="text/javascript" src="js/ask.js"></script>
  • # Amélioration possible

    Posté par  (site web personnel) . Évalué à 2.

    Au départ j'avais mal compris le fonctionnement de ce "framework" AJAX.

    En fait, j'avais pensé qu'en indiquant comme class "ask target-bidule" pour un lien, il allait récupérer via AJAX (XmlHTTPRequest) le résultat de la requête et qu'il allait dans ce résultat récupérer le contenu de la balise d'identifiant "bidule" pour la remettre dans la balise d'identifiant "bidule" de la page. Et ensuite j'ai découvert que dans content.php il y avait des "if" pour afficher ou non le contenu selon ce qu'il y avait dans la requête et si on était ou non en mode AJAX :(

    Vous allez me dire "Mais à quoi ça sert d'envoyer tout le contenu pour en récupérer juste un bout ?". A cela je réponderais : "Pouvoir profiter simplement d'une des fonctionnalités offerte par AJAX sur des applications-webs dont il serait coûteux de toucher au code : le non-rechargement de la page".

    En effet, en indiquant via "target-bidule" les zones que l'on veut récupérer, cela permetterait d'éviter des rechargement inesthétique de page. Ok on dépense autant de bande passante, mais ce n'est pas incompatible avec une mise à jour futur du code où à l'appel d'une requête on filtre le contenu selon la requête pour n'envoyer que le nécessaire. Bref, on profite des fonctionnalités d'AJAX en 2 temps : d'abord le non-rechargement, ensuite si on a le temps de toucher fortement au code de la réduction des échanges.

    Le pied serait aussi de pouvoir avoir plusieurs target : class="ask target-bidule target-machin" avec le parsing qui va bien.

    Sinon, je vois qu'il manque le support des requête en POST, c'est à dire la soumission des formulaires. Dommage car ce n'est pas rare d'en trouver. Cela pourrait se faire via la gestion d'évènement sur les onSubmit car beaucoup d'applications-webs utilisent du javascript pour soumettre les formulaires au changement d'une zone via onChange par exemple.

    Si quelqu'un développe mon idée concernant un parsing via DOM au retour de la requête pour mettre à jour uniquement les targets, je lui offrirais mon plus grand respect :)

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # C'est ça le progrès!

    Posté par  . Évalué à -3.

    Bof l'argument "Accessibilité pour les clients n'utilisant pas Javascript.". Faut vivre à son époque tout de même sinon on roulerait encore avec une botte de foin dans le coffre pour le cheval!. Pourquoi pas "Sans bugs pour IE7" tant qu'on y est!!!
    • [^] # Re: C'est ça le progrès!

      Posté par  . Évalué à 3.

      Mais c'est ce qui est fait dans beaucoup de framework, des fixs pour les bugs de ie6/7 et même pour d'autre navigateur :)
    • [^] # Re: C'est ça le progrès!

      Posté par  . Évalué à 8.

      C'est vrai que les aveugles on en a rien à foutre hein, ils ont qu'a avoir des tablettes braille qui supportent le javascript.
      Et les personnes déficientes moteur n'ont qu'à apprendre à pointer avec la langue, la navigation au clavier c'est un truc du siècle dernier!

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.