Accesskey le grand échec de l'accessibilité du Web.

Issu d’une idée aussi vieille que l’informatique, le raccourci clavier appliqué au Web est un cinglant échec qui condamne son utilisation à quelques chiffres associés à des fonctions clés du site.

Les référentiels, comme celui de l’ADAE ou du gouvernement anglais tentent de trouver un consensus en établissant une liste formelle des raccourcis clavier.

Mais à dispositif mal né, problèmes récurrents, cette liste pose autant de problèmes que les raccourcis eux-mêmes...

Rappel : principe du raccourci clavier d'un lien

L’attribut HTML “accesskey”, permet d’implémenter des raccourcis claviers sur les liens d’une page web, il s’utilise comme un attribut du lien sur le modèle : <a href=”...” accesskey=”1”>mapage.htm</a>

Le raccourci ainsi défini est accessible par une combinaison de touche.

Un dispositif mal pensé et mal implémenté

On n’insistera jamais assez sur cette règle d’or : n’utilisez jamais de lettres comme valeur d’accesskey.
Je sais, c’est surréaliste, mais c’est comme ça.

Conséquence sinistre du choix qui a été fait de s’appuyer sur la même combinaison de touche que les raccourcis logiciels, utiliser une lettre comme valeur de raccourci clavier désactivera le menu équivalent du navigateur ou du lecteur d’écran, ou l’inverse selon les choix du fabricant.

Il ne reste donc de disponible que les 9 chiffres, même si certains d’entres eux sont également utilisés par des logiciels à destination des utilisateurs handicapés comme le navigateur vocal Home Page Reader. Pour un système censé prendre en charge la navigation au clavier, c’est peu, très peu.

Ajoutons enfin, comble de l’humour noir pour des utilisateurs dont on peut supposer qu’ils aient une dextérité amoindrie, qu’il faudra sur certaines configurations dont Windows non pas 2 touches comme on le précise de manière erronée, mais 3 : ALT+MAJ+Chiffre (et encore heureux qu’on ne leur demande pas à ce moment là d’appuyer sur la barre d’espace avec le nez, ils auraient fini par croire à une moquerie).
Je sais (tous avec moi) : C’est ridicule, mais c’est comme ça !

Un dispositif limité pourtant indispensable

Au delà de ces limitations, les raccourcis clavier peuvent servir et il faut les utiliser chaque fois que possible sans pour autant être dupe de leur utilité réelle.

Reste maintenant à déterminer l’usage que l’on peut en faire.

Parce que c’est pas le tout de disposer d’une liste de 9 chiffres, partiellement inutilisable et soumise aux conditions logicielles d’utilisation mais encore faudrait-il qu’on soit d’accord sur une liste commune (quel raccourci pour quel usage).

C’est à ce moment là que l’affaire se complique encore, car de 9 chiffres la liste des accesskey va se réduire à 4 malheureux chiffres “utilisables en toute circonstance” et une grosse ambiguité.

Le consensus impossible

Donc, co-existent plusieurs listes qui tentent de fédérer des usages de fait ou supposés, et c’est bien là que le bât blesse.

La liste qui fait consensus, établie par le gouvernement anglais et reprise par l’ADAE est la suivante :

  • Touche s : Passer le menu
  • Touche 0 : Liste des touches clavier utilisées
  • Touche 1 : Page d'accueil (inopérant dans IBM Home Page Reader)
  • Touche 2 : Page d'actualité du site
  • Touche 3 : Carte du site
  • Touche 4 : Champ de saisie d'un formulaire de recherche.
  • Touche 5 : FAQ, Glossaire, index thématique...
  • Touche 6 : Page d'aide à la navigation dans le site
  • Touche 7 : Contact par e-mail
  • Touche 8 : Copyright, Conditions d'utilisation, licence...
  • Touche 9 : Livre d'or, feedback.

Liste, que nous allons répartir différemment, sous un angle plus fonctionnel, pour mieux comprendre ses faiblesses :

  • Touche s : Passer le menu
  • Touche 0 : Liste des touches clavier utilisées.
  • Touche 6 : Page d'aide à la navigation dans le site
  • Touche 3 : Carte du site
  • Touche 1 : Page d'accueil
  • Touche 2 : Page d'actualité du site
  • Touche 5 : FAQ, Glossaire, index thématique...
  • Touche 8 : Copyright, Conditions d'utilisation, licence...
  • Touche 7 : Contact par e-mail
  • Touche 9 : Livre d'or, feedback.

Une liste difficilement applicable

Première remarque, ça démarre très fort : Touche s : passer le menu. Qu’est-ce à dire ? La touche s aurait-elle échappée miraculeusement à l’avidité prédatrice des éditeurs de logiciel ?

Pas du tout, ça veut simplement dire que les rédacteurs utilisaient Internet Explorer, dépourvu de raccourci clavier s et c’est tout (oui je sais c’est..., mais c’est comme ça !).

N’oubliez pas : « N’utilisez jamais de lettre comme valeur de raccourci clavier », exit le s pour passer le menu.

Autre bizarerie : Un lien « passer le menu » s’appelle un lien d’évitement, élément essentiel pour la navigation au clavier.

Généralement, ce lien « passer le menu » va de pair avec un autre lien « aller au contenu ». A l’usage, il apparaît que ces deux liens sont indispensables, notamment en cas de structure de page plus évoluée qu’une simple organisation en « menu-contenu ».

Il semble donc indispensable, si l’on prévoit un raccourci clavier pour passer le menu d’avoir son équivalent pour aller au contenu, ce que n’ont pas fait les rédacteurs de cette liste.

Touches 0, 6, 3 : Liste des touches clavier utilisées, aide à la navigation dans le site, carte du site.

Ces trois touches regroupent les aides à la navigation, on peut se poser la question de l’utilité réelle de 6 « Page d’aide à la navigation dans le site » dont on ne voit pas l’intérêt ni même le contenu.

Par ailleurs, ne serait-il pas plus pertinent, plus souple, plus « friendly » comme le disent nos amis anglais de concentrer l’ensemble de ces aides (réduite dans les faits aux 9 raccourcis clavier et une carte du site) sur la même page ?

Touche 1 : page d’accueil

Rien à dire, nonobstant le fait que « 1 » est réservé par Home page Reader, mais bon, cet usage est suffisamment généralisé pour être conservé.

Touches 2, 5, 8 : Actualités, FAQ, glossaire et index thématique, copyright, conditions d’utilisation et licence.

Là on peut se demander ce qui est passé par la tête des rédacteurs : Si je n’ai pas de pages d’actualités, si je n’ai pas de FAQ et si, comme souvent, les indications de copyright, de conditions d’utilisation et de licence sont concentrés en bas de page, (quand elles sont présentes), ces trois raccourcis sont inutiles.

Le soucis, c’est que logiquement, je ne devrais pas les utiliser et c’est bien dommage si j’en ai besoin, par exemple pour lier les liens d’évitement à des sous-menus, ou à une TOC.

Touche 4 : Champ de saisie d’un formulaire de recherche

