Liste de contrôle vierge, formulaire imprimable
Checklist d'accessibilité des applications mobiles
EN 301 549 Chapter 11 + WCAG 2.2 AA for Native Mobile Apps
Liste de contrôle vierge à compléter hors ligne.
Cochez une case par ligne. Ajoutez vos commentaires et références de preuves dans la colonne Notes si nécessaire.
Compatibilité avec les lecteurs d'écran
EN 301 549 §11.1.1–§11.4, Tous les éléments d'interface doivent être accessibles aux lecteurs d'écran de la plateforme (TalkBack, VoiceOver).
| Réf | Gravité | Exigence | Statut | Notes / Preuves |
|---|---|---|---|---|
| EN 301 549 §11.5.2.3 | Critique | Tous les éléments interactifs ont des noms accessibles exposés à l'API d'accessibilité de la plateforme.Chaque bouton, lien, champ de saisie et commande doit avoir un nom programmatique, via contentDescription (Android), accessibilityLabel (iOS) ou texte visible. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 §11.5.2.5 | Critique | Tous les éléments interactifs exposent leur rôle aux technologies d'assistance.Les boutons doivent être annoncés comme boutons, les cases à cocher comme cases à cocher, les liens comme liens. Utilisez les contrôles natifs de la plateforme ou définissez explicitement accessibilityRole. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 §11.5.2.7 | Critique | Les changements d'état (déployé, sélectionné, coché) sont exposés par programmation.Lorsqu'une bascule change, qu'un menu déroulant se déploie ou qu'un onglet est sélectionné, le lecteur d'écran doit annoncer automatiquement le nouvel état. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 §11.5.2.12 | Majeur | Le focus suit un ordre de lecture logique correspondant à la disposition visuelle.La navigation par balayage du lecteur d'écran doit parcourir les éléments dans un ordre logique, de haut en bas, de gauche à droite. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A |
Saisie et gestes
EN 301 549 §11.1.2, Les gestes tactiles, les méthodes de saisie et le contrôle par clavier/contacteur doivent être accessibles.
| Réf | Gravité | Exigence | Statut | Notes / Preuves |
|---|---|---|---|---|
| WCAG 2.5.1 | Critique | Chaque geste de balayage, pincement ou multi-doigts a une alternative par appui simple ou bouton.Le pincement pour zoomer doit avoir des boutons +/-. Le balayage pour supprimer doit avoir un bouton Supprimer explicite. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| WCAG 2.5.8 | Critique | Les cibles tactiles respectent la taille minimale de 44×44pt (iOS) / 48×48dp (Android).Les petits boutons provoquent des échecs d'accessibilité motrice. Mesurez la taille rendue sur les appareils réels. Le padding compte dans la zone de toucher. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| WCAG 2.1.1 | Critique | La navigation complète au clavier et par contacteur fonctionne pour tous les parcours.Les utilisateurs de clavier externe et de contrôle par contacteur doivent pouvoir accomplir chaque tâche. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| WCAG 2.5.4 | Majeur | Aucune fonctionnalité ne dépend du mouvement de l'appareil (inclinaison, secousse) sans alternative.Secouer pour annuler doit avoir une alternative dans le menu. Incliner pour défiler doit avoir des boutons de contrôle. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 §11.7 | Majeur | L'application respecte les préférences d'accessibilité de la plateforme (texte en gras, réduction des mouvements, augmentation du contraste).Lorsque le système a activé « Réduire les mouvements », l'application doit réduire ou supprimer les animations. « Texte en gras » doit affecter la typographie de l'application. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A |
Accessibilité visuelle
WCAG 1.3–1.4 appliqués à l'interface mobile native, contraste de couleur, redimensionnement du texte, orientation.
| Réf | Gravité | Exigence | Statut | Notes / Preuves |
|---|---|---|---|---|
| WCAG 1.4.3 | Critique | Le contraste de couleur du texte respecte le ratio de 4,5:1 (3:1 pour le texte de grande taille).Mesurez par rapport à tous les arrière-plans, y compris les dégradés et les images. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| WCAG 1.4.11 | Majeur | Les composants d'interface non textuels (icônes, bordures, anneaux de focus) respectent un contraste de 3:1.Les bordures de boutons, les contours de champs de saisie, les graphiques d'icônes, tous doivent avoir un contraste suffisant par rapport à leur arrière-plan. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| WCAG 1.4.4 | Critique | Le texte se redimensionne jusqu'à 200 % via les paramètres système sans perte de contenu.Activez la mise à l'échelle des polices du système et vérifiez que tout le texte s'adapte correctement. Pas de troncature, chevauchement ni contenu masqué par débordement. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| WCAG 1.3.4 | Majeur | L'application fonctionne en mode portrait et paysage sauf si une orientation est essentielle.Le contenu doit se redistribuer pour les deux orientations. Ne verrouillez l'orientation que si le contenu l'exige vraiment. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| WCAG 1.4.1 | Critique | La couleur n'est pas le seul moyen de transmettre l'information.Les états d'erreur, les indicateurs de statut et les états sélectionnés doivent utiliser des formes, du texte ou des icônes en plus de la couleur. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A |
Notifications et retours
Les alertes, le retour haptique et les notifications système doivent être accessibles par plusieurs canaux sensoriels.
| Réf | Gravité | Exigence | Statut | Notes / Preuves |
|---|---|---|---|---|
| EN 301 549 §5.1.3.1 | Critique | Les notifications sont disponibles sous forme textuelle, pas uniquement sous forme de son ou de vibration.Les notifications push doivent inclure du texte lisible. Les alertes uniquement haptiques ou audio excluent les personnes sourdes et sourdaveugles. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| EN 301 549 §5.1.3.1 | Majeur | Le retour haptique a une alternative non haptique.Les utilisateurs qui ne peuvent pas percevoir les vibrations ont besoin d'une confirmation visuelle ou audio pour les événements haptiques. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| WCAG 4.1.3 | Majeur | Les messages de statut sont annoncés par le lecteur d'écran sans changement de focus.Les messages toast, les indicateurs de chargement et les confirmations de soumission de formulaire doivent utiliser les annonces d'accessibilité de la plateforme. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A |
Authentification et sessions
La connexion, la biométrie, les délais d'expiration et la gestion des sessions doivent être accessibles.
| Réf | Gravité | Exigence | Statut | Notes / Preuves |
|---|---|---|---|---|
| EN 301 549 §5.3 | Critique | La connexion biométrique (empreinte digitale, visage) a un recours par code PIN/mot de passe.Tous les utilisateurs ne peuvent pas utiliser la biométrie. Un parcours non biométrique doit toujours exister. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| WCAG 2.2.1 | Majeur | Les délais d'expiration de session avertissent l'utilisateur et permettent une prolongation.Affichez un avertissement au moins 20 secondes avant l'expiration. Permettez à l'utilisateur de prolonger. Ne déconnectez pas silencieusement. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A | |
| WCAG 3.3.8 | Majeur | L'authentification ne nécessite pas de tests de fonction cognitive (CAPTCHA) sans alternative accessible.Les CAPTCHAs sont des barrières pour de nombreux utilisateurs. Utilisez des méthodes de vérification alternatives. | ☐ Conforme ☐ Partiel ☐ NON CONFORME ☐ N/A |