Les standards du Web et l'étude MAMA

Posté par (page perso) . Modéré par Amaury.
Tags : aucun
26
17
oct.
2008
Internet
La firme a l'origine du navigateur Opera a conduit une très intéressante enquête sur le respect des standards du Web à travers un échantillon de plus de trois millions de pages.
Cette étude est intitulé MAMA (Metadata Analysis and Mining Application) et elle révèle un tableau assez sombre de l'état actuel du respect des standards du Web. Avant de tirer une conclusion quelconque d'une étude basée sur un échantillonnage du Web il faut s'interroger sur le choix des pages qui font partie de l'étude.
Cette question fait l'objet d'un compte rendu complet qui explique comment a été constitué la liste des 3 509 180 pages web scannées par l'étude MAMA. Initialement c'est le générateur aléatoire de Yahoo qui a été utilisé : http://random.yahoo.com/fast/ryl.
Bien que constituant un bon point de départ il a vite été nécessaire de suppléer aux défauts du générateur aléatoire de Yahoo qui ne pioche ses résultats que dans une liste statique constituée entre 2002 et 2004. Pour cela, ce sont les sites indexés par le projet DMoz qui ont été utilisés (près de cinq millions de sites en mars 2008). À cette liste on ajoute les sites des entreprises affiliées au W3C afin de voir si l'affiliation à l'organisme de standardisation du Web (World Wide Web Consortium) implique un meilleur respect des standards. La liste générée par le projet Alexa est également incluse dans l'étude MAMA afin d'obtenir un panel large et divers des pages Web existantes.

Une fois l'échantillon constitué le travail de fond d'analyse a pu commencer afin d'obtenir une vue précise de l'état actuel du Web sur le respect des standards. Une page récapitulative est présente sur le site et le détail de l'étude est également disponible sur le site d'Opera.

Le résultat le plus choquant de l'étude est que seulement 4,13 % des pages de l'étude MAMA passent l'étape de validation W3C sans erreur. Encore pire : sur les sites qui arborent fièrement les icônes de validité du W3C, il n'y en a que 50 % qui sont effectivement valides. Cela démontre qu'un site valide à un moment donné peut, au fil du temps et des changements, ne plus passer l'épreuve du validateur W3C. Il faut donc que les webmestres restent attentifs lors des modifications de leur pages.
Si on restreint les résultats aux sites des entreprises qui sont affiliés au W3C alors le taux de validation passe de 4,13 % à 20,15 % ce qui reste assez faible.
Dans le registre humoristique la pire page de l'étude MAMA est celle du site d'un obscur mouvement religieux américain qui contient près de 40 000 erreurs !