Le WCAG (Web Content Accessibility Guideline) rendant obligatoire la présence d’un formulaire de recherche, ce raccourcis clavier est évidemment utile et à pour lui d’être historiquement consacré à cet usage.

Touches 7 et 9 : contact email, livre d’or, feedback.

Il y à là aussi une grande ambiguité sans doute née d’une confusion issue d’un ouvrage célèbre : « dive into accessibility », écrit au départ pour des formats de blogs, mais largement repris comme base d'apprentissage, à une époque où la documentation sur l'accessibilité était assez rare, (cet ouvrage à été tellement cité et repris qu'il apparait encore en tête des résultats des moteurs de recherche, malgrès son grand-âge (2002) et son inadéquation aux formats habituels d'un site web).

L'interprétation de cet ouvrage, qui recommande d'affecter la touche 9 au "feedback" ou à une adresse email, à consacré l'usage de disposer sur toutes les pages d’un lien vers un « contact technique », généralement sous la dénomination « webmaster » pour signaler les problèmes d’utilisation.
Ce lien « technique » doit être direct c’est à dire employer un mailto afin de subvenir à une éventuelle défaillance d’un formulaire de contact ou la complexité d’une page de liste de contact.

C’est donc le 9 qui couvre "généralement" l’usage du lien email direct alors que dans cette liste cette notion, très importante, est reléguée sous le terme de « feedback » (une marque d’incompréhension du sujet ?) avec le « livre d’or » dont l’usage est totalement delaissé.

Telle que présentée sur la liste de l’ADAE, un néophyte va implémenter cette fonctionnalité sur la touche 7, même si cette touche amène finalement à un formulaire, toujours susceptible d’être inutilisable ou hors sujet, par exemple si il s'agit d'une demande de contact qui aurait peut de chance d'atterir finalement dans la boite du responsable technique.

Au delà du choix d'un chiffre, cette notion de "contact technique", qui ne peut pas être simplement fondue dans un "contact email" qui peut prendre bien des formes est absente de cette liste.
C'est pourtant un élément essentiel pour confronter l'accessibilité d'un site à ses utilisateur et en corriger rapidement les défauts les plus importants.

Le consensus minimum

Au final, le consensus, consacré en partie par l’usage, ne peut s’établir que sur 6 touches :

  • Touche 0 : liste des raccourcis
  • Touche 3 : carte du site
  • Touche 1 : page d’accueil
  • Touche 4 : formulaire de recherche
  • Touche 7 : contact email
  • Touche 9 : contact technique.

Avec, pour la touche 9 une très forte probabilité qu’elle soit de fait abandonnée au profit de la touche 7, dont l’efficacité sera amoindrie par tous ceux pour qui « contact email » est un « formulaire de contact », comme il est très commun de le voir, et non un lien direct vers la messagerie de l’utilisateur.

Une liste intelligente ?

Si, au lieu de se focaliser sur la valeur des touches et de croire devoir leur trouver un usage permanent, on s’intéresse aux fonctionnalités, la vision des raccourcis clavier change car il est possible dès lors de travailler à partir de fonctions communes généralement toujours présentes, soit qu’elles soient obligatoires ou simplement de bon sens :

  • Une page d’aide, qui peut-être une liste de raccourcis et/ou la carte du site (TOC).
  • Un lien permanent vers la page principale
  • Un moteur de recherche
  • Un lien « webmaster » généralement en bas de page avec les mentions administratives et techniques.

Cette liste de fonctionnalités a un avantage indéniable, elle n’est jamais ambiguë. D’autre part, point très important en terme d’accesibilité, elle est indépendante du contexte de la page, ces éléments si ils existent seront toujours présentés de la même manière.

Il est facile alors de rétablir une liste plus robuste et pérenne, une sorte de socle commun, issu en partie de l’usage et sur lequel peut venir se greffer d’autres raccourcis clavier propres à chaque site.

  • Touche 0 : Page d’aide (raccourcis et carte du site)
  • Touche 1 : Page d’accueil
  • Touche 4 : Formulaire de recherche
  • Touche 9 : Contact technique par lien direct (mailto)

Et de laisser aux auteurs la possibilité d’adapter les touches ainsi libérées (2, 3, 5, 6, 7, 8) à des fonctionnalités contextuelles, comme les liens d’évitements, une TOC ou tout autre usage pertinent et utile, en tout cas bien plus profitables pour les utilisateurs handicapés.

L’opportunité de dédier la touche 3 à la carte du site (mais ce qui implique que la page affichée par 0 devient ergonomiquement nulle voire contre-productive), et la touche 7 au « contact email » (mais en s’assurant que ne puisse être fait la confusion entre contact email et contact technique) restant à discuter et évaluer.

Peut-être serait-ce une manière de limiter les effets pervers de ce système mal pensé et mal implémenté, qualifié justement par Joe Clark dans un ouvrage célèbre de « délinquant juvénile de l’accessibilité ».

Pour en savoir plus

Trackbacks

Le mercredi 28 septembre 2005 à 15:22, de Mimi's blog :: #

ACCESSIBILITE : L'échec des accesskey

Voici une analyse très fine sur l'utilisation des accesskey et notamment les contraintes de l'implémentation de ces attributs pourtant nécessaires à l'accessibilité....

Les trackbacks pour ce billet sont fermés.

Evaluez ce billet

Commentaires

Le mardi 27 septembre 2005 à 14:50, par Maxwell :: site :: #

1000 mercis pour ces infos,
de trop nombreux sites parlent de ces accesskeys, et on s'y perd dans l'immensité des informations récoltées...




Le mardi 27 septembre 2005 à 15:05, par fred :: site :: #

"On n’insistera jamais assez sur cette règle d’or : n’utilisez jamais de lettres comme valeur d’accesskey.
Je sais, c’est surréaliste, mais c’est comme ça."

Le problème ici, c'est que c'est justement érigé comme une règle sans la moindre explication.

A l'inverse, le lien pourtant cité vers Openweb base beaucoup d'exemple sur les lettres, en tentant néanmoins une explication pour éviter cet usage et non l'interdire.

Ce qui me gène un peu, c'est de vouloir normaliser tout ça en ayant exactement les mêmes règles sur chaque site. L'article explique que ce n'est pas possible puisque ça ne s'adapte pas à toutes les structures.

Pourquoi éviter de se compliquer ?

L'accesskey d'un logiciel est clairement marqué par un soulignement de la lettre.
Pourquoi ne pas utiliser la première lettre de chaque menu, tout simplement.
Et si on a un doublon, une page (obligatoire) d'accessibilité doit pouvoir donner la règle d'accessibilité du site.
Au pire, ceux qui utilisent les accesskeys n'ont besoin que de pouvoir se positionner sur le premier lien du menu, le reste étant accessible par tabulation.

Et pour préserver l'accessibilité du logiciel (ici le navigateur), il suffit de garder au moins un seul lien accessible, le reste des menus du logiciel étant accessibles avec les flèches.

Bref, je trouve que c'est beaucoup de complication pour pas grand chose.
Rendre accessible n'équivaut pas à uniformiser tous les sites sur le même modèle.

