Test de disponibilité des interfaces

1) Pourquoi et ce que nous considérons « prêt »

• les critères WCAG 2 ont été remplis. 1/2. 2 niveaux AA pour les plates-formes cibles ;
• l'interface est entièrement traversable à partir du clavier ;
• travailler correctement avec les lecteurs d'écran ;
• les contrastes sont conformes aux normes ;
• tous les états/erreurs/statuts sont disponibles hors de vue et sans souris ;
• la localisation, RTL, reduce motion et mobile sont pris en compte.

2) Stratégie de test (pyramide A11y)

1. Auto-tests/linters (couverture rapide jusqu'à 40 à 60 % des classes de problèmes).
2. Vérification manuelle des patterns (clavier, focus, contenu, logique).
3. Session Assistive Tech (AT) : lecteurs d'écran, mise à l'échelle, filtres de couleurs.
4. Essais sur le terrain avec les utilisateurs (si possible).

Objectif : attraper les défauts systémiques au niveau des composants/patterns afin de ne pas se multiplier dans les dattes.

3) Chèque de vérification de base (course rapide)

• Clavier : tout est réalisable par tabouret/flèche ; l'ordre de focalisation est logique ; le piège du focus dans les modales est là ; L'ESC/Enter/Space fonctionne.
• L'indicateur de focus est visible dans n'importe quel sujet/sur n'importe quel fond.
• Contraste : Texte ≥ 4. 5:1 (ordinaire), ≥ 3:1 (majeur), icônes/contrôles lisibles.
• Sémantique : étiquettes correctes ('button', 'a', 'label', 'ul/li', 'th/td'), rôles et 'aria-' seulement si nécessaire.
• Lecteur d'écran : titres par hiérarchie, noms sémantiques des boutons/liens, alternatives pour les icônes/images.
• Formes : « label » explicite, les indices/erreurs sont liés (« aria-describedby »), les textes d'erreurs sont spécifiques.
• Dynamique : les toasts/bannières/erreurs sont déclarés via 'aria-live' ('polite '/' assertive').
• Les animations respectent 'prefers-reduced-motion' ; sans « secouer » l'interface.
• Localisation/RTL : les écrans clés sont alignés, les nombres/dates/devises sont formatés par des utilitaires.
• Mobilité : objectifs tactiles ≥ 44 × 44 px, zoom non interdit, rotation de l'écran ne casse pas le contenu.

4) Rôles, responsabilités et artefacts

Système de conception : Exigences A11y dans la description de chaque composant.
Développeurs : Tests automatiques, tests d'unité/interaction avec A11y-asserts.
QA : scripts manuels + sessions AT ; un rapport de gravité/fréquence.
UX/Content : microcopy error/status, lisibilité à haute voix.
Artefacts : checklists, scripts, screencasts AT, liste de défauts avec les référents WCAG, recommandations.

5) Contrôles automatisés

Linters/analyseurs : axe, eslint-plugin-jsx-a11y, pa11y, Lighthouse.
En pipline : on bloque les PR en cas de perturbations critiques (role/label/contraste/pièges à pièges).
Snapshots de contraste : tests visuels de thèmes/états.

6) Tests manuels : Scénarios

6. 1 Clavier

Passez la page uniquement avec le clavier (onglet/Maj + onglet/entrée/espace/flèches).
Vérifiez : visibilité du focus, priorité, disponibilité de toutes les actions, absence de « pièges » et d'éléments « morts ».
Dans la modalité : mise au point à l'intérieur, à la fermeture revient à l'initiateur.

6. 2 Lecteurs d'écran (ensemble minimum)

Desktop: NVDA/JAWS (Windows), VoiceOver (macOS).
Mobile: VoiceOver (iOS), TalkBack (Android).
Nous vérifions : les titres corrects (hiérarchie H), les noms des boutons/liens, la lecture des tables ('th '/' scope'), la déclaration des statuts, les erreurs de forme compréhensibles.

6. 3 Contenu et microcopy

Nous lisons les textes critiques à haute voix - sans ambiguïté, sans « erreur 400 ».
Erreur = « ce qui ne va pas + comment corriger + contrainte/format ».

6. 4 Dynamiques et régions vivantes

Le toast du succès est 'aria-live = « polite », l'erreur est' assertive '.
Progrès/téléchargement expliqué par le texte ; skeleton est préférable au spinner.

7) Formes et erreurs (en profondeur)

Chaque champ a un label associé (pas placeholder).
Les erreurs sont liées au champ : 'aria-invalid =' true ',' aria-describedby = '[id error]'.
Les formules de formats (date, téléphone) sont indiquées à l'avance ; les masques ne cassent pas l'entrée/l'insertion.
Bannière d'erreur totale pour submit + auto-scroll et focus sur la première erreur.
Textes d'erreur : concrets, sans jargon technique.

8) Tableaux, listes, graphiques

Tableaux : titres 'th' avec 'scope =' col/row ', signatures, CV.
Les listes sont réelles 'ul/ol/li', pas des divas.
Graphiques - autres tableaux/descriptions ; les légendes sont disponibles ; les couleurs ≠ le seul signal.

9) Multimédia et animations

Vidéo : sous-titres/décryptage ; Commande au clavier ; sans auto-play (ou avec silencieux).
GIF/microanimations : Désactiver avec 'prefers-reduced-motion' ; on évite les flashs.
Vibrations/sons - optionnels et dupliqués visuellement/texte.

10) Disponibilité mobile