Un autre résultat intéressant concerne la prévalence de Flash sur les pages Web actuelles. Cette technologie flash est utilisée dans 33,5 % des sites (67 % dans le cas de la chine et près de 42 % pour la France). La technologie AJAX (fondée sur XMLHttpRequest) est présente dans 3,2 % des pages.
Un script (quel qu'il soit) est présent dans 74,5 % des pages de l'étude MAMA et JavaScript est la technologie qui domine largement.

D'autres résultats en bref…

  • Les pages ayant un doctype "Transitional" sont dix fois plus nombreuses que les pages de type "Strict".
  • 85 % des pages de l'étude obligent les navigateurs à passer en mode Quirk.
  • Les pages ayant été générés par Microsoft Word ont un taux de validation de 0,62 % alors que pour Apple IWeb on a un excellent taux de 81,9 %.
  • Apache est le serveur de 67,72 % des domaines (Microsoft IIS représente 25,91 %).

En définitive cette étude MAMA effectuée par l'entreprise Opera Software est une mine de renseignements sur l'état actuel du Web. On y trouve une quantité de chiffres bruts et de statistiques qui permettent de se faire une idée plus juste du triste état de la compatibilité actuelle des pages avec les standards officiels du Web.
  • # Quand on voit ça.....

    Posté par (page perso) . Évalué à 10.

    ....on ne peut qu'admirer le travail fait par les développeurs de navigateurs web pour gérer toutes les erreurs et les cas non prévus.

    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

    • [^] # Re: Quand on voit ça.....

      Posté par (page perso) . Évalué à 10.

      ... et on se demande si c'est une bonne chose d'accepter ça... après, ça se normalise, et on te regarde avec des yeux grand ouverts "mais pourquoi tu veux faire ça ? Ca marche sans !"
      • [^] # Re: Quand on voit ça.....

        Posté par (page perso) . Évalué à 6.

        Ah ça je ne peux que te pertinenter ! C'est pour ça qu'ils ont du mérite. Parce qu'une norme et trop permissive, ils en chient à mort :)

        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

        • [^] # Re: Quand on voit ça.....

          Posté par . Évalué à 10.

          C'est même pire que ça. Les dev web, bon ou mauvais sont forcément « récompensés. » C'est comme si, qu'importe les erreurs de syntaxe ou problèmes de typage, ton compilo te générait des programmes qui s'exécutent tout le temps, qui segfault jamais, mais qui pourraient parfois renvoyer quelques valeurs fausses, mais pas très éloignées d'une valeur correcte…

          Mouais, c'est un mauvais exemple, on a déjà Visual Basic pour ça.
  • # Problème

    Posté par (page perso) . Évalué à 10.

    Perso, je développe uniquement en respectant les standards de manière stricte... mais je peux tout à fait comprendre que des sites ne soient plus valides s'ils ne sont pas maintenus par des développeurs rompus aux standards !

    L'exemple type : on fait un site qu'un client peut administrer, et il faut bien lui laisser un peu d'options pour mettre en forme ses textes... et bien évidemment, malgré TOUT ce qu'on va lui expliquer qu'il faut faire et ne pas faire POUR son intérêt (y compris installation d'extension Firefox, formation et consorts), vous pouvez être sûr qu'il va arriver à pondre du code non valide.
    (PEM : Principe d'Emmerdement Maximum, aussi appelé loi de Murphy)
    Des fois, je demande même au client s'il peut s'en passer, et là c'est plus simple, code XHTML non autorisé !

    Qui plus est, les clients s'en foutent... à chaque fois, j'explique les enjeux, et à chaque fois... "oui oui", mais ça sort par l'autre oreille.

    Une voix dans le désert...

    La seule solution vraiment extrême mais qui marche est de servir le site en application/xhtml+xml... mais aller expliquer au pékin lambda que son site ne va plus s'afficher correctement à la moindre erreur.

    Bref, impossible d'imposer ça à un client, d'ailleurs, le seul site auquel j'ai pu appliquer ça, c'est le mien...
    • [^] # Re: Problème

      Posté par (page perso) . Évalué à 5.

      La seule solution vraiment extrême mais qui marche est de servir le site en application/xhtml+xml... mais aller expliquer au pékin lambda que son site ne va plus s'afficher correctement à la moindre erreur.

      Ni sous Explorer, qui ne connaît pas ce content-type.
      • [^] # Re: Problème

        Posté par (page perso) . Évalué à 4.

        Il semblerait d'ailleurs que ce soit le fait d'un développeur, qui, considérant qu'ils n'avaient pas de parseur XML digne de ce nom à proposer, a préféré explicitement refuser ces contenus plutôt que de les accepter et de les traiter imparfaitement.

        Le résultat est tout de même identique, dans la mesure où cela oblige ceux qui veulent faire du XHTML 1.1 strict à ajouter une règle pour le servir à tort comme text/html à Explorer.

        Vivement qu'ils le prennent en charge, ça fait quoi, 8 ans de retard, pour le moment, non ?
      • [^] # Re: Problème

        Posté par (page perso) . Évalué à 7.

        Ni sous Explorer, qui ne connaît pas ce content-type.

        C'est pas faux, mais peut-on encore considérer cette chose comme un navigateur ? ;-)
        Oui, d'accord, la part de marché ! ;)

        Quand je vois les grosses entreprises qui ont fait des choix tout krosoft pour leurs intranets (ASP, activex, code tout cracra), rien que de passer à IE7 sous XP est une gageure pour leurs technards certifiés.

        Alors qu'une migration de navigateur sur un site standard... est quasi-transparente (on fait une vérification pour la bonne conscience, et encore, quand on y pense, ce sont des problèmes qui n'existent quasi-plus).
        Quand je discute avec leurs technards, j'ai l'impression qu'on ne parle pas le même langage et qu'on ne vit pas dans le même monde.
        Enfin, chacun ses choix.

        (mode évangélisation on)
        Autant pour moi si j'ai omis de dire ça (même si mon propre site envoie bien à IE du text/html !), c'est juste que je fais systématiquement une installation de Firefox chez les clients qui ne l'ont pas (avec tout plein de bons arguments pour leur site et leur machine adorée, le discours est rodé)... pas de pitié, si on veut se débarrasser de cette bouse d'IE, tous les moyens sont bons !

        Un utilisateur d'IE s'éteint, et un site web s'éveille...
        (mode évangélisation off)
    • [^] # Re: Problème

      Posté par (page perso) . Évalué à 3.

      Je suis allé voir ton site web, il est en effet valide aux yeux du W3C.
      Je le trouve vraiment bien foutu au niveau de la forme et on voit bien que tu fais une vrai séparation entre le fond et la forme de ton site ; la section skin est très ludique et chaque skin change complètement la forme, c’est bluffant.

      Cependant, ce que je trouve dommage, c’est qu’il manque tout de même des attributs « alt » au niveau des images, surtout en ce qui concerne le menu. Ton site est peut-être valide, mais pas suffisamment accessible (lynx, aveugles, toussa). D’ailleurs, il me semblait que c’était une recommandation du W3C de mettre des « alt » à ce niveau.

      Pour info : http://openweb.eu.org/articles/accessibilite_images
      • [^] # Re: Problème

        Posté par . Évalué à 6.

        Non il est très accessible du point de vue de images etc (déséctive les feuilles de style et tu verras) par contre il ne l'est pas du point de vue des contrastes... il faudrait renforcer la lisibilité du menu et de quelques images (l'écriture blanche sur fond gris clair... pas terrible)
        autrement c'est nikel coté compatibilité avec les navigateurs vocaux ou braille.

        concernant la recommandation de mettre des "alt" ça n'est utile que lorsque l'image remplace du texte. dans le cas des menus, le texte est présent dans le code html, il est simplement déplacé/cahcé par la feuille de style et une image est utilisée à la place du texte pour constituer le lien à l'écran. Donc, si tu regardes bien, il n'y a pas de balise img dans son menu, l'image est ajoutée en fond de chaque entrée du menu via feuille de style. c'est d'ailleurs la méthode à utiliser pour être certain d'être ok niveau standards et accessibilité.
        • [^] # Re: Problème

          Posté par (page perso) . Évalué à 2.

          Mea culpa… En effet, j’avais pas fait gaffe dans le code qu’il n’y avait pas de balise img et qu’il y avait des span avec du texte en rapport aux images (d’ailleurs ces span s’« activent » pour certains skins).
          css Zen Garden¹ — qui est une référence sur l’utilisation des CSS — utilise cette méthode.

          Au niveau accessibilité/visibilité du site, il y a certains skins qui permettent d’avoir un meilleur contraste.

          ¹ : http://www.csszengarden.com/
          • [^] # Re: Problème

            Posté par . Évalué à 0.

            je comprends pas bien le moinssage (à l'heure où j'écris le message de la canette était à 0)...
  • # Et linuxfr?

    Posté par . Évalué à 10.

    La page d'acceuil de linuxfr ne valide pas non plus...
    N'étant pas développeur web, je ne comprends strictement rien aux messages d'erreurs qui semblent indiquer que les erreurs viendraient des balisent < p > qui apparaitraient dans un mauvais contexte...
    est-ce quelque chose facile à résoudre par les devoppeurs de templeet?
    • [^] # Re: Et linuxfr?

      Posté par . Évalué à 3.

      C'est pour ça que le bas de page dit:

      "Cette page est peut-être conforme xhtml 1.0."

      :)
    • [^] # Re: Et linuxfr?

      Posté par . Évalué à 4.

      Il me semble que les problèmes de validations de Linuxfr viennent des contenus des utilisateurs.

      Par exemple cette page est pour l'instant valide, mais il suffit d'un post avec une balise pas fermée ou d'un chevron pas échappé et c'est le drame ...
  • # La validation n'est pas un but en soi

    Posté par . Évalué à -3.

    Ce sont des résultats très intéressants, mais il ne faut pas oublier que la validation n'est pas un but en soi, et la communauté Web commence à revenir du "tout standard".

    Sur le sujet, on peut lire avec profit l'article récent de Molly Holzschlag, paru sur A List Apart :
    http://alistapart.com/articles/webstandards2008
    • [^] # Re: La validation n'est pas un but en soi

      Posté par . Évalué à 10.

      Non, ce n'est pas un but, c'est un impératif. En suite, comment la communauté du Web pourrait revenir du "tout standard" alors que les chiffres montrent qu'elle ne l'a jamais été ?

      Pour en venir aux critiques sur le W3C. Certainement que le processus n'est pas parfait. Certainement qu'on peut changer des choses. Mais dire que le W3C va pas assez vite, la blague. La majorité des webdev sont pas capable d'être à jour, ils sont bien calfeutré dans leurs (mauvaises) habitudes et à sauter sur une techno top-moumoute alors qu'ils sont pas capable de produire du code HTML 4 décent. Et le web évolue tellement vite qu'il faut encore prendre en compte IE6 quand tu fais un site web, tellement ce monstre ideux sorti en 2001 est encore utilisé. Conbien de fonctionnalité de CSS 2.1 ne peut-on même pas utiliser pleinement ? Beaucoup trop.

      A ce rhytme, l'utilisation de CSS 3 sur un site grand public, c'est pour 2020. Le W3C peut initier n'importe quelle technologie révolutionnaire, si les webdev veulent pas obliger les gens à utiliser un navigateur récent et décent, on se trainera des limitations vraiment merdiques encore longtemps. Les gens craches bien les thunes pour avoir le dernier téléphone portable ou la dernière télé HD-ready, ils peuvent comprendre que si ils veulent un Web moderne, il leur faut un navigateur moderne.

      Quand je dis que c'est un impératif de produire du code valide, c'est par ce que c'est la garantie d'avoir un document intéropérable, et traitable aussi bien par un humain que par un programme. Oui, c'est la garantie que _toi_ tu as fait ce qu'il fallait. Tu ne devrais pas produire du code biaisé, pour un système biaisé. Si les protocoles et les formats sousjacent au Web (TCP/IP, HTTP, DNS) se permettaient d'être aussi folklorique que la page web moyenne, on consulterait pas souvent des pages web.

      Tout les jours je dois pondre du code non valide pour que ça fonctionne sur tout les navigateurs. Passer du temps pour comprendre les bugs de rendu de tel ou tel navigateur, etc (et bizarrement, le dernier de la classe, c'est toujours IE). Et c'est plus fatigant que de produire du code propre et valide.

      Le jour où les moteurs de rendu te rembaleront ton site parce que tes pages ne sont même pas bien formée, à la XHTML 1.1, on avancera.

      Et à ce moment là, on pourra juger de la valeur des standards actuels et envisager l'avenir du Web.
      • [^] # Re: La validation n'est pas un but en soi

        Posté par . Évalué à 6.

        Je plussoie !

        Aujourd'hui, j'ai laissé complètement tomber la compatibilité avec cette m...e de IE6 tant j'en ai ras la caisse de passer des heures à faire du bugware. Je l'ai expliqué clairement à mon boss : "Ecoute, on peut pas continuer comme ça, tel template Joomla passe sous IE6 révision n et pas sur la rév n-1. Je ne peux pas passer des heures à faire de la validation à chaque entrée d'article pour vérifier que ça continue à passer". Aujourd'hui c'est Firefox, Opera ou IE7. Et on met un disclaimer en entrée et des badges "Get Opera" ou "Get Firefox" sur les sites :D
      • [^] # Re: La validation n'est pas un but en soi

        Posté par . Évalué à 2.

        Le web, je connais, t'inquiète pas :-)

        La seule chose que je dis, c'est que les standards du W3C ne sont pas un but en soi. Je dis bien "dans la vraie vie".

        Alors, évidemment qu'il faut s'en rapprocher, je ne les rejette pas ! Mais on peut faire un site standard à base de tableaux ! On peut faire un site standard avec des <br> et des <font> !

        Les principes fondamentaux à appliquer aujourd'hui, c'est plutôt :

        - la structuration sémantique des sites web, sans la pousser à outrance. Voir à ce sujet l'excellent article de Vincent Valentin : http://www.htmlzengarden.com/2008/10/fil_d_ariane_et_semanti(...)

        - le concept d'amélioration progressive, le principe étant qu'un site web doit pouvoir être utilisé par tous. Les standards du web en sont certes l'une des clés, mais pas la seule.

        Voilà pourquoi je disais que la validation n'est pas un but. Alors, certes, ça aide à trouver des bugs, mais au final, il ne faut pas tout baser là-dessus.
        • [^] # Re: La validation n'est pas un but en soi

          Posté par . Évalué à 6.

          Ce n'est pas le but, on est d'accord là dessus.

          Avoir un document valide n'est pas une fin, ça n'en fait pas un "bon" document pour autant, mais c'est une condition fondamentale.

          A quoi bon ajouter des données sématiques dans un document syntaxiquement erroné ? Crois-tu franchement que quelqu'un qui n'est pas capable de produire des documents correctement formés va utiliser correctement les éléments sémantiques ? Va-t-on se retrouver avec un interpréteur Microformat "mode Quirk" ou autres joyeusetés ?

          Du moment que le document doit être interprété par un programme, l'importance du respect du standard est prépondérante. Et l'exploitation des informations sémantiques ne peut pas se faire sans. Ajouter de la sémantique à un document non-conforme est idiot.

          En outre, les éléments de (X)HTML ont une valeur sémentique pour bon nombre. Alors faire une mise en page avec des <table/> est erroné, bien que syntaxiquement valide.

          La validité des documents est la pierre angulaire d'un web interopérable et riche.
          • [^] # Sémantique et

            Posté par . Évalué à 2.

            Je n'ai jamais compris pourquoi les gens refusent <br>.
            Un retour à la ligne a parfaitement sa place dans un texte, je le fais personnellement tout le temps. Et c'est différent de l'ouverture d'un nouveau paragraphe.

            Je trouve ça très énervant tous ces systèmes de wiki et de blogs qui ne permettent pas de retour à la ligne. C'est vraiment l'horreur pour rédiger quoi que ce soit.
            Enfin, dans la plupart des cas, on peut quand même placer explicitement un retour à la ligne avec un caractère spécial, mais je comprends pas pourquoi \n n'est souvent pas automatiquement remplacé par <br> et \n\n par </p><p>.
            • [^] # Re: Sémantique et

              Posté par . Évalué à 1.

              C'est simple : c'est parce que dans la majorité des cas, <br> était utilisé pour des mauvaises utilisations, genre paragraphe.

              Mais évidemment, il peut avoir encore sa place sans problème dans un site web moderne, pour une utilisation simple: tu veux faire un saut à la ligne, sans sémantique associée.

              Il faut avouer que le cas reste, à mon avis, rare. Dans pas mal de cas, il y a tout de même une séparation sémantique, et même si ce n'est pas un paragraphe, ce peut tout de même être un <div>, ce qui structure mieux et peut te permettre de styler cette partie.

              Après, il y a des cas où <br> peut quand même être utilisé, pourquoi pas ?
            • [^] # Re: Sémantique et

              Posté par (page perso) . Évalué à 3.

              Un retour à la ligne n'a pas sa place dans un texte en prose. On distingue des paragraphes et des phrases, mais rien entre les deux.
              • [^] # Re: Sémantique et

                Posté par (page perso) . Évalué à 4.

                Ah, et puis une raison de ne pas utiliser les retours à la ligne dans un texte en prose : on ne peut pas être sûr qu'ils seront visibles, par exemple si la ligne se termine à la fin de la ligne, justement.

                C'est également la raison pour laquelle les styles par défaut d'OpenOffice.org et de Microsoft Office craignent complètement : les paragraphes n'ont rien qui permette de les distinguer (alinéa, ou à la limite espace vertical), et du coup les gens mettent un paragraphe vide pour séparer les leur…
                • [^] # Re: Sémantique et

                  Posté par (page perso) . Évalué à 0.

                  Dans OpenOffice les paragraphes sont légèrement séparés quand même. 0.21 cm par défaut je crois.
                • [^] # Re: Sémantique et

                  Posté par . Évalué à 2.

                  les paragraphes n'ont rien qui permette de les distinguer (alinéa, ou à la limite espace vertical), et du coup les gens mettent un paragraphe vide pour séparer les leur…

                  C'est aussi le résultat d'une mauvaise habitude qui s'est généralisée il y a longtemps, poussant les rédacteurs à vouloir faire de la mise en forme en même temps qu'ils rédigent. Alors ils ajoutent un paragraphe vide au lieu de modifier l'espacement inter-paragraphe plus tard.
              • [^] # Re: Sémantique et

                Posté par (page perso) . Évalué à -1.

                Mais mais mais, que fais tu de la liberté des écrivains? Blaise Cendrars par exemple va souvent à la ligne sans que ce soit considéré (notamment par les typographes) comme un changement de paragraphe.
                Et d'autre part, après deux points?

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

                • [^] # Re: Sémantique et

                  Posté par . Évalué à 0.

                  Après deux points, on en met un troisième, ou bien on utilise etc. mais faut PAS UTILISER LES DEUX.

                  Sinon, on a aussi <ul> et ses <li> pour s'amuser. Avec une ptite CSS, on peut même avoir la liste des trucs derrière les « : » affichés comme une phrase en français correct…
                  • [^] # Re: Sémantique et

                    Posté par . Évalué à 5.

                    <cite>Sinon, on a aussi <ul> et ses <li> pour s'amuser.</cite>

                    Et que dire lorsqu'il manque <ul> en permanence...


                    Désolé...

                    Pardon? Ok, je --> [ ]
            • [^] # Re: Sémantique et

              Posté par . Évalué à 2.

              Heu...


              Mais qui est contre le <br/> ?
              • [^] # Re: Sémantique et

                Posté par (page perso) . Évalué à 2.

                Moi, en tout cas contre la façon dont loufoque les utilise. D'ailleurs, à propos, loufoque, dans tous les cas, il faut écrire <br/> et non <br>. :-)
                • [^] # Re: Sémantique et

                  Posté par . Évalué à 1.

                  Sauf si tu fais du HTML4 ;-) (ce qui est parfaitement légitime)
                  • [^] # Re: Sémantique et

                    Posté par (page perso) . Évalué à 1.

                    Mais moche.
                    • [^] # Re: Sémantique et

                      Posté par . Évalué à 2.

                      Je vois ce que tu veux dire par là.

                      XHTML1 _est_ du HTML4 XMLisé. C'est tout.

                      On peut faire un site parfaitement valide en HTML4, parfaitement sémantique, et beau ! (La beauté étant du côté des CSS, le choix de HTML4 ne change rien).

                      Et puis d'ailleurs les navigateurs lisent la plupart des sites XHTML1 en tant que HTML4, faute de mime-type approprié. Et ça marche bien comme ça.

                      Bref, explicite ta phrase ;)
                      • [^] # Re: Sémantique et

                        Posté par (page perso) . Évalué à 2.

                        C'est simple : je trouve laid le fait d'utiliser la même syntaxe pour les balises auto-fermantes que pour les balises enveloppantes, et source d'erreurs, en plus.
        • [^] # Re: La validation n'est pas un but en soi

          Posté par . Évalué à 7.

          Alors, évidemment qu'il faut s'en rapprocher, je ne les rejette pas ! Mais on peut faire un site standard à base de tableaux ! On peut faire un site standard avec des <br> et des <font> !

          Le défaut du site à base de tableaux, c'est que ça peut devenir assez vite effroyable à naviguer avec une tablette braille...

          Un des gros problèmes de nombreux web designers c'est qu'ils ne connaissent pas assez de malvoyants.

          Un bon site web au niveau accessibilité est un site web qui, quand on retire les stylesheets, s'affiche comme un document texte peu ou pas formaté... et ce n'est pas si difficile à obtenir (et pour un web designer pro, acquérir la compétence pour le faire n'est jamais chose perdue)
          • [^] # Re: La validation n'est pas un but en soi

            Posté par . Évalué à 3.

            Je vais me faire l'avocat du diable ;) (parce que je sais bien que les tableaux, c'est Mal, je le dis assez au taf)

            J'avoue que je n'ai jamais utilisé de tablette braille mais j'ai pas mal utilisé JAWS, et il se débrouille plutôt bien avec les sites en tableau. Notamment, il arrive à "deviner" dans la plupart des cas qu'un tableau est un tableau pour de la présentation, et auquel cas, il n'en parle pas. Le problème dans cette phrase, c'est bien "dans la plupart des cas" ;-)

            Par ailleurs, avec l'avènement de ARIA, et l'utilisation adaptée de labels, on peut rendre un site accessible même avec des tableaux.

            Pour une utilisation avec JAWS, l'un des points fondamentaux est la structuration avec des titres, ce qui permet une navigation transverse dans la page.

            Je cherche juste à nuancer ici certaines croyances parfois un peu catégoriques, que je croyais justes il y a encore peu. Dans l'absolu, je suis pour l'éradication totale des tableaux (et autres) :-) Mais dans la vraie vie, malheureusement, certaines personnes dont il faudrait couper les bras continuent à les utiliser, et JAWS, heureusement pour les utilisateurs mal/non-voyants du web, arrive de mieux en mieux à les gérer correctement.
            • [^] # Re: La validation n'est pas un but en soi

              Posté par . Évalué à 5.

              Ah, c'est clair, c'est important de pointer qu'il y a des outils reformulant les pages pour les malvoyants, mais s'il y a moyen de faire les choses correctement dès le début et ne nécessitant pas de soft supplémentaire, je préfère y passer un peu de temps plutôt que de devoir ensuite réintégrer une logique supplémentaire dans mes pages, au risque d'oublier des éléments.
    • [^] # Re: La validation n'est pas un but en soi

      Posté par (page perso) . Évalué à 3.

      Le gros problème (et ça a été très bien expliqué dans un article sur Openweb) est le suivant : http://openweb.eu.org/articles/conformite_validation_surqual(...)

      Où s'arrêter dans la recherche de qualité, face à des impératifs de temps et de coûts ?

      La seule solution actuelle est d'inclure une démarche qualité dans le projet de manière continue... pondre du code valide, sémantique, et maintenir le niveau de qualité élevé (que ce soit à la pogne ou via des CMS qui offrent cette possibilités).

      ça va si tu as des projets où tu peux avoir cette maîtrise (tu as un ou plusieurs développeurs rompus à ces techniques), mais sur certains projets, ça peut vite être compliqué si un intervenant ne maîtrise pas ça.

      Perso, j'ai fait le choix de presque faire de la surqualité parce que je maîtrise mes solutions de A à Z, mais il suffit d'un maillon faible dans la chaine, et le processus de qualité se gauffre lamentablement.
  • # CMS

    Posté par . Évalué à 7.

    Les systèmes de gestion de contenu ont peut-être l'inconvénient d'uniformiser les sites web persos (quand on a installé un MediaWiki, on a pas forcément le courage / le temps / l'envie d'apprendre CSS pour le personaliser), mais au moins ça peut améliorer les choses côté respect des standards.

    J'ai installé un MediaWiki, il passe le test sans erreur. Evidemment, ça interdit pas un utilisateur de venir mettre n'importe quel code html dégueulasse dans une page. Enfin je crois.

    J'ai installé un phpWebGallery, ça passe moins bien (14 erreurs, 5 warnings sur une page de garde vierge). Du bug à remonter pour que ça soit corrigé...
    • [^] # Re: CMS

      Posté par (page perso) . Évalué à 2.

      Ouais bah je veux pas dire mais va mater le code de la page d'accueil de wikipedia france. Aller je suis bon prince je te copies quelques lignes

      {{Accueil/titre}}
      <!-- ===================================================== -->
      {|width="100%" cellspacing="0" cellpadding="0" style="margin-top:0.6em"


      Pour ceux qui se demandent, le {| en langage media wiki, ça veut dire fait moi un tableau. En l'occurence un tableau bien gruik.
      • [^] # Re: CMS

        Posté par . Évalué à 1.

        Ca a pas l'air d'incommoder le validateur :
        http://validator.w3.org/check?uri=http%3A%2F%2Ffr.wikipedia.(...)
        • [^] # Re: CMS

          Posté par (page perso) . Évalué à 5.

          Parceque le validateur, il te dit si syntaxiquement ta page est correct, rien de plus. Un tableau, tu doit l'utiliser pour présenter des matrices, dans les endroits où si c'était un document papier, tu prendrais ta règle pour dessiner un tableau de données. Ici ce n'est pas le cas, il faudrait utiliser des div.
  • # Tiens...

    Posté par (page perso) . Évalué à 3.

    Tiens, personne ne parle de nano-merde... Enfin si, l'autre, ça parle un peu de IE...
    • [^] # Re: Tiens...

      Posté par (page perso) . Évalué à 3.

      Pourquoi devrait-on en parler ? Il s'agit ici de normalisation, donc s'il y a bien un logiciel qui est hors sujet, c'est bien Explorer, le sous-navigateur qui empêche encore de faire du XHTML 1.1 strict…
    • [^] # Re: Tiens...

      Posté par (page perso) . Évalué à 2.

      D'ailleurs, je viens d'y penser, ce logiciel-là porte un nom trompeur, parce que ce n'est pas un navigateur Internet, ce qui n'a aucun sens, mais un navigateur Web… :-)
      • [^] # Re: Tiens...

        Posté par (page perso) . Évalué à 2.

        il ne gère pas le ftp:// ?
        • [^] # Re: Tiens...

          Posté par (page perso) . Évalué à 2.

          « Gère », c'est vite dit. Et dans la même phrase qu'un pronom désignant le navigateur de l'Empire, ça pique un peu les yeux. :-)
          • [^] # Re: Tiens...

            Posté par (page perso) . Évalué à 3.

            j'aurais pu mettre "supporte", mais ce n'est pas le bon terme et c'est moi qui ne supporte pas IE, ma déontologie m'interdisant de l'utiliser au boulot (bon, pour télécharger Firefox j'ai dû le lancer au moins une fois il y a longtemps, je ne sais pas pourquoi il n'y a pas wget accessible facilement de CMD.exe :/).
            • [^] # Re: Tiens...

              Posté par . Évalué à 2.

              Si tu veux faire le geek, t'as un ftp dans cmd.exe
              Un peu lourd a utiliser, mais juste pour dl un .exe, il fait l'affaire.

              :-P
  • # Est-ce seulement notre faute ?

    Posté par (page perso) . Évalué à 4.

    Je développe un petit site sympa, dans mon petit coin (
    http://harmonie.aix.free.fr/ ), pour mettre des photos, des dates de concerts, etc.
    Tout est en XHTML 1.0 Strict, autant que possible, et j'en profite pour tester des trucs sémantiques (vevent, etc.).
    J'en ai eu tellement marre de supporter IE6 que je le bloque tout simplement, en proposant de passer à IE7 ou Firefox (je pense qu'au bout de 4-5 pages comme ça, le visiteur mets à jour).

    Seulement voilà, pour rendre le tout un peu interactif, j'ai voulu faire en sorte qu'on puisse facilement trouver l'adresse.
    Un lien vers Google Maps, c'est bien mais pas top, puisque la mode c'est de mettre la carte directement dans la page.
    Et donc voilà, je mets une balise object, donc théoriquement la page est valide (c'est ce que dis le validateur).

    Mais en pratique, l'object en question c'est du text/html non-valide.
    Le validator voit cette page valide, mais une fois la carte chargée, l'extension Firefox affiche 145 erreurs :
    http://harmonie.aix.free.fr/contact.php5

    Donc même avec la meilleure volonté du monde, il y a toujours un moment où on doit faire un compromis pour rester "compétitif" aux yeux du visiteurs (qui connait Google Maps mais pas le W3C).

Suivre le flux des commentaires

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