Clavier :
Comprendre le CS 2.1.1
2.1.1 Clavier : toutes les fonctionnalités sont utilisables à l'aide d'une interface clavier sans exiger un rythme de frappe propre à l'utilisateur, sauf lorsque la fonction sous-jacente nécessite une saisie qui dépend du tracé du mouvement effectué par l'utilisateur et pas seulement des points de départ et d'arrivée de ce tracé. (Niveau A)
Note 1 : cette exception ne concerne que la fonction sous-jacente et non la technique de saisie. Par exemple, lorsqu'on utilise l'écriture manuscrite pour saisir du texte, la technique de saisie (l'écriture manuscrite) nécessite une saisie qui dépend d'un tracé, mais la fonction sous-jacente (la saisie de texte) ne le requiert pas.
Note 2 : cela n'interdit pas et ne devrait pas décourager l'utilisation de la souris ou de toute autre méthode de saisie en plus de l'utilisation du clavier.
Objectif de ce critère de succès
L'objectif de ce critère de succès est de garantir, partout où cela est possible, que le contenu peut être manipulé à l'aide d'un clavier ou d'une interface clavier (un clavier alternatif peut donc être utilisé). À l'aide d'un clavier ou d'un clavier alternatif, le contenu peut être manipulé par des personnes qui n'ont pas de vision (qui ne peuvent utiliser de périphériques comme les souris nécessitant une coordination de l’œil et de la main) ainsi que par les personnes qui doivent se servir de claviers alternatifs ou de périphériques de saisie qui agissent comme des émulateurs de clavier. Les émulateurs de clavier incluent les logiciels de saisie par commande vocale, les logiciels de commande par le souffle, les claviers virtuels, les logiciels reposant sur le balayage et de nombreuses technologies d'assistance et claviers alternatifs. Les personnes malvoyantes peuvent aussi avoir des difficultés à suivre un pointeur et trouver plus facile (ou n'avoir que cette possibilité) d'utiliser un logiciel si elles peuvent le contrôler à l'aide d'un clavier.
Des exemples de « rythme de frappe propre à l'utilisateur » incluent les situations dans lesquelles un utilisateur serait amené à répéter ou exécuter plusieurs commandes dans un court laps de temps ou dans lesquelles une touche doit être maintenue enfoncée pendant une période prolongée avant que la commande ne soit prise en compte.
La phrase « sauf lorsque la fonction sous-jacente nécessite une saisie qui dépend du tracé du mouvement effectué par l'utilisateur et pas seulement des points de départ et d'arrivée » a été ajoutée pour distinguer ces éléments qui ne peuvent raisonnablement être contrôlés au clavier.
La plupart des actions réalisables à l'aide d'un périphérique de pointage peuvent également l'être au clavier (par exemple, cliquer, sélectionner, déplacer, redimensionner). Il existe cependant un petit ensemble de commandes effectuées à l'aide d'un périphérique de pointage qui ne peuvent être faites au clavier de quelque manière connue que ce soit sans requérir un nombre démesuré de commandes. Dessiner à main levée, faire du coloriage, faire voler un hélicoptère par dessus des obstacles sont autant de fonctions nécessitant une saisie qui dépend du tracé du mouvement. Tracer des lignes droites, des formes géométriques courantes, redimensionner des fenêtres et déplacer des objets à un endroit (dès lors que le tracé vers cet endroit n'est pas significatif), ne nécessitent pas de saisie qui dépend du tracé du mouvement.
L'utilisation de MouseKeys ne satisferait pas à ce critère de succès car il ne s'agit pas d'un équivalent du clavier du point de vue de l'application ; c'est un équivalent de la souris (du point de vue applicatif, c'est une souris).
Il est admis que le développement de fonctionnalités de saisie utilisateur prend en compte le fait que les fonctionnalités d'accessibilité par le clavier du système d'exploitation peuvent être utilisées. Par exemple, les touches de modification peuvent se trouver verrouillées. Dans un tel environnement, le contenu fonctionne toujours, n'envoie pas d'évènements qui entreraient en conflit avec les touches de modification verrouillées et produiraient des résultats indésirables.
Avantages spécifiques du critère de succès 2.1.1 :
-
Les personnes aveugles (qui ne peuvent utiliser de périphériques comme les souris qui nécessitent une coordination de l’œil et de la main)
-
Les personnes malvoyantes (qui peuvent avoir du mal à trouver ou à suivre le symbole du pointeur sur l'écran)
-
Certaines personnes ayant des tremblements de la main trouvent l'utilisation de la souris très difficile et se servent donc habituellement d'un clavier
Exemples pour le critère de succès 2.1.1
Exemple 1 : un programme de dessin
Un programme de dessin permet aux utilisateurs de créer, dimensionner, positionner et faire pivoter des objets à partir du clavier.
Exemple 2 : une fonctionnalité de glisser-déplacer
Une application qui utilise le glisser-déplacer prend également en charge le couper-coller ou des contrôles de formulaire pour déplacer les objets.
Exemple 3 : déplacer et relier entre eux des points distants
Un programme de liaison de points permet à l'utilisateur de se déplacer d'un point à l'autre sur l'écran et d'utiliser la barre d'espace pour relier le point courant au précédent.
Exemple 4 : exception - un programme de coloriage
Un programme de coloriage est considéré comme une exception dans la mesure où le maniement du pinceau varie en fonction de la vitesse et de la durée du mouvement.
-
Exemple 5 : exception - simulateur pour apprendre à voler sur des modèles d'hélicoptère
Un simulateur pour apprendre à voler sur des modèles d'hélicoptère est considéré comme une exception car la nature même du simulateur est d'enseigner le comportement en temps réel par rapport à un modèle d'hélicoptère.
-
Exemple 6 : un assistant numérique personnel avec un clavier en option
Un assistant numérique personnel qui est généralement utilisé via un stylet possède en option un clavier que l'on peut connecter. Le clavier permet de naviguer sur le web de manière tout à fait standard. Le contenu web est complètement utilisable puisqu'il a été conçu pour fonctionner au clavier seulement.
Ressources liées
Les ressources sont présentées dans un but d'information seulement, il ne s'agit pas d'une approbation.
(Aucune ressource n'est actuellement documentée)
Techniques et échecs pour le critère de succès 2.1.1 - Clavier
Chaque élément numéroté dans cette section représente une technique ou une combinaison de techniques que le groupe de travail des WCAG considère comme suffisante pour satisfaire à ce critère de succès. Les techniques énumérées satisfont le critère de succès seulement si toutes les exigences de conformité aux WCAG 2.0 ont été appliquées.
Techniques suffisantes
G202 : Garantir le contrôle par le clavier pour toutes les fonctionnalités (en anglais)
Garantir le contrôle par le clavier en utilisant l'une des techniques suivantes
G90 : Fournir des événements déclenchés au clavier (en anglais) en utilisant l'une des techniques suivantes :
SCR20 : Utiliser à la fois des fonctions au clavier et spécifiques à d'autres périphériques (en anglais) (programmation par script)
SCR35 : Rendre les actions au clavier accessibles en utilisant l'événement onclick sur les liens et les boutons (en anglais) (programmation par script)
SCR2 : Utiliser des événements redondants au clavier et à la souris (en anglais) (programmation par Script)
FLASH17 : Fournir l'accès aux objets Flash à l'aide du clavier et éviter les pièges au clavier (en anglais) (Flash) ET utiliser les techniques suivantes lorsque applicable :
Techniques (recommandées) supplémentaires pour 2.1.1
Bien qu'elles ne soient pas nécessaires à la conformité, les techniques supplémentaires suivantes devraient être envisagées afin de rendre le contenu plus accessible. Toutes ces techniques ne peuvent pas être utilisées ou ne seraient pas efficaces dans toutes les situations.
Utiliser les attributs XHTML role, state et value si des éléments statiques réutilisés ont des composants interactifs (lien à venir) ET SCR29 : Ajouter des actions au clavier accessibles à des éléments HTML statiques (en anglais) (programmation par script)
Fournir des raccourcis clavier pour les liens et contrôles de formulaire importants (lien à venir)
Utiliser des combinaisons uniques de lettres pour débuter chaque élément d'une liste (lien à venir).
Choisir le déclencheur d'événement le plus abstrait (lien à venir) (Programmation par script)
Utiliser l'événement onactivate (lien à venir) (programmation par script)
Éviter l'utilisation à d'autres fins des commandes au clavier communément utilisées par les agents utilisateurs (lien à venir)
Échecs fréquents pour le CS 2.1.1
Le groupe de travail des WCAG considère les erreurs fréquentes suivantes comme des échecs du critère de succès 2.1.1.
Mots clés
- fonctionnalité
processus et résultats atteignables par une action de l'utilisateur
- interface clavier
-
interface utilisée par un logiciel pour obtenir une saisie au clavier
Note 1 : une interface clavier permet aux utilisateurs de fournir aux programmes une saisie au clavier même si la technologie native ne comporte pas de clavier.
Exemple : un assistant numérique personnel (PDA) à écran tactile possède une interface clavier intégrée à son système d'exploitation et un connecteur pour des claviers externes. Les applications dans le PDA peuvent utiliser l'interface pour obtenir une saisie au clavier externe ou par d'autres applications qui simulent une sortie clavier comme les interpréteurs d'écriture manuscrite ou les applications de transcription vocale en texte avec des fonctionnalités « d'émulation clavier ».
Note 2 : l'utilisation d'une application (ou de parties d'une application) à travers un pointeur souris dirigé au clavier, comme MouseKeys, ne constitue pas une opération réalisée au travers d'une interface clavier car l'utilisation du programme passe par l'interface de pointage et non pas par l'interface clavier.