5568 sujets

Sémantique web et HTML

Pages :
Bonjour comment faire un lien : "Ajouter au favoris" pour qu il soit conforme au W3C sans passer par javascript
Merci pour vos reponses
Bonjour,

On évitera en fait de dupliquer dans la page Web des fonctionnalités natives des navigateurs : chaque utilisateur dispose, dans son navigateur, d'un moyen d'ajouter un lien à ses signets/favoris à sa convenance. Il peut avoir des exceptions quand la conception de la page est telle qu'elle bloque la fonctionnalité native, mais ce n'est pas le cas ici.

D'autre part, l'ajout aux favoris ne peut se faire que via javascript, avec plus ou moins de compatibilité selon le navigateur, et plus ou moins de succès selon la configuration de ceux-ci : on aboutit inévitablement à des liens qui ne fonctionnent pas pour certains utilisateurs, ce qui produit l'effet inverse de ce qu'on escomptait : au lieu de leur simplifier les choses, on les plonge dans la perplexité Smiley cligne

A trop vouloir prendre en main le visiteur, on oublie qu'il est d'abord utilisateur : les réponses pré-conçues qu'on lui propose seront souvent dénuées de sens dans son contexte d'utilisation.

Note: au passage, même remarque sur la non-duplication de fonctionalités natives pour les liens type "imprimer cette page", "aller en haut", "agrandir les caractères"...
Modifié par Laurent Denis (10 Feb 2006 - 08:15)
merci pour la reponse je vais retirer mon lien "ajouter en favoris" de mon site
Modifié par finpiet (10 Feb 2006 - 16:52)
a écrit :
Note: au passage, même remarque sur la non-duplication de fonctionalités natives pour les liens type "imprimer cette page", "aller en haut", "agrandir les caractères"...


Houla une fois de plus je ne comprends plus.

pas de système permettant d'augmenter la police autre que celui du navigateur?

et pas de liens "retour haut de page"?

C'est quand que vous allez vous mettre d'accord en ce qui concerne l'accessibilité j'en ai marre de jouer les girouettes.
La duplication des fonctionnalités du navigateur est un pis-aller mis en cause depuis longtemps.
Modifié par Laurent Denis (11 Feb 2006 - 15:05)
J'ai participé à l'atelier accessibilité de la spip féria 2005 à Paris.

Présent stephane deschamps et Aurélien .

Conseil entendu au cours de cet atelier mettre un lien haut de page.

Stéphane donnant l'exemple d'une personne ne pouvant naviguer qu'avec son menton et à qui on n'evite de se retaper le scroll inverse une fois en bas de la page.

Alors quand on fait de l'accessibilité de validateurs ça vas y'as pas de mal mais quand on écoute que l'on s'applique et que l'on veux faire de l'accessibilité réfléchie, que l'on gratte un peu ça se barre joyeusement en couille y'en as pas un qui dit pareil.

C'est pénible de lire et d'entendre tout et son contraire et de pouvoir se forger sa propre idée dans des conditions pareils.
Modifié par knarf (16 Feb 2006 - 22:13)
Modérateur
Bonjour knarf et les autres,

Je pense qu'il est normal d'être sans cesse confronté à des avis et opinions contradictoires lorsqu'il est question d'accessibilité. C'est un sujet vague où plusieurs facteurs et interprétations des situations font que certaines fonctionnalités sont discutables. Il y a souvent 10 bonnes raisons d'ajouter un truc dans ses pages pour améliorer l'ergonomie et l'accessibilité, mais quelqu'un peut arriver à trouver 10 bonnes raisons de le retirer.

Pour l'ajout aux favoris, je suis d'accord que ca n'a pas sa place dans le document web et je pense que nous sommes tous d'accord là-dessus. Pour ce qui est du lien Aller en haut de page, je ne suis pas du même avis que Laurent. Je crois qu'utilisé un seul Aller en haut de page tout en bas du document web peut s'avérer très utile et je ne vois pas comment ce lien pourrait venir nuire à l'accessibilité du document si des bonnes pratiques sont appliqués sur celui-ci.

