Ajouter une accessibilité sémantique (ARIA) aux vues de jeu #74

New issue

Open

opened 2026-07-02 06:25:29 +00:00 by Reliodas · 0 comments

Reliodas commented

2026-07-02 06:25:29 +00:00

Owner

Constat audit du 2 juillet 2026 : le client ne contient aucun attribut ARIA (grep aria- : 0 occurrence). Les changements d'état pilotés par le serveur (nouvelle question, décompte, révélation, résultat) ne sont pas annoncés aux technologies d'assistance, et les contrôles (réponses, plateau des catégories, tableau de la finale, codebreaker) n'exposent ni rôle ni état sélectionné.

Objectif : rendre les parcours candidat et spectateur utilisables avec un lecteur d'écran et au clavier, en complément du #54 qui reste centré sur l'ergonomie multi-écrans, le contraste et le focus visuel.

Tâches :

annoncer les transitions de statut et le chronomètre via des régions aria-live (politesse adaptée : question/résultat en polite, fin de temps en assertive) ;
exposer l'état des boutons de réponse (aria-pressed ou role=radio/radiogroup) et le verrouillage après envoi ;
donner des libellés explicites aux contrôles iconographiques ou tronqués (✓/✗, badges, code de salle, tableau numéroté de la finale) ;
rendre le plateau des catégories et le tableau de la finale navigables au clavier avec un ordre de focus cohérent ;
documenter la politique d'accessibilité dans docs/Implémentation.md (section client).

Critères d'acceptation :

les vues candidat, spectateur et MJ passent un audit automatique (axe-core via Playwright ou équivalent) sans violation critique ou sérieuse ;
une partie complète (manche 1 → finale) est jouable au clavier côté candidat ;
les annonces aria-live sont couvertes par des tests composants (présence, contenu, politesse) ;
aucun changement de contrat Socket.IO ni de logique serveur.

Dépendances / limites : complémentaire de #54 (responsive/projection : contraste, tailles, focus visuel) et de #60 (Firefox) ; se coordonner avec #73 si les composants de scène sont mutualisés d'abord.

Constat audit du 2 juillet 2026 : le client ne contient aucun attribut ARIA (`grep aria-` : 0 occurrence). Les changements d'état pilotés par le serveur (nouvelle question, décompte, révélation, résultat) ne sont pas annoncés aux technologies d'assistance, et les contrôles (réponses, plateau des catégories, tableau de la finale, codebreaker) n'exposent ni rôle ni état sélectionné. Objectif : rendre les parcours candidat et spectateur utilisables avec un lecteur d'écran et au clavier, en complément du #54 qui reste centré sur l'ergonomie multi-écrans, le contraste et le focus visuel. Tâches : - [ ] annoncer les transitions de statut et le chronomètre via des régions `aria-live` (politesse adaptée : question/résultat en `polite`, fin de temps en `assertive`) ; - [ ] exposer l'état des boutons de réponse (`aria-pressed` ou `role=radio`/`radiogroup`) et le verrouillage après envoi ; - [ ] donner des libellés explicites aux contrôles iconographiques ou tronqués (✓/✗, badges, code de salle, tableau numéroté de la finale) ; - [ ] rendre le plateau des catégories et le tableau de la finale navigables au clavier avec un ordre de focus cohérent ; - [ ] documenter la politique d'accessibilité dans `docs/Implémentation.md` (section client). Critères d'acceptation : - les vues candidat, spectateur et MJ passent un audit automatique (axe-core via Playwright ou équivalent) sans violation critique ou sérieuse ; - une partie complète (manche 1 → finale) est jouable au clavier côté candidat ; - les annonces aria-live sont couvertes par des tests composants (présence, contenu, politesse) ; - aucun changement de contrat Socket.IO ni de logique serveur. Dépendances / limites : complémentaire de #54 (responsive/projection : contraste, tailles, focus visuel) et de #60 (Firefox) ; se coordonner avec #73 si les composants de scène sont mutualisés d'abord.