1178 sujets

Accessibilité du Web

Bonjour tout le monde Smiley smile

J'ai conscience que cette discussion risque de déchaîner des passions, mais ça fait un moment qu'elle me démange, aussi je rappelle qu'on peut ne pas toujours être en accord les uns les autres et quand même respecter la pensée des autres Smiley cligne

Je sépare ici volontairement les deux options, je pense qu'il faut les traiter séparemment.

Bien entendu, mon avis dépend de mes compétences actuelles à mettre en oeuvre l'un et l'autre. Cet avis évoluera certainement au fil de mes progrès.

Pour les standards, je pense aujourd'hui que c'est plus long à mettre en oeuvre qu'une page codée avec des tableaux par exemple. En effet, si j'ouvre un outil comme Dreamweaver, en quelques clics, je peux créer une page complexe avec des tableaux imbriqués. De plus je n'aurais pas à me préoccuper du rendu sur différents navigateurs puisque je ne fais pas du standard.

En opposition, si j'ouvre mon éditeur de textes pour créer une page aux standards, je vais devoir rédiger toutes les lignes de code, ouvrir au moins trois navigateurs et batailler pour que ma page est un bon rendu sur ceux-ci... Et comme je suis loin de maîtriser, je ne compte pas le temps passé ici et ailleurs à chercher les réponses à mes problèmes Smiley cligne

Bien entendu, ceux qui maîtrisent déjà bien les standards gagneront déjà du temps sur certains écueils que je n'aurais su éviter.

Pour l'accessiblité, là, à mon avis, c'est du temps supplémentaire à consacrer. Il s'agit d'ajouter des éléments aux pages et parfois même de les organiser de façon différentes afin d'atteindre le but recherché.

Toutefois, afin d'éviter tout doute, je rappelle que je suis pour les standards et l'accessibilté........ et la satisfaction d'avoir accompli un travail propre est importante Smiley cligne
Pour ma part, j'ai poussé le raisonnement de la standardisation jusqu'au bout, puisque j'ai également en quelque sorte standardisé ma manière de produire.