Là où je suis d'accord que les Aller en haut de page sont une mauvaise pratique c'est lorsqu'ils sont utilisés en sur-abondance dans le document. Après chaque paragraphe par exemple. C'est redondant et j'imagine pas la catastrophe dans les lecteurs écrans et la navigation au clavier.

Pour ce qui est de laisser l'utilisateur utiliser les fonctionnalités déjà à sa disposition, au niveau du clavier, d'accord, il y a la touche Home. Mais prenons quelqu'un qui navigue exclusivement à la souris. Que ce soit avec IE ou Firefox, comment peut-il revenir en haut de page ? Dans Firefox, je ne vois aucun bouton rapidement cliquable pour le faire, et dans IE, la seule chose que j'ai trouvé c'est de faire un clique-droit sur la scrollbar et cliquer sur TOP. Avec autant d'accrobatie, aussi bien de s'ouvrir une succursale du Circle du Soleil. Smiley smile

Au niveau de l'ergonomie et l'accessibilité, tout est une question de dosage, et tout n'est pas totalement noir ou blanc.
knarf a écrit :
Matthieu donnant l'exemple d'une personne ne pouvant naviguer qu'avec son menton et à qui on n'evite de se retaper le scroll inverse une fois en bas de la page.


Pour un réponse circonstancielle à un cas d'utilisateur très spécifique, on va générer divers problèmes qui toucheront un public plus large (problèmes de reprise du focus, comportement imprévu dans telle configuration, prise d'habitude de l'utilisateur de ne pas utiliser son navigateur, etc.)

C'est pour ce type de cas que l'accessibilité ne consiste justement pas à entasser dans la page Web des réponses au cas par cas.
Administrateur
"Vouloir rendre une page accessible à tous, c'est la rendre inaccessible à certains."

(parfois je m'étonne)
Tony Monast a écrit :
Mais prenons quelqu'un qui navigue exclusivement à la souris. Que ce soit avec IE ou Firefox, comment peut-il revenir en haut de page ?


Ce n'est pas une problématique d'accessibilité. Soit :
- on a affaire à un utilisateur contraint d'utiliser un dispositif de pointage très spécifique, et c'est du ressort de celui-ci et de son interface (cliquer sur un bouton "haut de page" de l'interface de l'UA, utiliser une mouse gesture, etc)
- on a affaire à une préférence personnelle...

On n'ira nulle part en accessibilité en voulant tout assumer dans la page Web (l'accessibilité totale et le reste) et en oubliant que des normes d'accessibilité des agents utilisateurs répondent aux normes de contenus.
Modifié par Laurent Denis (11 Feb 2006 - 16:29)
Modérateur
Laurent Denis a écrit :

Ce n'est pas une problématique d'accessibilité. Soit :
- on a affaire à un utilisateur contraint d'utiliser un dispositif de pointage très spécifique, et c'est du ressort de celui-ci et de son interface (cliquer sur un bouton "haut de page" de l'interface de l'UA, utiliser une mouse gesture, etc)


Oui, mais sans vouloir présumer quoique ce soit, je pense qu'il est prudent de dire que beaucoup d'utilisateurs ne savent pas comment configurer et personnaliser leur User-Agent, et encore moins pour du mouse gesture.

Laurent Denis a écrit :

On n'ira nulle part en accessibilité en voulant tout assumer dans la page Web (l'accessibilité totale et le reste) et en oubliant que des normes d'accessibilité des agents utilisateurs répondent aux normes de contenus.


Ajouter un seul lien Haut de page, invisible à l'impression, en bas totalement du document, je ne trouve pas que c'est vouloir assumer toute l'accessibilité dans la page web. D'ailleurs, je ne vois pas non plus de problématique à le faire.

À l'état actuel, sur deux navigateurs très populaires (IE et Firefox), je ne vois aucune fonctionnalité ergonomique pour revenir en haut de page facilement. Entre le souhaitable, et l'état réel des navigateurs web et de leur utilisation d'aujourd'hui, il y a des concessions à faire. Le jour où la majorité des navigateurs offrira un bouton natif dans l'interface pour aller en haut page, je serai tout à fait d'accord pour supprimer ces liens Haut de page dans mes pages web.
Tony Monast a écrit :


