Changer l'ordre d'apparition des div versus Accessibilité

Bonjour à tous,

J'ai remarqué que certains gabarits CSS changent l'ordre d'apparition des div dans le code source.
Je m'explique :
- Dans le fichier HTML, nous voyons dans l'ordre :

<div id="#menuGauche">...</div>
<div id="#menuDroite">...</div>
<div id="#centre">...</div>

- Or, en appliquant une CSS, le gabarit s'affiche ainsi (de gauche à droite):
menu gauche, centre, menu droite.

Ma question est simple : est-ce que cela ne va pas à l'encontre de l'accessibilité de changer l'ordre d'apparition dans le code source ??
Modifié par vilyjix (13 Oct 2006 - 14:20)

C'est surtout qu'il vaut mieux mettre ça dans l'autre sens : centre d'abord, et ensuite les bords... Maintenant suivant la présentation qu'on veut, c'est pas toujours pratique

Si les gens (je le fais aussi parfois) mettent dans l'ordre gauche, droite puis centre, c'est pour des raisons de comportement des float. C'est beaucoup plus simple comme ça.

Bonjour,

a écrit :
Ma question est simple : est-ce que cela ne va pas à l'encontre de l'accessibilité de changer l'ordre d'apparition dans le code source ??

Question simple... ? le débat dure depuis la nuit des temps...

La séparation contenu, structure et représentation, qui est le fondement de l'utilisation de CSS permet en effet de manipuler à l'envie les éléments indépendamment de leur ordre dans le code source.

C'est bien pratique car cela permet d'adapter la représentation au type de media, par exemple menu "naturellement" à gauche sur un ecran normal et contenu "repositionné" en premier sur un écran de petite taille.

En revanche, cela peut poser des problèmes d'accessibilité dés lors que ces manipulations rendent "illogique" le parcours du contenu par la tabulation de liens en liens, par l'utilisation de loupe d'écran, par l'utilisation combiné d'une loupe d'écran et d'une synthèse vocale.

Accessiweb en à fait un critère d'invalidation, le fameux critère 10.3 qui spécifie que l'ordre d'apparition des éléments à l'écran doit respecter l'ordre de la structure Html pour l'odre de lecture naturel : de gauche à droite et de haut en bas.

Quelques uns des experts Accessiweb, dont je fais partie, estime que cette réponse à un vrai problème est particulièrement innapropriée : elle est trop restrictive dans son champs d'application (elle interdit des mises en pages utilisables), elle créé un redoutable problème d'interpréation de deux recommandations WCAG et enfin elle interdis certaines adaptations utiles sur des périphériques limités.

Mais là encore, on ne le répètera jamais assez, tout est une question de contexte.

Ce qui doit guider le repositionnement d'élément c'est en tout premier lieu l'ordre dans lequel les éléments vont être parcourus par la tabulation (critère WCAG 9.4) : il faut garantir que cette navigation soit logique et cohérente.
L'autre contrainte forte et essentielle : Il faut que la structure offre une lecture "logique" du contenu CSS désactivées (critère 6.1).

Concernant l'ordre de lecture des éléments, notamment par l'utilisation simultané d'une synthèse vocale et d'une loupe d'écran, le "diagnostic" est beaucoup plus difficile à établir faut de disposer du contexte : la structure, les problèmes, les aides à la navigation, les limites acceptables...

C'est un problème assez identique dans sa difficulté d'appréciation à celui de l'agrandissement de la taille des caractères.

Pour résumer :

- Rien n'interdis pour WCAG le repositionnement d'éléments aux conditions de la validation des critères 9.4 (tabulation) et 6.1 (lecture naturelle du contenu CSS désactivées).

- Concernant le critère 6.1 : C'est non-négociable, autrement dit on ne doit jamais modifier la structure pour permettre une représentation si cela modifie l'ordre naturel de la lecture du contenu.
Ce qui va avec cette règle d'or : CSS mets en page un contenu préalablement logique, cohérent et utilisable...

