Le principe des accesskey
s est particulièrement simple et direct : permettre à l'utilisateur d'atteindre et d'activer liens et contrôles de formulaire HTML à l'aide de combinaisons de touches clavier librement déterminées par le concepteur. De la sorte, l'interactivité dans une page ne dépend plus de la seule souris : un utilisateur de lecteur d'écran, un utilisateur handicapé moteur, ou un banal amateur de racourcis clavier... peuvent renseigner un formulaire ou activer un lien avec le périphérique de leur choix, puisque d'autres dispositifs sauront exploiter ce qui est prévu pour le clavier. Cette solution est d'autant plus attractive que le prix à payer pour le concepteur est réduit : un simple attribut de l'élément concerné suffit à spécifier la touche à utiliser.
L'immaturité de ce mécanisme nous fait pourtant reprendre ici l'expression de Joe Clark, qui, tout en soulignant son excellent potentiel, le qualifie de délinquant juvénile du HTML accessible...
(Joe Clark, Building Accessible Websites, 2002).
En effet, en l'absence de convention sur le choix des "touches", faute de caractères réservés à cet usage, compte-tenu du peu de combinaisons réellement disponibles, d'une implémentation partielle dans les divers navigateurs, des conflits prévisibles entre accesskey
s de la page et racourcis clavier propres à la configuration matérielle et logicielle de l'utilisateur... la portée pratique de ce dispositif d'accessibilité est sérieusement amoindrie. A tel point qu'on est en droit de s'interroger : les accesskey
s ne sont-elles pas, en l'état actuel, en partie illusoires ?
Le principe des touches d'accès clavier
Les règles d'accessibilité insistent sur la nécessité de permettre à l'utilisateur d'interagir avec les pages Web non seulement grâce à un dispositif de pointage (la traditionnelle souris), mais aussi et surtout par l'intermédiaire du clavier. Le Curriculum for Web Content Accessibility Guidelines 1.0 rappelle clairement que :
Tous les utilisateurs ne disposent pas d'un environnement graphique, d'une souris ou d'un tel dispositif de pointage. Certains font appel au clavier, à des claviers alternatifs ou à la saisie vocale pour naviguer dans les liens, activer les contrôles de formulaires, etc. Les développeurs de contenu doivent toujours s'assurer que les utilisateurs pourront interagir avec une page à l'aide d'autres dispositifs qu'un dispositif de pointage. Une page conçue pour l'accès clavier (en sus de l'accès à la souris) sera généralement accessible aux utilisateurs d'autres dispositifs d'entrée. En outre, concevoir une page pour l'accès clavier améliorera également son design global.
Les Touches d'accès clavier (accesskey
s) sont l'un de ces mécanismes alternatifs d'accès aux hyperliens et aux items de formulaire :
Presser la touche d'accès clavier assignée à un élément donne à celui-ci le focus. L'action réalisée quand un élément reçoit le focus dépend de l'élément lui-même. Par exemple, quand un utilisateur active un lien défini par l'élément
a
, l'agent utilisateur suit généralement le lien. Quand l'utilisateur active un bouton radio, l'agent utilisateur modifie la valeur du bouton. Quand l'utilisateur active un champ de texte, il permet la saisie, etc.
Il leur est donné le rang de priorité 3 dans les Directives pour l'accessibilité aux contenus Web :
Prévoir des raccourcis clavier pour les liens importants (y compris ceux derrière les cartes cliquables côté client), les champs de formulaires, groupés ou individuels. [Priorité 3]
Par exemple en HTML, spécifier des raccourcis grâce à l'attribut "
accesskey
".
Notez la formulation vague adoptée par la spécification HTML4.01: de fait, focus
se traduit de manières diverses selon les navigateurs. Ainsi Opera ou Mozilla activeront le lien immédiatement, ou placeront le curseur dans un champ de saisie, tandis qu'Internet Explorer attendra que soit pressée la touche Entrée à la suite de l'accesskey
pour suivre un lien et aller à la page-cible...
Concrètement, ce focus
n'est pas donné par une touche unique, afin de le distinguer de la saisie courante au clavier. Il est obtenu à l'aide d'une combinaison de touches, variable selon les systèmes d'exploitation et les navigateurs. Par exemple :
- IE Windows : Alt et [accesskey], puis Entrée ;
- Mozilla, Netscape, K-Meleon, FireFox Windows: Alt et [accesskey] ;
- Opera 7 Windows, Macintosh, Linux : Esc + Shift et [accesskey] ;
- MSIE Macintosh : Ctrl et [accesskey], puis Entrée ;
- Safari 1.2 Macintosh : Ctrl et [accesskey] ;
- Mozilla, Netscape Macintosh : Ctrl et [accesskey] ;
- Galeon/Mozilla/FireFox Linux : Alt et [accesskey] ;
- Konqueror 3.3+ : Ctrl, puis [accesskey] (successivement) ;
- Netscape 4, Camino, Galeon, Konqueror avant la version 3.3.0, Omniweb, Safari avant la version 1.2, Opera Windows/Linux avant la version 7, ne supportent pas les
accesskey
s.
Pour en rester aux navigateurs graphiques courants, les utilisateurs sont donc confrontés à une grande diversité dans l'accès aux touches clavier. Certains devront presser la touche Entrée, d'autres non. Les touches additionnelles peuvent être Alt, Ctrl, Esc ou même parfois une combinaison de deux touches (Dans Opera quel que soit le caractère, mais aussi dans tous les navigateurs en cas de touche numérique : le pavé numérique étant ignoré, il faut en passer par la touche shift). Peut-on supposer que chaque utilisateur maîtrise son outil de navigation, et sait quelle combinaison utiliser ? Pour ne pas transformer notre amélioration de l'accessibilité en jeu de devinettes, il est prudent de rappeler ces différentes combinaisons possibles dans une page d'aide à l'accessibilité (nous reparlerons de celle-ci ci-dessous).
La mise en place sur un site
Pour permettre l'utilisation des touches d'accès clavier, il suffit de les assigner aux liens et aux éléments de formulaire à l'aide de l'attribut accesskey
. Les éléments supportant l'attribut accesskey
sont :
-
a
(liens) ; -
area
(images cliquables) ; -
button
,input
ettextarea
(éléments de formulaire). L'attributaccesskey
peut également être utilisé dans lelabel
associé à un contrôle unique, ou dans l'élémentlegend
d'unfieldset
regroupant plusieurs contrôles.
(Note: les exemples données dans cette partie utilisent des lettres comme touche d'accès clavier, car ce choix est a priori le plus intuitif quand on aborde ce mécanisme. Nous verrons cependant dans la suite de l'article que les lettres sont en réalité à proscrire, pour des motifs liés aux implémentations.)
On écrira donc par exemple pour le champ de saisie d'un formulaire de recherche :
-
Au plus simple,
<input type="text" accesskey="C" />
-
ou mieux, dans le
label
associé au champ,<label for="search" accesskey="C">Chercher : </label> <input type="text" id="search" name="search" />
(En effet, selon la spécification HTML4.01,
lorsqu'un
)label
reçoit le focus, il transmet celui-ci au contrôle auquel il est associé)
Et pour la touche d'accès d'un lien :
<a href="http://www.example.org" accesskey="E">Exemple</a>
Selon l'interpétation de la spécification HTML4.01 par les Directives pour l'accessibilité aux contenus Web, les agents utilisateurs (navigateurs...) devraient expliciter la touche spécifiée par l'attribut accesskey
. Typiquement, le caractère correspondant devrait être souligné dans la mesure où il apparaît dans le contenu du label
d'un élément de formulaire (A l'image d'une pratique courante dans les menus d'application). On constatera aisément qu'il n'en est rien, à l'heure actuelle, dans la quasi totalité des navigateurs graphiques (Les exceptions étant iCab et plus récemment Konqueror 3.3 qui signale les accesskey
à l'aide d'info-bulles lorsque l'utilisateur se met dans ce mode spécifique en pressant la touche Ctrl). Du côté des lecteurs d'écran, il semble que seules les versions récentes de Jaws signalent les accesskey
s.
Il est donc indispensable d'informer l'utilisateur des touches d'accès clavier que vous choisissez, car il n'existe aucun standard dans ce domaine. Quelques sélections d'accesskey
s issues de sites prestigieux sont toutefois souvent employées : voir par exemple celles du gouvernement anglais, de WebAIM, ou celle de Mark Pilgrim (Nous en ferons le bilan infra).
Cette information devrait être donnée de deux manières complémentaires :
-
en situation, dans le contexte de chaque lien concerné, dans le
label
d'un élément de formulaire, ou lalegend
d'unfieldset
:<dl> <dt> <label for="champ" accesskey="C"> Chercher (Accès clavier: touche C) </label> </dt> <dd> <input type="text" name="champ" id="champ" /> <input type="submit" value="Chercher" /> <p> <a href="..." accesskey="A">Recherche Avancée</a> (Accès clavier: touche A) </p> </dd> </dl>
Il faut noter que, présentée de cette manière, l'information qui sera aussi claire que possible pour les utilisateurs concernés, risque d'être à l'inverse une source de confusion pour d'autres, qui n'éprouvent pas le besoin d'utiliser un autre dispositif de pointage que leur souris. Il faut donc veiller à être suffisamment explicite sans pour autant encombrer un formulaire ou une liste de liens au point d'en rendre la lecture difficile : outre l'obligation d'une rédaction concise de l'intitulé, ceci incite également à être économe de ses
accesskey
s. -
On aura avantage à renseigner sur les touches choisies dans une liste récapitulative, placée par exemple en tête de la politique d'accessibilité du site, pour des touches d'accès répétées de page en page. Typiquement :
Les touches d'accès clavier suivantes sont utilisables dans ce site :
- Lien vers l'accueil : touche...
- Lien vers la page de recherche : ...
- Lien vers le plan de site : ...
- Lien vers l'index thématique : ...
Ceci n'a de sens, évidemment, que si cette page d'accessibilité est immédiatement accessible dès l'entrée sur n'importe quelle page du site, voire dotée elle-même d'un accès-clavier clairement annoncé.
Il peut enfin être tentant de recourir à des effets de présentation CSS pour renforcer cette information :
-
Par exemple, en utilisant un contenu généré qui fera apparaître [accès clavier : A] à la suite d'un lien du type
<a href="..." accesskey="A">Accueil</a>
. La feuille de style contiendra alors :a[accesskey]:after { content: " [accès clavier : " attr(accesskey) "] "; }
-
Ou encore en recourant à un effet de soulignement, de casse, de graisse... de la lettre concernée dans l'intitulé du lien :
a[accesskey] strong { font-weight: bold; border-bottom: 1px solid; text-transform: uppercase; }
qui agira sur la lettre A dans le lien suivant :
<a href="..." accesskey="A"> <strong>a</strong>ccueil </a>
On peut imaginer de nombreux moyens (plus ou moins convainquants) de signaler via CSS les touches d'accès claviers disponibles... mais il est indispensable d'inclure ce renseignement de manière explicite dans le contenu HTML, comme indiqué précédemment. En effet, les touches d'accès claviers n'ont guère de sens si elles ne sont indiquées qu'aux seuls utilisateurs de navigateurs graphiques supportant les CSS. Elles doivent être explicitées dans les lecteurs d'écrans, plages braille et tout autre média susceptible de les exploiter ; donc indépendamment du support des feuilles de style ou d'un accès visuel à la page. L'effet de présentation obtenu via CSS ne peut être qu'un rappel de cette information.
Le choix des touches d'accès clavier
En théorie, n'importe quel caractère pourrait être utilisé, ce qui signifie aussi bien des chiffres, des lettres minuscules, majuscules, accentuées, des signes de ponctuation, ou tout autre caractère Unicode. En pratique, non seulement les caractères non présents directements sur les claviers, mais aussi les caracères accentués sont ignorés ; dans la plupart des navigateurs, majuscules et minuscules ne sont pas différenciées en tant qu'accesskey
... finalement seuls les caractères US-ASCII sont fiables, dans la mesure où ils sont obtenus à l'aide d'une seule touche physique du clavier. Il reste donc à peine plus de 36 caractères disponibles : les lettres non accentuées de a à z, les chiffres de 0 à 9, et les quelques signes de ponctuation les plus répandus.
D'autre part, les systèmes d'exploitation et les applications côté utilisateur ont leurs propres sélections de racourcis clavier, susceptibles d'entrer en conflit avec les accesskey
s de votre site :
- En cas de conflit (mais c'est un usage et non une règle formelle), votre
accesskey
l'emporte dans les navigateurs graphiques, ce qui peut créer une gêne importante pour l'utilisateur, voire le priver d'une fonctionnalité essentielle. Unaccesskey="d"
privera par exemple les utilisateurs d'Internet Explorer de tout accès clavier à la barre d'adresse de leur navigateur. Il en sera de même pour les utilisateurs de Jaws associé à Internet Explorer. - A l'inverse, IBM HomePageReader, par exemple, ignore les
accesskey
s en cas de conflit avec ses propres touches réservées associées à alt (A, C, D, E, F, G, H, I, J, L, N, O, S, T, V, W et 1). Cependant, l'utilisateur d'HPR doit avoir cliqué au préalable dans la fenêtre d'affichage du navigateur avec sa souris pour que les touches d'accès clavier du site puissent être utilisées : comportement certes surprenant pour un lecteur d'écran, mais qui montre bien le peu de place que celui-ci laisse à ce mécanisme.
Signalons ici plusieurs pages de test du W3C qui vous permet de vérifier aisément la disponibilité des accesskey
s littérales et numériques dans votre propre configuration.
Enfin, compte-tenu de la diversité des OS et des outils de navigation, et sans compter les paramètres personnels de certains utilisateurs, il est extrêmement difficile d'établir une liste de touches "sûres". On peut cependant retenir quelques données générales :
- Les touches caractères sont les plus susceptibles d'être déjà réservées côté utilisateur : elles fournissent les raccourcis-claviers des menus de logiciels (la touche F donnant accès au traditionnel menu Fichier des navigateurs, par exemple).
- Les touches numériques sont beaucoup plus rarement employées de cette façon. Il faut cependant noter que certaines peuvent être utilisées par les lecteurs d'écrans (Certaines versions de Jaws utilisent 8 et 9 pour les clics de la souris ; pour Window Eyes, les nombres de 0 à 9 sont utilisées dans un mode de lecture par zones d'écran. IBM Home Page Reader, pour sa part, n'utilise que la touche 1, pour passer en mode lecture des titres seulement).
- Les touches restantes (ponctuation et autres signes) ne sont pas présentes ou facilement accessibles sur tous les claviers. Les touches / (slash), \ (backslash) et ] (crochet droit fermant), qui sont apparemment les plus susceptibles d'être "libres", s'avèrent souvent acrobatiques, voire impossibles d'accès sur des claviers non américains ou francophones. Sans compter que leur côté peu intuitif ne milite guère en leur faveur.
Conclusion ?
Sans aller jusqu'à renoncer à l'utilisation des accesskey
s, ce qui est le choix de la politique d'accessibilité actuelle du Gouvernement canadien, tout ceci conduit à relativiser leur intérêt et à se limiter à quelques touches numériques associées à des fonctions clés de la navigation sur le site. Certes, ces touches ne seront pas opérationnelles pour les utilisateurs de Window Eyes par exemple, mais elles provoqueront un minimum de conflit par ailleurs, et ne constitueront pas une gêne.
Voici les touches numériques qui font l'objet d'un consensus croissant, et qui sont recommandées simultanéement par le guide d'accessibilité des sites publics du gouvernement anglais et le Référentiel accessibilité des services Internet de l'administration française :
- Touche 0
- Liste des touches clavier utilisées. Cette liste peut se trouver en tête de la politique d'accessibilité du site, ou dans un document spécifique.
- 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, page où se trouve ce formulaire.
- 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...
On trouvera également dans les recommandations officielles françaises et anglaises la touche s (inopérant dans IBM Home Page Reader), pour les liens d'évitement des listes de liens (skip navigation).
Mise à jour (janvier 2005) : Un récent script permettant d'utiliser Jaws avec le navigateur Firefox implémente de nouveaux racourcis clavier qui font appel aux touches 1 à 6 pour permettre à l'utilisateur de naviguer dans les titres d'un document : l'utilisation d'une partie des touches numériques ci-dessus devient donc problématique.
On remarquera qu'une grande partie de ces liens correspondent à ceux définis par le standard HTML pour l'élément link
:
<link rel="start" href="/" title="accueil" /> <link rel="search" href="..." title="Recherche" /> <link rel="help" title="Politique d'accessibilité" href="..." /> <link rel="index" title="Carte" href="..." /> <link rel="contents" title="Index" href="..." />
D'autre part, les liens vers la page d'accueil, le moteur de recherche, la carte du site... peuvent aisément figurer dans un menu "accessibilité" placé en tête de page, immédiatement accessible et facile à parcourir de manière plus conventionnelle en raison de sa brièveté.
Enfin, concernant le lien d'évitement de la navigation, rappelons que les lecteurs d'écran tels IBM HomePageReader et Jaws disposent de leurs propres mécanismes plus performants : la navigation de titre en titre par exemple.
Il est donc indispensable de fournir en priorité les mécanismes d'accessibilité les plus efficaces pour ces fonctions clés :
- Titrage hiérarchisé et cohérent des sections fonctionnelles de la page ;
- Ordre de tabulation dans les formulaires et entre les listes de liens ;
- Menus d'accessibilité en tête de page offrant accès à la page d'accueil, à la recherche, à la navigation et au contenu ;
- Liens skip navigation permettant de "sauter" les séries de liens des menus ;
- Elément
link
dans l'en-tête de page... (Derek Featherstone, du WATS, fait à ce propos plusieurs propositions d'alternatives auxaccesskey
s);
Ceci fait, les accesskey
s numériques ci-dessus apporteront un surcroît d'accessibilité pour une partie des utilisateurs. Il reste à espérer que ce mécanisme sera précisé et son implémentation améliorée dans les spécifications futures.
OpenWeb remercie les membres de BrailleNet pour leur relecture critique de cet article.
Vos commentaires
Suivre les commentaires : |