1178 sujets

Accessibilité du Web

Bonjour à tous,

Suite au coup de gueule récent de Raphael sur le blog (Arrêtons de remplacer systématiquement les tableaux par des div !), je me pose la question de l'accessibilité des div imbriquées.

L'abus de div me semble dangereux pour la maîtrise de la cohérence du code : balises non fermées, code peu lisible et donc difficile à maintenir/débuguer. De plus, je suis conscient des dangers de la divite, qui occulte l'importance d'un balisage sémantique structurant (on met des div partout mais pas de hN, de p ou de listes...), ou qui pousse certains à croire qu'une mise en page en tableaux peut-être « convertie » (en gardant la même logique du « découpage ») en mise en page à base de divs. Le rappel était donc utile, nécessaire, et appréciable. Smiley cligne

D'ailleurs, tant que j'y suis, je vous en met un petit passage (pour ceux qui n'auraient pas lu le billet, ou alors en diagonale) :
a écrit :
Utiliser une balise unique comme <div> va à l'encontre de cette philosophie, et - plus important - rend la lecture bien plus complexe pour l'ensemble des agents utilisateurs (navigateurs, moteurs de recherche, outils adaptés).


Mais quid, concrètement, de l'accessibilité des div imbriquées ?

Citant toujours Raphaël, dans les commentaires cette fois :
Raphael a écrit :
Le gros problème, comme avec les tableaux, est surtout l'imbrication multiples de <div> qui n'a alors aucun sens.

Pour ce qui est de ZenGarden, c'est un peu spécial : le code HTML de base a été prévu dès le départ pour pouvoir être très modulable et complètement stylable. Il est donc très lourd et souvent pour rien, mais l'avantage est que n'importe quel élément peut être stylé n'importe comment.

Je pensais justement à ce cas, pas forcément à ZenGarden, mais plus généralement au fait de produire un template un peu chargé qui permette des modifications importantes du design, avec plus de latittude qu'un code « épuré » qui banirait les div inutiles. Dans le cas des template de CMS, par exemple, c'est une question non négligeable.

Là dessus, un petit tour du côté du W3C (traduction française de la spécification HTML 4.01) :
a écrit :
Les éléments DIV et SPAN, en conjonction avec les attributs id et class, offrent un mécanisme générique qui rajoute de la structure aux documents. Ces éléments définissent le contenu comme étant en-ligne (SPAN) ou de bloc (DIV) mais n'imposent aucune autre expression de présentation sur le contenu. Ainsi, les auteurs peuvent utiliser ceux-ci en conjonction avec les feuilles de style, l'attribut lang, etc., pour exploiter HTML selon leurs besoins et leurs goûts propres.

Une div est donc un élément de type bloc « neutre » dont les deux rôles principaux sont :
- support d'information de langue (le cas échéant) ;
- support de mise en forme.

À priori, aucune contre-indication à l'utilisation (réfléchie) de divs imbriquées.

Reste donc la question -- capitale -- du rendu, dans la pratique, de div imbriquées par les différents agents utilisateurs :
- pour ce qui est des navigateurs graphiques, rien à signaler ;
- avec un navigateur en mode texte comme Lynx, les div ne sont pas rendues ;
- avec les différents lecteurs d'écran ?
- autres cas d'utilisation ?

J'en appelle donc aux spécialistes -- et plus généralement à tous ceux qui s'y connaissent un peu -- en matière d'accessibilité. Y a-t-il des cas problématiques, en dehors des écueils conceptuels et méthodologiques pointés par Raphaël ? Ou bien peut-on en conclure que les div imbriquées ne sont pas « fondamentalement » dommageables ?


Merci d'avance pour vos réponses.


PS : attention, pas de troll, on n'est encore que jeudi !
Modérateur
bonsoir,

je dirais (avant vendredi) plutot :

Ne jetez pas vos tableaux utiles contre de beaux div "tout propre".

... Pour le div il y a aussi ce rendu dans une page sans style associé organisant en quelque sorte une zone delimité par son retour a la ligne , avant et aprés et qui peut servir avantageusement d'ancrage<edit>donc un autre role important </edit> et acessoirement "stylisable" .(aller au contenu ou a une zone du contenu a partir d'un menu/sommaire de la page) ...hmmm le tableau aussi , oui mais non , contenu tabulaire ou pas? , (arf , c'est pas frie day ! )! ...

Enfin , c'est juste pour relevé le topic avant 00h00
Modifié par gcyrillus (21 Sep 2006 - 21:43)
a écrit :

- avec les différents lecteurs d'écran ?

R.A.S. : Les div ne sont pas rendues, donc tu peux imbriquer ce que tu veux comme tu veux où tu veux.
Par contre, ça devient dommageable dès le moment où tu commences à remplacer les éléments sémantiques essentiels par des div, par exemple à la place d'un titre ou d'un paragraphe.
Mais sinon, aucune contrindication.
Modérateur
Le point que je trouve important, c'est surtout de n'avoir que des balises utiles et explicites.
Une div pour gagner en souplesse, c'est une pratique à éviter autant que possible mais bon, soit, quand ça sert réellement parce que sinon, ça ne devrait pas apparaître.

Tout comme chacun l'a précisé, une chose importante à souligner est que la divite aigüe est bien lorsqu'on remplace une balise telle que p ou une cellule de tableau par une div, ce qui peut prêter à conséquence, mais que la div vide inutile est moins préjudiciable ; c'est surtout (mais pas que çà) que ça ne fait pas propre. ( Je qualifie çà de divite obtue Smiley langue )

gcyrillus a écrit :
Pour le div il y a aussi ce rendu dans une page sans style associé organisant en quelque sorte une zone delimité par son retour a la ligne , avant et aprés et qui peut servir avantageusement d'ancrage<edit>donc un autre role important </edit> et acessoirement "stylisable" .(aller au contenu ou a une zone du contenu a partir d'un menu/sommaire de la page)
Un hr ne ferait-il pas l'affaire dans ce cas ?

