Pratique et vérification

Tester une page au clavier : un exercice pour débuter

Un test au clavier vérifie si une personne peut suivre une tâche web définie sans souris. Choisissez un court parcours, utilisez Tab et Maj+Tab, activez les éléments avec la touche appropriée et notez les résultats. Cet exercice révèle des barrières, mais ne couvre qu’une partie d’un examen d’accessibilité plus large.

Des designers examinent des maquettes papier

Un test au clavier vérifie si une personne peut suivre une tâche web définie sans souris. Choisissez un court parcours, utilisez Tab et Maj+Tab, activez les éléments avec la touche appropriée et notez les résultats. Cet exercice révèle des barrières, mais ne couvre qu’une partie d’un examen d’accessibilité plus large.

Idées essentielles

  • La tâche a un début et une fin.
  • Navigateur et URL publique sont notés.
  • Les contrôles nécessaires sont atteignables.
  • Le focus actif est visible.

Commencer par un parcours réel

Choisissez ouvrir une leçon, atteindre son fichier puis revenir au cours. Écrivez le départ et le signe de réussite. Testez la page publiée plutôt qu’une capture de maquette. Fermez les dialogues sans rapport, puis répétez avec un dialogue ouvert s’il appartient à la tâche. Notez navigateur et adresse pour qu’une autre personne reproduise le contrôle dans des conditions comparables.

Observer les déplacements du focus

Appuyez lentement sur Tab et identifiez l’élément actif. Le focus est-il visible ? La séquence est-elle logique ? Revenez avec Maj+Tab. Un détail décoratif ne devrait pas imposer un arrêt inutile, tandis qu’un bouton réel doit être atteignable. Easy Checks de W3C présente ce contrôle comme un premier examen ; notre feuille en fait une pratique limitée avec observations précises.

[1]

Distinguer sens et fonctionnement

Un lien atteignable peut avoir un libellé ambigu. Notez l’attente avant activation et comparez la destination. Boutons et liens ont des rôles distincts ; MDN explique l’importance des éléments HTML natifs. Si un panneau s’ouvre, vérifiez comment poursuivre et revenir. Décrivez l’échec observé sans transformer une supposition sur le code en cause confirmée. Une observation exacte est déjà utile.

[2]

Corriger et reprendre le même parcours

Choisissez une barrière et une correction précise : libellé descriptif ou focus visible. Répétez la tâche initiale et gardez les deux observations. Un parcours réussi ne rend pas tout le site accessible : lecteurs d’écran, contraste, structure et autres tâches restent à examiner. Le résultat est un constat reproductible et une réparation vérifiée dans un périmètre réduit, à conserver dans toute présentation du projet.

Votre liste de preuves

Cochez seulement ce que vous avez vérifié. Cette liste décrit votre progression, pas un audit indépendant ni une prévision. Il n’y a pas d’enregistrement automatique ; téléchargez la note pour la conserver.

Tester une page au clavier : un exercice pour débuter

0 / 6 vérifiés

En mots simples

Un constat utile décrit la barrière, la tâche reproductible et le résultat de sa réparation.

À vous de jouer

Ouvrez un cours et son fichier sans souris. Notez une étape confuse ou bloquée, décrivez le résultat attendu, corrigez un point puis répétez le parcours.

Résultat attendu

Un relevé avant et après pour une tâche, avec page, navigateur et résultat. Ce n’est pas un rapport complet de conformité.

Vérifiez votre réponse: Réussir l’exercice prouve-t-il la conformité WCAG ?

Non. Il couvre un petit parcours au clavier. Les premiers contrôles W3C révèlent certaines difficultés. Une évaluation plus large demande d’autres critères, tâches et technologies d’assistance, avec un périmètre explicite dans les conclusions plutôt qu’une affirmation générale de conformité.

Questions et réponses

Réussir l’exercice prouve-t-il la conformité WCAG ?

Non. Il couvre un petit parcours au clavier. Les premiers contrôles W3C révèlent certaines difficultés. Une évaluation plus large demande d’autres critères, tâches et technologies d’assistance, avec un périmètre explicite dans les conclusions plutôt qu’une affirmation générale de conformité.

Signaler un problème sans connaître sa cause technique ?

Oui. Une observation précise aide avant le diagnostic. Donnez page, action et résultats attendu et réel. N’affirmez pas une cause supposée. L’équipe peut enquêter pendant que vous conservez une tâche reproductible qui montre clairement la difficulté rencontrée.

Un constat utile décrit la barrière, la tâche reproductible et le résultat de sa réparation.

Sources et lectures

  1. W3C WAI — Easy Checks ↗Sources consultées:
  2. MDN — HTML accessibility ↗Sources consultées: