Pour ce genre de test spécial, notre formulaire habituel pour signaler des bogues ne suffit pas, il n'a pas tous les champs nécessaires. En plus, pour les rapports d'accessibilité, il y a des règles supplémentaires en plus de celles pour les bogues classiques, comme expliqué dans les articles de l'académie sur les exigences de rapport de bogues et les pièces jointes au rapport de bogue.

Des obligations supplémentaires auxquelles chaque rapport d'accessibilité doit se conformer sont décrites dans les chapitres suivants. Tu trouveras deux exemples à la fin de l'article pour illustrer des rapports d'accessibilité respectant ces règles.

Titre

Pour le titre de ton bogue, respecte ce format selon le niveau d'accessibilité (A ou AA) et le point de contrôle du WCAG :

Problèmes de niveau A

Problèmes de niveau AA

[A] [WCAG Critères de succès]: <titre du bogue>

[AA] [WCAG Critères de succès]: <titre du bogue>

[A] [1.1.1]: L'image significative n'a pas d'attribut alt

[AA][4.1.2]: Lien de suppression annoncé sans rôle

Le texte à remplacer doit être substitué par une description de ton bogue, comme tu le ferais pour les rapports de bogue habituels.

Par exemple:

[A] [1.1.1] Les liens des médias sociaux sont annoncés de manière incorrecte

Voici quelques exemples de titres de bogue pour les problèmes d'accessibilité les plus fréquents. N'hésite pas à les prendre et à les ajuster comme tu veux:

[A] [4.1.2] Le lien de déconnexion est annoncé sans rôle

[A] [2.4.3] Le bouton de bascule du filtre est annoncé avec un état incorrect

[A] [2.4.2] Le titre de la page n'est pas unique et descriptif

[AA] [2.4.7] La bordure de mise au point n'est pas visible pour le lien du testeur sous le bouton Connexion.

Étapes pour reproduire

En général

Première étape : En plus d'ouvrir l'URL de test, dis-moi quel outil t'as utilisé dès le début. Remplace le mot <outil> par, genre, NVDA, JAWS, WAVE, etc., dans le modèle suivant:

En utilisant <outil>, ouvrez <URL de test>, par exemple : En utilisant NVDA, ouvrez https://www.test.io

Plusieurs éléments: Si un point de contrôle foire pour plusieurs éléments du même genre (par exemple, bouton ou lien), mets-les ensemble dans un seul rapport.

Occurrences multiples: Pour noter plusieurs fois le même problème sur la même page ou sur différentes pages, liste-les dans tes résultats sous une section intitulée ❝Autres occurrences:❞ .

Actions décrites: Comme les personnes malvoyantes ou aveugles n'utilisent pas de souris d'ordinateur, ne détaille pas les actions de la souris. Privilégie plutôt les actions au clavier et au pavé tactile, par exemple:

Utilise la touche TAB pour aller vers le compte utilisateur.

Appuie sur ENTREE pour activer le lien de déconnexion.

Balaye vers la gauche pour mettre le focus sur le menu hamburger.

Outils automatisés: Tu peux utiliser des trucs comme WAVE pour repérer les problèmes, mais ton rapport, y compris tes étapes, doit être décrit du point de vue de l'utilisateur. Ne détaille pas comment tu utilises un outil automatisé et ce qu'il signale dans tes étapes, mais décris plutôt tout comme si tu n'avais pas utilisé d'outil, en te basant simplement sur les points de contrôle WCAG.

Problèmes de contraste des couleurs

Voici comment tu dois faire (remplace les espaces réservés):

```
Ouvrez <URL de test>
```
...
...

Mesurez le rapport de contraste des couleurs de <nom de l'élément>

Les soucis avec le même combo de couleurs ne peuvent être mentionnés qu'une fois. Par exemple, un problème avec du texte bleu sur un fond blanc et du texte blanc sur un fond bleu constituent le même combo de couleurs et ne peuvent pas être signalés deux fois.

Résultat réel

Dans la section des résultats réels - en plus du résultat réel habituel que tu dois noter lors des tests exploratoires ordinaires - précise quel point de contrôle a foiré, par exemple:

Points de contrôle WCAG 2.1 non valides : 1.3.2 Niveau A

Pièces jointes

Le type de pièce jointe à ajouter dépend du problème d'accessibilité:

Contraste des couleurs: capture d'écran
Tous les autres problèmes: enregistrement d'écran

Captures d'écran: Comme dans les tests ordinaires, assure-toi d'identifier le problème sur les captures d'écran.

