bonjour,
a écrit :
Je vais faire moi même le test bien sur mais ce serait intéressant de savoir ce qui est visé par ce sélecteur. J'aurai tendance à dire intuitivement que c'est le <div> adjacent au <a>, mais comme dans ton exemple tu mets un display:block; que div a déjà par défaut je dois me tromper.
Non, tu ne te trompes pas, le display:block est juste là pour rendre visible le bloc préalablement caché par display:none.
Ceci dit la technique display:none/block est à éviter au profit d'une technique dérivée de celle de Paul Bohman qui consiste à positionner l'élément caché en dehors du wiewport (comme le fait ghost par exemple).
Je n'ai pas voulu trop compliqué la sauce pour Tof qui à du chemin à faire...
@ghost : La structure que tu proposes pose quelques soucis :
- L'utilisation d'un em pour encapsuler ton couple image+texte n'est pas très pertinente du point de vue de sémantique.
- L'utilisation d'un élement a comme boite contener pour quelque chose qui n'est pas un lien est là aussi peut pertinente comme tu le soulignes d'ailleurs.
En audit on parlerais sans coup férir d'un détournement de balisage...
Cela pose un autre problème, plus épineux qui est la longueur des liens, franchement très excessive.
Un utilisateur de lecteur d'écran à la possibilité de lister tous les liens de la page, c'est une fonctionnalité particulièrement importante pour lui.
En produisant des liens aussi longs, avec, en outre, des descriptions alternatives d'images "innoportunes", tu vas gravement polluer cette liste de liens et la rendre difficilement utilisable...
<edit >@gcyrillus : Non parce que l'élément a est destiné à contenir le lien vers une ressource et pas un autre chose...
En utilisant deux éléments adjacents, un lien de type ancre qui pointe vers le texte "caché", on respecte le rôle de l'élément a et on donne la possibilité aux utilisateurs de lecteurs d'écrans d'atteindre les textes "cachés" à partir de la liste des liens de la page, ce qui est exactement ce qu'on est en droit d'attendre d'un fonctionnement de ce type...
</edit>
La technique à base d'éléments adjacents, quitte à utiliser du javascript est moins problématique même si cela ne résoud pas le problème de la désactivation de javascript...
Au final, ce genre de construction de cartes interactives sont assez difficiles à envisager du point de vue de l'accessibilité.
Le choix se porte plutôt à trouver la technique "la moins mauvaise" de la classique image map aux structures css enfants adjacents javascriptées ou non.
Pour ce qui est du manque de support de focus sur un enfant adjacent, j'en reste coi et passablement dérouté car cela tue un des principaux intérêts de ce sélecteur.
Si quelqu'un à un retour différent sur ce sujet je suis client...
Jean-pierre
Modifié par jpv (21 Nov 2006 - 00:34)