Oui, mais sans vouloir présumer quoique ce soit, je pense qu'il est prudent de dire que beaucoup d'utilisateurs ne savent pas comment configurer et personnaliser leur User-Agent, et encore moins pour du mouse gesture.


Tout à fait d'accord. Mais est-ce de l'accessibilité ?

C'est amusant: on est prêt à se reposer parfois sur des réglages utilisateurs dans Jaws pour l'accès aux intitulés de liens, ou aux formulaires (sachant que Jaws est une horreur effroyablement complexe à configurer et à apprendre), mais on considère que l'utilisateur d'un navigateur graphique doit être déchargé de la responsabilité d'un apprentissage nettement plus aisé ? Pour des problèmes nettement moins obstructifs ?

Je veux bien, ce sont des problèmes réels. Mais il y a un problème de notion sur ce qu'est l'accessibilité à régler d'abord; surtout s'il s'agit de demander des règles d'accessibilités simples, directes et uniques Smiley cligne

Tony Monast a écrit :
Ajouter un seul lien Haut de page, invisible à l'impression, en bas totalement du document, je ne trouve pas que c'est vouloir assumer toute l'accessibilité dans la page web. D'ailleurs, je ne vois pas non plus de problématique à le faire.


Voir http://www.cs.tut.fi/~jkorpela/www/totop.html , pour un synthèse (très) récente.

Tony Monast a écrit :
Le jour où la majorité des navigateurs offrira un bouton natif dans l'interface pour aller en haut page, je serai tout à fait d'accord pour supprimer ces liens Haut de page dans mes pages web.


Avec alors le problème d'utilisateurs qu'il faudra sevrer ou qui n'auront pas été incités à chercher un outil plus adapté à leurs besoins qu'IE et FF en configuration par défaut, ainsi que d'ergonomies fonctionnelles qui changeront d'un coup.

Une chose importante, dans tout cela : le retour en haut de page, s'il est absent de l'interface pour un utilisateur qui pourrait en avoir besoin : ce n'est pas obstructif. Pour reprendre l'exemple cité par Raphaël, c'est pénible de scroller jusqu'en haut. Mais ça se fait. On ne parle pas ici de fonctionnalité dont l'absence est obstructive pour un utilisateur.
Administrateur
a écrit :
Tout à fait d'accord. Mais est-ce de l'accessibilité ?

Personnellement j'aime bien considérer l'accessibilité au delà du simple handicap.
Un certain Tim Berners-Lee a dit un jour :
a écrit :
"Rendre le Web accessible signifie mettre le Web et ses services à la disposition de tous les individus, quels que soient leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales"

On va bien plus loin que le simple handicap physique ou mental.


Moi j'ai un exemple très bête et quotidien : comment produire des documents accessibles à mon novice de papa ?
Il n'est pas pour ainsi dire handicapé, mais sa réticence informatique est à elle seule un sacré handicap !

Pour être clair : si mon papa n'a pas de lien "haut de page", il va s'amuser à scroller l'ascenseur, même si la page fait 3km.
Pour lui, avoir un bouton "haut de page" rend sa navigation sacrément plus facile.

a écrit :
Pour reprendre l'exemple cité par Raphaël, c'est pénible de scroller jusqu'en haut. Mais ça se fait. On ne parle pas ici de fonctionnalité dont l'absence est obstructive pour un utilisateur.

Exact. Ce n'est pas obstructif.
Utiliser des tableaux imbriqués n'est pas obstructif non-plus, utiliser des frames multiples non-plus. (Je le sais pour avoir testé des sites épouvantables avec une étudiante aveugle sous Jaws).
Ne pas utiliser d'accesskeys, de liens d'évitements, etc. n'est pas bloquant pour l'utilisateur.

En fait très peu de choses sont vraiment obstructives. Souvent, les règles d'accessibilité ne sont que de l'ordre du confort (plus ou moins important).

Mais faciliter la navigation ou l'accès au contenu, apporter du confort aux utilisateurs, c'est pas un peu ça aussi, l'accessibilité du Web ?
Modifié par Raphael (11 Feb 2006 - 17:09)
Raphael a écrit :

