L'utilité de la balise <a> dans une application web

Salut,

J'écris encore une fois au sujet de mon album photo dynamique fait avec Jquery et toujours pour faire les choses le plus proprement possible.

Tout d'abord il faut savoir que je génère un album statique en CSS que j'écrase ensuite avec le javascript. Dans cette petite application j'utilise des images comme bouton de navigation. Ma question est donc faut-il faire de ces images des liens (ou ancres choisissez le terme que vous préférez) pour que ce soit "sémantiquement" correct? Car, en fait, il n'y a plus d'ancre, plus de destination réellement mais juste une action associée au clique! Et concrètement, avec JQuery, on n'a quasiment plus besoin, si ce n'est plus du tout, de la balise <a>.

J'attends donc vos avis.

Merci par avance,

bbp.
Modifié par bbp (21 Nov 2007 - 11:39)

Salut,

Pour être indépendant du mode de navigation (et donc conserver la navigation clavier, entre autres), il faut que ces actions soient effectuées sur des éléments focusables -> très souvent des liens.

En théorie, un clic sur l'un de ces liens devrait emmener le visiteur sur une nouvelle page où se trouverait ta photo et via JS, on annule l'action normale du lien en la remplaçant par une de son choix.
Modifié par koala64 (21 Nov 2007 - 11:50)

Pas bête le coup du focus.
Par contre, j'ai choisi de faire mon album en pur css sans aller d'une page à l'autre. Je n'aime pas ouvrir une page blanche avec uniquement une photo dedans...

C'est plus une question d'accessibilité.

Ce qui compte avant tout, c'est l'accès à l'information indépendamment des technologies disponibles. Javascript, c'est une option, tout comme CSS, et à ce titre, il est mal venu de faire dépendre ton application de ces langages, que tu te serves d'une bibliothèque ou non.

Après, rien ne t'empêche de mettre ta page en forme plutôt que de balancer une simple photo lorsque JS est indisponible. Ca demande un peu plus de traitement mais ça permet de rendre un service, non pas totalement équivalent mais, plus proche de ce que tu aurais pu obtenir lorsque chaque langage est actif.

En fait ton premier message m'a fait réfléchir à d'autres points de l'ergonomie. Mais ce n'est plus de la sémantique. Je trouve tout de même l'intérêt de <a> plutôt limité dans mon cas.

Hello,

Sinon, tu peux éventuellement utiliser un bouton (<button>, <input type="button">, ...).

<edit>Mais ça ne t'affranchit pas du problème de l'accès à l'information si JavaScript est désactivé, comme le dit koala64.
Modifié par Julien Royer (21 Nov 2007 - 14:21)

Si javascript est désactivé, c'est déjà fait. Les boutons, quant à eux, doivent être dans un formulaire et puis coté mise en forme...
Même le lien, je ne vois plus trop l'intérêt de l'utiliser car on peut définir les tabindex et créer d'autres raccourcis comme les flèches gauche et droite pour le défilement des photos.

bbp a écrit :
Les boutons, quant à eux, doivent être dans un formulaire

Non.

bbp a écrit :
et puis coté mise en forme...

Ca par contre, c'est un problème, en effet.

bbp a écrit :
Même le lien, je ne vois plus trop l'intérêt de l'utiliser car on peut définir les tabindex

Mouais, bof.

bbp a écrit :
et créer d'autres raccourcis comme les flèches gauche et droite pour le défilement des photos.

À voir. Tu ne risques pas de perturber l'utilisateur en assignant des actions de navigation à des touches qu'il peut utiliser pour d'autres raisons?

Une chose que je n'ai pas comprise: sans Javascript, tu as quoi à la place de tes liens? Quel moyen de navigation?

Le système classique, c'est quand on a une couche HTML avec des liens pointant vers les diverses pages ou documents (dont des photos seules, à la rigueur), et qu'en Javascript on intercepte le clic sur le lien (et donc le chargement du document par le navigateur) pour lancer une fonction qui chargera un contenu dans la page en cours.
Tu as fait quelque chose de sensiblement différent?

Ce que j'ai aujourd'hui en statique : http://bb.public.free.fr/css/statique.html
Aujourd'hui, je l'écrase purement et simplement http://bb.public.free.fr/css/prelude.html , ce n'est pas forcement la bonne solution. Car les images continuent à se charger si j'en crois firebug sans pour autant d'avoir d'image en réponse ou d'en-tête http!

En fait j'ai (j'aurai plutôt) deux navigations. Un façon miniatures et l'autre sur l'image affichée en grand format avec des boutons suivant et précédent. C'est sur ces boutons que ma question se porte.