Le mardi 27 septembre 2005 à 15:26, par Jean-pierre :: #

"Le problème ici, c'est que c'est justement érigé comme une règle sans la moindre explication."

L'explication est donnée : "utiliser une lettre comme valeur de raccourci clavier désactivera le menu équivalent du navigateur ou du lecteur d’écran"

Pour être plus clair : si tu implémentes l'accesskey "F", tu interdiras à ton utilisateur d'utiliser le raccourcis clavier "F" du navigateur pour enregistrer la page par exemple.

Avec une petite précision : il pourra toujours le faire avec la souris, mais justement si il utilise des raccourcis clavier c'est qu'il ne peut pas utiliser la souris.

Dans d'autres cas, comme un lecteur vocal où les raccourcis clavier du logiciel sont très utilisés, le résultat est catastrophique puisque utiliser des lettres comme accesskey rends simplement la navigation impossible !

Maintenant, si tu prends en compte tous les navigateurs des langues "européennes" et les lecteurs d'écrans, les 26 lettres de l'alphabet occidental sont prises.

Le W3C à abdondamment reconnue cette erreur majeure, des tentatives ont été menée, comme de tenter de faire une différence majuscule/minuscules mais cela demanderait une modification des langages et des logiciels irréalisable.

Dans les prochaines versions des langages, notamment XHTML 2.0, le groupe de travail espère résoudre le problème en modifiant la gestion des accesskey.

En attendant, le verdict est simple : pas de lettres, c'est inutilisable.

Par ailleurs, le billet alerte justement sur la "difficulté" et la "complexité" des listes officielles des raccourcis clavier disponibles en vue de promouvoir une simplification à l'essentiel, et de laisser libre les autres raccourcis pour que l'auteur puisses les adapter à ses propres pages.

Jean-pierre

Le mardi 27 septembre 2005 à 15:39, par jean-pierre :: #

"Ce qui me gène un peu, c'est de vouloir normaliser tout ça en ayant exactement les mêmes règles sur chaque site."

Imagines que sur chaque site que tu visites, on te demande de cliquer de manière différente pour jouer un lien, des fois un clic, des fois deux, des fois un clic gauche et deux clic droit...
Tu n'en aurais pas un peut ras la casquette ?

Jean-pierre

Le mardi 27 septembre 2005 à 15:42, par fred :: site :: #

"Pour être plus clair : si tu implémentes l'accesskey "F", tu interdiras à ton utilisateur d'utiliser le raccourcis clavier "F" du navigateur pour enregistrer la page par exemple."

Si justement tu gardes l'accesskey F pour le premier lien du menu navigateur, les flèches suffisent pour accéder aux autres menus.

Dans la pratique, pour ce qui est de la navigation, 1 seul accesskey pourrait suffire, celui du premier lien du menu du site, les autres étant accessibles par tabulations.
Ceux qui utilisent les raccourcis clavier quotidiennement savent aussi employer la touche Maj+Tab pour revenir en arrière.
Comme ils savent utiliser CTRL+Tab ou CTRL+Maj+Tab pour naviguer d'onglet en onglet.

Tout ça ressemble à définir une stratégie de guerre pour tuer un moustique.

Le mardi 27 septembre 2005 à 16:27, par Jean-pierre :: #

"Si justement tu gardes l'accesskey F pour le premier lien du menu navigateur, les flèches suffisent pour accéder aux autres menus."

Bon, tu à réglé le problème de F, que fais tu de A, qui est le seul moyen sous IE d'accéder au menu d'agrandissement des caractères ?
Que fais tu de B qui est sous mozilla, version anglaise, le raccourcis pour bookmarker la page.
Que fais tu de M, raccourcis d'accès à l'historique de firefox, version française.
Que fais tu du vocabulaire italien, espagnol, néerlandais ???
Pour le seul couple anglos/français je pourrais continuer la liste des lettres "interdites" 26 fois.

Cette recommandation "ne pas utiliser de lettres" n'est pas née de spéculations fumeuses, c'est un constat de fait, une réalité tenace et accessoirement la position de toutes les législations ou référentiels sur l'accessibilité.

Ce qui implique que les sites qui utilisent cette technique dangereuse, seront valides ET inutilisables, ce qui est le cas d'un site référencé sur le lien de ta signature.

Par ailleurs du point de vue purement théorique, imaginons qu'il existe ne serait-ce qu'une lettre "libre" (en réalité il y en à vraiement une.. :) ), comment garantir qu'une nouvelle version ou un nouveau logiciel ne l'utilise pas ?

Le problème ne tiens pas à la bibliothèque de lettre utilisée mais à la méthode : les combinaisons de touches sont les mêmes et rien ne peut permettre d'en contextualiser le traitement logiciel, conclusion on est dans un cas typique de collision par définition ingérable sans le rajout d'une couche applicative ou la modification des methodes et logiciels incriminés.

Certains états, comme le gouvernement canadien ont poussé le raisonnement encore plus loin en interdisant purement et simplement les accesskey sur leurs pages, ce qui est une position raisonnable si les logiciels offraient nativement des alternatives crédibles.

"Au pire, ceux qui utilisent les accesskeys n'ont besoin que de pouvoir se positionner sur le premier lien du menu, le reste étant accessible par tabulation."

Mais pourquoi vouloir faire "au pire" quelque chose que l'on peut faire "au mieux" ???

Je veux bien croire que l'idée des accesskey alphabétiques soulignés est séduisante, ça à un coté "logiciel" très valorisant, on à tous fait ça au début.

