• Présidentielles et accessibilité

    Par divarvel dans Web Development le 16 Avril 2007 à 18:17
    La campagne présidentielle 2007 a marqué l'intérêt que portent les candidats à la sphère internet.
    Tous les candiats sans exception ont mis en place un site internet pour soutenir leur campagne.
    Je me suis demandé quels sites respectaient le plus les standards web, et l'accessibilité.
    J'ai commencé par tester la validité des sites, puis j'ai regardé un peu plus en détail la manière dont était codés quelques sites.

    La validité

    Sans grande surprise, aucun des sites ne respectent la validité de leur code, certains n'ont même pas de doctype (!).

    La qualité du code (X)HTML

    Le site sarkozy.fr , bien que non valide, et pourvu d'un design organisé par tableaux, n'est pas très loin de la validité, les seules erreurs proviennent de l'affichage des flash, affichage qu'il est difficile de rendre valide (le code d'insertion fourni par marcromedia ne l'est pas). Le site est pourvu d'un doctype, les balises sont en minuscules, les images ont un attribut alt.

    Le site desirsdavenirs.org réussit à condenser 12 erreurs sur la page d'accueil, qui n'est qu'une simple introduction. Ce site ne comporte même pas de doctype, comporte des "<SCRIPT LANGUAGE="JavaScript">" (!!) et n'utilise aucune balise sémantique pour marquer les titres et les contenus. Seule une balise <strong> est perdue au mileu de ce code ignoble.

    Grosse déception aussi pour le site de François Bayrou, 108 erreurs à la validation (!!!), des balises en majuscules, des div à la place de balises sémantiques, et pourtant ils ont mis un doctype (XHTML 1.0 transitional tant qu'à faire ^^). Décevant.

    Le dernier site que j'ai regardé, c'est celui de Besancenot. Du grand art ! Les communistes manchots qui l'ont codé on commencé par mettre le doctype à la ligne 8 (et puis un doctype XHTML, tant qu'à faire) En fait le code commence par "<HTML><HEAD><TITLE>" oulah. On est tombé sur des champions. Ouais pasque les balises en majuscule c'est trop la classe ! xD Après les meta, ya le doctype, et une réouverture des balises html, etc. Ils ont pas été foutus de relire leur code. Et on enchaine direct sur un <script language="javascript"> erk. Quelques lignes de JS, du CSS et là stupeur : </HEAD>. Donc c'était pas une erreur, c'est effectivement des champions. Et ça continue avec les balises en majuscules, un design en tableaux, évidemment, des div et des span au lieu de hn et strong, ou autres em, des alt jamais spécifiés dans les images... Non seulement c'est mal codé, mais en plus d'une manière qui restreint l'accessibilité aux personnes handicapées... Et cette vermine rouge se dit solidaire... A vomir

    Voilà voilà, c'était mon analyse personelle, en furetant un peu je suis tombé sur cette page : http://fr.opquast.com/etudes/candidats-2007/

    Ca recense de façon plus approfondie tous les critères qui font la qualité d'un code (X)HTML.
    Leurs conclusions rejoignent les miennes, à savoir  que le site de sarkozy est le moins pire, et celui de Besancenot le pire.

    L'accessibilité web a des progrès à faire....

    6 commentaires

  • Redesign #2

    Par divarvel dans Web Development le 10 Avril 2007 à 23:10
    Chose promise, chose dûe, voilà la bête !
    Pardon encore pour les clichés ^^

    7 commentaires

  • Redesign

    Par divarvel dans Web Development le 9 Avril 2007 à 20:46
    RedesignJe suis en train de vous concocter un nouveau design, très web 2.0 (évidemment).

    J'ai eu envie d'accumuler les clichés, donc ne vous offusquez pas, si vous trouvez que ça fait too much, c'est parce que c'est du second degré... (Macaron, boutons "glossy").
    J'ai mis le header, sachant que la charte graphique en découle, donc des tons bleu pastel réhaussé par du orange. Si c'est à chier, dites le moi vite svp ;)

    8 commentaires

  • Manipuler le xHTML par JS

    Par divarvel dans Web Development le 13 Mars 2007 à 16:01
    Pour obtenir une page dynamique sans rechargement complet, il faut pouvoir la manipuler par JS.
    Exemple : Un formulaire qui traite toutes les informations par JS, un bouton pour cacher/afficher un bloc de texte, des "fenêtres"... Les possibilités sont illimitées (pour les fenêtres, utilisez un framework :p)

    Etape 1 : Etiqueter la page
     Pour que JS puisse s'y retrouver dans votre page xHTML, la manière la plus simple est de donner des id aux balises.

    <p id="nomLabel">Texte</p>
    <div id="nomLabel2">Bloc de page</div>

    Si vous le pouvez, utilisez toujours des balises sémantiques, pas la peine de charger sa page de div et de span inutiles si des balises adéquates existent.

    Etape 2 : Accéder à la page par JS
    Pour accéder par JS à une balise étiquetée, c'est la fonction getElementById();

    var element = document.getElementById("nomLabel");

    Ensuite, on peut faire plein de trucs avec cette variable element, récupérer/modifier ce qu'il ya  à l'intérieur de la paire de balises (innerHTML), modifier ses attributs CSS (afficher/masquer par exemple), récupérer la valeur dans le cas d'un <input > d'un form.

    alert(element.innerHTML);
    alert(element.value); //Si la balise est de type input
    element.style.display = "none"; //Masque le bloc
    element.style.border = "1px solid red"; //Bidouiller les propriétés CSS
    element.className = "nomClasse"; //Modifier la classe CSS appliquée à l'élément

    De façon générale, les attributs CSS gardent leur nom en JS, sauf s'ils contiennent des tirets (z-index devient zIndex par exemple)

    Vous avez déjà de quoi faire un formulaire géré par JS, et pas mal de bidouillis.


    Exemple : un bouton qui affiche/masque un bloc de texte.
    Code xHTML

    <p id="texte" style="display : none;">Lorem ipsum dolor sit amet, etc...</p>
    <a href="javascript:void(0);" onclick="toggleText(this);">Afficher le texte</a>

    Code JS

    function toggleText (link){
        var element = document.getElementById("texte");
        if (element.style.display == "none"){
            element.style.display = "block";
            link.innerHTML = "Masquer le texte";
        }else{
            element.style.display = "none";
            link.innerHTML = "Afficher le texte"; 
        }
    }

    Voilà. Ce que j'ai fait est affreux sur un plan accessibilité, car quiconque n'a pas activé JS ne verra jamais le texte. Le mieux est de faire un texte visible par défaut, d'appeler juste après un bout de JS qui aura pour fonction de le cacher. Comme ça, celui qui a JS ne le verra pas par défaut, et pourra faire joujou avec, mais celui qui n'a pas JS activé le verra. (L'important c'est de transmettre des infos, plus que de pouvoir les cacher/masquer)

    Voilou, j'espère que ce tuto assez basique vous sera utile !

    1 commentaire

  • PG et la prog

    Par divarvel dans Web Development le 11 Février 2007 à 20:08
    Graaaaaaah ! Déjà qu'elle y connait rien en info, maintenant elle se mêle de programmation... Snif.
    Déjà on programme avec Maple. Pour ceux qui connaissent pas, Maple c'est un formidable outil de calcul formel, associé à un piteux langage de programmation. Toutes sortes d'instructions non standard, une gestion des boucles... pathétique, et une syntaxe générale qui me rappelle le pascal. (vous savez, ce truc qu'on utilisait il ya longtemps)
    Pour un soft qui sort régulièrement avec des versions de plus en plus performantes, c'est déprimant.

    Bon, ça c'est l'intro.

    La nouvelle marotte de PG, c'est de dire qu'il ne faut pas se servir des fonctions natives de Maple. (en gros de se priver de son seul intérêt)
    Mais le pire, c'est le pourquoi de cette étrange décision.
    "C'est plus rapide de recoder les fonctions, le programme sera plus rapide" (sic!)
    Donc, pour résumer, voilà le fonctionnement de Maple.
    Il parse le code pour repérer les erreurs.
    Il l'interprète, le compile et enfin l'exécute.
    Par quel MIRACLE, utiliser une fonction native précompilée et over optimisée serait-il plus lent que de
    faire interpréter puis compiler puis utiliser une fonction. Ca implique que le temps d'interprétation et de compilation soit négatif. Problème.

    Deuxièmement, sur un plan moins technique, je voulais parler du comportement général du programmeur.
    Un comportement bien (que je m'efforce de respecter) consiste à aérer son code, indenter, éviter les astuces™ foireuses de programmation, de faire des bouts de code réutilisables, mettre des noms de variables explicites, bien sûr à commenter, bref respecter le lecteur éventuel.

    Le programmeur qui code pour lui pourrait à la limite ne pas suivre ces conventions (bien que je ne lui conseille pas), mais quand on est professeur, ça devient indispensable.
    Surtout que la majorité des élèves ne connaissait pas la programmation avant le premier cours de cette année.

    En gros, voilà ce qu'il ne faut pas faire (en règle générale, mais surtout lorsque c'est un "corrigé") :

    Racine_carré :=proc(a,e)
         local p,c,q,em,b,n,f,u;
         p:=0; c:=1; while c<a do p:=p+1; u=2*u od;
         u:=1; q:=0; while 2*q<p-2 do q:=q+1; c=2*c od;
         em:=e/(3*u); b:=1/5;f:=proc(x,a)  ;(x*x+a)/(2*x) end;
         print(p,q,'valeurs_initiales_choisies u0_et_u1_sont', u, 'et', evalf(f(u,a)));
         u:=f(u,a); n:=1;while b>em do n:=n+1;b:=b*b;u:=f(u,a) od;
         print('valeur_approchée de_racine_de_',a,'est', evalf(u));
         print('valeur_obtenue_en_',n,'_iterations');
         print('valeur_approchée_donnée_par_maple', evalf(sqrt(a)));
         end;
    Voilà le code à la PG, featuring plusieurs instructions par ligne, la proc sous définie en plein milieu d'autres
    instructions, aucune indentation, aucun commentaire.
    Comment donner envie aux gens de programmer. Bravo. Clap Clap.

    Racine_carré :=proc(a,e)
      local p,c,q,em,b,n,f,u;
      p:=0;
      c:=1;
      while c<a do# On approxime rapidement le premier terme de la suite par des puissances de 2
       p:=p+1; c=2*c
      od;
      u:=1;
      q:=0;
      while 2*q<p-2 do# On calcule u0=2^E(p/2)
       q:=q+1; c=2*c
      od;
      em:=e/(3*u);#Calcul visant à obtenir la précision de l'approximation
      b:=1/5;
      f:=proc(x,a) # Fonction dépendant d'un paramètre
       (x*x+a)/(2*x);
      end;
      print(p,q,'valeurs_initiales_choisies u0_et_u1_sont', u, 'et', evalf(f(u,a)));
      u:=f(u,a);
      n:=1;
      while b>em do#Tant que la précision voulue n'a pas été atteinte
       n:=n+1;b:=b*b;u:=f(u,a)
      od;
      print('valeur_approchée de_racine_de_',a,'est', evalf(u));
      print('valeur_obtenue_en_',n,'_iterations');
      print('valeur_approchée_donnée_par_maple', evalf(sqrt(a)));
     end;
    Voilà un code un peu plus clair
    Enfin bon c'est pas à moi de faire son boulot, mais ya des fois ça m'énerve

    5 commentaires


    Suivre le flux RSS des articles de cette rubrique
    Suivre le flux RSS des commentaires de cette rubrique