L'accessibilité numérique bancaire et l'EAA

Pourquoi banque et accessibilité s’accordent mal

La banque est censée protéger les gens. Gérer son argent — consulter ses soldes, effectuer des paiements, demander des prêts, examiner ses relevés — fait partie intégrante de la vie financière moderne. Lorsque les plateformes bancaires numériques sont inaccessibles, les personnes les plus susceptibles d’être exclues sont souvent celles qui disposent du moins d’alternatives.

Des clients âgés souffrant d’une perte de vision liée à l’âge et qui dépendent de lecteurs d’écran. Des personnes en situation de handicap moteur qui ne peuvent pas utiliser de souris. Des clients sourds qui ne peuvent pas recourir au service client téléphonique et doivent tout effectuer en ligne. Ce sont des utilisateurs réels, présents dans la clientèle de chaque banque, et l’European Accessibility Act fait désormais de leur accès une obligation légale.

La banque et les services financiers sont explicitement nommés dans le champ d’application de l’EAA. L’échéance du 28 juin 2025 s’appliquait aux services financiers tout comme au commerce en ligne et aux télécommunications. Pour les banques, ce n’est pas facultatif.

Les échecs d’accessibilité les plus courants dans la banque

Connexion et authentification inaccessibles

Les parcours de connexion sont la porte d’entrée de chaque service bancaire, et ils présentent fréquemment des problèmes d’accessibilité :

• CAPTCHA sans alternative audio, empêchant les utilisateurs aveugles de franchir l’authentification
• Parcours de mot de passe à usage unique (OTP) qui reposent sur le SMS — certains utilisateurs présentant des troubles cognitifs ont des difficultés à gérer une authentification en plusieurs étapes sous la pression du temps
• Expirations de session qui n’avertissent pas les utilisateurs avant de mettre fin à une session, et qui ne peuvent pas être prolongées — les utilisateurs qui mettent plus de temps à accomplir leurs tâches (ce qui inclut de nombreux utilisateurs en situation de handicap) se retrouvent déconnectés à répétition

Le critère WCAG 2.1 2.2.1 Délai modifiable (niveau A) exige que les limites de temps d’une session soient ajustables ou prolongeables.

Champs de formulaire non étiquetés et inaccessibles

La banque implique de nombreux formulaires : virements de fonds, mise en place de paiements, changements d’adresse, demandes de prêt. Les mêmes échecs d’accessibilité des formulaires qui affectent n’importe quel site web sont particulièrement coûteux dans la banque — un utilisateur aveugle qui ne peut pas remplir un formulaire de paiement ne peut pas accéder à un service bancaire essentiel.

L’échec le plus courant : des champs de formulaire sans éléments <label> correctement associés. Sans étiquette, les lecteurs d’écran annoncent « zone d’édition, vide » et l’utilisateur ne sait pas quoi saisir. Nous traitons ce sujet en détail dans notre guide des messages d’erreur accessibles et cela s’applique tout autant aux champs de formulaire standard.

Relevés et documents PDF inaccessibles

Relevés mensuels, conditions générales, contrats de prêt, documents d’information sur les produits — les banques produisent d’énormes volumes de contenu PDF, et la quasi-totalité est générée à partir de systèmes qui produisent des PDF inaccessibles.

Un PDF accessible possède une structure balisée, un ordre de lecture logique, des niveaux de titres significatifs et un texte alternatif pour toute image contenant de l’information. Un PDF exporté depuis un document Word ou généré par un moteur de reporting sans traitement d’accessibilité n’en possède généralement aucun. Pour en savoir plus, consultez notre guide d’accessibilité des PDF.

Navigation au clavier déficiente dans les parcours transactionnels

Virer des fonds, ajouter un bénéficiaire, consulter l’historique des transactions — les parcours complexes en plusieurs étapes courants dans la banque contiennent souvent des composants qui ne fonctionnent qu’à la souris : des menus déroulants qui ne répondent pas aux entrées clavier, des sélecteurs de date sans prise en charge du clavier, des boîtes de dialogue de confirmation qui piègent le focus clavier.

Applications mobiles inaccessibles

L’EAA couvre les applications mobiles au même titre que les sites web. Les applications bancaires en particulier ont tendance à comporter des composants natifs qui se comportent différemment des éléments web, avec des couches d’accessibilité qui exigent un travail explicite pour être mises en œuvre correctement.

Parmi les échecs courants de la banque mobile : des éléments interactifs trop petits pour être touchés de manière fiable (le critère WCAG 2.5.5 Taille de la cible, niveau AAA, suggère un minimum de 44×44 pixels CSS), un contraste insuffisant dans les thèmes d’interface personnalisés, et des barres d’onglets ou schémas de navigation personnalisés qui n’exposent pas leur état aux API d’accessibilité.

Contraste insuffisant dans la conception de l’interface

La conception des interfaces bancaires tend souvent vers le minimalisme et l’usage du gris clair sur blanc pour les informations secondaires — numéros de compte, références de transaction, textes d’accompagnement. Ceux-ci échouent fréquemment au critère WCAG 1.4.3 Contraste minimum (niveau AA), qui exige un ratio de 4,5:1 pour le texte normal.

Le coût de confiance de l’inaccessibilité

La banque est une relation de confiance. Lorsqu’un utilisateur en situation de handicap ne peut pas accéder à ses relevés de compte, ne peut pas mettre en place un prélèvement automatique de façon autonome, ou se voit contraint d’appeler une ligne téléphonique (qui peut elle-même présenter des barrières d’accessibilité) pour accomplir des tâches que ses pairs valides effectuent en ligne, le message est clair : ce service n’a pas été conçu pour vous.

Le coût de réputation de ce message, dans un secteur où la confiance des clients est fondamentale, est considérable. Le coût juridique au titre de l’EAA est de plus en plus concret. Et le coût pratique — les clients qui migrent discrètement vers un concurrent qui fonctionne avec leur technologie d’assistance — est plus difficile à mesurer mais bien réel.

Par où commencer

L’EAA exige une norme WCAG 2.1 niveau AA sur l’ensemble de vos services numériques. Pour la plupart des banques, atteindre ce niveau sur tous les points de contact numériques simultanément n’est pas réalisable — la surface est trop vaste. Priorisez selon l’impact sur le client :

Priorité la plus élevée :

1. Parcours de connexion et d’authentification — si les clients ne peuvent pas entrer, rien d’autre n’a d’importance
2. Gestion de compte essentielle : consulter le solde, consulter les transactions, virer des fonds
3. Téléchargements de relevés et documents PDF

Deuxième priorité :

1. Mise en place et gestion des paiements
2. Parcours de demande de prêt et de produits
3. Parcours essentiels de l’application mobile (correspondant aux priorités web)

Pour chaque domaine, exécutez à la fois une analyse automatisée (qui détecte les problèmes de contraste, d’étiquetage et de structure) et des tests manuels avec technologie d’assistance (qui détectent les échecs de navigation au clavier, les problèmes de gestion du focus et les problèmes d’annonce des lecteurs d’écran).

Lancez une analyse gratuite de votre site bancaire public pour voir où vous en êtes actuellement sur les problèmes automatisables. Pour un examen complet des parcours bancaires authentifiés — là où résident la plupart des échecs d’accessibilité complexes — parlez à notre équipe d’un programme d’audit structuré.