Mais outre le fait que de vouloir transposer des IHM logicielles au web est une très mauvaise idée actuellement (les technologies ne le permettent pas dans le cas d'un site web), tu devrais faire au moins deux choses : accorder un minimum de confiance aux centaines d'experts qui se sont arrachés les cheveux face à ce problème, et surtout, ouvrir un site "équipé" de raccourcis clavier alphabétique avec un lecteur d'écran, cela devrait suffire à te convaincre.

Sinon, c'est essentiellement pour tes clients et ceux qui n'en ont pas besoin que cela va servir.
Pour les autres, le verdict sera simple : je ne visites pas car JE NE PEUX PAS.

Jean-pierre

Le mardi 27 septembre 2005 à 17:39, par fred :: site :: #

Attention , je partage aussi globalement cette analyse sur les accesskeys (plus au niveau de la conclusion), avec le dogmatisme en moins.
Mais je dirais que c'est vraiment "trop" intellectualiser le machin pour l'instant.
Parce qu'aussi, si on imagine une normalisation parfaite pour les accesskeys, ça ne signifira pas forcément qu'un site soit ergonomiquement pratiquable pour autant.

Certains outils de publication en ligne pourtant reconnus ne sont pas si accessibles que ça, sans parler d'accesskey, l'encodage des caractères affichant parfois des résultats surprenants.
-----------------
"Bon, tu à réglé le problème de F, que fais tu de A, qui est le seul moyen sous IE d'accéder au menu d'agrandissement des caractères ?"

Le seul moyen ? Non, ATL+A puis accès à la taille du texte.
-----------------
"Que fais tu de B qui est sous mozilla, version anglaise, le raccourcis pour bookmarker la page."

Non, c'est CTRL+D pour bookmarker une page.
CTRL+B, c'est pour ouvrir les marques pages.
Pas de conflit avec ALT donc.
------------------
"Que fais tu de M, raccourcis d'accès à l'historique de firefox, version française."

Non, c'est CTRL+H pour l'historique, par ailleurs accessible depuis le menu avec ALT+H
--------------------
"Mais pourquoi vouloir faire "au pire" quelque chose que l'on peut faire "au mieux" ???"

C'est pas au pire qu'il faut comprendre, c'est au plus simple. Si tu sais te positionner sur le premier menu, le reste est accessible facilement.
--------------------
"tu devrais faire au moins deux choses : accorder un minimum de confiance aux centaines d'experts qui se sont arrachés les cheveux face à ce problème"

Un certain francophone outre atlantique parle plutôt de "technologues" que d'experts.
Ils apportent parfois plus de confusion que de solutions.
D'autres ont mis en évidence avec sincérité le fait qu'un site doit savoir choisir ses cibles.
Ca signifie parfois une exclusion.
--------------------
S'il le fallait, ça montre la confusion des accesskeys en effet.
Pourquoi, comme tu le dis, définir une règle limitée à 9 ou 10 accesskeys alors ?
Et les utilisateurs de portails, ils peuvent se brosser ?
Je trouve enfin qu'on se focalise tellement sur l'accessibité des personnes handicapées avant de penser à une accessibilité fiable pour des personnes non handicapées.
Non pas que j'exclue ou méprise les premières, mais l'accesskey est pour moi encore synonyme "d'accessoire".
Par accessibilité, on entend accessibilité à un contenu.
Et si je veux par exemple trier que les articles d'Olivier sur ce blog en imaginant qu'il en ait publié 1000 ?
Et si je veux n'afficher que les commentaires de Dupont, parce que je sais que Dupont a toujours des commentaires pertinents ?
Rien ne me le propose encore.

Et écrire en lettres blanches sur fond blanc, c'est trés accessible ça ?
-> Aller au contenu Aller au menu Aller à la recherche

Si je tape les lettres 'roi' dans le moteur de recherche parce que je me souviens d'un article interessant y faisant référence, tu as vu le nombre de résultats ? Et celui que je cherche se retrouve noyé parmi ceux là, inaccessible...
Donc un moteur de recherche pertinent est une règle plus importante que des accesskeys pour accéder au contenu.
Rechercher le mot exact, rechercher dans le titre, dans une rubrique particulière, dans des commentaires, etc.
;)

Le mardi 27 septembre 2005 à 18:48, par gizmo :: #

Ce que je vais dire aurais tres bien pu tomber sur un autre billet du meme style dans ce blog ou dans un autre, il est juste tombe ici, pas de chance.

Quand je lis ces articles qui tentent d'utiliser des accesskey, qui parlent des combinaisons de touches pour y parvenir, des problemes de conflits avec les raccourcis exsitants, je me demande a chaque fois si les personnes qui debattent de ce sujet savent de quoi elles parlent.

En effet, de quoi parle-t-on? De raccourcis claviers, certes, mais dans quel but? Faciliter l'acces a internet aux handicapes moteurs! Et la, j'ai comme l'impression que l'on prend comme axiome qu'un handicape moteur est forcement affuble d'une tare mentale, en sus.

Je m'explique. On prend souvent comme exemple, pour illustrer le probleme des accesskeys, la manipulation qu'il faut faire dans IE : CTRL + MAJ + Accesskey, et de ce lamenter sur les personnes qui n'ont plus qu'un doigt a chaque main. Depuis Windows 95SE, tous les Windows disposent du mechanisme de remanance des touches, qui permet de taper n'importe quelle combinaison de touche avec un doigt. Et tous les handicapes moteurs lourds que je connais utilisent ce mecanisme depuis des lustres (sauf quand il s'agit de dispositif de pointage specialise...). Ce mecanisme existe aussi sous Mac et sous les environnements graphiques Linux majeurs.

Autre point, on parle ensuite des techniques d'evitement pour passer le menu, acceder au contenu, par oppositon a une navigation fastidieuse a coup de tabulation ou une navigation auditive.
Sans mauvais jeu de mot, avez-vous jamais regarder un aveugle ou un mal-voyant se servir d'un navigateur vocal? C'est impressionnant! Tout d'abord, il met le pitch a pres de 200%, ce qui rend le texte tout a fait incomprehensible pour nous autres (et tres agacent d'un point de vue auditif), et il aura atteind le contenu bien plus vite avec un balisage propre et epure qu'avec un lien d'evitement qu'il va devoir reperer puis retenir d'un site a l'autre. Et pour les autres qui utilisent leurs yeux, soit ils sont capables pour la plupart de se servir d'un dispositif de pointage, plus simple et rapide qu'un clavier, soit peuvent utiliser des outils de navigation au clavier plus performants que la tabulation (je pense ici a la navigation SHIFT + fleche de direction d'Opera par exemple).

Enfin, ces acceskey semblent etre pour beucoup comme une tentative d'accessibilite ratee. Et pour cause, elle l'est! Pour avoir pris contact avec un centre tenu par des handicapes pour la formation d'autres handicapes a l'usage d'internet, je peux vous dire que ce n'est pas le support des accesskey qu'ils attendent. A croire que les principaux interresses n'ont meme pas ete consultes!
Par contre, ce que certains m'ont fait remarquer, comme perte de l'internet moderne, c'est la disparition du support de la balise "link" dans la plupart des navigateurs. Or justement, celles-ci disposent deja des principales rubriques que l'on essaie de caser dans ces miserables accesskeys! On avait la un merveilleux moyen de rendre les differentes parties d'un sites accessible (en terme de lien), avec des raccourcis qui n'auraient interferer avec rien d'autre parce que geres en natif par le navigateur. Et on a loupe le coche! Mosaic le proposait, Netscape le proposait, et puis pffuit, disparu de la plupart des navigateurs, relegue ou rang "d'outil d'aide a l'indexation par les moteurs de recherche" (remarque aberrante issue d'un autre site).

Bref, tout ca pour dire que theoriser, c'est bien, mais il ne faut pas en abuser. Si vous voulez vraiment faire du web accessible, adressez-vous a vos clients! Il existe tout un tas d'organismes qui disposent d'informations quant aux besoins des handicapes. La ligue braille est sans doute la plus connue pour les aveugles/mal-voyant, mais pour peu que vous habitez dans ou a proximite d'une ville, vous trouverez facilement des gens qui seront ravis qu'on leur pose enfin les questions, a eux.


Desole, mais cela devait sortir.

Le mardi 27 septembre 2005 à 22:10, par jean-pierre :: #

"je me demande a chaque fois si les personnes qui debattent de ce sujet savent de quoi elles parlent."