Mais faciliter la navigation ou l'accès au contenu, apporter du confort aux utilisateurs, c'est pas un peu ça aussi, l'accessibilité du Web ?


Alors la, tout a fait d'accord.

Quand au "surchargement" de la page, il me semble qu'un simple lien " haut de page" ne surcharge pas plus que bien d'autres choses completement futile que l'on voit souvent sur les sites.
Raphael a écrit :
Moi j'ai un exemple très bête et quotidien : comment produire des documents accessibles à mon novice de papa ?
Il n'est pas pour ainsi dire handicapé, mais sa réticence informatique est à elle seule un sacré handicap !


Encore une fois : ça n'entre pas dans le champ de l'accessibilité. ça ne veut pas dire que cela n'est pas un problème, loin de là. Mais que l'accessibilité, sa démarche et ses normes ne sont pas l'outil pour y répondre.
Raphael a écrit :
Utiliser des tableaux imbriqués n'est pas obstructif non-plus,


Si. L'imbrication de tableaux rend impossible la tâche des outils d'aide quand il s'agit de tenter de reconstituer la cohérence sémantique.

Raphael a écrit :


Mais faciliter la navigation ou l'accès au contenu, apporter du confort aux utilisateurs, c'est pas un peu ça aussi, l'accessibilité du Web ?


Non. C'est de l'ergonomie, du savoir-faire, de la qualité même (et surtout). Mais pas de l'accessibilité.

(Je suis tout à fait volontairement concis : il y a une définition de l'accessibilité. On en a parlé sur ce forum, à propos de 4 principes de bases et d'une démarche.)
Modifié par Laurent Denis (11 Feb 2006 - 18:30)
Modérateur
Laurent Denis a écrit :

Voir http://www.cs.tut.fi/~jkorpela/www/totop.html , pour un synthèse (très) récente.


Oui, je sais, je l'ai lu avant de répondre, mais je ne suis pas d'accord sur certains points. L'analyse est quand même intéressante, lorsqu'on prend la peine de la lire jusqu'au bout.

Pour le moment, je suis ni contre ni pour l'utilisation d'un lien haut de page, je le fais uniquement lorsque le client ou le patron le demande. Je ne trouve pas que les points négatifs s'appliquent dans tous les cas, et certains sont très discutables.

Je suis quand même de près cette discussion, sait-on jamais si quelqu'un arriverait à me convaincre.
Modérateur
Laurent Denis a écrit :

Je suis tout à fait volontairement concis : il y a une définition de l'accessibilité. On en a parlé sur ce forum, à propos de 4 principes de bases et d'une démarche.


J'ai raté ce sujet ? Pourrais-tu être plus précis ? J'aimerais connaître ces 4 principes de bases et de la démarche.

Merci !

P.S. S'il-vous-plaît, cessez d'être trop intéressant dans la discussion, ma copine me gueule après parce que je suis rivé sur le forum, un beau samedi après-midi ! Smiley eek
Donc on pourrais considerer que le switcher d'Openweb qui pour moi montrait l'exemple Smiley eek est à l'encontre de ce que viens d'expliquer Laurent-Denis car les feuilles de styles utilisateurs c'est bien gérable par l'agent utilisateur.

Pour le lien favoris pas de doute mais pour le lien haut de page si je suis les conseils de ne pas empiler plusieurs fonctionnalités offertes déjà par le navigateur je fait comme bleeps qui as enlevé son lien favoris et j'enléve de ce fait un confort qui ne rendait pas la page innaccessible.

Pourquoi au lieu de condamner d'office ce confort de la maniére ou cela est dit ne pas expliquer que si il est utilisé correctement et à bon escient cela peux s'avérer utile mais en mettant les warnings nécéssaires sur la surrabondance néfaste de ce type d'aide.

A chaque fois que je te lis Laurent j'ai des pans entier de ce que je croyais êtres des acquis qui se cassent la gueule.

Le dernier en date le fait de passer l'information uniquement par la couleur c'était pour un lien en l'occurence.

Le message d'aprés tu me retorque que trop d'information tue l'information et ben là je suis sur le cul et je t'avoue que je ne sais plus quoi faire et qui écouter.