D'ailleurs, étant donné que le rendu d'une div pour définir un groupe de balises n'est pas forcémment rendu quelquesoit le support, ne serait-il pas judicieux de faire un peu plus appel au hr pour délimiter ces groupes et donc ne cantonner la div qu'à son vrai rôle ? C'est certes un élément de structure qui peut servir à regrouper des balises mais c'est générique, ce qu'il vaut mieux éviter.
Modérateur
a écrit :
Un hr ne ferait-il pas l'affaire dans ce cas ?


oui , effectivement , je l'y avait mis aussi en parenthese avant le tableau, puis enlever , ça devenait confus (comme d'hab chez moi) et puis je ne voulais pas trop debordé du sujet initial div/tableau.
id + division visuelle et semantique du contenu en effet plus pertinante qu'un div englobeur , .... ou differente .

le hr separe et reste visuelle , le div englobe/regroupe en bloc de façon neutre( 2 groupes d'image par exemple le <p> n'est peut-etre pas plus pertinent dans ce cas )) , invisible visuellement et semantiquement (si j'ose dire), a la base il est beaucoup plus souple a stylé ,
... enfin depend de la pratique que l'on en fait , il semble quand même pas mal tourne vers un usage pour la mise en forme visuel qu'autre chose , sans troller . Smiley cligne . ce qui lui vaut d'etre le "remplaçant" des tableau qui etait deja detourné pour ces raisons .

Toujours difficile d'user des bonnes balises et ... a bon escient , ce que l'on croit bien faire un jour ne l'est plus forcement plus tard , ...tant que l'on continue a se poser des questions et qu'il y a des gens pour en parler , ça devrait finir par se decanter ...

Smiley biggrin
Je ne reviens pas (ou alors très rapidement pour un simple rappel) sur quelques éléments de base:
- div est un élément de regroupement pertinent, indispensable support de styles et de script. A ce titre, en évitant l'emploi ou le détournement d'éléments spécifiques uniquement pour des effets de présentation ou de dynamisme, div participe à l'accessibilité d'un document Web.
- la multiplication de ces div de regroupement là où les styles/scripts pourraient être supportés plus directement par le balisage spécifique n'est pas une source d'inaccessibilité, ni un problème sémantique majeur, mais bien davantage une mauvaise économie de moyens.
- en revanche, l'utilisation abusive de div de substitution à la place d'éléments HTML spécifique est en effet un travers fréquent et une source de non accessibilité : plus un code sera "dense" en éléments signifiant utilisé à bon escient, plus fort sera son potentiel d'accessibilité, car il donnera d'autant plus de prise aux outils d'aide et aux agents utilisateurs ayant à le manipuler.

Cela nous conduit à un point plus rarement abordé: la présence d'éléments de regroupement peut être un facteur supplémentaire d'accessibilité, en fournissant aux outils un support supplémentaire de navigation dans le document, ou de fractionnement de celui-ci en entités plus réduites. A titre d'exemple, certains navigateurs (Opera) permettent déjà de naviguer au clavier de bloc en bloc. Certains scripts tentent d'extraire l'information de la page en se basant sur ses divisions de premier niveau, etc. Bien évidemment, et plus simplement, un simple <div id="content"> est déjà une cible de lien de navigation interne dans la page...

Bref, comme pour tout balisage, l'utilisation pertinente des éléments div concourt à l'accessibilité.

Mais la limite est évidente : rien ne différencie un regroupement "logique" et un regroupement au motif uniquement stylistique (quoique, pourtant, les deux devraient coïncider dans un document idéalement structuré et idéalement présenté).

A ce égard, il est intéressant de faire un peu de prospective, et de regarder XHTML2.0: son élément section est justement (et très grossièrement) cette sorte de div qui ne serait plus juste une div, permettant de générer une structure significative, hiérarchisante (génération automatique des niveau de titres par l'élément <h>)...

Conclusion: il n'existe pas en HTML4.x (et donc en XHTML1.x) de mauvais élément pour l'accessibilité (ce serait un non sens ou le signe d'une énorme erreur dans l'évolution de ces formats depuis HTML3.2). Il existe en revanche, et il existera toujours quelques soient les formats et leur articulation (structure/présentation par exemple) des mauvais usages et de bons usages Smiley cligne
Modifié par Laurent Denis (23 Sep 2006 - 05:54)
Merci à tous pour les réflexions, les informations, et les ouvertures.

Pour la question que je posais, QuentinC et Laurent Denis ont apporté une réponse claire : les div imbriqués ne sont pas un problème d'accessibilité, mais un problème d'économie de moyens.

Mais bien sûr, comme je l'indiquais avec force précautions oratoires dans mon premier message, la problématique des usages « intensifs » de l'élément div dépasse cette simple question. Et il me semble que nous en avons fait le tour (ou du moins que nous en avons cité/précisé un certain nombre).

Encore merci, et -- pour ma part -- le sujet est « clos ». Smiley smile
Salut,

2 points que j'aimerais souligner.

1. Ramener la question de la divite au passage non maitrisé du la mise en page avec <table> à la mise en page tableless via css est à mon avis une erreur, la perversion de la chose est ailleurs. J'en parle ici :
http://clb56.freezee.org/archive/?page=2006#repere9

2. Cette phrase de mpop est caractéristique de la manière dont un problème peut être mal posé :
a écrit :

on met des div partout mais pas de hN, de p ou de listes...


A tout le moins cela aurait du être :
"On ne met pas de hN, de p ou de listes... Mais on met des div partout"

Le problème n'est pas dans ce qu'on fait : mettre des div (comme l'indique Laurent c'est en-soi totalement non problématique). Mais bel et bien dans ce que l'on ne fait pas : considérer qu'il y a un code html constituant un document html.

La divite c'est ça, la négation complète du document html lui même. Et aucun besoin d'un passé de <table> addict pour en arriver là.

PS :
Mpop, quel intérêt à déclarer cette discussion close ???
Là je ne comprend pas... Vraiment !!!
Modifié par clb56 (23 Sep 2006 - 15:51)
La question soulevée par Laurent est effectivement souvent à la source des "divites" : on utilise <div> pour créer un objet enveloppant d'autres objets tels que hn, p, img, etc... Toute la question est de savoir pourquoi l'on choisit de regrouper ces objets : est-ce pour une raison de logique de traitement (application d'un style, d'un script, etc.) ou de mise en page (positionnement, traitement graphique, etc.) ? L'ambiguité du statut de <div> ne vient-elle pas partiellement de CSS qui est à la fois un "descripteur" (comment doivent se comporter telles ou telles balises dans une restitution screen ou print ou handheld ou autre ? ) et à la fois "positionneur" (à travers par exemple des position:absolute qui ne sont pas envisagées comme "mettre cet objet hors du flux pour telle ou telle raison liée au contenu qu'il porte" mais comme "placer l'objet à tel endroit de la page au pixel près"... La neutralité de <div> pousse à cet abus que permet CSS, mais qu'on utilise moins avec <span> alors que la différence entre eux est mince (inline-block).
Je suis en train de terminer un site 100% bilingue où pour éviter la prééminence d'une langue sur l'autre, tous les éléments (entêtes, menus, textes) sont dans des <div> qu'un script PHP affiche de façon aléatoire et où l'on passe d'une langue à l'autre (ça fait partie du "concept" du site) par CSS (=> question aux experts en passant : comment gérer l'attribut lang ???)
Du coup ce site comporte bcp de <div> mais ça ne me paraît pas être abusif... l'abus n'est pas dans le nombre mais dans l'usage, non ?
Arsene a écrit :
l'abus n'est pas dans le nombre mais dans l'usage, non ?


Pour relancer sur mon post précédent ce n'est ni l'un ni l'autre. Encore une fois c'est une question de méthode : qu'est ce qui fait que des div en arrivent à être présents dans le document html.

Si c'est pour ajouter de la structure très bien (j'ai toujours pas très bien compris comment et en quoi... Mais bon)

Si c'est pour permettre une mise en oeuvre de css particulières que le document html en l'état ne permet pas (pour autant bien sur que le document en l'état ne le permette pas, ce point pose la question du niveau dans le maniement des CSS et est AMHA trop souvent négligé), c'est très bien aussi. En fait c'est même vachement fait pour ça.

Si c'est un machin généré à tour de bras et ex nihilo pour présenter un modèle graphique pensé et réalisé avec un logiciel graphique sans la moindre prise en compte que par ailleurs il y a bien un document html qui n'en demandait pas tant (et pour cause puisqu'il ne demande rien de ce point de vue), alors c'est du délire...

Ce délire est la divite.
Modifié par clb56 (26 Sep 2006 - 19:31)
Bonjour,

a écrit :
Si c'est pour ajouter de la structure très bien (j'ai toujours pas très bien compris comment et en quoi... Mais bon)


On répète :

a écrit :
Les éléments DIV et SPAN, en conjonction avec les attributs id et class, offrent un mécanisme générique qui rajoute de la structure aux documents.
7.5.4 Spécifications HTML 4.01 - Le regroupement des éléments : les éléments DIV et SPAN
(L'emphase est de moi)



Autrement dit :

Rajouter des div avec un attribut d'identification (id et/ou class) permet de rajouter un élément de structure identifiable notamment en vue d'un traitement logiciel, par exemple un script, ou pour l'attribut id définir la cible d'un lien interne, ou encore pour CSS assurer la réprésentation et le style...

En précisant, chose importante, que le traitement de div et span par CSS pour assurer la représentation n'est qu'un aspect du rôle de ces éléments, même si c'est le plus commun pour nous.

C'est en ce sens qu'il faut comprendre la qualité de "regroupement d'éléments" qui est la définition donné par la spécification.

Prenons un exemple "parlant" ( Note à Arsene : pourrais tu préciser ton problème de gestion de l'attribut "lang" ? ):

Imaginon un site bilingue, ce qui pose un problème vis à vis de la gestion de l'indication de langue.

On nous demande de définir la langue d'usage d'un document ET d'indiquer toutes les modifications de langue à l'intérieur d'un document.

Evacuons (c'est un débat encore inachevé) l'indication de la langue d'usage, ou langue de traitement, d'un document bilingue ( Smiley lol ) et concentrons nous sur le contenu.

Je peux : Rajouter sur chaque titre, paragraphe, liste, liens, citations, emphase... la langue d'usage.
C'est long, compliqué, fasitidieux et promis à l'échec à moyen terme.

OU

Je peux : rajouter de la structure en encapsulant les contenus dans des div auxquels je vais attribuer la langue d'usage :
C'est simple, facile et tout et tout.

Je n'ai que des bénéfices à cette manière de faire, par exemple la possibilité d'indiquer l'usage d'un terme "anglais" dans la partie de document "française".

Continuons...

Imaginons maintenant que je veuille travailler sur ces contenus, par exemple parce que mon site bilingue est équipé d'un moteur de recherche .
Je veux concentrer la recherche sur le seul contenu "utile", donc discriminer par la "langue" et la "nature", admettons les "contenus" qui ne sont pas des "menus", l'indication de la langue de recherche étant définis par une option du moteur.

Je peux : Demander à mon moteur de ne rechercher que sur les contenus identifiés par lang=en", mais c'est insuffisant car je vais chercher également sur les "menus".

OU

Je peux rajouter un attribut permettant de discriminer le contenu, par exemple div id="contenu_anglais" si j'ai un seul bloc de contenu ou div class="contenu_anglais" si j'ai plusieurs blocs disséminés dans la page.

Ce faisant je précise encore ma structure...

Dans le "web 2.0++ RC3 V998.4" si nous ne disposions pas de cette faculté de pouvoir structurer un document, en dehors de la sémantique du balisage, en vue de traitement logiciel, on en serait encore au "Web -2".

C'est la raison également, comme l'explique Laurent, que la multiplication de div "non-pertinents" appauvris considérablement la structure.

Tout d'abord et surtout lorsqu'ils remplacent les éléments dédiés, ce qui est un cas flagrant de détournement de balisage.

Et enfin parcequ'en compliquant à l'excès la structure, et d'autant plus qu'on utilise des div "anonymes", ils rendent également plus compliqué le traitement logiciel.

Jean-pierre
Modifié par jpv (27 Sep 2006 - 03:16)
Salut,

Intéressant, magistral et écrasant...

Merci.

a écrit :

"web 2.0++ RC3 V998.4"


Jusqu'à plus ample informé, l'accessibilité de la signification de ce contenu est pour ce qui me concerne très problématique.
a écrit :
Evacuons (c'est un débat encore inachevé) l'indication de la langue d'usage, ou langue principale, d'un document bilingue ( lol ) et concentrons nous sur le contenu.


C'est justement ma question Smiley biggol
Comment renseigner :

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">

et :

<meta http-equiv="content-language" content="fr" />

dans un site parfaitement bilingue...