Croyez bien que je ne me serais pas permis de parler des accesskey comme d'aucun autre sujet si je n'avais pas le minimum de connaissance requises pour le faire et d'experience pour en avoir tiré les même conclusions que la totalité des experts, la totalité des législations et des référentiels qui en sont issus, la totalité des membres du WAI et des dizaines d'utilisateurs-testeurs handicapés avec lesquels j'ai travaillé ces quatres dernières années.

Mais ce n'est pas le sujet du débat.

"En effet, de quoi parle-t-on? De raccourcis claviers, certes, mais dans quel but? Faciliter l'acces a internet aux handicapes moteurs!"

Pas tout à fait, les raccourcis claviers ont cette particularité d'être utilisés par l'ensemble des handicaps, moteurs, visuels, neurologiques, cognitives, cela concerne tout le monde, souvent au delà d'ailleurs du handicap proprement dit, puisque vous-même les utilisez.

"Depuis Windows 95SE, tous les Windows disposent du mechanisme de remanance des touches, qui permet de taper n'importe quelle combinaison de touche avec un doigt."

Absolument, en revanche les implications sont physiquements non négligeable.
Dans des situation d'usage intensif, comme une activité professionnelle, on constate exactement le même problème que les syndromes relevés chez les utilisateurs intensifs de souris ou de joystick due à la répétition mécanique d'un même geste dans une même situation.
Au point que l'on constate chez eux une tendance naturelle à préférer utiliser, quand faire se peut, la souris numérique, même si cela implique une chute importante des performances et de l'efficacité.

Ceci étant votre remarque n'est pas infondée, j'aurais du prendre soin de préciser le système des touches rémanentes.

Je n'ai pas trouvé ça utile pour démontrer cette idée simple que trois touches c'est plus con qu'une seule.

Le reste de votre commentaire, qu'il me serait trop long de citer ici est beaucoup plus dérangeant parce que vous faites acroire des idées fausses et dangereuses.

Que vous ayez rencontré un expert de la navigation vocale est une chose, mais généraliser à tous les utilisateurs est faux, en contradiction avec toutes les études sérieuses menées depuis 1996 pour la plus ancienne qu'il m'ai été donnée de lire.

Vous présupposez une maitrise des outils adaptés comme des lecteurs d'écrans.
Les dizaines d'études menées avec les utilisateurs eux-même montrent toute la difficulté d'apprentissage et de maitrise, non pas de l'outil lui-même, mais de son interaction avec son environnement, en loccurence une page web.
A moins que vous ne considériez que ces études ne sont, comme ce billet, que l'éculubration de "théoricien" déconnectés.

Par ailleurs, les publics handicapés sont comme les autres, il utilisent préférentiellement les configurations par défaut de leur matériel (pour être précis, plus de la moitié d'entre eux), comme ma grand-mère qui notent les urls des sites qu'elle veut garder dans un carnet téléphonique car elle ne connait pas le menu bookmark.

"je peux vous dire que ce n'est pas le support des accesskey qu'ils attendent. A croire que les principaux interresses n'ont meme pas ete consultes!"

L'idée que les recommandations de l'accessibilité ont été rédigées par d'obscurs codeurs du W3C, deconnectés de la réalité de la vraie vie et surtout dans le dos des principaux intéréssés est assez répandue.
Cela fait partie des légendes urbaines à ranger dans la catégorie "il y à des crocodiles dans les égouts de paris".

Une simple visite sur les sites du W3C vous aurait appris que les WCAG ont été rédigés avec des utilisateurs handicapés et après un long travail de test et de validation.

Ceci dit, toutes remarques est bonne à prendre, je serais très intéréssé de rentrer en contact avec le centre dont vous parler.
Vous pouvez me transmetre leurs coordonnées à l'adresse email de signature de ce billet.

Je suis en revanche assez d'accord sur les remarques concenant la balise link rel et la notion de barre de navigation contextuelle.

Jean-pierre


Le mardi 27 septembre 2005 à 23:03, par jean pierre :: #

@fred

Je ne voudrais pas plus avant, polluer les commentaires de ce billet sur des sujets qui n'ont vraiment rien à voir.

Aussi je vais faire des réponses courtes même si plus brutales par nature.

En revanche, vous avez à disposition le forum si vous voulez poursuivre une discussion plus générale.

"Parce qu'aussi, si on imagine une normalisation parfaite pour les accesskeys, ça ne signifira pas forcément qu'un site soit ergonomiquement pratiquable pour autant."

Parfaitement d'accord et alors ?, en quoi le fait qu'un système ne réponde pas à la résolution d'une problèmatique plus générale autoriserait-il de faire n'importe quoi ?

Au sujet des raccourcis que je cite et sur lesquels tu opposes les raccourcis fonctionnels (CTRL+) :
Tu confonds deux types de raccourcis, la démarche habituel pour bookmarquer une page n'est pas CTRL+touche (raccourcis fonctionnel), mais ALT+Touche+souris (ou flêche).
En interférant avec ce mécanisme tu fait perdre le contrôle de l'interface qui est alors perçus comme "ne fonctionnant plus" à des utilisateurs qui ont déjà des difficultés à l'utiliser en situation normale.

"C'est pas au pire qu'il faut comprendre, c'est au plus simple. Si tu sais te positionner sur le premier menu, le reste est accessible facilement."

Je suis désolé de dire que c'est faux, et je te réitère ma suggestion de faire ta propre expérience.
"D'autres ont mis en évidence avec sincérité le fait qu'un site doit savoir choisir ses cibles.
Ca signifie parfois une exclusion."

La sincérité n'empêche nullement de dire de grosses bétises.

"Pourquoi, comme tu le dis, définir une règle limitée à 9 ou 10 accesskeys alors ?
Et les utilisateurs de portails, ils peuvent se brosser ?"

Concernant l'usage d'un dispositif réservé à la prise en charge d'un handicap et si pour leur "simple plaisir" cela gêne en quoi que ce soit l'objectif de prise en charge, alors oui.

Traduit en langage policé : les accesskey ne sont pas une fonction utilisateur, c'est un dispositif adapté réservé, d'autant plus qu'il est déjà limité.

"Je trouve enfin qu'on se focalise tellement sur l'accessibité des personnes handicapées avant de penser à une accessibilité fiable pour des personnes non handicapées."

Que veux tu que je te dise ?, si penser à l'accessibilité des personnes non handicapées c'est utiliser des accesskey alphabétiques ou des menus images sans alternatives ben je te dirais ce que tu dis aux handicapés : allez voir ailleurs.
Je le dis sans animosité mais que puis je dire d'autre ?
Ha si, si tu à besoin, l'excellent forum d' alsa saura te donner d'excellent conseils pour produire des sites accessibles au plus grand nombre dans le respect de tous ... :)

Pour le reste, manifestement hors sujet, je serais heureux et disponible pour en discuter sur le forum, mais là je ne vois pas le rapport.

Jean-pierre


Le mercredi 28 septembre 2005 à 07:17, par Laurent Denis :: site :: #

Voilà de suprenants procès pour un billet parfaitement fondé sur ses constats de base (ne pas utiliser les accesskeys littéraux).

Je ferai simplement une remarque pour répondre aux divers procès déplacés sur le rôle de "l'expert", de l'utilisateur (Fred) et de l'handicapé (tel que cité par Gizmo) : contrairement à une affirmation totalement gratuite, utilisateurs et utilisateurs handicapés sont au coeur du processus d'élaboration des règles d'accessibilité et d'ergonomie. Qu'il s'agisse des référentiels d'accessibilité du W3C, d'AccessiWeb, ou de toutes les pratiques recommandées pour leur application par les experts. Mais là où intervient l'expert, comme le montre bien ce billet, c'est dans la prise en compte rationnelle de demandes d'accessibilité et d'ergonomie individuelles et rapidement divergentes. Autrement-dit, pour citer une règle que nous rappelons souvent aux contributeurs Opquast :

"Il y a un fossé considérable entre la pertinence d'une bonne pratique sur un site individuel et sa mise en application sur l'ensemble des services en ligne. La grande difficulté réside dans le fait d'anticiper les cas limites, les difficultés de mise en application. Ne soyez pas étonnés si certains éléments qui vous semblent évidents pour votre site sont contestés parce qu'ils ne seraient pas toujours valables."
( www.opquast.com/dotclear/... )

Le billet de Jean-Pierre s'inscrit exactement dans cette démarche, qui repose sur l'expertise et en constitue en fait la caractéristique la plus utile : extraire des multiples contraintes individuelles un ensemble de recommandations (ou une norme) exploitables dans un Web pour tous.

Maintenant, il y a beaucoup plus intéressant que cela dans ce billet, à commencer par son approche fonctionnelle des accesskeys, qui révèle très bien les faiblesses de la liste consensuelle franco-britannique.

Sur le problème du plan de site : "Touches 0, 6, 3 : Liste des touches clavier utilisées, aide à la navigation dans le site, carte du site."

Réunir ces trois outils ? Les deux premiers, oui, évidement. Mais le plan de site ? Les formulations de la 3e partie du billet révèlent le problème d'application de la recommandation : est-ce:
- aide **ou** plan de site ?
- plan de site **et** aide éventuelle ?

Dans le premier cas, la recommandation pourra être interprétée comme rendant le plan de site optionnel, ce qui serait dramatique étant la pertinence de cet outil.

Dans le second cas, la réunion de l'aide à la navigation et du plan de site a quelque-chose de déroutant et de non intuitif, sur lequel j'avoue avoir du mal à mettre le doigt.

On le voit mieux si on prend en compte les sites permettant une personnalisation de l'interface via un compte personnel (Type wikipedia, par exemple) : l'aide alors nettement plus développée va logiquement commencer par les accesskeys. Et n'a plus rien à voir avec le plan du site. Il me semble que cette pratique "accesskeys+plan" sera inapplicable dans différents cas. Et qu'il vaut mieux conserver deux parties a priori différentes de l'interface, en laissant la possibilité de les réunir lorsque c'est approprié, de les gérer autrement dans d'autres cas.

Ce qui, dans la proposition finale, conduirait à conserver cette fameuse touche 3.

Ah... Que ce billet est stimulant ! ;)