Concernant les boutons, je ne mettais jamais posé la question et ne connaissais même pas l'élément button!!! Merci pour ça.

Peut-être faut-il maintenant déplacer ce sujet dans le forum application web...

Et pourquoi tu n'utiliserais pas les liens pour ce a quoi ils servent, c'est a dire ouvrir une autre page?

C'est pourtant simple, sur ta vignette tu mets un lien qui renvoi à la même page mais avec un paramétre qui indique la photo a ouvrir, style index.php?idoc=4.

Et quand javascript est activé tu mets un return:false.

En fait tu n'as pas uniquement le cas ou l'utilisateur n'a pas activé js, tu as aussi le cas de l'utilisateur pressé qui clique partout avant le js chargé, tu as le cas de l'utilisateur qui a la tel version de opéra qui suporte pas jquery v38, le type qui a explorer 5, celui qui as explorer 6 avec un virus étrange... Et le cas ou tu fais une mise à jour de ton js et ou du coup tout ton site foire complétement.

Regarde cette galerie photo (ou je sais ça traine un peu mais le photographe avec ces jpg qualitée 12 et son serveur super partagé m'aide pas beaucoup) avec et sans javascript, cela marche pareil, les fléches et les vignettes.

Edit : C'est une question à débattre mais je ne pense pas que l'on puisse parler d'application web pour une galerie photo. Ce qui peut être consideré comme une application c'est l'interface de gestion de cette galerie. Et effectivement dans cette partie tu peux te permettre plus de liberté par rapport à l'accessibilité parceque tu peux exiger de tes utilisateurs qu'ils aient par exemple js activé pour l'utiliser, mais c'est uniquement pour la partie application.
Modifié par matmat (21 Nov 2007 - 16:53)

matmat a écrit :
Et pourquoi tu n'utiliserais pas les liens pour ce a quoi ils servent, c'est a dire ouvrir une autre page?

C'est pourtant simple, sur ta vignette tu mets un lien qui renvoi à la même page mais avec un paramétre qui indique la photo a ouvrir, style index.php?idoc=4.

Et quand javascript est activé tu mets un return:false.

Tout simplement parce que je ne cherche pas à le faire!

matmat a écrit :
En fait tu n'as pas uniquement le cas ou l'utilisateur n'a pas activé js, tu as aussi le cas de l'utilisateur pressé qui clique partout avant le js chargé, tu as le cas de l'utilisateur qui a la tel version de opéra qui suporte pas jquery v38, le type qui a explorer 5, celui qui as explorer 6 avec un virus étrange... Et le cas ou tu fais une mise à jour de ton js et ou du coup tout ton site foire complétement.

L'internaute nerveux c'est à voir plus tard, la compatibilité je la trouve honorable concernant Jquery. J'ai pas compris le coup de la màj du JS!

matmat a écrit :
Regarde cette gallerie photo (ou je sais ça traine un peu mais le photographe avec ces jpg qualitée 12 et son serveur super partagé m'aide pas beaucoup) avec et sans javascript, cela marche pareil, les fléches et les vignettes.

Pas mal, j'aime assez. Pour finir, et si moi je voulais me faire plaisir en m'intéressant à Jquery?
Edit à mon tour:

matmat a écrit :
Edit : C'est une question à débattre mais je ne pense pas que l'on puisse parler d'application web pour une gallerie photo. Ce qui peut être consideré comme une application c'est l'interface de gestion de cette gallerie. Et effectivement dans cette partie tu peux te permettre plus de liberté par rapport à l'accessibilité parceque tu peux exiger de tes utilisateurs qu'ils aient par exemple js activé pour l'utiliser, mais c'est uniquement pour la partie application.

C'est juste qu'on ne parle plus de sémantique dans ce sujet...

Du coup, je me demande ce que je peux obtenir avec button.
Modifié par bbp (21 Nov 2007 - 16:42)

matmat a écrit :

Edit : C'est une question à débattre mais je ne pense pas que l'on puisse parler d'application web pour une gallerie photo.

Désolé, mais ça me titille à chaque fois...

C'est :
- "gallery" en anglais
- "galerie" en français
... mais "gallerie" n'existe pas.

Je comprend ton interêt pour jQuery et ta reflexion sur le rôle des liens dans une interface web, pour tout te dire dans une interface administrateur des fois pour aller au plus simple je mets même des img onclick="action()"... Parceque les boutons c'est quand tu vas vouloir les mettre en forme que tu vas bien t'amuser...
Mais dans le cas d'une galerie pour moi ça reste un site web donc quelque chose qui doit être le plus robuste possible.
Pour la compatibilité, les choses ce complique toujours quand tu prends en compte l'utilisateur nerveux avec ie, l'utilisateur maladroit avec safari...etc

Pour cadrer un peu les choses:

1. La version jQuery a l'air un peu buguée (ou bien est-ce juste moi?). C'est un problème à traiter spécifiquement, et pas vraiment le sujet ici, donc je n'en dis pas plus.

2. Plus important: la version sans Javascript est très peu utilisable, et pose de gros problèmes en termes d'ergonomie (utilisation pas terrible du :hover) et d'accessibilité (ne serait-ce qu'à cause du chargement intégral des images... mais il n'y a bien sûr pas que ça). J'aurais tendance à dire qu'elle ne sera vraiment utile pour personne, et qu'il faudrait la supprimer.
Par ailleurs, faire deux versions séparées est toujours problématique, en termes de maintenance (il faut faire les choses en double) et pour les utilisateurs (ils faut qu'ils puissent choisir la bonne version à consulter, ce qui n'est pas évident).

3. Si on supprime la version sans Javascript, on a deux options:
- soit on fait uniquement une version Javascript, et basta;
- soit on modifie la version Javascript en utilisant les principes de «graceful degradation» en permettant au moins un accès basique aux images (avec des liens hypertexte qui vont bien).

Quant à la sémantique... vu l'accessibilité nulle des deux versions, je doute que ça ait un impact quelconque si on choisit un balisage «sémantiquement correct» ou «sémantiquement incorrect» (pour peu qu'on puisse définir ce qui serait l'un ou l'autre). Vu comme c'est parti, ça ne sert pas à grand chose de s'en soucier une seconde, je pense.

Raphael a écrit :
C'est :
- "gallery" en anglais
- "galerie" en français
... mais "gallerie" n'existe pas.

C'est vrai qu'il y a nombre d'anglicismes orthographiques dans notre language écrit.

1) Je n'ai pas fournis d'album Jquery, juste le fait de supprimer l'album statique. Ensuite l'affichage de l'album Jquery devrait apparaître, je travaille doucement... Ca part du principe que tu cite dans ton 3.2)

