Blocages d'accessibilité qui coûtent des conversions

Vous cherchez les défauts d'accessibilité qui empêchent aussi les gens de convertir. Vous ne produisez pas un audit WCAG complet ni un avis juridique.

PAGE OU PARCOURS ET SON ACTION DE CONVERSION : {{FLOW_AND_ACTION}}
BALISAGE, LISTE DE COMPOSANTS OU DESCRIPTION DE CAPTURE : {{PAGE_STRUCTURE}}
PROBLÈMES DÉJÀ REMONTÉS : {{KNOWN_ISSUES}}
NOTES SUR LES TECHNOLOGIES D'ASSISTANCE OU LES APPAREILS, LE CAS ÉCHÉANT : {{AT_NOTES}}

Produisez un tableau : Problème | Où il se produit dans {{FLOW_AND_ACTION}} | Qui il bloque | Empêche la conversion ou la ralentit seulement | Critère WCAG si vous en êtes sûr | Correctif | Effort.

Couvrez au minimum : accès au clavier et état de focus visible sur chaque contrôle, libellés reliés aux champs, erreurs annoncées et non signalées par la seule couleur, contraste des boutons et des textes d'aide, taille des zones tactiles, menus déroulants et fenêtres modales personnalisés qui piègent ou perdent le focus, limites de temps, lecture automatique et animations, textes alternatifs sur les images porteuses d'information.

Ensuite :
- Classez par impact sur la conversion plutôt que par niveau de gravité. Un bouton de validation inatteignable au clavier passe devant un défaut de contraste décoratif.
- Listez tout ce qui, dans {{KNOWN_ISSUES}}, est déjà corrigé ou en doublon, pour que le backlog reste honnête.
- Dites quels constats exigent un vrai lecteur d'écran ou un test utilisateur pour être confirmés, compte tenu de {{AT_NOTES}}.

Contraintes : ne jugez que ce qui apparaît dans {{PAGE_STRUCTURE}}. Ne citez pas un numéro de critère WCAG dont vous n'êtes pas certain, écrivez « critère incertain » à la place. Ne prenez pas le score d'un outil automatique comme preuve que le parcours peut être mené à bout. Pas de tirets cadratins.