Étendre la zone interactive

Bonjour à tous,

Pour faciliter le clic sur une interface, j'étends la zone cliquable d'une ancre via CSS.

Code HTML

<div id="exemple">
        <a href="#URL">Titre de la page/article</a>
        <p>Chapo, description ou synthèse de la page/article...</p>
</div>

Code CSS

// 1) Mise en forme du bloc
#exemple { height:68px; width:842px; padding:16px; }
        
// 2) Mise en forme de l'ancre
#exemple a {
    // a) Placement de l'élément sur un index supérieur
      z-index:1000;

    // b) Transformation de l'élément en bloc
      display:block;

    // c) Redimensionnement de l'ancre à la taille du bloc
      height:68px;
      width:842px;
      padding:16px;

    // d) Repositionnement du bloc
      position:absolute;
      margin-top:-16px;
      margin-left:-16px;
}

// 3) Positionnement du bloc suivant
#exemple p { position:absolute; margin-top:32px; }

Cela permet une bonne "sémantique" tout en accentuant la propension au clic.

Mon souci... IE n'applique pas de zone cliquable sur la balise <p /> alors que son z-index est plus faible que celui de la balise <a />. La zone cliquable ne s'étend pas sur l'élément (pour en permettre sa sélection je pense).

Avez-vous une idée pour rendre cliquable cet élément ? ou est-ce une mauvaise pratique parce que cela ne permet plus la sélection du texte ?
Modifié par yep (13 Dec 2011 - 10:08)

Bonjour,

yep a écrit :
Cela permet une bonne &quot;sémantique&quot; tout en accentuant la propension au clic.

Euh non... Pour la sémantique, il serait préférable de placer le titre dans un éléments de titre (hn).

yep a écrit :
Avez-vous une idée pour rendre cliquable cet élément ?

Utiliser un lien dans le paragraphe ?

yep a écrit :
ou est-ce une mauvaise pratique parce que cela ne permet plus la sélection du texte ?

C'est effectivement une mauvaise pratique à mon sens.


Accessoirement, fixer la hauteur du div conteneur n'est pas une bonne pratique non plus. Essage d'agrandir les caractères de ta page pour voir le résultat.

Bonjour,

je pense malgré tout que Laurie-Anne est dans le vrai. Un titre, même dans un contenu secondaire, reste un titre : tu peux utiliser un h4, h5 ou h6 suivant la profondeur de ta hiérarchie de titres. Un lien <a> sera parfait dans ce contexte, à l'intérieur du titre... Sémantiquement, un titre est un titre, peu importe la profondeur à laquelle on le croise.

Et pour ton paragraphe, en fait tu veux le rendre cliquable mais que ce ne soit pas un lien ? Sémantiquement c'est plus proche d'une atrocité que d'une bonne pratique.. Si on accède à un contenu en cliquant dessus, c'est un lien : aucune autre alternative ne serait correcte - et surtout pour une question d'accessibilité ! C'est le principe essentiel du html, de passer d'un contenu à l'autre en suivant des liens.

Pourquoi ne pas utiliser un lien ( du type "Lire la suite" ) à la fin de ton paragraphe, sans que toute la zone soit cliquable ? Cela ajouterait un accès simple et lisible pour tout le monde.

La seule autre solution que j'aurais en tête serait d'en faire une image, contenue dans un lien. Et dieu sait que ça m'en coûterait de te conseiller ça - sachant qu'on parle d'un paragraphe de texte !

Bonjour Ten et merci pour ton retour.

http://www.w3.org/TR/html4/struct/global.html#h-7.5.5

a écrit :
A heading element briefly describes the topic of the section it introduces.

Cela peut être un titre, toutefois HTML a été conçu pour formater l'information au même titre que peut le faire un éditeur de texte comme "MS Office Word" (d'où la présence de balises similaires aux styles par défaut présent dans cet outil). Pour ma part, je n'utilise pas les "headings" (titres de niveau 1, 2, ...) dans l'entête ou le pied de page de mes documents (Word ou HTML). C'est mon choix

a écrit :
Et pour ton paragraphe, en fait tu veux le rendre cliquable mais que ce ne soit pas un lien ?

En fait, je veux que la zone d'interaction ("cliquable" si on a une souris) soit définit en fonction des instructions CSS définit pour la balise <a />.
Seul IE n'a pas le comportement des autres navigateurs qui appliquent à la lettre les instructions et étendent ainsi cette zone (tout en permettant de sélectionner le texte y étant présent).

