Ordre de tabulation cohérent

Hello,

J'ai un tutoriel sur le feu sur la réalisation d'un design fluide en trois colonnes avec deux flottants. Le code HTML proposé sera comme suit :

<div id="gauche">...</div>
<div id="droite">...</div>
<div id="centre">...</div>

Les deux premiers blocs étant flottants, et ayant une largeur spécifiée (en pixels ou pourcentages), tandis que le dernier (bloc central, accueillant probablement le contenu principal de la page) est statique, sans largeur spécifiée.

Suite à une question sur la concordance de l'ordre visuel (lecture de gauche à droite) avec l'ordre de tabulation, j'ai rédigé l'encart suivant pour le tutoriel :

a écrit :
Un point sur la navigation au clavier et l'ordre de tabulation : en navigant de lien en lien avec le clavier, l'ordre de tabulation (c'est à dire l'ordre dans lequel les liens sont sélectionnés, un par un) suit l'ordre du code HTML. Avec la construction proposée ci-dessus, on devra donc passer tous les liens des colonnes latérales, avant d'arriver au bloc central.

Certains critères d'accessibilité déconseillent ce type de structure. C'est le cas par exemple du Guide Accessiweb, dont le critère 10.3 (niveau Bronze) est formulé ainsi : Avec les feuilles de style désactivées, l'ordre d'apparition de l'information est-il respecté par rapport à l'ordre d'apparition initialement défini ?

Ce critère fait cependant débat. Certains lui préfèrent la notion de cohérence de l'ordre de l'information : si l'information est cohérente aussi bien en mode graphique qu'avec les feuilles de style désactivées, il n'y a pas de problème d'accessibilité majeur.

Une dernière chose : si vous placez de nombreux liens dans les colonnes latérales, il peut être utile de placer dans votre page des liens d'évitement ou des liens d'accès rapide permettant de sauter les colonnes latérales ou d'accéder directement au contenu principal. Voir à ce propos l'article de Jean-Pierre Villain : les liens d'évitement.

J'ai écrit ça en me souvenant vaguement d'un échange à ce sujet sur Alsacréations (pas remis la main dessus). Il me semble que Laurent y disait que le critère Accessiweb en question était une extrapolation propre à Accessiweb. J'ai tenté de parcourir les WCAG 1.0 ainsi que les points de contrôle et tests du RGAA (ouille la tête ), sans trouver de critère équivalent. Serais-je passé à côté ?

Globalement, que pensez-vous de cet encart ? Comment faudrait-il le corriger (s'il faut le corriger... mais c'est probable) ?

Merci d'avance pour vos lumières.
Modifié par Florent V. (18 May 2007 - 09:45)

oui et non, contrairement à accessiweb le rgaa n'interdit pas sur un trois colonne d'avoir un ordre de tabulation différent de l'ordre visuelle, ce qui est important c'est que l'ordre soit cohérent par exemple que tu ne commence pas à naviguer dans une bloc d'information donnée puis que tout à coup tu change pour aller dans une bloc completement différent puis que tu revienne à celui d'avant.

Je te conseil de lire :
http://www.rgaa.referentiels.modernisation.gouv.fr/index.php/front/web/points_de_controle/6_1