Enregistrement d'écran: Lorsque tu fais ton screencast, prends ton temps avant d'atteindre l'élément ayant le problème. Si tu vas trop vite, le spectateur risque de manquer le souci. Si tu vas trop rapidement pendant l'enregistrement, le chef d'équipe pourrait te demander une vidéo améliorée.

Problèmes de navigation au clavier

Quand tu fais ton enregistrement d'écran, n'oublie pas de montrer les touches que tu as pressées sur ton clavier. Sinon, les gens auront du mal à comprendre le problème. Active le clavier à l'écran sur ton ordi, c'est dispo pour Windows et macOS. Un clavier virtuel s'affichera, et tu pourras simuler l'appui sur une touche en cliquant simplement dessus.

Modèle de formulaire

En ce moment, y a pas de formulaire dédié pour les rapports d'accessibilité, alors en attendant, on utilise celui pour les rapports d'utilisabilité. Histoire que tous les rapports aient la même tronche, faut les formater. Juste en dessous, on te file un modèle tout bien mis en forme qu'on te suggère d'utiliser.

Il te suffit de copier-coller ce modèle dans le champ de texte unique du formulaire d'utilisabilité, de remplacer les espaces entre crochets (par exemple, [outil], [URL], etc.) et de balancer tes informations.

Notes:

Si t'as pas utilisé d'outil pour repérer le problème, genre pour les soucis de navigation au clavier, la première étape doit être classique: Ouvrir <URL>.
Si t'as besoin de plus ou moins d'étapes, tu peux ajuster la numérotation comme il faut.

##### Steps
1. Using <tool>, open <URL>
2. 
3. 
4. 
5. 

##### Actual result
<actual result>
**Failed WCAG 2.1 checkpoint(s)**: X.X.X Level <A/AA>

##### Expected result
<expected result>

Exemples

Exemple de lecteur d'écran

Titre:

[AA] [2.4.3]: La mise au point n'est pas piégée dans la fenêtre modale du menu hamburger

Étapes:

En utilisant VoiceOver, ouvrez https://test.io/
Balayez vers la droite pour mettre au point le menu hamburger
Double-tapez pour l'activer
Faites glisser à travers la fenêtre modale du menu hamburger élargi et observez

Résultat réel:

La mise au point continue à se déplacer à travers le contenu de l'arrière-plan derrière la fenêtre modale, qui ne fait pas partie du menu hamburger superposé.

Checkpoint(s) WCAG 2.1 en échec: 2.4.3 Niveau AA

Résultat attendu:

La mise au point devrait être piégée dans la fenêtre modale du menu hamburger. Les éléments masqués de la page sous-jacente ne doivent pas être mis au point et annoncés.

Exemple de navigation au clavier

Titre:

[AA] [2.4.7] Le lien "Obtenir une démo" n'a pas de contour de mise au point visible

Étapes:

En utilisant NVDA, ouvrez https://test.io/
Appuyez sur TAB pour mettre au point le bouton "Obtenir une démo" sous la section "Prenez-vous la qualité personnellement" et observez

Résultat réel:

Le lien "Obtenir une démo" dans la section "Prenez-vous la qualité personnellement" n'a pas de contour de mise au point.

Autres occurrences: Icônes des réseaux sociaux

Checkpoint(s) WCAG 2.1 en échec: 2.4.7 Niveau AA

Résultat attendu:

Les éléments interactifs doivent avoir un contour de mise au point visible lorsqu'ils sont mis au point.

Exemple de contraste des couleurs

Titre:

[AA] [1.4.3] Le texte blanc sur fond bleu du lien "Obtenir une démo" ne respecte pas les exigences en matière de contraste des couleurs

Étapes:

Ouvrez https://test.io/
Faites défiler jusqu'au lien "Obtenir une démo"
Mesurez le ratio de contraste des couleurs du lien "Obtenir une démo"

Résultat réel:

Le lien "Obtenir une démo" ne respecte pas les exigences en matière de contraste des couleurs. Le texte en bleu (#21BEF4) sur fond blanc (#FFFFF) a un ratio de contraste de seulement 2,15:1.

Checkpoint(s) WCAG 2.1 en échec: 1.4.3 Niveau AA

Résultat attendu:

Les petits textes doivent avoir un ratio de contraste d'au moins 4,5:1. Les gros textes (en gras et de 14 pt ou plus) doivent avoir un ratio de contraste d'au moins 3:1.