Le mercredi 28 septembre 2005 à 07:34, par Laurent Denis :: site :: #

@Fred :

> "A l'inverse, le lien pourtant cité vers Openweb base beaucoup d'exemple sur les lettres, en tentant néanmoins une explication pour éviter cet usage et non l'interdire."

Oui, les exemples de la première partie de l'article sont volontairement basés sur les acceskeys littéraux, qui sont tout simplement ce que tout un chacun s'attend à trouver.

Mais non, la suite de l'article ne tente pas une explication : il la donne clairement.

Et non encore, il ne "tente pas d'éviter" l'utilisation des accesskeys littéraux : il les exclue explicitement, y compris la touche "s".

Merci de lire attentivement mes articles avant d'en parler de manière totalement erronée.

Le mercredi 28 septembre 2005 à 09:36, par jean-pierre :: #

"Dans le premier cas, la recommandation pourra être interprétée comme rendant le plan de site optionnel, ce qui serait dramatique étant la pertinence de cet outil."
...
"Et qu'il vaut mieux conserver deux parties a priori différentes de l'interface, en laissant la possibilité de les réunir lorsque c'est approprié, de les gérer autrement dans d'autres cas."

Je suis absolument d'accord avec ça.
Ce qui est intéressant étant de laisser la possibilité de les réunir si c'est pertinent.

En fait cette première idée de créer un item général "d'aide" était une réaction à la tendance naturelle des néophytes de prendre cette liste comme un élement normatif et de se contraindre à la respecter même au prix d'évidente lourdeur ergonomique.

J'ai eut par exemple l'occasion d'intervenir sur un site ou la carte du site comportait 5 url et où la liste des raccourcis claviers se limitait à trois items.
A ma suggestion d'assembler ces deux pages, le webmaster m'à opposé cette liste qu'il analysait comme une "norme", ce qui va être souvent le cas pour des néophytes, peut habitués à l'art subtil de l'interprétation des recommandations du WCAG ou des référentiels.
Pourtant, le référentiel en question, stipule bien que ce n'est qu'une liste "conseillé", ce qui sous-entends qu'est laissé à l'auteur la décision de sa pertinence in-situ, ce qui est souvent le cas avec le WCAG.

D'où ma première réaction qui était de me dire, faisont l'inverse, limitons la "norme" au strict essentiel et laissons les auteurs prendre d'eux-même l'initiative.

En seconde lecture, je te rejoins, sur un élément aussi important qua la carte du site ce n'est probablement pas une bonne idée.

L'autre avantage que j'y vois et auquel je n'avais absolument pas pensé c'est que la carte du site est un des dispositifs les mieux implémentés par les webmasters pour une tout autre raison : il parait que c'est essentiel pour le référencement...:)
Et je connais bien les réactions quelquefois hystériques dés que l'on touche aux offrandes sacrificielles à sa majesté Google.


Jean-pierre

Le mercredi 28 septembre 2005 à 10:49, par Mathey Thomas :: site :: #

Hébien cela rejoint ce que je peux expérimenter sur le terrain au jour le jour, un grand fouilli...

Le mercredi 28 septembre 2005 à 11:47, par Mimi :: #

En tout cas, merci Jean-Pierre. Très instructif ;)

Le mercredi 28 septembre 2005 à 17:54, par tight :: #

Et pourquoi pas mixer lettres et chiffres ? Du style <.. accesskey="F4" ..> :D

Le mercredi 28 septembre 2005 à 21:42, par Stephan :: #

> Et pourquoi pas mixer lettres et chiffres ? Du style <.. accesskey="F4" ..> :D

C'est une blague hein ? C'est ça ?

Le jeudi 29 septembre 2005 à 06:20, par Frank :: site :: #

Bonjour Philippe,

Tu cites le WCAG pour l'exemple de la touche 4 (recherche)

"Le WCAG (Web Content Accessibility Guideline) rendant obligatoire la présence d’un formulaire de recherche, ce raccourcis clavier est évidemment utile et à pour lui d’être historiquement consacré à cet usage."

