Raphael a écrit :
Pas obligatoirement : "display" et "visibility" sont objectivement des propriétés d'affichage (donc a priori de média screen et non de media speech).
Je dis peut-être une bêtise, mais pour ma part, ça ne me paraît pas si logique que ça.
Une demi-bêtise, en fait
. Précisons ce qu'il en est, car le détail est un peu compliqué :
Du point de vue de l'implémentation,
display n'est pas finalement une propriété d'affichage, en dépit de son nom et de ce que la spécification peut laisser supposer au premier abord. C'est bien une propriété de
rendu valable quelque-soit le media, y compris aural et speech. La norme vers laquelle on s'achemine en effet serait que :
- un display:none sans précision de media (ou "all") s'applique dans un navigateur vocal comme dans un navigateur graphique,
- un display:none restreint au media screen ne s'applique pas dans un navigateur vocal.
- un display:block dans une CSS speech annule un display:none précédemment fixé pour tous les medias, en fonction des règles de la cascade (tout comme on le pratique pour une CSS print qui modifie le display d'une CSS all).
La confusion sur display et le média speech vient de ce que cette propriété est présentée par CSS2.x au chapitre du
modèle de rendu visuel. Mais si on revient sur le
modèle de traitement CSS2.x, on voit qu'il y a ambiguïté, car display supprime un élément (présent dans l'arbre du document) de la structure de formattage. Et ce n'est qu'après établissement de la structure de formattage que celle-ci est transférée vers le media. On peut en conclure qu'un display:none est valable quelque-soit le media.
On pourrait objecter que display ne devrait pas être retenu au moment où s'établit la structure de formatage, car cette propriété pourrait être écartée à l'étape précédente du traitement, lorsque chaque élément est annoté avec des valeurs de propriétés en rapport avec le media cible. Mais le choix de ne pas procéder ainsi dans les implémentations, face à l'ambiguïté de la spécification, répond à une contrainte évidente pour les navigateurs vocaux et pour les lecteurs d'écran : si le document tel qu'il est lu a un contenu différent du contenu affiché, cela n'aura pas de sens pour un utilisateur, mal voyant ou non, qui utiliserait simultanéement les deux medias (comme on peut le faire actuellement avec Opera, Jaws, IBM HPR, etc). Le problème est encore plus criant dans une page Web avec interaction vocale. Il aboutirait à des situations ingérables dans les "
verticals" (une application d'aide à la conduite embarquée dans un véhicule, par exemple).
visibility, en revanche, est sans ambiguïté une propriété propre aux medias visuels (screen, projection, handheld, print et tv) : son équivalent pour le media speech est la propriété
speak.
Notons que si display était exclu du media speech, on ne pourrait retrouver un contenu identique à l'écran et en lecture que si un speak:normal pouvait annuler un display:none... ce qui serait totalement aberrant du point de vue de la logique des propriétés CSS. Sans compter le fait qu'un display:none appliqué à un élément parent n'est pas annulable pour un élément enfant, alors qu'un speak:none appliqué à l'élément parent peut-être annulé par un speack:normal pour un élément enfant... Bref, speack ne peut pas être l'équivalent de display, raison supplémentaire pour que celui-ci soit valable pour tous les medias.
Concernant le comportement des lecteurs d'écran actuels, la situation est brouillée par le fait que Jaws, IBM HPR, etc. ne sont pas actuellement des applications conformes à CSS.
- les media ne sont pas pris en compte correctement. Un display:none dans une CSS screen sera appliqué, et ne pourra pas être annulé faute de support des CSS aural ou speech.
- visibility est l'objet d'un second problème d'implémentation. Il ne devrait en aucun cas être pris en compte, mais il l'est souvent.
- display:none et visibility hidden seront ou non pris en compte en fonction d'une troisième série de problèmes d'implémentation, qui concerne le type de lien vers la feuille de style, selon le choix entre les éléments link, style, l'instruction xml stylesheet et leurs syntaxe précise (situation comparable à la prise en compte des CSS screen par les mobiles).
Au bout du compte :
- pour comprendre en pratique ce que donneraient des implémentations conformes, voir
Opera 8.x qui implémente ce qu'il faut de manière correcte. Même si c'est encore marginal pour l'accessibilité, le fait qu'il existe au moins un navigateur vocal conforme est très bon signe pour l'avenir.
- pour les lecteurs d'écran actuels, étant donné la confusion des implémentations, éviter en effet de jouer sur ces deux propriétés.
Modifié par Laurent Denis (21 Sep 2005 - 07:51)