2)Peux-tu m'en dire plus au sujet du chargement des images et de l'accessibilité?

Florent V. a écrit :
Quant à la sémantique... vu l'accessibilité nulle des deux versions, je doute que ça ait un impact quelconque si on choisit un balisage «sémantiquement correct» ou «sémantiquement incorrect» (pour peu qu'on puisse définir ce qui serait l'un ou l'autre). Vu comme c'est parti, ça ne sert pas à grand chose de s'en soucier une seconde, je pense.

Bon voilà, c'est réglé

bbp a écrit :

C'est juste qu'on ne parle plus de sémantique dans ce sujet...

Une précision:personne n'en parle parce qu'il n'y en a aucune à retenir ici.

Si j'ai bien compris (c'est un peu confus), c'est un problème de liens qui ont "#" comme href ?

Dans ce cas, c'est valide. Si l'on veut, c'est "sémantique", quoique personne ne soit à même de fournir la moindre définition utile de ce terme appliqué au HTML, et pour cause. Le plus souvent, il signifie en fait "pas trop inapproprié quand au rôle de l'élément tel qu'il est présenté dans la spécification". Bon bah: ça n'est pas du tout inapproprié.

Ce n'est pas du tout accessible, ni robuste, mais ce n'est apparemment pas le problème. Donc, c'est résolu.

Florent V. a écrit :


Quant à la sémantique... vu l'accessibilité nulle des deux versions, je doute que ça ait un impact quelconque si on choisit un balisage «sémantiquement correct» ou «sémantiquement incorrect» (pour peu qu'on puisse définir ce qui serait l'un ou l'autre). Vu comme c'est parti, ça ne sert pas à grand chose de s'en soucier une seconde, je pense.

On peut avoir d'autres raisons que l'accessibilité de se servir de manière appropriée du balisage HTML. L'interopérabilité et la réutilisabilité, par exemple. "Sémantique" et accessibilité, c'est un peu comme "référencement" et "accessibilité": ça se recoupe sur un champ précis, mais chacun des deux est bien autre chose.

Laurent Denis a écrit :
Ce n'est pas du tout accessible, ni robuste

Pourquoi donc? J'apprends encore et toujours. J'avais déjà plus ou moins vu que ce n'est pas accessible, mais pourquoi? Puis robuste, aussi j'aimerais savoir.
Si quelqu'un veut bien m'expliquer ou un lien à regarder parce que une recherche sur google ne retourne pas grand chose avec "accessibility href" ou "accessibility link"