Par contre Opquast ne le préconise qu'as partir de 15 pages.

Quelle attitude adopter?

En ce qui concerne le fait d'éviter les formulaires mail et les solutions de pages les regroupants.

Au début de web-pour-tous on m'as fait la remarque (malheureusement je ne sais plus qui) que le fait d'ouvrir directement sur le logiciel mail du client était génant car cela ouvrait une nouvelle fenetre qui n'était pas specialement désirée.

Donc j'aurais un peu la même question quelle attitude adopter dans le cas d'une reflexion comme celle-ci.

Est ce que finalement la solution de la page n'est pas la moins mauvaise en terme d'accessibilité?

Cordialement Frank

Le jeudi 29 septembre 2005 à 06:22, par Frank :: #

Vous avez rectifié de vous même bien sur il s'agit de Jean-Pierre et pas de Philippe.

Le jeudi 29 septembre 2005 à 09:03, par FlorentG :: #

Ce problème d'AccessKeys est surtout un problème de Navigateurs, encore une fois... Quelle idée, par exemple sous FireFox, d'avoir utilisé la combinaison alt + xx, avec tous les conflits que ça génère ?

Le jeudi 29 septembre 2005 à 09:06, par Jean-pierre :: #

Bonjour franck

" Opquast - BP N°60 : Si le site comporte plus de 15 pages de contenu textuel, un moteur de recherche interne est accessible depuis toutes les pages."

En fait la notion de page est asez ambigüe sur le web, il faudrait plutôt dire quelque chose comme "si le volume de texte et de données est important" mais ce qui n'aiderait pas plus le néophyte à comprendre.

Du coup l'expression "15 pages de contenu textuel" est très opportune, pas sur le nombre de pages mais sur le volume que ça représente.

Mais peut-être que Laurent pourrait préciser ce point ?

"Au début de web-pour-tous on m'as fait la remarque (malheureusement je ne sais plus qui) que le fait d'ouvrir directement sur le logiciel mail du client était génant car cela ouvrait une nouvelle fenetre qui n'était pas specialement désirée."

Il est vrai que le fait d'ouvrir la messagerie de l'utilisateur fait intyervenir une fenêtre.

En même temps, comment l'utilisateur qui voudrait, au hasard, signaler que les formulaires sont inutilisables, le ferait-il si il lui faut le faire par formulaire ?

La notion qui est dérrière cette fonctionnalité est le "contact technique", libre à l'auteur de faire par ailleurs un formulaire de contact classique.

Jean-pierre

Le jeudi 29 septembre 2005 à 09:11, par Jean-pierre :: #

"Ce problème d'AccessKeys est surtout un problème de Navigateurs, encore une fois... "

Non.

La combinaison des raccourcis claviers est une propriété du système d'exploitation, pas spécifique à un logiciel particulier.

Jean-pierre

Le jeudi 29 septembre 2005 à 09:30, par Jean-pierre :: #

Je voudrais préciser ma remarque précédente quipourrait être mal comprise.

L'idée derrière les accesskey est de mettre à disposition une méthode commune et universelle pour produire des raccourcis claviers.

Du coup on s'appuie sur le plus petit dénominateur commun qui est le système d'exploitation.

Si on laissait la liberté à chaque logiciel de définir sa propre combinaison de raccourcis pour les accesskey on ne ferais que multiplier les sources de problèmes.

Ce qui explique pourquoi cette combinaison est standardisée.

Jean-pierre

Le jeudi 29 septembre 2005 à 10:08, par Laurent Denis :: site :: #

Bonjour,

A propos de la BP Opquast sur le moteur de recherche interne :

L'une des contraintes de base d'un référentiel comme celui des bonnes pratiques qualité Opquast est la vérificabilité. Un utilisateur du référentiel, qu'il gère lui-même la qualification de son site ou qu'il fasse appel à mon-opquast, a besoin d'un critère de décision précis. Cela exclut les formulations de BP du type "si le volume de texte et de données est important", et conduit à introduire du quantitatif qu'il est parfois difficile de fonder sur des données objectives.

D'où les 15 pages de contenu. Malgré l'ambiguïté de la notion de page et l'arbitraire du nombre, ce libellé permet une prise de décision efficace.

Cela dit, il faut aussi raisonner en termes graduels : cette BP de niveau 2 pourrait être élargie au niveau 3 par une autre BP ( A vous de proposer dans l'Atelier Opquast ;) ). D'ailleurs, une des propositions de nouvelle BP en cours de réflexion y invite clairement : "Le moteur de recherche indexe tous les contenus disponibles sur le site, que ce soit à l'affichage ou en téléchargement." ( www.opquast.org/atelier/i... )

Le jeudi 29 septembre 2005 à 11:47, par FlorentG :: #

"La combinaison des raccourcis claviers est une propriété du système d'exploitation, pas spécifique à un logiciel particulier."

Si, le logiciel peut décider quelle combinaison de touche il associe les accesskeys... On le voit bien sous Opéra où il faut d'abord faire Shift + Esc, puis taper l'accesskey. Il n'y a alors aucun conflit...

Le jeudi 29 septembre 2005 à 11:52, par FlorentG :: #

"Si on laissait la liberté à chaque logiciel de définir sa propre combinaison de raccourcis pour les accesskey on ne ferais que multiplier les sources de problèmes."

Oui :)

L'important alors est de trouver une combinaison qui n'interfère pas avec le système d'exploitation :( Sinon on a trop de conflits possibles...

Le jeudi 29 septembre 2005 à 13:04, par Jean-pierre :: #

Bonjour Florent

"On le voit bien sous Opéra où il faut d'abord faire Shift + Esc, puis taper l'accesskey. Il n'y a alors aucun conflit..."


Oui, mais... non
Par exemple MAJ+ESC+1 envoi sur la messagerie d'opéra, problème délicat pour tous les accesskey de page d'accueil.
Parrallèlement Opera offre son propre raccourcis pour aller sur la page d'accueil d'un site CTRL+MAJ+ESPACE.

Mais peut-être que ce raccourcis, ou cette combinaison MAJ+ESC est ou sera utilisée par un programme tiers, comme un lecteur d'écran, qui à la différence d'un navigateur vocal, utilise le navigateur comme couche d'accès au contenu, dont il désactive certaines fonctions utilisateurs au profit des siennes, ce qui est normal.

Ca signifie quoi ?
Ca signifie deux choses importantes pour les agents utilisateurs :
- L'idée des accesskey fondées sur un dénominateur commun aux couches logicielles n'à pas de sens, c'est une faillite.
- Il faut faire "remonter" cette charge au niveau logiciel le plus haut, c'est à dire le navigateur et tout autre dispositif qui utiliserait le navigateur comme couche applicative.

L'autre enseignement, ou disons l'autre reflexion est plus pertubante, notamment pour les auteurs :
-L'idée de laisser aux auteurs le soin de déterminer les raccourcis clavier est TRES discutable, parce qu'elle ne peut se fonder sur aucun consensus normatif.

