Working together for standards The Web Standards Project

WaSP : Se battre pour les standards

Le W3C (World Wide Web Consortium) et d’autres groupes et organismes de standardisation ont établi des technologies pour la création et l’interprétation de contenu Web. Ces technologies, que nous appelons “standards du Web”, ont été conçues pour offrir tous les avantages du Web au plus grand nombre tout en s’assurant de la pérennité de tous les documents publiés sur le Web (se reporter à l’encadré pour plus de détails).

Concevoir des sites Web avec ces standards est plus simple qu’avant leur avènement et contribue à réduire les coûts de production, tout en offrant des sites accessibles à une plus large audience et une plus grande diversité de moyens d’accès à Internet. Les sites développés en suivant ces principes continueront à fonctionner correctement avec les navigateurs traditionnels sur les ordinateurs de bureau, alors que de nouveaux outils d’accès à Internet apparaissent sur le marché.

Tout cela semble tomber sous le sens. Alors, où est est le problème, et pourquoi un tel Web Standards Project ?

Le Problème

Même si les principaux éditeurs de navigateurs ont été impliqués dans la création des standards du Web depuis la création du W3C, la conformité à ces standards resta très imparfaite pendant des années. En fournissant des navigateurs qui supportaient mal les standards, les éditeurs ont participé à la fragmentation du Web, nuisant ainsi aux designers, aux développeurs, aux entreprises et aux utilisateurs.

L’absence de support uniforme des standards du W3C a généré de la frustration chez les utilisateurs : parce qu’en utilisant le “mauvais navigateur”, beaucoup ne pouvaient pas voir le contenu ou effectuer la transaction demandée. Parmi les utilisateurs les plus touchés se trouvent les handicapés et les personnes ayant des besoins spécifiques en terme d’accès.

Le dilemme et les coûts

En même temps, le manque de support des standards du W3C a mis les graphistes, les développeurs et propriétaires de site face à un terrible dilemme : peut-on se permettre financièrement d’implémenter plusieurs versions de chaque page web en vue de supporter autant de navigateurs incompatibles ? Si non, quels navigateurs devraient être sacrifiés, et à combien de millions de visiteurs potentiels déciderait-on de refuser l’accès ?

Dans tous les cas, le coût était trop élevé, et l’est toujours à l’heure actuelle.

La fragmentation du marché des navigateurs ajoute au moins 25% au coût de développement de tous les sites. Par manque de budget, beaucoup de développeurs ont produit des sites fermés à des clients potentiels. Beaucoup de développeurs qui connaissaient les standards ne voyaient pas l’intérêt de développer des sites pour des navigateurs qui ne les supportaient pas. D’autres ne connaissaient rien ou presque aux standards, et c’est toujours le cas, même dans les sociétés de service qui semblent à la pointe des technologies comme ASP, Java, Flash MX et .Net, sans pour autant comprendre balisage structurant (“structural markup”), les feuilles de style, et l’intérêt de séparer la structure de la présentation.

Certains concepteurs, bloqués par l’incompatibilité des navigateurs, ont délibérément oté toute technologie de leur site, à part les plus anciennes et les plus universelles, sacrifiant fonctionnalité et intérêt pour l’utilisateur au profit de la compatibilité avec tous les navigateurs.

D’autres ont utilisé des éditeurs graphiques et des outils de publication pour générer plusieurs couches de code optimisées pour les défauts des principaux navigateurs. Cela a gâché de l’argent et de la bande passante, et bien souvent généré des sites qui ont cessé de fonctionné avec la nouvelle génération de navigateurs (et n’a jamais fonctionné dans les navigateurs et matériels alternatifs, des synthétiseurs vocaux à Lynx, en passant par les assistants numériques connectés et des navigateurs moins répandus comme Opera). Le Web est encombré de cadavres de sites ayant été impressionnant dans leur temps, mais qui ne fonctionnent plus avec les navigateurs ou matériels modernes. Le pire, c’est que de tels sites sont encore construits tous les jours…

Certains développeurs ont été tellement frustrés qu’ils ont fait fi des standards et ont commencé à développer exclusivement dans des environnements propriétaires. Bien que riches en potentiel créatif, de telles technologies manquent d’une grande accessibilité, et ne répondent pas à des besoins rudimentaires telles que la possibilité de mettre un signet, d’imprimer, de faire du copier/coller, et d’autres tâches que les utilisateurs peuvent effectuer sur des sites traditionnels.

