XHTML 1.0 et accessibilité

Le bon sens en marche contre l'intégrisme

Un article qui résume très bien ma position est l'excellent W3C go home. Ne nous méprenons pas, l'idée n'est pas de dire que les normes du W3C sont à jeter à la poubelle. Au contraire. Simplement, depuis l'apparition de certains illuminés qui ne jurent que par le 100% conforme XHTML 1.0 et traînent dans la boue des sites (qui parfois respectent une norme, simplement pas la "dernière") il est bon de recadrer le débat.

Une information diffusée conformément aux formats et normes préconisées, c'est bien. Mais mieux vaut une information diffusée dans un format un peu bancale que pas d'information du tout. Typiquement je connais plein de passionnés de course à pied longue distance qui font leur sites persos avec Microsoft Word et exportent en HTML. Oui le code HTML ainsi généré est dégoûtant. Oui ils utilisent souvent des frames alors qu'il ne faudrait pas. Oui ils sont souvent en contradiction avec les règles d'accessibilité élémentaires. Mais qui peut leur jeter la pierre? Ce sont des hommes et des femmes qui ont une passion, la course à pied, et qui veulent la partager avec les autres. Pour cela ils utilisent les moyens qu'ils ont à leur disposition. Et c'est très bien comme ça.

Il est absurde et faux de dire qu'une page HTML codée "à la papa" avec des tableaux pour la mise en forme est illisible. Elle est peut-être moins lisible, c'est peut-être moins élégant, mais ça a le mérite d'exister.

Je reprends mon exemple des coureurs à pied. On va me dire "mais il n'y a qu'à leur apprendre...". Il n'y a qu'à rien du tout, quand on voit ce que demande en terme de temps et d'investissement la préparation à une course de type 100km ou 24h à pied, on peut comprendre que les participants n'aient pas envie de faire une formation avancée XHTML 1.0 et CSS2.

Récemment l'argument massue des défenseurs des normes devient l'accessibilité. Et si jamais on ose avoir l'outrecuidance de dire que "finalement c'est pas si grave si on utilise des tableaux pour..." on se fait renvoyer dans ses buts vite fait bien fait. Pour un peu on passerait pour l'odieux personnage qui pense que les aveugles, les handicapés moteurs et autres n'ont qu'à circuler (y'a rien à voir!).

C'est on ne peut plus faux. Bien sûr qu'on souhaite que l'information soit accessible au plus grand nombre. Et je suis le premier à faire mon possible pour que mes sites soient accessibles. Mais je ne peux faire que mon possible. Je n'ai qu'un temps restreint. Donc pendant des années j'ai trimballé derrière moi des casseroles, des vieilles pages HTML plus ou moins pourries mais que je n'avais simplement pas le temps de mettre à jour ni de mettre en conformité. Mais en attendant ces pages étaient disponibles, et en ligne. Suis-je pour autant un salaud qui méprise les handicapés? J'en doute.

Du coup à force de voir tout ce débat malsain sur la conformité XHTML 1.0 strict CSS2 accessible niveau 3 et tout le tralala, j'ai décidé de boycotter les logos du W3C et du WAI, et donc vous ne verrez jamais sur mes pages UWiKiCMS les boutons jaunes bien connus, même si souvent ils pourraient y avoir leur place.

Fin du coup de gueule.

Dans tous les cas, UWiKiCMS a été l'occasion pour moi de rattraper un certain retard. Loin d'être parfait, il respecte plutôt bien la norme.

XHTML 1.0 et CSS2

Pour ce qui est de la conformité XHTML, normalement UWiKiCMS génère du code compatible XHTML 1.0 strict. Ceci étant (voir l'explication plus haut) il est tout à fait possible que sur certaines pages il y ait des erreurs. C'est d'autant plus probable que comme UWiKiCMS autorise l'inclusion de pages PHP arbitraires, tous les coups sont permis.

Si j'ai tenu à faire du XHTML 1.0 ce n'est pas pour pouvoir pavaner avec un logo, c'est simplement parce que je pense que c'est un bon moyen de créer des pages perennes qui seront bien rendues sur les navigateurs de demain.

Je passe régulièrement les pages au valideur HTML, dans l'ensemble les rapports ne sont pas trop mauvais.

Concernant les feuilles de style CSS2, elles me permettent de relooker le site à moindre frais. J'en profite pour dire que ceux qui prétendent que le support CSS fonctionne parfaitement et qu'il peut se substituer à la mise en page par tableaux que:

  • ils se trompent
  • vous avez vraiment essayé avec IE6 ou vous vous moquez de moi?
  • je leur dis zut

Dans tous les cas vous pouvez toujours essayer de passer les CSS d'UWiKiCMS au valideur CSS.

Accessibilité

La meilleure arme d'UWiKiCMS pour respecter les normes d'accessibilité, c'est sa simplicité et son dépouillement. Pas de gadgets, pas de problèmes. Je passe régulièrement des outils de validation type Bobby / Webxact, et j'essaye de valider un maximum de tests. La structuration en XHTML 1.0 permet une bonne linéarisation, et j'essaye d'être très vigilant sur tout ce qui est tags ALT ou autres.

En outre, j'utilise régulièrement UWiKiCMS avec lynx ou links, pour la bonne raison que certains de mes ordinateurs tournent en mode console uniquement, et donc je peux garantir à 100% que tout fonctionne en mode non graphique. Ca ne prouve bien sûr pas du tout que le site est accessible, mais je pense que c'est toujours un point positif.

Le seul écart notable que je m'autorise, c'est que le style par défaut de mon site est fait de tel façon que sur l'événement HOVER les liens et bordures d'image "grossissent". Ca fait un effet sapin de noël qui me fait beaucoup rire mais qui est parfois une catastrophe en matière d'ergonomie. Il faut vivre avec ses contradictions 8-) Dans tous les cas, désactiver le support CSS résoud le problème instantanément.

Page générée par UWiKiCMS 1.1.8 le vendredi 29 mars 2024.
Copyright © 2005 Christian Mauduit. Document placé sous licence GNU FDL.
Mis à jour le jeudi 02 juin 2005.