a écrit :
C'est le principe essentiel du html, de passer d'un contenu à l'autre en suivant des liens

Merci j'ai une vague notion de ce qu'est le web et même du standard HTML : un lien c'est <link /> ; <a /> est une ancre permettant une référence hypertexte (tiens "href") à un fragment du contenu (#).

a écrit :
Pourquoi ne pas utiliser un lien ( du type "Lire la suite" ) à la fin de ton paragraphe, sans que toute la zone soit cliquable ?

Tu y réponds

a écrit :
pour une question d'accessibilité

Une ancre fait référence à un contenu tierce : quoi de mieux que le titre de ce contenu pour y faire référence ? Ce n'est pas la fonction d'un chapô qui décrit ce contenu, d'où l'absence de la balise <a /> sur cette information, le cas échéant le balisage ne me paraît pas pertinent.

De mon point de vue, le balisage HTML ne doit pas être dicté par l'interface. Il est à utiliser uniquement pour structurer l'information ; CSS permettant d'obtenir le rendu graphique.
Modifié par yep (13 Dec 2011 - 12:05)

Hum...

Voila ce qu'est link


Uniquement pour importer une ressource externe, donc. <a> n'est pas qu'une ancre, c'est un lien hypertexte, la fondation du html.

Un lien ne fait pas référence, il envoie vers. Une ancre, c'est pareil : elle envoie vers un contenu dans la même page.

a écrit :
Pour ma part, je n'utilise pas les titres de niveau 1 et 2 dans l'entête ou le pied de page de mes documents (Word ou HTML). C'est mon choix.

Aucun niveau de titre dans l'entête ? Alors que c'est l'introduction à l'ensemble du site ? Tu vas toi-même à contresens de la définition d'un niveau de titre que tu cites. Et tu es bien le seul à ma connaissance à ne pas utiliser de h1 pour le titre d'un site ou son logo par exemple.

Sinon, pour en revenir à ton problème de compatibilité : dans ton exemple, tu n'as pas appliqué de z-index à ton <p>. Essaies d'en appliquer un, inférieur à 1000. C'est IE, donc autant essayer.

Si jamais ça ne change rien, c'est que les position:absolute associées aux marges lui posent problème : il faudra peut-être essayer des positions relatives, par exemple.

Pour finir :

a écrit :
De mon point de vue, le balisage HTML ne doit pas être dicté par l'interface. Il est à utiliser uniquement pour structurer l'information ; CSS permettant d'obtenir le rendu graphique.

Tu as au moins compris ça : mais je vois mal comment tu fais entrer une zone cliquable étendue dans la partie "rendu graphique"... Un lien - et donc une zone cliquable - fait partie de l'information au même titre qu'un paragraphe. Cela a une signification sémantique importante ( surtout quand tu évoques le référencement naturel ).

Ce n'est également que mon avis - mais ce qui est évident c'est qu'avec la sémantique proposée par Laurie-Anne tu n'aurais pas rencontré ton problème.

Bonne continuation !
Modifié par Ten (13 Dec 2011 - 12:19)

Hello.

yep a écrit :
Une ancre fait référence à un contenu tierce : quoi de mieux que le titre de ce contenu pour y faire référence ? Ce n'est pas la fonction d'un chapô qui décrit ce contenu (...)

Voilà, tu as répondu à ta question.

Justement, d'où la balise <a /> uniquement sur le titre, même si pour faciliter l'interaction (le clic), CSS permet d'améliorer l'expérience utilisateur en élargissant cette zone ; le tout selon le principe de la loi de Fitts pour que l'utilisateur puisse accéder plus rapidement à la fonction de clic, mais aussi pour lui faciliter le clic parce que la zone cliquable est plus grande qu'un petit texte.
Modifié par yep (13 Dec 2011 - 12:35)

Dans ce cas, mets du padding sur ton texte, rends le plus visible. Mais ne rend pas cliquable un élément qui n'est pas un élément d'interface. Visiblement tu cherches la solution la plus ergonomique. Détourner un élément de son usage est certainement la pire.

La loi de Fitts ne touche en aucun cas à la sémantique, ce qui est le sujet de controverse principal dans ce cas. L'application pratique de cette loi dans l'ergonomie web consiste la majeure partie du temps à ne pas serrer un petit lien dans un petit bouton - en caricaturant. Elle traite du mouvement et de son objectif : dans ton cas, la propension au clic augmente proportionnellement à la taille de la zone cliquable.