je trouve les exemples assez parlant (et je dis pas ça parcque c'est moi qui les aient fait )
Modifié par goetsu (18 May 2007 - 11:20)

Super, c'est bien ce que je pensais. Les exemples sont effectivement bien parlants.

Pour mon encart, vu qu'il s'agit d'un tutoriel pas spécifiquement orienté accessibilité, est-ce qu'il faudrait :
- modifier une ou deux phrases et rajouter un lien vers le point de contrôle 6.1 du RGAA ?
- juste dire que « tant que l'ordre des informations est cohérent, ça ne pose pas de problème d'accessibilité » et ne pas rentrer dans les subtilités Accessiweb & co ?

libre à toi de suivre tout de même les conseils d'accessiweb qui ne sont pas mauvais mais beaucoup plus contraignants en terme d'utilisation des CSS pour construire tes gabarits.

Pour ma part, j'inverserais l'ordre de rédaction pour parler d'abord du RGAA + lien vers pc 6.1 + parler des liens d'évitement indispensable dans certains cas puis dire que pour aller plus loin on peut suivre accessiweb.

Attention tout de même, je rappelle que c'est pas la version définitive du RGAA donc on ne sais jamais, si tout le monde renvoie des commentaires négatif sur ce point de contrôle, il peut etre amené à changer.

Merci Aurélien pour tes lumières.

Version corrigée :

a écrit :
Un point sur la navigation au clavier et l'ordre de tabulation : en navigant de lien en lien avec le clavier, l'ordre de tabulation (c'est à dire l'ordre dans lequel les liens sont sélectionnés, un par un) suit l'ordre du code HTML. Avec la construction proposée ci-dessus, on devra donc passer tous les liens des colonnes latérales, avant d'arriver au bloc central.

Ceci n'est pas particulièrement problématique, à partir du moment où l'on respecte les principes suivant : les informations, lues dans l'ordre du code HTML, doivent rester compréhensibles, et on tâchera de proposer un ordre logique de parcours au clavier. On veillera donc à ce que l'ordre des « colonnes » dans le code HTML soit cohérent, afin que le document soit lisible même si les styles CSS sont désactivés.

Dans l'idéal, on préfèrera cependant un ordre du code HTML qui correspond à l'ordre visuel de lecture. Le Guide Accessiweb en fait d'ailleurs un critère d'accessibilité (Fiche 10.3) : « Avec les feuilles de style désactivées, l'ordre d'apparition de l'information est-il respecté par rapport à l'ordre d'apparition initialement défini ? ». Par contre, la construction présentée dans ce tutoriel ne permet pas de gérer ce critère. Si on doit le respecter, on lui préfèrera d'autres techniques, à base de positionnement absolu, d'utilisations légèrement différentes des flottants, ou encore... d'un tableau de mise en page avec trois cellules.

Voili voilou. Je donne juste le lien vers le point de contrôle du RGAA en mentionnant le principe général (paraphrase -- vaguement ciblée -- de l'intitulé du point de contrôle), ce qui devrait éviter les surprises en cas de légère modification du RGAA sur ce point.

Par contre, le laïus sur l'article de Jean-Pierre est passé à la trappe, pour éviter d'avoir un encart trop lourd.
Modifié par Florent V. (19 May 2007 - 11:34)

Bonjour,

a écrit :
Suite à une question sur la concordance de l'ordre visuel (lecture de gauche à droite) avec l'ordre de tabulation

Tu a raison de te référer à RGAA 6.1, en revanche ce n'est pas le seul tests pour valider le rendu de la structure.

Il faut également référer à RGAA 9.4 :

a écrit :

Point de contrôle : 9.4 Proposer un ordre logique de parcours au clavier

Au sujet de Accessiweb 10.3

La synchronisation ordre de lecture et ordre de la représentation imposé par Accessiweb 10.3 résoud, par effet d'escalier, l'ordre de navigation au clavier.

En revanche ce n'est pas le but initial de ce critère qui devrait évoluer suite au débat engagé dans le cadre du groupe de travail d'évolution des critères.

Jean-Pierre

Mais heu !
Pourquoi donc tant de subtilités pour ma pauvre petite tête ?

J'avais effectivement vu le point de contrôle 9.4 du RGAA. Je vais le rajouter comme référence. Par contre, pour Accessiweb, je ne détaille pas plus que ce que j'ai mis, sinon je dois faire un article à part sur la question. Et comme là tout de suite je rédige un article sur un technique de positionnement CSS, ça me semblerait un peu excessif.

Je corrige ci-dessus.

Bonjour,

a écrit :
Pourquoi donc tant de subtilités pour ma pauvre petite tête ?

Héhé, ça interroge beaucoup sur les modèles de structure CSS toutes faites et leur condition d'application

Ton exemple est typique : faire flotter la colonne droite avant le contenu pose inévitablement le problème du contenu et de la logique du discours.

Et du coup WCAG/RGAA 6.1 et 9.4 et son extrapolation Accessiweb 10.3

Jean-Pierre

a écrit :
On veillera donc à ce que l'ordre des « colonnes » dans le code HTML soit cohérent

Non, pas a priori.

L'ordre de tabulation colonne droite / gauche ou colonne gauche/droite est indifférent du point de vue RGAA :
- RGAA 9.4: une colonne de menu et une colonne de contenu n'ont pas de liens logique univoque, obligeant à les atteindre dans un certain ordre seulement.
- RGAA 6.1: le passage d'une colonne à l'autre ne constitue pas une interruption de la navigation dans un bloc d'information cohérent.
Ce sera uniquement l'ordre de tabulation dans chaque colonne qui sera en jeu (si, dans l'une de ces colonnes, des blocs d'informations ne sont compréhensibles/utilisables que dans un certain ordre).

La prise en compte d'accessiweb, en revanche, ajoute la contrainte d'avoir qu'un ordre de tabulation colonne gauche puis colonne droite uniquement

Maintenant, dans des cas spécifiques, les critères RGAA joueront :
- colonne gauche de menu principal, première partie
- colonne centre de contenu
- colonne droite de menu principal, seconde partie

Dans ce cas, rompre l'ordre gauche/droite/centre sera invalidant (le contenu "interrompt" la consultation du bloc d'information "menu" composé de deux parties successives).

Bilan (et version simple pour le tutoriel):
- dans tous cas, se souvenir d'abord qu'un menu de navigation est une chose qu'(X)HTML ne gère pas, car il ne sait baliser que des documents et non des interfaces: nous commettons nécessairement des abus, et le résultat, y compris pour l'accessibilité, ne peut pas être optimal.
- ne saucissonnez pas vos contenus en tranches alternées pour réaliser plus facilement votre colonnage.
- ne faite pas de préconisation d'ordre général dans vos tutoriels quand il s'agit d'inviter d'abord à réfléchir en fonction des contenus finaux et réels (c'est l'une des raisons pour lesquelles je suis devenu extrêmement méfiant devant les tutoriels sur la mise en page CSS, pour ne pas dire que je suis en train de virer doucement à l'agacement profond...).
Modifié par Laurent Denis (19 May 2007 - 13:23)

Laurent Denis a écrit :
Bilan (et version simple pour le tutoriel):
- ne saucissonnez pas vos contenus en tranches alternées pour réaliser plus facilement votre colonnage.
- ne faite pas de préconisation d'ordre général dans vos tutoriels quand il s'agit d'inviter d'abord à réfléchir en fonction des contenus finaux et réels (c'est l'une des raisons pour lesquelles je suis devenu extrêmement méfiant devant les tutoriels sur la mise en page CSS, pour ne pas dire que je suis en train de virer doucement à l'agacement profond...).

Désolé pour ton agacement profond , mais tu reconnaitras que lorsqu'on ne s'appelle ni Laurent Denis, ni Florent Verschelde, on peut avoir besoin de quelques exemples facilitants pour s'en sortir, quand bien même le fait même de fournir ces exemples comporte des risques de court-circuitage de la réflexion.

(Je sais pas si je me fais comprendre là...)

Le but de mon petit encart sur l'accessibilité est justement d'éviter le dit court-circuitage, d'inviter à la réflexion. Si tu penses qu'on peut faire ça mieux que ce que j'ai proposé ci-dessus, je suis ouvert à toute proposition, mais là j'avoue ne plus savoir par quel bout le prendre.

Reprendre la formulation du RGAA, ou repartir de là :

a écrit :
S'assurer, dans le code source, que l'ordre d'un bloc d'informations positionné via les styles ne vient pas empêcher la bonne compréhension d'un autre bloc d'informations

Le terme "cohérent" que tu emploies peut vouloir dire toutes sortes de choses...
Modifié par Laurent Denis (19 May 2007 - 13:41)

Florent V. a écrit :


Désolé pour ton agacement profond , mais tu reconnaitras que lorsqu'on ne s'appelle ni Laurent Denis, ni Florent Verschelde, on peut avoir besoin de quelques exemples facilitants pour s'en sortir

Sur le fond, non. Ou bien on est intégrateur/développeur/etc (ou en formation pour le devenir) et on fait comme Florent Verschelde qui s'est formé au cours ces derniers mois sans dépendre de tutoriels de ce type ou en les dépassant rapidement. Ou bien on utilise un CMS et on ne touche pas aux templates ni aux CSS.

Voilà, ce n'est absolument pas politiquement correct, c'est l'antithèse d'une large partie de la démarche de ce forum (avec lequel je prends justement mes distances) et de beaucoup d'autres, mais c'est dit

<edit>Précisons: le sens, c'est que tant qu'il y aura un encouragement à "bidouiller", "mettre les mains dans le cambouis", "faire du CSS en amateur" et autres "communautés sympas", ce seront autant de freins vers des CMS plus évolués prenant ouvertement en compte cette problématique. Lesquels répondraient non seulement aux besoins du grand public, mais à la plupart des besoins des intégrateurs actuels, qui pourraient oublier enfin CSS.</>
Modifié par Laurent Denis (19 May 2007 - 14:04)

Laurent Denis a écrit :
<edit>Précisons: le sens, c'est que tant qu'il y aura un encouragement à "bidouiller", "mettre les mains dans le cambouis", "faire du CSS en amateur" et autres "communautés sympas", ce seront autant de freins vers des CMS plus évolués prenant ouvertement en compte cette problématique. Lesquels répondraient non seulement aux besoins du grand public, mais à la plupart des besoins des intégrateurs actuels, qui pourraient oublier enfin CSS.</>

Je veux bien que ces communautés aient tendance à diriger le débutant vers le "bidouillage" plutôt que les CMS, mais en quoi empêchent-elle le développement de CMS plus évolués ?

Julien Royer a écrit :

Je veux bien que ces communautés aient tendance à diriger le débutant vers le "bidouillage" plutôt que les CMS, mais en quoi empêchent-elle le développement de CMS plus évolués ?

En ne faisant pas naître, ou en n'encourageant pas la demande pour ces évolutions.

Ces CMS se font déjà sans cela (ne serait-ce que par reconversion du Wysiwyg à la mode 2.0). Mais ils ne mûriront qu'un peu plus tard qu'on ne pourrait le faire.

Et par ailleurs: je suis un peu intégrateur CSS, à ce qu'il paraît du moins: eh bien, mon rêve le plus cher est de ne plus avoir à toucher une ligne de code (X)HTML CSS, et de pouvoir travailler enfin avant tout sur des architectures de contenus. Le jour où les forums CSS et autres openweb mourront faute d'utilité, ce sera l'un des petits signes que le bouzin est devenu un petit plus civilisé

Le Wysiwyg est une grande idée.
Modifié par Laurent Denis (19 May 2007 - 15:22)

Laurent Denis a écrit :

et de pouvoir travailler enfin avant tout sur des architectures de contenus.

Bon je me permet la question parce que ça m'intéresse vraiment.
Qu'est ce que tu entends par architectures de contenu ?
Modifié par Christian Le Bouler (19 May 2007 - 16:20)

Je partirais bien dans cette discussion de fond sur les rôles de chacun et les peut-être nécessaires évolutions des outils (CMS) et des contenus pédagogiques et lieux d'accompagnement (Alsacréations...), mais j'ai un encart à reprendre.


Bon. Je crois que j'ai trop confusionné les choses en mélangeant allègrement deux problématiques :
- la navigation au clavier ;
- l'absence de rupture logique lors de la lecture du document linéarisé (ordre du code HTML).

Pour la première, et au vu du point de contrôle 9.4 du RGAA, il n'y a pas de souci particulier avec le tutoriel et les exemples fournis. Donc je ferais aussi bien de laisser ça de côté.

Pour la deuxième, un petit avertissement en encart reste, il me semble, justifié.

On peut donc faire :
- un avertissement en un paragraphe, attirant l'attention sur le fait qu'il est préférable que l'agencement des contenus dans le code source ne pose pas de problème de compréhension du contenu lu dans cet ordre ;
- ce même avertissement, avec référence au point de contrôle 6.1 du RGAA ;
- la même chose, avec en plus la précision sur Accessiweb 10.3.

Un avis sur la question ?

Laurent Denis a écrit :
Le Wysiwyg est une grande idée.

Le Wysiwym est pas mal non plus.

Florent V. a écrit :

Le Wysiwym est pas mal non plus.

Absolument! Bien plus intéressant d'ailleurs amha.

Un tutoriel n'a de valeur d'apprentissage que pour un seul public, celui qui l'a écrit

Alors au lieu de produire des chose en pensant qu'elles ont vocation à enseigner il est préférable et plus sain de les considérer comme des comptes rendus de travaux pratiques, ayant simplement pour vocation d'être notés...

... En espérant avoir la moyenne.

Au delà de ces considérations, pourrait-on se pencher un peu sur mon problème ?
Modifié par Florent V. (20 May 2007 - 16:33)