Guides Banque & Assurance

Accessibilité bancaire et assurance : formulaires complexes, PSD2 et authentification

Le défi de l'accessibilité dans le secteur bancaire

Les services bancaires en ligne sont devenus indispensables : consultation de comptes, virements, souscription de produits, gestion de sinistres d'assurance. Pour les 12 millions de Français en situation de handicap, l'accès autonome à ces services est un enjeu d'inclusion majeur.

Le secteur bancaire cumule plusieurs défis d'accessibilité : formulaires complexes à multiples étapes, authentification forte (PSD2), données tabulaires (relevés de compte), graphiques interactifs (suivi de portefeuille) et délais de session limités pour des raisons de sécurité.

Les obligations légales pour banques et assurances

Les banques et assurances sont concernées par plusieurs textes :

  • RGAA : les établissements publics bancaires (Banque de France, Caisse des Dépôts) y sont directement soumis
  • European Accessibility Act (EAA) : depuis juin 2025, les services bancaires aux consommateurs doivent être accessibles
  • Directive PSD2 : l'authentification forte doit être accessible aux personnes handicapées (article 97)
  • Loi française : les entreprises de plus de 250 M€ de CA (toutes les grandes banques) sont soumises au RGAA

L'authentification forte accessible (PSD2/DSP2)

La directive PSD2 impose une authentification forte (SCA) pour les opérations sensibles. Le problème : de nombreux dispositifs ne sont pas accessibles :

Problèmes courants

  • Clavier virtuel aléatoire : les pavés numériques avec disposition aléatoire sont inaccessibles aux lecteurs d'écran et aux personnes à mobilité réduite
  • SMS OTP : les codes par SMS nécessitent de quitter l'application, ce qui est difficile pour certains utilisateurs
  • Biométrie : la reconnaissance faciale/digitale n'est pas utilisable par tous
  • Applications de validation : les notifications push requièrent une interaction rapide

Solutions accessibles

  • Proposer plusieurs méthodes d'authentification (clavier classique + biométrie + code SMS)
  • Permettre la saisie du code par un champ texte standard accessible au clavier
  • Étendre les délais de saisie des codes OTP (au moins 2 minutes)
  • Rendre les notifications de validation compatibles avec les lecteurs d'écran
  • Proposer une alternative au clavier virtuel aléatoire

Formulaires bancaires et d'assurance

Souscription de produits

Les parcours de souscription (crédit, assurance, épargne) sont souvent des formulaires en 5 à 10 étapes. Points critiques :

  • Indicateur de progression : utiliser aria-current="step" et annoncer l'étape en cours
  • Résumé avant validation : afficher clairement toutes les informations saisies avant la signature électronique
  • Simulation : les simulateurs de crédit/assurance avec curseurs (sliders) doivent avoir des alternatives en champs numériques
  • Documents contractuels : les CGV et conditions particulières doivent être en format accessible (pas d'images de texte)

Gestion des sinistres

La déclaration de sinistre en ligne doit être accessible :

  • Upload de justificatifs avec retour accessible sur le statut du fichier
  • Suivi de dossier avec états clairement annoncés
  • Messagerie intégrée accessible pour les échanges avec le gestionnaire

Relevés et données financières

Tableaux de transactions

Les relevés de compte en HTML doivent respecter les critères RGAA sur les tableaux :

  • En-têtes de colonnes balisés avec <th scope="col">
  • Caption descriptif : « Relevé de compte courant - Février 2026 »
  • Montants négatifs signalés autrement que par la couleur (signe « - » ou mention « débit »)
  • Filtres et tri accessibles au clavier

Graphiques financiers

Les graphiques d'évolution de portefeuille, de répartition d'actifs, etc. doivent :

  • Avoir une alternative textuelle décrivant les tendances principales
  • Proposer les données sous forme de tableau accessible en complément
  • Ne pas transmettre d'information uniquement par la couleur

Checklist accessibilité pour le secteur bancaire

ComposantVérificationPriorité
AuthentificationAlternative au clavier virtuel aléatoireCritique
AuthentificationDélai suffisant pour saisie OTPCritique
FormulairesLabels sur tous les champsCritique
FormulairesMessages d'erreur accessiblesCritique
RelevésTableaux balisés avec en-têtesÉlevée
GraphiquesAlternative textuelle ou tabulaireÉlevée
DocumentsPDF accessibles (balisés)Élevée
SessionAvertissement avant expirationÉlevée
L'accessibilité bancaire n'est pas qu'une obligation légale : c'est un avantage compétitif. Les banques accessibles fidélisent une clientèle plus large, y compris les seniors et les personnes en situation de handicap temporaire.
Non, les claviers virtuels à disposition aléatoire sont généralement non conformes au RGAA car ils ne sont pas accessibles au clavier ni aux lecteurs d'écran. Une alternative accessible (champ de saisie standard ou biométrie) doit être proposée.
Oui, l'article 97 de la directive PSD2 précise que l'authentification forte ne doit pas créer d'obstacles injustifiés. Combinée à l'EAA, les banques doivent proposer au moins une méthode d'authentification forte accessible aux personnes handicapées.
Utilisez des tableaux HTML avec en-têtes balisés (th scope="col"), un caption descriptif, des montants clairement identifiés (débit/crédit, pas uniquement par la couleur rouge/vert), un tri et des filtres accessibles au clavier, et proposez un export en format accessible (CSV, PDF balisé).

Testez la conformité de votre site

Scannez votre site et obtenez un rapport détaillé avec recommandations IA.

Scanner mon site - 15€