Checklist d’accessibilité pour un MVP

Fixer la frontière avant que le design se fige

Identifiez utilisateurs, contextes, plateformes et parcours complet. Intégrez les besoins liés au handicap à la recherche et au risque plutôt que de réserver un audit final générique. Choisissez le standard interne applicable et obtenez un conseil qualifié si les obligations dépendent de la juridiction, du secteur ou d’un marché public. Ce guide n’est pas un avis juridique.

N’accordez pas automatiquement d’exemption au MVP. Un produit étroit peut utiliser contrôles sémantiques, langage clair, ordre de focus et mise en page adaptable dès la première version. Arrêtez et consultez un spécialiste pour un parcours de santé, sûreté, finance, emploi, service public ou autre domaine important, ou si l’équipe ne sait pas interpréter le standard sur une interaction critique.

Inventorier le parcours et les formes de contenu

Listez titres, régions, contrôles, formulaires, validation, tableaux, médias, graphiques, gestes, glisser-déposer, délais, authentification et mises à jour dynamiques. Pour chacun, consignez nom, rôle, état, instructions et moyen équivalent lorsque la modalité exclurait. Incluez états vide, erreur, chargement, succès et récupération.

Établissez une base sur appareils et navigateurs représentatifs avec clavier seul, zoom et agrandissement du texte, contraste renforcé si pertinent, lecteur d’écran et réduction des animations. Un scan automatique trouve certains motifs mais ne juge ni ordre de lecture, ni pertinence des libellés, ni compréhension de la tâche. Consignez versions, étapes manuelles et barrières observées.

Planifier les corrections dans composants et recette

Priorisez les barrières bloquant le résultat central, puis défauts répétés et contenus. Intégrez sémantique, focus, association des erreurs, contraste, cibles tactiles, sous-titres ou alternatives et responsive au système de composants. Évitez une version accessible parallèle si une interface maintenue peut répondre au besoin, car deux voies divergent.

Ajoutez des critères observables aux stories et une porte accessibilité à la définition de fini. Attribuez responsables design, contenu et ingénierie. Testez tôt avec de vrais composants. Si une recherche avec des personnes handicapées est pertinente, menez-la de façon éthique et rémunérée selon le processus normal, sans présenter un petit échantillon comme preuve universelle.

Recetter le parcours avec des preuves en couches

Combinez outils fondés sur les standards, revue de code et contrôles manuels. Vérifiez atteinte au clavier ou contacteur, focus, noms et annonces du lecteur d’écran, zoom et reflow, contraste, mouvement, récupération d’erreur et services plateforme. Documentez environnement, preuves, échecs et exceptions. Un score automatique ou un seul lecteur ne prouve pas une accessibilité complète.

Définissez la recette par des preuves observables, par exemple un parcours testé, un build approuvé, des contrôles reproductibles, un runbook d’incident et une transmission vérifiée. Rien de cela ne prouve rétention, revenu ou adéquation marché. Séparez preuve de livraison, approbation d’un fournisseur externe et résultat business.

Porter l’accessibilité dans la maintenance

Publiez les limites connues et une voie de support accessible si pertinent, avec responsables et dates. Gardez scripts, règles de composants et audits dans les systèmes du produit, puis répétez après changements de dépendance, design system ou OS. Incluez l’accessibilité dans incidents et transmission. L’absence de plainte ne prouve pas l’absence de barrière.

Gardez dépôts, domaines, stores, analytics, organisations cloud et identifiants de production sous une propriété explicite de l’entreprise. Accordez des accès limités et révocables, puis répétez la transmission avant la dernière facture. L’étiquette du prestataire compte moins que la capacité d’une autre personne autorisée à inspecter, déployer, reprendre et poursuivre le produit.

Critères de décision

Posez les mêmes questions à chaque option avant de choisir.