Concrètement le groupe de travail XHTML 2, discute de l'opportunité de supprimer la notion de raccourcis clavier "auteur", au profit de la notion de "point d'accès".
Il n'y aurait pas de différence en terme d'implémentation pour les auteurs, seul l'attribut change : "access=quelquechose", mais ce serait à l'agent utilisateur de proposer une méthode unique et non-conflictuelle de raccourcis clavier pour accèder à ces "point d'accès".
Chaque navigateur aurait donc la possibilité d'utiliser une combinaison de touche "propriétaire" pour accéder à des "points d'accès" du document dont les cibles seraient communes et déterminés par une norme.

Autrement dit c'est prendre le meilleur de la méthode "le raccourcis clavier d'accès direct" appliqué au concept de barre de navigation contextuelle du mécanisme des link rel.

Les conséquences, telle que décrites par le working draft XHTML 2 :
- Les auteurs n'auraient plus à s'inquiéter des conflits d'interface, puisque ce ne serait plus leur job de définir les raccourcis clavier.
Ce qui implique qu'ils acceptent d'en perdre le contrôle, ce qui va en faire hurler certains.
- Les auteurs devraient se concentrer essentiellement sur l'implémentation logique et pertinente de "point d'accès" dans les documents.
- Les utilisateurs, devraient avoir le contrôle de cette fonctionnalité (définir les raccourcis claviers), pour corriger (ou adapter) l'interface à leur besoin et aux éventuels conflits.

Cette approche très différente implique néanmoins que soit établie une norme donc une liste de ces fameux points d'accès, à laquelle les auteurs et les agents utilisateurs devraient se conformer.

Il est encore trop tôt pour dire ce qui adviendra de cette idée, qui rejoins le commentaire de gizmo concernant les link rel et la barre de navigation contextuelle, puisqu'au final il ne s'agit ni plus ni moins que de sa transposition.

L'avantage de cette méthode étant d'éviter de rajouter une couche, assez difficile à gérer dans les faits en implémentant cette fonctionnalité au niveau du document lui-même.

En tout état de cause, on se dirige vers un abandon (mais quand ??? ) de cette notion de raccourcis clavier "auteur", et je penses vraiment que c'est une bonne chose.

En attendant, il faut "faire avec", "faire au mieux" et patienter (enfin ce sont surtout les utilisateurs qui patientent et c'est bien le problème).

Sous toute réserve que j'ai bien illustrée cette idée, dont certaines interprétations divergent, les champollion des spécifications sauront j'espère me corriger.

Enfin, pour être complet, d'autres avis militent pour l'abandon pur et simple de ce genre de système au profit d'un traitement purement applicatif de l'agent utilisateur, ce qui mérite d'être également discuté, notamment dans le cadre d'une généralisation des concepts associés au web sémantique, mais bon les conditions à réunir paraissent encore lointaines.
Jean-pierre

Le jeudi 29 septembre 2005 à 19:57, par Frank :: site :: #

Bonjour,

Alors je vais peut être dire une bêtise (je suis plus à une près ;-) ),mais Eric du forum Alsacréations avait demandé une fois si l'on ne pouvais pas eventuellement placer les liens d'évitements justement dans le header par l'intermédaire de balises link.

Par contre le problème d'IE pouvais se poser car il ne les prenaient pas en compte.

C'est un petit peu ce que tu explique à la fin de ta dernière réponse?

Le vendredi 30 septembre 2005 à 00:56, par jean-pierre :: #

Comme l'explique gizmo dans son commentaire, le concept très intelligent mais difficile à maintenir dan les faits des liens link rel associé à une barre de navigation contextuelle à été abandonné, notamment par firefox, pour des raisons que je ne connais pas...

De toute manière la fait que IE n'implémente pas ce système le rends difficilement utilisable.

Les link rel sur le contenu sont beaucoup plus que des liens d'évitement puisqu'ils offrent un système complet à deux niveaux, d'une part un système de navigation fondé sur des attributs normatifs (suivant, précédent, home...), d'autre part la posibilité pour l'auteur de décrire la structure de la page (rubrique, sous-rubriques...) et une liste de liens extérieurs, généralement utilisée pour créer des relations thématiques avec le contenu de la page.

Le soucis, c'est que tout doit être implémenté manuellement ou de manière dynamique, mais c'est assez difficile à maintenir, surtout pour un néophyte.

Dans le projet XHTML 2.0, c'est un système analogue, bien que plus réduit mais qui ne demande qu'une maintenance réduite.
En effet si un "point d'accès" est supprimé du corps de la page il n'est plus référencé par le navigateur, alors qu'avec les link rel c'est à l'auteur de prendre soin de mettre à jour la liste.

Jean-pierre

Le vendredi 30 septembre 2005 à 15:04, par Spir :: site :: #

Mh c'est bien ca! J'en ai mis sur le dernier site que j'ai fait. Mais je pense que très peu de monde les utilise.

Le vendredi 30 septembre 2005 à 15:26, par Chris :: site :: #

Merci Jean Pierre pour ces explications.

Le samedi 1 octobre 2005 à 10:04, par Laurent Denis :: site :: #

@Jean-Pierre :

> Comme l'explique gizmo dans son commentaire, le concept très intelligent mais difficile à maintenir dan les faits des liens link rel associé à une barre de navigation contextuelle à été abandonné, notamment par firefox, pour des raisons que je ne connais pas...

Cette barre de navigation n'avait plus aucune utilité dans la démarche de séduction des utilisateurs d'IE entreprise par la fondation Mozilla avec le navigateur Firefox et son UI supposé amélioré :
- IE n'implémentant pas cette fonction, elle était inutile dans Firefox puisque les utilisateurs ne piuvaient être déçus de ne pas l'y trouver.
- Très peu de sites exploitant les "links rel" en dehors des flux RSS exploités indépendamment de cette barre, maintenir ce support ne donnait à Firefox aucun avantage concurrentiel sur IE.

le succès de FF est une bonne chose dans l'absolu pour la restauration d'un marché de navigateurs diversifié. Mais en payant le prix parfois élevé d'un nivellement de celui-ci par le bas, compte-tenu de la politique que devait adopter la fondation Mozilla.

Le samedi 1 octobre 2005 à 10:12, par Laurent Denis :: #

Désolé, commentaire parti incomplet. Je complète :

Avec l'absence de support par défaut des link rel hors RSS, Firefox a encore un peu plus enfoncé dans l'oubli l'une des très rares applications sémantiques riches du HTML accessible à monsieur tout le monde, auteur comme utilisateur. Le potentiel d'accessibilité, d'ergonomie et de qualité de cet outil est considérable, mais remarquablement ignoré. Il est vrai qu'une navigation reposant sur les link rel ne ferait l'affaire ni des parasites googliens, ni des designer.

C'était mon quart d'heure mode "agacé par les faux-semblants des uns et des autres" ;)

Ajouter un commentaire

Les commentaires pour ce billet sont fermés.

  • CSS2
  • Memento XHTML
  • Le zen des CSS
  • CSS
  • Web accessible