Cela, on l'avait tous bien compris.

Le problème que Laurie-Anne a soulevé et que je tente au mieux de comprendre et d'expliquer, c'est que tu tentes de rendre cliquable un élément qui ne l'est pas. Ce qui, sémantiquement, est une mauvaise pratique.
Modifié par Ten (13 Dec 2011 - 12:48)

yep a écrit :
- accessibilité : lors de la lecture des &quot;liens&quot; dans la page (donc sans leur contexte), un paragraphe va être trop long et ne renseigne pas sur le contenu lié parce qu'il le décrit.

Pas de souci ici, seul le début du paragraphe sera renseigné. Les utilisateurs ont l'habitude. Il n'y a donc aucun problème d'accessibilité.

yep a écrit :
- référencement &quot;naturel&quot; : reprend la même problématique que précédemment mais c'est surtout pour mieux identifier/qualifier les contenus

Pas de problème non plus, du moins rien de démontrable.

Si tu veux juste qu'on te débugge ton code, pourquoi demander s'il est sémantique et accessible (et refuser qu'on te signale qu'il n'est ni l'un nu l'autre) ?

merci à tous pour vos retours.

Je viens de passer 30 min à écrire une réponse à vos retours, pour finalement tenter d'être plus succinct.

Ma question n'était pas assez précise : elle ne porte pas sur l'aspect "sémantique" (quel code utiliser) mais sur le comportement d'IE face à du texte placé sous une zone cliquable.

Du coup, je souhaitais in fine un débogage mais en sachant au préalable si le rendu obtenu par IE était un bug (ou non) et s'il existait une solution pour obtenir le même rendu que sous FF, Opéra, Safari qui étendent la zone cliquable comme spécifié en CSS et cela, si possible, sans modifier le HTML.

On a "légèrement" dévié la discussion, dans ce cas.

As-tu essayé les diverses solutions proposées, et réussi à parvenir à tes fins ?

Effectivement un peu, mais cela reste constructif, j'aime ça (merci encore pour vos retours).
@Ten, je réponds à ton message précédent.

Ten a écrit :
Hum...
Voila ce qu'est link
Uniquement pour importer une ressource externe,

Je citerais plutôt la source http://www.w3.org/TR/html4/struct/links.html#h-12.3
(W3Schools est une ignominie sans nom) où un lien (traduction littérale de "link") permet d'associer deux ressources par différente relation allant d'un sens à l'autre (attributs "rel" et "rev").

a écrit :
&lt;a&gt; n'est pas qu'une ancre, c'est un lien hypertexte

"a" pour "anchor" traduit par "ancre", non ? La notion d'hypertexte vient avec l'attribut "href" pour "h+ref" soit "référence hypertexte", mais celui-ci n'est pas obligatoire.

Du coup une ancre fait référence à un document ou une partie de ce document (fragment). C'est le navigateur qui rend cette balise "activable/cliquable" et qui charge le document lorsque cet élément est activé.

Ten a écrit :
Aucun niveau de titre dans l'entête ? Alors que c'est l'introduction à l'ensemble du site ?

Je n'avais jamais pensé que le header pouvait être assimilé à l'introduction du site.

Ten a écrit :
Tu vas toi-même à contresens de la définition d'un niveau de titre que tu cites.

Non, je fais souvent le parallèle à un bon document Texte :
- la page de garde avec un titre = <title />
- au niveau des parties, les titres = headings
Les éléments contextuels tel que l'index ou le sommaire (= nav), l'entête (= header), le pied de page (= footer) n'ont pas ce type d'éléments structurants dans un document MS Office Word. Pourquoi le faire en HTML ?

Cela va de pair avec

a écrit :
Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.

... comme sur un wiki ou sur les documents du W3C : le sommaire reprend les titres des sections, titres appliqués au contenu (vs. contexte).

HTML a été conçu pour structurer l'information pas pour faire de la présentation, ni de l'interaction comme c'est actuellement en train d'être le cas (cf. HTML5) : cette technologie est dépassée pour ce dont nous avons besoin.
Alors, certes les éléments contextuels sont apparus pour faciliter la navigation, l'accès aux contenus.

Ten a écrit :
Et tu es bien le seul à ma connaissance à ne pas utiliser de h1 pour le titre d'un site ou son logo par exemple.

En agence web, beaucoup de développeurs utilisent le <h1 /> dans le header pour avoir au minimum un <h1 /> dans la page, parce que les webdesigners n'en ont pas prévu. Ils tentent de pallier l'incompétence de certains, c'est devenu une habitude de développements.

Ten a écrit :
Sinon, pour en revenir à ton problème de compatibilité : dans ton exemple, tu n'as pas appliqué de z-index à ton &lt;p&gt;. Essaies d'en appliquer un, inférieur à 1000. C'est IE, donc autant essayer.

J'ai tenté sans succès, d'où mes questions.

Ten a écrit :
Si jamais ça ne change rien, c'est que les position:absolute associées aux marges lui posent problème : il faudra peut-être essayer des positions relatives, par exemple.

Je vais tenter de ce pas, merci.

Ten a écrit :
Tu as au moins compris ça : mais je vois mal comment tu fais entrer une zone cliquable étendue dans la partie &quot;rendu graphique&quot;... Un lien - et donc une zone cliquable - fait partie de l'information au même titre qu'un paragraphe. Cela a une signification sémantique importante ( surtout quand tu évoques le référencement naturel ).

Justement, j'en reviens au fait que ceux sont les navigateurs qui définissent les balises <a /> comme "interactives/cliquables", alors qu'elles ne sont pas les seules : il pourrait y avoir un rendu pour l'attribut "longdesc" sur les images par exemple, ou des liens créés automatiquement dès la présence de l'attribut "href" sur les éléments qui peuvent le supporter.
Un "lien" est cliquable si et seulement si l'attribut "href" est défini.

Un grand merci pour ces retours, je tente avec un "position:relative" et vous tient au courant.
Modifié par yep (13 Dec 2011 - 16:08)

C'est vraiment intéressant ce que tu dis, mais je ne peux m'empêcher de tiquer sur la comparaison entre un document html et un doc word.

Le html a évolué tout à fait différemment de la bureautique, c'est bien ce qui en fait un média à part entière. La direction dans laquelle évolue le html avec html5 semble affirmer cette idée, justement.

D'un autre côté, je saisis bien l'importance que tu donnes à la structure de l'information, et je pense que c'est un sujet trop peu pensé en agence. Mais à l'inverse de toi, il me semble tout à fait juste de dire que la structure de l'information est la pour servir sa présentation : l'objectif d'une telle structure est de rendre le contenu lisible et praticable facilement. C'est d'ailleurs bien le but de Word, avec ses mises en pages douteuses, ou d'InDesign dans un versant plus professionnel.

On établit effectivement un sommaire, une hiérarchie de contenus et des liens contextuels afin de faciliter le parcours et la recherche de l'information.

Et dans ce rapport aux documents texte, il manque vraiment la dimension de l'action. Un navigateur rend effectivement la balise <a> cliquable car elle engage une action, tout comme le font les éléments de formulaires. Et on l'indique grâce à un curseur différent. Cela fait partie des usages du web, qu'aucune structure de l'information ne peut rendre sans l'interaction du html.

Concernant les h1, tu es bien dur avec les webdesigners : on ne met pas un h1 autour d'un logo ou du nom d'un site parce qu'il n'y en a pas ailleurs, mais bien parce que c'est l'information la plus importante dans chaque page. Aucune autre balise ne peut mieux rendre l'importance sémantique du logo / nom du site.

Je suis réellement intrigué par l'énorme différence d'interprétation que peuvent susciter ces principes basiques du html. Les spécifications sont ce qu'elle sont : de longues, très longues pages d'explications sujettes à interprétations - des designers, développeurs, navigateurs, OS, etc.. mais l'évolution permanente des pratiques et des spécifications donne la direction générale. Et j'espère ne pas me tromper en la suivant, comme la majorité des professionnels du web.

Ou en es-tu sur ton problème initial ? Est-ce que ça a bien un rapport avec les positions ?

J'ai tenté, sans succès, le comportement souhaité ne passe pas sur IE.

Alors essayons d'avancer. Concernant ton css, tu peux déjà retirer les marges et les remplacer par les propriétés top et left : cela placera bien plus naturellement tes éléments. Il reste préférable d'utiliser des positions relatives, à mon avis, car les éléments ne sortent pas du flux.

Ensuite, je pense qu'il manque à ton conteneur exemple un position:relative et un z-index dont la valeur est à tester - je dirais au-dessus de 1000.

Un problème très courant sur IE avec le z-index est résolu en positionnant également le parent. D'ailleurs, tu n'as pas précisé de quel version d'IE on parlait ?