Interactifs ≥ 44 × 44 px, intervalles suffisants.
Ne pas interdire la mise à l'échelle (meta viewport sans 'user-scalable = no').
Forme/clavier : les types corrects ('tel', 'email', 'nombre') ne cachent pas les capacités du système.
Vérifiez dans le thème obscur et avec les polices système « plus ».

11) Localisation, nombres et RTL

Des lignes via i18n-clés avec le contexte ; les langues longues (DE/TR) ne cassent pas la mise en page.
Les formats date/monnaie sont des utilitaires, pas des lignes.
Mode RTL : miroirs icônes de navigation, vérifier l'ordre de mise au point et chariot, entrée bidirectionnelle.

12) Spécificité du flou critique (iGaming)

Paiements/conclusions

Instructions claires, limites/délais/commissions - texte.
Les erreurs du fournisseur sont déclarées explicitement, sans codes ; il y a une alternative à l'action.
Confirmation de l'opération : focus sur le CTA logique, possibilité d'annulation.

CUS/vérification

Conseils étape par étape sur les photos/documents ; progrès et ETA.
Erreurs Flou/Blink/Recadré - avec des exemples de correction.
Ton neutre, pas d'humour.

13) Évaluation de la gravité des défauts

Blocker : impossible de terminer une tâche clé (clavier/lecteur d'écran).
Critique : la fonction critique fonctionne, mais avec de sérieuses barrières.
Major : dérange, il y a une solution de contournement.
Mineur : cosmétique/non-conformité haydam sans impact sur la tâche.

Chaque défaut est une référence au critère WCAG et au scénario reproduit.

14) Critères d'acceptation (Définition de Done, A11y)

Parcourir un script clavier sans souris à 100 %.
axe/Lighthouse : pas d'irrégularités critiques/élevées.
Contraste AA dans tous les thèmes/états.
Lecteur d'écran-course des chemins clés (navbar, formes, models, toasts).
Documentation A11y pour les nouveaux composants/fiches (modèle de rôle, aria, focus, exemples).
La régression des tests A11y est verte en IC.

15) Processus et automatisation

Avant le développement : Critères A11y dans les tâches, mises en page avec états de mise au point/erreurs.
En développement : linters/ahe lors de l'assemblage local ; snapshots visuels de contrastes/focus.
Dans CI : pa11y/axe-scan par pages critiques ; chute du billet sous Blocker/Critical.
Après la sortie : audits trimestriels, suivi des plaintes des utilisateurs sur A11y-tag.

16) Anti-modèles

Placholder au lieu de label.
« bou » au lieu de « button »/« a ».
Anneaux de discussion éteints « pour la beauté ».
Couleur comme seul porteur de statut.
Models sans focus trap/ESC.
Interdiction de mise à l'échelle sur mobile.
« Erreur 400/500 » sans explication humaine.

17) Modèles de scénarios de test

Scénario 1 - Navigation clavier (page avec formulaire)

1. Tabulation jusqu'au premier champ, entrez les données.
2. Maj + Onglet arrière - Assurez-vous que l'ordre est correct.
3. Appelez validation (submit) : le focus est transféré à la première erreur.
4. Fermez le modeleur avec la touche ESC, le focus est retourné à l'initiateur.

Scénario 2 - Lecteur d'écran (page de paiement)

1. Allez au titre de la page (h1), écoutez les sections.
2. Ouvrez la sélection de méthode - la déclaration des rôles/états est audible.
3. Faites délibérément une erreur de somme - message lu et lié au champ.
4. Un toast réussi sur le paiement a été déclaré « polite ».

Scénario 3 - Dynamique

1. Exécutez l'opération en attente> 3 s - il y a un texte sur le processus/ETA.
2. En cas d'erreur du réseau, la bannière 'assertive'est accessible à partir du clavier, il y a un chemin « répéter/aider ».

18) Micro-modèles utiles

Rôles/aria pour toasts

html
<div role = "status" aria-live = "polite"> Payment accepted. Balance updated. </div>
<div role = "alert" aria-live = "assertive"> The payment was denied. Try another method. </div>

Association de l'erreur au champ

html
<label for = "amount "> Amount </label>
<input id="amount" aria-invalid="true" aria-describedby="amount-error">
<div id = "amount-error "> Minimum 100 UAH. Please enter a larger amount. </div>

Modalité (attributs sémantiques)

html
<div role="dialog" aria-modal="true" aria-labelledby="m-title">
<h2 id =" m-title "> Confirm Payment </h2>
<! -- content -->
<button> Confirm </button>
<button> Cancel </button>
</div>

19) Plan rapide de mise en œuvre des pratiques A11y

1. Audit des composants/patterns actuels (contraste/focus/sémantique de rôle).
2. Modifications du système de conception : ajoutez une section A11y à chaque composant.
3. Outils : configurer les linters/axe/pa11y/Lighthouse localement et en CI.
4. Formation : hydes courts pour concepteurs/développeurs/rédacteurs.
5. Pilote : réparer les 3 à 5 défauts les plus fréquents (modeles, moules, toasts).
6. Règlement : DoD avec critères A11y ; audit trimestriel.

La trappe finale

Vérifiez le clavier, le focus, les contrastes, le lecteur d'écran, la dynamique.
Déclarez les statuts via aria-live ; erreurs - liées aux champs.
Respectez la motion reduce, n'interdisez pas la mise à l'échelle.
Pensez avec la sémantique (tags/rôles), pas « à quoi ressemble ».
Automatiser les contrôles, mais toujours compléter manuellement.
Enregistrez les défauts en référence au WCAG, à la gravité et au scénario de reproduction.