C'est de trop de suivre cette recommandation à la lettre je suis encore trop rigide dans mon interprétation de l'accessibilité?

Je crois que c'est ça qui me donne le plus de mal la différence d'interprétation en fonction de la question.

a écrit :
On n'ira nulle part en accessibilité en voulant tout assumer dans la page Web (l'accessibilité totale et le reste) et en oubliant que des normes d'accessibilité des agents utilisateurs répondent aux normes de contenus.


On ira nulle part en n'éduquant pas les utilisateurs à se servir de ces agents utilisateurs.

Si le gens étaient formés on ne se forcerait peut être pas à tout assumer.

On avait commencé sur web pour tous dans un article végétatif de la version 2 à expliquer par exemple l'utilisation de <link> sur les navigateurs le permettant, expliquer à quoi servait les liens d'évitements , à cela ajouter le fait de créer et d'utiliser une feuille de style utilisateur, et tous ce que peux apporter un navigateur comme Opéra, apprendre aux gens qu'ils peuvent redimensionner la police via le navigateur, quand ils en auront marre de surfer sur des sites ne le permettant pas sous IE il passerons à un autre navigateur ou zapperons le site, des 2 cotés c'est bénéfique.

Il faudrait que l'on s'y remette mais c'est vrai que le temps manque pour chacun de nous.

Je compare l'internaute à un consomateur, si on lui explique qu'il peux avoir mieux sans payer plus chére la logique voudrait qu'il veuille de la qualité et soit plus critique envers un site ou un navigateur ne la donnant pas.


EDIT:

tony, c'est à vérifier mais je crois bien que ce dont parle parle Laurent-Denis c'est quelquepart dans cet échange.

Existe til-un-résumé-sur-l'accessibilité
Modifié par knarf (11 Feb 2006 - 21:20)
Je viens de relire je ne sais pas combien de fois pour essayé de capter la nuance entre principe, méthodologie et point de contrôle de l'accessibilité.

Donc en fait tout ce dont je parle, liens d'évitements, switcher, retour haut, ne sont en aucun cas des principes d'accessibilité ce ne sont que des surcouches fonctionnelles apportant du confort (ergonomie) mais qui si elles sont trop utilisées peux nuire à l'expérience utilisateur.

Si je reprends ce qu'ont dit Laurent-denis et jpv dans l'échange cité:

Le principe:
Les éléments d'interaction doivent être utilisables ;

La méthodologie ou la démarche:
Permettre une expérience fonctionnelle quelque-soit le media ou les capacités du client.

Le point de contrôle:
Existe t il une solution alternative si il existe un risque que le média proposé ne soit pas accessible à l'utilisateur (flash, javascript...)

Si on ne prends pas en compte les 2 premiers dans le devellopement et que l'on passe directement au troisiéme c'est presqu'à coup sur l'utilisation d'une jambe de bois pour y parvenir ou être obliger d'inclure quelquechose qui n'as pas été prévu et pensé.

ou

le principe
Le contenu et les commandes doivent être compréhensibles ;

la méthodologie ou la démarche:
Concevoir un contenu cohérent et compréhensible sur la seule base du flux.

Le point de contôle :
la navigation est elle cohérente en cas de navigation au clavier et sinon utiliser les tabindex (j'ai pas la dénomination exacte en tête).

Si les 2 premiers n'ont pas été pris en compte et que l'on à recours aux tabindex pour satisfaire le point de contrôle c'est à coup sur aller droit dans le mur.
Modifié par knarf (12 Feb 2006 - 04:29)
Bonjour à toutes et tous Smiley smile

Juste pour en remettre une petite couche Smiley lol

Le référentiel ADAE est le document de référence que devra utiliser, entre autre, la fonction publique, pour rendre ses sites accessibles. Ci-dessous, Priorité : Argent, un extrait de la recommandation 12.4 (Aide à la navigation)
Référentiel ADAE a écrit :

Proposer aussi des liens de retour vers le haut de page lorsque les pages sont longues...


Au delà de cette recommandation, j'utilise beaucoup cette possibilité pour ma navigation personnelle... Donc je l'installe sur mes sites Smiley cligne
Modifié par dominique (13 Feb 2006 - 10:07)
Pages :