Explication (ce n'est pas une recette magique Smiley cligne ):

Lorsque je sais que j'aurai au moins, mettons quatre ou cinq pages à écrire selon le même gabarit (par exemple, un cours sur... disons XML Smiley lol ), je me bricole une DTD ou un schéma, sans aucunement me soucier de la forme finale de la page, et produis tranquillement une première page en XML. Je me concentre uniquement sur l'information (merci XML Smiley smile ).
Ensuite j'écris ma feuille de style XSL, regarde ce que cela donne en (X)HTML.
Troisième étape, la CSS. Quelques aller-retour éventuellement avec la feuile XSL pour ajouter les identifiants nécessaires (mais en réfléchissant bien au préalable à la structure du (X)HTML, ce n'est souvent pas utile), ou ajuster deux ou trois éléments.
J'utilise ensuite ce "pipeline", et me concentre uniquement sur la production de contenu au format XML.

Oh, bien sûr, cela est long au début. Mais à terme, cela est très rentable. Je n'ai plus du tout à me soucier de la production de code standard: le parseur (beurk, quel vilain mot) XSL le fait à ma place. Je ne me concentre que sur la structure de mon cours, et sur le contenu.

Sans compter l'immense facilité de mise à jour de la page, à deux niveaux: soit le CSS si je veux simplement changer l'apparence, soit XSL+CSS si je veux également modifier la structure de la page (X)HTML de sortie.

Résultat: pour produire une page comme celle-là, il ne me faut qu'une journée (à partir de rien...).
C'est vrai qu'en amont, j'ai passé une journée à écrire la DTD, une autre pour la feuille XSL, et une demi pour la CSS Smiley confused

Ajouter toutes les contraintes d'accessibilité, et non seulement les principes de base, me prendrait probablement une autre journée. Mais je n'aurais alors pas besoin de modifier toutes les pages de mon site, l'une après l'autre: une modif sur la feuille XSL, et hop, la moulinette ferait le travail à ma place.

Donc en ce qui me concerne, les standards me font en fait largement gagner du temps.
Modifié par Gilles (18 Feb 2005 - 09:38)
dominique a écrit :
Pour les standards, je pense aujourd'hui que c'est plus long à mettre en oeuvre qu'une page codée avec des tableaux par exemple. En effet, si j'ouvre un outil comme Dreamweaver, en quelques clics, je peux créer une page complexe avec des tableaux imbriqués. De plus je n'aurais pas à me préoccuper du rendu sur différents navigateurs puisque je ne fais pas du standard.

En opposition, si j'ouvre mon éditeur de textes pour créer une page aux standards, je vais devoir rédiger toutes les lignes de code, ouvrir au moins trois navigateurs et batailler pour que ma page est un bon rendu sur ceux-ci...


Fausse question.

La question que tu poses ne concerne pas l'application des standards : tu demandes en fait si cela prend plus de temps de faire une page avec un éditeur wysiwyg qu'avec un éditeur texte.

La problématique sera en effet exactement la même que le but soit de faire une page "standard" ou non.

Et accessoirement, n'importe qui peut faire une page standard en quelques secondes avec un CMS du type dotclear (pour un blog), wikini (pour un wiki), ou je ne sais plus quoi d'évoqué récemment ici pour un livre d'or, etc.
Modifié par Laurent Denis (18 Feb 2005 - 10:24)
Administrateur
Je ne suis pas si sûr que ce soit une "fausse question" finallement.

Prenons simplement le cas de l'Accessibilité et de ses normes.

Vouloir s'y conformer signifie :
- se pencher sur les centaines de points de contrôle WCAG
- avoir des notions de comportement sur de multiples outils (lecteur braille, synthétiseur vocal, navigateurs spécifiques, etc.)
- savoir que la plupart des médias actuels se contrefichent encore des normes WCAG et interprêtent les CSS à leur manière (exemples du "display: none", clip, etc.)
- connaitre les outils de validation, leurs limites

Rien que le fait d'accumuler toutes ces connaissances est une grosse étape et prend énormément de temps. La preuve, sur ce forum spécialisé en Standards, peu d'entre-nous cpossèdent les rudiments de ces connaissances.

Une fois ces connaissances acquises, il faut les mettre en pratique. Et là, c'est encore une autre histoire !
Entre les incompatibilités et les interprétations personnelles, il faut tâtonner, simplifier, choisir une partie de la population qu'on ne pourra pas contenter, etc. Bref, beaucoup d'analyses et d'audit pour cibler la population la plus large posible en terme d'accessibilité.
Il y'a également toute une réflexion à mener sur l'accessibilité dans le sens ergonomique (place du menu, menus rapide, contraste de page, etc.)... et ce ne sont pas les outils automatiques (cms, blogs, etc) qui vont faire ces choix à votre place.

Bref : oui, faire un site accessible, donc standard, prend "un peu" plus de temps.
Modifié par Raphael (18 Feb 2005 - 11:05)
Dans le processus d'apprentissage, il est certainement plus long d'apprendre à bien coder que d'apprendre à utiliser un outil automatique créateur de soupe. Et encore heureux, manquerait plus qu'il soit plus long d'apprendre un truc crétin qu'un truc intelligent.

Par contre, une fois à connaissance égale, c'est à dire la personne sur son dreambidule ou autre, et l'autre personne avec ses connaissances et sa maitrise du sujet, la création est à mon avis aussi rapide, *perso* je met peu de temps à réaliser le codage d'un design par exemple, mais ensuite on arrive à quelque chose qu'on ne peut pas comparer, d'un côté on va tenter de faire accessible, et de l'autre on va se contenter d'en rester là. Donc forcément, ça sera plus long de faire accessible Smiley biggol

Je rejoins Laurent sur les CMS, ce sont de formidables outils à faire du bon boulot pour ceux qui n'ont pas les connaissances (pas envie, pas le temps, ... de les acquérir) pour réaliser un code propre, fonctionnel et accessible. C'est à mon avis une voix qu'il faudrait plus souligner et indiquer. Tout le monde n'a pas envie de connaitre les specs comme Laurent Smiley lol

Belle ouverture des neunoeils Laurent Smiley cligne , voilà mon prochain combat !!! Celui de vouloir faire coder correctement est vain !

<edit>
A oui un autre truc !
Il ne faut pas voir le temps pris uniquement à la création, mais aussi à la modification.
La séparation contenu/mise en forme implicitement liée à la conception aux normes et accessible permet un gain de temps énorme.
L'utilisation d'un code soigné permet d'éditer son contenu bien plus facilement. L'utilisation d'un code standard, léger et fonctionnel (et surtout sémantique) permet une plus grande facilité de gestion d'automatisation (pour les créateurs de CMS par exemple).
Modifié par Olivier (18 Feb 2005 - 11:19)
Raphael a écrit :
Je ne suis pas si sûr que ce soit une "fausse question" finallement.

Prenons simplement le cas de l'Accessibilité et de ses normes.


Faute de temps, je ne répondais que sur la conformité.

En effet, l'accessibilité est une toute autre problématique au coût et à l'investissement très différents.
Modérateur
Je ne crois pas que ce soit plus long utiliser le mode Code ou le mode Wysiwyg d'un logiciel de développement web comme Dreamweaver, à connaissance égale des langages utilisés. Évidemment, un bon vieux tableau pour faire les zones principales de l'interface évite de devoir tester dans une armée de navigateurs, mais une fois que tu maîtrise bien les CSS et que des énormités de rendu te sois arrivées, tu sais quoi faire et ne pas faire. Alors le temps supplémentaire diminu pour rendre l'interface compatible dans la majorité des navigateurs.

J'aborde aussi dans le même sens qu'Olivier. Le temps doit aussi être pensé à moyen et long terme, pas seulement à court terme. J'avais des interfaces en tableaux, et crois-moi, c'était l'horreur lorsque je devais modifier certaines choses. Je perdais beaucoup de temps.

Pour ce qui est de l'accessibilité, effectivement, c'est plus long à mettre en place. Il faut renseigner chaque intitulé de lien, ce qui n'est pas une mince affaire lorsque tu as une grosse application web et que la majorité des liens peuvent être plus explicite via l'attribut title. Tu dois t'assurer de mettre toutes les balises nécessaires pour les tableaux, positionner les éléments pour facilité la navigation, mettre des accesskeys, parfois mettre des tabindex, tester le site pour être certain qu'il soit accessible et faire la vérification dans des checklists d'accessibilité.

Bref, à moyen et long terme, je ne crois pas que c'est plus long faire des sites respectants les standards que faire des sites en tableaux (sans se soucier d'aucun standard).

Dans le fond, comme tout produit qui se veut de qualité, ca prend toujours plus de temps à faire qu'un travail fait rapidement sans souci de rien, d'aucun standard de codage ou norme de qualité. C'est plus tard que tu te rends compte de l'impact et des avantages que ca l'apporte, tant au niveau de la satisfaction d'un bon travail accompli que pour la rapidité de modification et du niveau de flexibilité de l'interface.
Modifié par Merkel (18 Feb 2005 - 15:22)
Salut,

1) Standard :
- ça peut être un chouilla plus long sur le début, mais on se rattrape sur la taille du projet
- il faut aussi compter le temps de mise à jour, d'évolution et de modification, qui là est carrément en faveur des standards. Cette remarque est valable que le code en question soit modifié par le créateur d'origine ou un autre, ce qui a son importance vis-à-vis de l'acheteur du produit.