- Accessiweb impose de synchroniser la structure et la représentation, ce qui interdis de fait les repositionnements : Un élément "avant" dans la structure est nécessairement "à gauche", en succession verticale, dans la représentation .
Cela concerne les "grandes divisions de la page" et surtout la structure menu/contenu.
C'est extrèmement restrictif mais cela offre une "garantie", notamment du critère WCAG 9.4 ( par effet d'escalier car ce n'est pas ce critère qui est cité comme référence).

Pour le reste : Où est la page ?

Jean-pierre
Modifié par jpv (13 Oct 2006 - 15:45)

Salut,

jpv a écrit :

Ce qui va avec cette règle d'or : CSS mets en page un contenu préalablement logique, cohérent et utilisable...

Non !

La formulation est beaucoup trop faible, il ne s'agit pas d'un préalable.

Il s'agit certe d'une élaboration logique, cohérente, pertinente ( il suffit de remplacer le concept de sémantique par celui de pertinence et ça ira beaucoup mieux pour tout le monde ), utilisable ( joli mot au passage, je ne sais toujours pas qui de nous deux résiste le plus à l'autre ).

Mais elle n'est préalable à rien du tout, elle se soutient de manière absolue, hors toute perspective de modalités de présentation quelconques. Dans cette affaire les css ne servent qu'à ça, permettre à cet absolu de se maintenir.

On pense que les css mettent en page... Et bien on se trompe sans doute. Les css d'un point de vue conceptuel n'existent que pour permettre le maintient du statut absolu de l'élaboration "logique, cohérente... etc..." du document html en lui même, alors qu'il est pourtant, mais "par ailleurs", question de "mise en page".

Les css n'existent que comme secondes. Le html n'existe que comme unique.

et pour ceux qui aiment bien parler de couple (x)html/css, on vous avait pourtant prévenu :

a écrit :

Les histoires d'amour finissent mal ...

... En général.

Modifié par clb56 (14 Oct 2006 - 01:30)

Salut,

a écrit :
et pour ceux qui aiment bien parler de couple (x)html/css, on vous avait pourtant prévenu :
Les histoires d'amour finissent mal ...

... En général.

Qui garde les enfants ?

Il est question d'élaboration logique, mais quoi qu'il arrive elle ne sera pas la même pour tous en raison des handicaps et des navigateurs utilisés, et même si on cherche à tendre vers une logique commune, on en a chacun notre propre perception.
Une utilisation d'un site en mode textuel (par navigateur vocal par exemple), permettra une lecture quasi linéaire, avec certaine permission de saut dans cette linéarité.
A l'inverse, l'utilisation d'un site en mode graphique de sera pas utilisé pareil, car l'oeil, rapide à la synthèse, va percevoir la lecture selon l'attraction de certains éléments par rapport à d'autres et lire ce qui va l'intéresser. Et ceci, sans être obligé d'éviter un menu ou un contenu sans savoir ce qu'on va trouver par la suite.

L'interêt d'avoir des sites "mis en page" pour reprendre le terme de Clb, c'est quand même d'apporter un plus visuel (pour une -relative- majorité de gens) de manière à accélérer la perception du site et de son contenu (structure plus évidente, textes importants plus denses, textes secondaires plus discrêts, etc.). Sans cela, pourquoi utiliser des CSS ?? Autant faire des sites en xhtml et ne plus les utiliser. Mais l'engouement pour internet risquerait de décroître aussi vite qu'il à crût.

Je me dis au final qu'il faut quand même faire le discernement entre :
- une disposition graphique "proche" de la linéarité du document html (haut en bas et gauche à droite) mais adapté à sa logique de navigation en mode graphique,
et celle qui va complètement remettre en question la sémantique en utilisant par exemple des positionnements absolus qui vont la contredire, placant visuellement des éléments sous d'autres situés après dans le code html.
Le but étant au final d'offrir un contenu sans pour autant perturber l'utilisateur, qui de toute manière verra ce qu'il voit selon sa personne. On ne propose de toute manière pas exactement la même chose aux uns et aux autres, alors pourquoi vouloir dans ce cas que la vision graphique soit restrictivement adapté à la vision textuelle ?

clb56 a écrit :
Salut,

[...]

Je crois que j'ai strictement rien compris à ton post Mais c'est pas grave

Je suis parfaitement d'accord avec jpv, les CSS permettent de mettre en page (de manière assez simple), quelque chose qui est déjà à la base logique, cohérent et utilisable.

Hors de question d'utiliser du CSS sur un document XHTML ou XML qui part dans tous les sens, aucun miracle ne sera possible. Cf. le problème des colonnes où l'ordre dans le code XHTML va rendre possible ou non la mise en colonnes de certains éléments.

Pour certaines mises en pages donc, il va falloir, malheureusement, planifier le code XHTML. Ce qui d'ailleurs pose problème pour ce qui est de la "séparation" contenu/présentation. Si la présentation est effectivement complètement séparée du contenu, elle est quand-même assez liée à la structure.

Ca pourrait venir des CSS, le manque de fonctionnalités, il faudrait des propriétés permettant par exemple d'inverser des éléments lors de la présentation (dire spécifiquement, tel div va à gauche, l'autre va en-dessous, l'autre à droite, etc.). Maintenant ce n'est pas la mission des CSS. Les CSS sont là uniquement pour donner du style, pas vraiment pour faire une grosse mise-en-page...

.
.
.

Euh... Ca me rappelle une phrase :

clb56 a écrit :
On pense que les css mettent en page... Et bien on se trompe sans doute.

Héhé, avec un peu de réfléxion je rejoins ce que t'as dit.

Mais alors, comment mettre en page "proprement" un document ? Comment rendre logique et utilisable un document qui ne le sera pas ?

La réponse est simple messieurs : XSLT.

Dans un monde idéal, on aurait un document XHTML (ou XML), avec plein de trucs dedans. Première étape, on réorganise la structure en quelque chose de plus logique, plus propice à être mise en page, grâce à XSLT. Deuxième étape, on rajoute le style via les CSS.

Le problème est évident, les agents-utilisateurs ne sont pas près pour ça. Du moins tout ce qui n'est pas Gecko, Opera ou Safari...

clb56 a écrit :


jpv a écrit :
Ce qui va avec cette règle d'or : CSS mets en page un contenu préalablement logique, cohérent et utilisable...

La formulation est beaucoup trop faible, il ne s'agit pas d'un préalable.

a écrit :

(pré-a-la-bl') adj.
Qui doit être dit, fait, examiné avant qu'on passe outre.
(source littré)

Ce qui de mon point de vue, me semble suffisemment fort.
La logique du discour, porté par le contenu, doit être considéré et établie avant sa représentation par l'intermédiaire de CSS...

Je ne vois sincèrement pas ce qui te pose problème là dedans.

a écrit :
Les css d'un point de vue conceptuel n'existent que pour permettre le maintient du statut absolu de l'élaboration "logique, cohérente... etc..." du document html en lui même, alors qu'il est pourtant, mais "par ailleurs", question de "mise en page".

Si j'explique ça à mes stagiaires ils vont sans doute me regarder en se demandant ce que j'ai fumé avant...

Par ailleurs CSS appliqué à une structure par tableau de mise en page ne pourra rien permettre du tout, ou si peu, pour la séparation structure, contenu, représentation.

Restons simples :
- CSS est le langage de mise en page pour Html (il en existe d'autres pour XML par exemple)
- Il permet une séparation structure/contenu/représentation (si la structure HTML le permet... )

Jean-Pierre

jpv a écrit :
Restons simples :
- CSS est le langage de mise en page pour Html (il en existe d'autres pour XML par exemple)

C'est vrai pour le CSS 1. Pour la version 2, ils l'ont appliqué à l'XML aussi.

salut tout le monde,

jpv a écrit :

La logique du discour, porté par le contenu, doit être considéré et établie avant sa représentation par l'intermédiaire de CSS...

Non, elle doit être considérée et établie hors toute perspective de présentation. Et ce qui rend cela possible c'est les css.

jpv a écrit :

Les css d'un point de vue conceptuel n'existent que pour permettre le maintient du statut absolu de l'élaboration "logique, cohérente... etc..." du document html en lui même, alors qu'il est pourtant, mais "par ailleurs", question de "mise en page".

Si j'explique ça à mes stagiaires ils vont sans doute me regarder en se demandant ce que j'ai fumé avant...



Oui j'avais remarqué ce genre de difficulté des gens avec l'abstraction, mais d'expérience avec de la patience on y arrive.

FlorentG a écrit :

Hors de question d'utiliser du CSS sur un document XHTML ou XML qui part dans tous les sens,

On y est presque...

Je propose donc la formulation suivante :

Hors de question d'avoir un html qui ne parte pas dans tous les sens sans les CSS qui permettent de gérer les questions relevant de la présentation suivant les types de media.

Et d'après ce que j'ai compris, c'est bien là dessus que l'usage du html "old school" c'est cassé les dents. Non ???

Autrement dit les css ne demandent pas un document "bien ordonné" (pour le résumer comme ça) elles le permettent.
Modifié par clb56 (14 Oct 2006 - 16:04)

bonsoir,

@ clb :

Mon seul propos était d'essayer de faire passer des idées simples :
- Le contenu de la page doit être lisible et compréhensible lorsque CSS est désactivé.
- Lorsqu'on repositionne des éléments on doit s'assurer que cela ne créé pas des problèmes de navigation à la tabulation.
- On doit également, même si c'est un sujet plus délicat, évaluer les effets néfastes des repositionnements sur l'utilisation d'outils du type loupe d'écran, combiné ou pas à une synthèse vocale.

Pour le reste, je crains que nous prenions le risque de faire mal à des mouches qui ne demandent rien.

Enfin, ceci :

a écrit :
Hors de question d'avoir un html qui ne parte pas dans tous les sens sans les CSS

...
Autrement dit les css ne demandent pas un document "bien ordonné" (pour le résumer comme ça) elles le permettent.

est fondamentalement faux pour la première assertion et partiellement dangereux pour la seconde.

CSS ne peut rien faire et ne permet rien quant à la structure d'un document Html, ce n'est pas son rôle...

Il ne faut pas confondre l'outil et ce qu'on doit en faire, le danger étant de créer des incompréhensions qui génèrent des absurdités comme de simuler des structures de tableaux avec CSS.

Je veux bien débattre de tout ça, mais il me semble, pour la bonne tenue de ce fil que ce devrait être l'occasion d'un nouveau sujet.

Jean-Pierre
Modifié par jpv (15 Oct 2006 - 02:02)

Salut

jpv a écrit :


Enfin, ceci :


Hors de question d'avoir un html qui ne parte pas dans tous les sens sans les CSS

est fondamentalement faux



Historiquement, à ce que j'ai compris, c'est au contraire fondamentalement vrai. C'est à dire que tant que ce qui concerne les questions de mise en page n'est pas pris en charge par les css alors le html ne peut que partir dans tous les sens (ou alors cette affaire de séparation de "ceci" et de "cela" n'a strictement aucun sens).

... Ce qui n'empêche évidemment que l'on puisse produire un html complêtement pourri même en utilisant les css. Il suffit pour cela de ne rien comprendre au html, de ne rien comprendre aux css, et de ne rien comprendre aux relations que ces deux là peuvent "éventuellement" entretenir.