La definition of GUI (Graphical User Interface) ne se limite pas à un agencement de boutons, menus et fenêtres. Dès lors qu’une interface graphique est déployée dans un contexte réglementé, elle doit répondre à des exigences d’accessibilité précises, codifiées par des normes que la plupart des articles sur le sujet passent sous silence.
EN 301 549 et GUI des logiciels métiers : le cadre que le web occulte
Le débat sur l’accessibilité numérique se concentre presque exclusivement sur les sites web et les applications mobiles. Les interfaces graphiques des logiciels de bureau, clients lourds et applications métiers restent dans l’angle mort, alors qu’elles sont soumises aux mêmes obligations.
A lire également : Plateforme numérique (digitale) : définition
La norme EN 301 549 v4.1.1 consacre un chapitre entier aux logiciels. Elle impose que toute application dotée d’une GUI respecte les quatre principes fondamentaux : perceptible, utilisable, compréhensible, robuste. Les exigences portent sur la navigation au clavier, les alternatives textuelles pour chaque élément graphique, le focus visible et la restitution correcte par les technologies d’assistance.
Depuis la transposition de la Directive (UE) 2016/2102, la conformité à EN 301 549 est devenue la référence technique pour les produits et services TIC du secteur public. Les éditeurs de logiciels métiers destinés aux administrations (B2G) sont désormais contractuellement tenus de démontrer cette conformité.
Lire également : Le portail astucieux : la révolution numérique au service des citoyens
Ce que cela change pour la conception d’une GUI
Concevoir une interface graphique accessible ne revient pas à ajouter un overlay ou un thème à contraste élevé en fin de projet. La norme exige que chaque composant interactif soit opérable sans souris, ce qui remet en cause des patterns de design répandus : drag-and-drop sans alternative clavier, menus contextuels accessibles uniquement au clic droit, arbres de navigation sans gestion du focus.
Nous observons dans les audits que les logiciels métiers concentrent les non-conformités les plus sévères. Un ERP ou un outil de gestion documentaire qui n’expose pas ses états (sélectionné, étendu, réduit) via les API d’accessibilité du système d’exploitation rend la GUI totalement opaque pour un lecteur d’écran.
RGAA, WCAG et GUI : articuler les référentiels
Le RGAA (Référentiel général d’amélioration de l’accessibilité) est le cadre français. Il s’appuie sur les WCAG du W3C et cible avant tout les contenus web. Sa méthode technique fournit des critères et tests directement applicables aux pages HTML.
Pour une GUI non web, le RGAA ne s’applique pas directement. C’est EN 301 549 qui prend le relais, en reprenant les critères WCAG et en les adaptant au contexte logiciel. L’articulation fonctionne ainsi :
- Les interfaces web (sites, applications web) sont auditées selon le RGAA, lui-même aligné sur les WCAG 2.1 niveau AA.
- Les interfaces graphiques d’applications natives (desktop, clients lourds) relèvent du chapitre 11 de la norme EN 301 549, qui transpose les critères WCAG au contexte logiciel.
- Les applications mobiles suivent les règles du chapitre 11 de EN 301 549, complétées par les recommandations spécifiques aux plateformes (iOS, Android).
Cette distinction est rarement explicitée dans les guides généralistes, ce qui conduit des équipes de développement à auditer une GUI de logiciel desktop avec des outils conçus pour le web, sans pertinence technique.
Critères d’accessibilité GUI : les points de friction récurrents
Les quatre principes (perceptible, utilisable, compréhensible, robuste) se déclinent différemment selon que l’on traite une page web ou une interface graphique applicative. Voici les zones de friction les plus fréquentes sur les GUI non web.
Navigation au clavier et gestion du focus
Une GUI accessible doit permettre d’atteindre et d’activer chaque élément interactif par le clavier seul. Le focus visible doit être perceptible à tout instant, avec un indicateur suffisamment contrasté. Les frameworks de développement desktop (Qt, WPF, GTK, JavaFX) offrent un support natif du focus, mais les composants personnalisés le cassent régulièrement.
Exposition des rôles et états via les API d’accessibilité
Chaque bouton, case à cocher, onglet ou arborescence d’une GUI doit transmettre son rôle, son nom et son état aux API d’accessibilité du système (UI Automation sous Windows, ATK sous Linux, NSAccessibility sous macOS). Un composant graphique qui ne remonte pas ces informations est un composant invisible pour les utilisateurs de technologies d’assistance.
Contraste et redimensionnement
Les règles de contraste des WCAG s’appliquent aussi aux GUI natives. Le ratio minimum de 4.5:1 pour le texte standard reste la cible. Le redimensionnement du texte sans perte d’information ni troncature est une exigence que beaucoup de logiciels métiers échouent à satisfaire, faute de mise en page adaptative dans leurs interfaces graphiques.
Audit d’accessibilité d’une GUI non web : outils et méthode
Auditer une interface graphique native ne se fait pas avec Lighthouse ou axe DevTools. Ces outils inspectent le DOM HTML et n’ont aucune prise sur une GUI de logiciel desktop.
- Accessibility Insights for Windows (Microsoft) inspecte l’arbre UI Automation et détecte les composants sans nom, rôle ou état exposé.
- Accerciser (GNOME) remplit la même fonction pour les applications GTK/ATK sous Linux.
- Xcode Accessibility Inspector couvre les applications macOS et iOS.
- Les tests manuels au clavier restent indispensables : navigation par tabulation, activation par Entrée/Espace, gestion des flèches dans les composants composites.
Nous recommandons de combiner l’inspection automatisée avec un test réel via un lecteur d’écran (NVDA ou JAWS sous Windows, VoiceOver sous macOS). L’outil automatisé détecte les propriétés manquantes, mais seul un parcours utilisateur révèle les ruptures de flux et les libellés ambigus.
La conformité d’une GUI à EN 301 549 ne se décrète pas en fin de cycle. Elle se construit dès la phase de conception, en intégrant les rôles ARIA-like du framework cible et en testant chaque composant graphique avant son intégration. Les équipes qui repoussent l’accessibilité à la recette finale découvrent des non-conformités structurelles, coûteuses à corriger sur des éléments d’interface déjà verrouillés.