2) Accessibilité : là c'est forcément plus long, puisqu'on se rajoute des contraintes spécifiques. Il existe de nombreuses règles WCAG, et une bonne partie ne peuvent être vérifiées que manuellement, un outil automatisé n'ayant pas de notions de sémantique.
Cependant, il est certain que le fait d'avoir au départ produit du code conforme et propre est évidemment un plus pour aller dans ce sens, puisqu'on augmente nécessairement l'accessibilité de la page (par rapport à une mise en page tabloïde) en l'épurant de tout le code de présentation, en augmentant ainsi la place de l'élément principal : l'information.
Administrateur
En fait, je crois qu'il vaut mieux ne pas faire d'embrouilles sur les termes : l'Accessibilité est un standard. Elle a ses normes W3C comme tous les autres standards.

Faire "standard" n'est pas seulement faire du XHTML (pourquoi XHTML d'ailleurs et pas HTML) + CSS.

C'est bien pourquoi j'ai pris la question au sens très large des standards et en y incluant l'accessibilité.
Mon opinion est que la séparation forme / contenu imposée par xHTML est bénéfique.
Pourquoi?
- Dreamweaver fonctionne, mais nécessite Deamweaver pour les modifications (ici, je peux vous le dire, certaines secrétaires n'ont pas appréciée de devoir rentrer dans cette usine à gaz).
- Le contenu est réutilisable, toujours. Pour l'instant, on pense XSLT, mais il y a / aura d'autres approches. Imaginons un petit site statique que l'on souhaite dynamiser un peu. Si on a tout en XML, on alimente automatiquement une base de données et réalise immédiatement une version dynamique.
- Dans cet esprit encore, et plus généralement, il faut penser à la pérennité de ce qui est mis en place. C'est bien beau de faire un beau site mais si/quand on quitte la boîte, il doit pouvoir être repris par n'importe qui.
- La séparation forme/contenu allié aux feuilles de style CSS; c'est nickel pour beaucoup d'entreprises. Quid si la charte graphique doit changer (changement de logo?)
- L'application des standards d'accessibilité, comme dit ici en est un exemple: combien de webmestres vont devoir recommencer à zéro leur site entier? (vous me direz: c'est comme l'an 2000: tout bénéf pour les informaticiens qui ont du coup du travail - n'empêche que je trouve que cela discrèdite fortement le webmestre...)
- Enfin, beaucoup d'outils / approches peuvent te permettre de gagner du temps. L'utilisation de squelettes est une bonne idée.
Juste un petit témoignage pour abonder dans le sens de Gilles (2ème post du topic).
Comme lui j'essaye de standardiser (et d'automatiser) la production des pages web. Comme lui j'utilise XSLT pour le faire, avec quelques différences cependant :

1/ sauf exception d'un contenu très spécifique, je ne bricole pas de DTD pour les contenus mais utilise directement XHTML.

2/ la feuille XSLT est paramétrique et capable de produire les différentes mises en page requises pour un site.

3/ j'utilise une couche supplémentaire qui est un fichier XML (avec cette fois une DTD spécifique, mais réutilisable pour tout site web) de description d'un site web complet. Diverses notions y sont représentées, chaque page notamment y est décrite comme un agrégat de contenus (certains contenus comme les menus sont d'ailleurs produits automatiquement) et dispose du paramètre de mise en page.

Au final l'utilisation des standards (je veux dire XML et CSS dans mon cas) est un gage de productivité tant à la création qu'à la maintenance.

Je suppose que cela rejoint d'autres interventions : avec une certaine maîtrise et une architecture ou des outils corrects le gain peut devenir important.
Modifié par Xavier (19 Feb 2005 - 23:35)
Xavier a écrit :
Juste un petit témoignage pour abonder dans le sens de Gilles (2ème post du topic).


En ajout, je précise que lorsque je parlais d'une journée pour la mise en "conformité accessible" des pages produites, je faisais référence au contexte particulier de ce site: pas de javascript, pas de flash, peu d'images... si je devais écrire de la même manière un site sur, mettons... les sites du Patrimoine Mondial, les conséquencs en temps ne seraient plus les mêmes Smiley murf

Xavier a écrit :
Comme lui j'essaye de standardiser (et d'automatiser) la production des pages web. Comme lui j'utilise XSLT pour le faire, avec quelques différences cependant :

Je me sens moins seul Smiley ravi

Xavier a écrit :
1/ sauf exception d'un contenu très spécifique, je ne bricole pas de DTD pour les contenus mais utilise directement XHTML.


J'ai préféré utiliser ici une DTD, car j'écris par exemple des codes du genre <exemple type="xsl"> ou <exemple type=javascript">. Avec des listes de balises dans tous les coins, des codes avec des < et des > partout... j'ai dû écrire une DTD pour être tranquille.

Xavier a écrit :
2/ la feuille XSLT est paramétrique et capable de produire les différentes mises en page requises pour un site.

Moi aussi. Dans la "to do list", je prévois également une sortie PDF. Mais -hum- on va attendre un peu Smiley sweatdrop

Xavier a écrit :
3/ j'utilise une couche supplémentaire qui est un fichier XML (avec cette fois une DTD spécifique, mais réutilisable pour tout site web) de description d'un site web complet. Diverses notions y sont représentées, chaque page notamment y est décrite comme un agrégat de contenus (certains contenus comme les menus sont d'ailleurs produits automatiquement) et dispose du paramètre de mise en page.

C'est intéressant; concrètement, comment procèdes-tu? Chaque contenu est-il un fichier XHTML "standalone", dont tu récupères une partie (le body ou un div particulier) pour l'agrégation? Je pensais justement, pour un de mes projets, utiliser quelque chose dans ce genre...

Xavier a écrit :
Au final l'utilisation des standards (je veux dire XML et CSS dans mon cas) est un gage de productivité tant à la création qu'à la maintenance.

Je suppose que cela rejoint d'autres interventions : avec une certaine maîtrise et une architecture ou des outils corrects le gain peut devenir important.

Oui. Nous sommes, je crois, tous d'accord là-dessus Smiley cligne .
a écrit :

Xavier a écrit :
3/ j'utilise une couche supplémentaire qui est un fichier XML (avec cette fois une DTD spécifique, mais réutilisable pour tout site web) de description d'un site web complet. Diverses notions y sont représentées, chaque page notamment y est décrite comme un agrégat de contenus (certains contenus comme les menus sont d'ailleurs produits automatiquement) et dispose du paramètre de mise en page.

C'est intéressant; concrètement, comment procèdes-tu? Chaque contenu est-il un fichier XHTML "standalone", dont tu récupères une partie (le body ou un div particulier) pour l'agrégation? Je pensais justement, pour un de mes projets, utiliser quelque chose dans ce genre...
Les fichiers de contenus sont effectivement des fichiers XML "standalone" bâtis le plus souvent avec des balises XHTML. Le fichier lui même n'est pas pour autant valide XHTML, il ne contient pas par exemple <head></head> <body></body>... Le noeud racine est un <html> qui abrite des <div><p><pre><code><h1>... enfin tout ce qu'il faut pour décrire un bout de document (d'ailleurs je ne suis pas sur qu'il soit indispensable dans le cas que tu exposes d'avoir ta propre DTD. Ne pourrais tu pas écrire <div class="xsl"> au lieu de <exemple type="xsl"> ?)
De temps en temps j'utilise une DTD propre pour des objets particuliers assez éloignés d'un fragment de document.
J'ai également des contenus (menus, plan du site, contenus redirigés) générés automatiquement à partir du modèle.

J'utilise 2 passes XSLT.
A l'analyse du modèle, la première est chargée de générer les contenus devant l'être, et de rassembler ceux écrits manuellement. J'obtiens ainsi pour chaque page du site la totalité de son contenu.
La seconde passe est chargée d'appliquer la mise en page et le style (idem ton process si j'ai bien compris).