La fonction crée l’organe

En réaction à ces problèmes, le Web Standards Project (WaSP) a été formé en 1998 avec pour objectif la promotion des principaux standards du web, tout en encourageant les éditeurs de navigateurs à faire de même, offrant ainsi un accès simple, peu coûteux et universel à l’information.

Même si notre message n’a pas toujours été le bienvenu auprès des départements Marketing et Relations Publiques des éditeurs de navigateurs, il a fini par l’emporter : en partie parce que les ingénieurs de beaucoup d’éditeurs de navigateurs étaient du même avis que nous et ont considéré le WaSP comme un allié dans leurs batailles internes contre leur hiérarchie.

Début 2000, les éditeurs ont tenu les promesses faites par les standards, promesses dont nous avions assuré -parfois bruyamment- la promotion. Les principaux navigateurs du marché actuel, ainsi que leurs concurrents, offrent un excellent support de HTML4, XHTML 1, CSS, ECMAScript (la version standardisée de JavaScript) et du DOM—ou sont sur le point de le faire.

Grâce à ces navigateurs, concepteurs et développeurs ont enfin la liberté de construire avec XHTML et CSS, et dans la plupart des cas, peuvent séparer la structure de la présentation pour augmenter la portabilité et l’accessibilité. Dans une certaine mesure, les concepteurs et développeurs peuvent aussi utiliser le DOM standardisé du W3C pour ajouter des fonctionnalités sophistiquées à leurs sites.

Alors, qu’est est le problème, et pourquoi y a-t-il toujours un un tel Web Standards Project ?

Ce qui nous attend

Même si les navigateurs d’aujourd’hui supportent les standards, des milliers de concepteurs professionnels et développeurs continue d’utiliser des méthodes archaïques liant intimement structure et présentation, ignorant parfois complètement la structure sémantique et utilisant mal (X)HTML comme outil de conception. Des professionnels bien payés bidouillent des sites invalides et inaccessibles bourrés de balisage structurellement vidé de sens, d’énormes images cliquables, de tables imbriquées et de scripts de détection obsolètes provoquant des problèmes d’utilisabilité qu’ils étaient précisément censés éviter au départ.

Beaucoup de livres sur le développement Web continuent d’enseigner des méthodes dépassées, et beaucoup de professionnels tirent fierté du fait qu’ils fabriquent des sites qui fonctionnent de façon identique dans les navigateurs conformes et non-conformes, au dépend de l’accessibilité, de la viabilité sur le long terme et de la compatibilité ascendante. D’autres développent du code propriétaire qui ne fonctionne que dans quelques navigateurs répandus.

Ainsi, l’un des objectifs premiers du WaSP est de fournir des moyens éducatifs à l’attention de nos pairs, pour qu’ils apprennent comment dé en respectant les standards, ce qui est autant leur intérêt que celui de leurs clients et des utilisateurs.

Beaucoup de concepteurs utilisent dans leur travail des environnements graphiques de développement, conçus à l’apogée de la guerre des navigateurs. Comme mentionné précédemment, ces outils créent par défaut des sites invalides et non sémantiques, optimisés pour les défauts des navigateurs en version 4.0, plutôt que pour les standards. En 2002, deux des principaux outils graphiques ont considérablement amélioré leur support des standards Web et de l’accessibilité. (L’un des deux l’a fait avec l’aide du Web Standards Project). Mais pour utiliser ces améliorations, les concepteurs doivent apprendre les bases et l’intérêt de la conception et de la construction de sites respectant les standards, ce qui nous mène au besoin de former les développeurs.

Les clients et les responsables de sites ont, eux aussi, besoin de cette information s’ils souhaitent créer des sites qui soient accessibles par les navigateurs et outils d’aujourd’hui, et qui resteront viables quand ces navigateurs et outils évolueront. Le WaSP espère qu’une fois informés, les responsables de sites arrêteront de les considérer comme des variantes electroniques de plaquettes publicitaires qui doivent être identiques dans tous les environnements ; et qu’il se consacreront plutôt à fournir du contenu et des fonctionnalités appropriés variables en fonction des besoins et possibilités des différents navigateurs et outils d’accès à l’information.

Mission originelle

La mission originelle du WaSP, de 1998 est disponible sur archive.webstandards.org.

© 1998-2002 Web Standards Project, www.webstandards.org

© 2002 Tristan Nitot pour la traduction. http://standblog.org/