Accessibilité numérique d'une application : les règles
L’accessibilité numérique rend une application utilisable par une personne aveugle, malentendante, à mobilité réduite ou dyslexique, avec ou sans matériel spécialisé. En France, l’article 47 de la loi du 11 février 2005 en fait une obligation pour les organismes publics et pour les entreprises au-delà d’un seuil de chiffre d’affaires. Le référentiel de contrôle s’appelle le RGAA.
Le sujet arrive presque toujours trop tard dans les projets. L’interface est figée, le budget consommé, et la remise à niveau suppose de rouvrir chaque écran un par un. Traité en amont, le même travail se fond dans les arbitrages de conception sans ligne budgétaire séparée.
Quatre principes avant toute grille technique
Le site officiel de l’accessibilité numérique de l’État résume l’exigence en quatre mots : perceptible, utilisable, compréhensible, robuste. Ces quatre principes structurent aussi les recommandations WCAG publiées par le W3C, la référence internationale du domaine.
Perceptible veut dire que l’information passe par plusieurs canaux. Une photo porte une alternative textuelle, une vidéo porte des sous-titres, un contraste suffisant sépare le texte de son fond. Utilisable renvoie à la manipulation : chaque fonction se déclenche au clavier, la navigation reste cohérente d’un écran à l’autre, le focus se voit.
Compréhensible touche à la prévisibilité. Un formulaire annonce ses erreurs en clair, les libellés gardent le même sens partout, la langue de la page est déclarée. Robuste concerne la compatibilité avec les technologies d’assistance : lecteur d’écran, plage braille, contacteur, logiciel de dictée, loupe système.
Cette dernière brique explique beaucoup d’échecs. Une interface peut sembler impeccable à l’œil et rester muette pour un lecteur d’écran, parce que les boutons n’ont pas de nom accessible ou que les changements d’état ne sont jamais annoncés. Le rendu visuel ne dit rien de ce que restitue la machine.
Un malentendu tenace mérite d’être levé au passage. Ces règles ne servent pas qu’un public restreint et identifié. Un contraste correct sauve la lecture d’un écran de smartphone en plein soleil, des sous-titres rendent une vidéo consultable dans un train sans écouteurs, une navigation clavier propre accélère le travail d’un utilisateur avancé, et une gestion fine du focus aide toute personne qui manipule son téléphone d’une seule main. Les situations de handicap temporaires, un bras plâtré, une otite, une fatigue visuelle passagère, produisent exactement les mêmes besoins que les situations permanentes.
Qui est légalement concerné, et à partir de quel seuil
Le champ d’application publié sur le site interministériel dédié distingue quatre familles d’organismes soumis à l’article 47 de la loi du 11 février 2005 :
- les personnes morales de droit public ;
- les entités privées délégataires d’une mission de service public ;
- les entités privées créées pour satisfaire des besoins d’intérêt général autres qu’industriel et commercial ;
- les entreprises qui dépassent un seuil de chiffre d’affaires.
Ce seuil est chiffré sans ambiguïté : 250 millions d’euros de chiffre d’affaires annuel moyen, calculé sur les trois derniers exercices comptables clos et réalisés en France. Une PME française n’y tombe donc pas par sa seule taille. Elle y tombe si elle porte une délégation de service public, ou si elle produit un service pour un donneur d’ordre lui-même soumis, cas fréquent dès qu’une collectivité commande une application.
Le cadre européen élargit le périmètre par un autre chemin. La directive 2016/2102 vise les sites et les applications mobiles du secteur public. La directive 2019/882, dite European Accessibility Act, couvre selon la Commission européenne un ensemble bien plus large de produits et de services : ordinateurs et systèmes d’exploitation, smartphones, distributeurs automatiques de billets, bornes de vente de titres et d’enregistrement, équipements de télévision numérique, services et équipements de téléphonie, accès aux médias audiovisuels, transport de voyageurs aérien, ferroviaire, routier et fluvial, services bancaires, livres numériques et commerce électronique. La Commission précise que les États membres devaient l’inscrire dans leur droit national avant juin 2022.
Pour un éditeur, la conséquence est simple à formuler. Une boutique en ligne, un service bancaire ou une liseuse relèvent d’une logique de conformité produit propre au texte européen, indépendante du seuil de 250 millions d’euros.
Le RGAA, la grille qui fait foi en France
Le Référentiel général d’amélioration de l’accessibilité fournit la méthode de contrôle française. Sa version 4 a été arrêtée conjointement par la ministre chargée des personnes handicapées et le ministre chargé du numérique le 20 septembre 2019. La version applicable aujourd’hui est le RGAA 4.1.2, une version 5 étant annoncée pour la fin 2026.
Le référentiel range ses critères en treize thématiques : images, cadres, couleurs, multimédia, tableaux, liens, scripts, éléments obligatoires, structuration de l’information, présentation de l’information, formulaires, navigation, consultation. Chaque critère se vérifie par une série de tests numérotés. Cette granularité rend l’audit reproductible : deux auditeurs différents aboutissent au même verdict sur le même écran.
Deux normes se trouvent sous le référentiel. La norme européenne EN 301 549, dans sa version V2.1.2 d’août 2018, sert de référence réglementaire. Elle reprend, comme l’indique le W3C, les critères WCAG 2.1 de niveau AA sans modification pour le contenu web. Les recommandations WCAG avancent selon leur propre calendrier : version 2.0 publiée le 11 décembre 2008, version 2.1 le 5 juin 2018 avec dix-sept critères de succès supplémentaires, version 2.2 le 5 octobre 2023 avec neuf critères supplémentaires, puis une mise à jour le 12 décembre 2024.
Le socle technique change la façon d’appliquer ces règles. Une application web progressive, une application hybride et une application native ne s’auditent pas avec les mêmes outils, même quand les exigences restent identiques. Le choix entre natif, hybride et PWA gagne à intégrer ce paramètre dès le cadrage, pas après la première livraison.
Les trois publications qui matérialisent la conformité
La conformité ne reste pas interne. Elle s’expose publiquement, à travers trois documents que le référentiel décrit précisément.
La déclaration d’accessibilité vient en premier. Elle comprend l’état de conformité, le signalement des contenus non accessibles, les dispositifs d’assistance et de contact, et la mention de la faculté de saisir le Défenseur des droits. Elle se publie sur le service concerné, au sein d’une page accessibilité joignable depuis la page d’accueil et depuis n’importe quelle autre page. L’adresse recommandée est une URL en /accessibilite.
Le schéma pluriannuel de mise en accessibilité vient ensuite. Sa durée maximale est de trois ans. Il expose la politique de l’entité : stratégie, ressources, formation, organisation interne, travaux de mise en conformité des services en ligne. Ces travaux se déclinent chaque année en plans d’actions, publiés en ligne eux aussi et rappelés dans la déclaration.
Reste la mention de niveau de conformité, affichée sur la page d’accueil, avec un libellé imposé selon le résultat de l’audit.
| Mention affichée | Condition |
|---|---|
| Accessibilité : totalement conforme | tous les critères de contrôle du RGAA respectés |
| Accessibilité : partiellement conforme | au moins 50 % des critères respectés |
| Accessibilité : non conforme | moins de 50 % des critères, ou aucun audit valide |
Le seuil de 50 % surprend souvent. Il sépare deux libellés, il ne définit aucun confort d’usage : un service à 55 % de critères respectés bloque encore des utilisateurs sur des parcours entiers.
Ce que l’exigence change dans la fabrication
Le sujet se traite à trois moments du projet, avec des gestes différents à chaque fois.
Au moment des maquettes
Les arbitrages les plus coûteux à corriger se prennent ici. Contrastes de la palette, taille des zones cliquables, hiérarchie des titres, espacement des blocs de texte. Un point mérite une vigilance particulière : aucune information ne doit reposer sur la seule couleur, sinon un champ en erreur devient invisible pour une personne daltonienne.
La question des libellés se pose aussi tôt. Un bouton nommé « En savoir plus » répété douze fois sur un écran ne donne aucun repère à un utilisateur qui parcourt la liste des liens par la synthèse vocale. Les étapes de conception d’une application mobile absorbent ces contraintes sans surcoût quand elles sont posées avant la validation graphique.
Pendant le développement
Le travail porte sur la structure restituée aux outils d’assistance : libellés associés aux champs, ordre de tabulation logique, focus visible, alternatives textuelles pertinentes, annonce des changements d’état, sous-titres sur les contenus vidéo. Rien d’exotique, mais des points qui disparaissent vite sous la pression des délais.
Chiffrer cette part dès l’estimation initiale évite la mauvaise surprise. Le sujet s’intègre naturellement aux postes détaillés dans un budget de développement d’application, au même titre que les tests ou la maintenance.
À la recette
Trois vérifications rapides détectent la majorité des blocages : parcourir l’application au clavier seul, la traverser avec un lecteur d’écran, zoomer à 200 % pour voir si la mise en page tient. L’audit RGAA formel intervient après, sur un échantillon de pages représentatif des parcours réels.
Les outils automatiques ont leur place dans cette phase, à condition de connaître leur limite. Ils repèrent les alternatives manquantes, les contrastes insuffisants, les champs sans libellé associé, autrement dit ce qui se mesure. Ils ne jugent ni la pertinence d’une alternative textuelle, ni la logique d’un ordre de lecture, ni la clarté d’un message d’erreur. Ces critères se contrôlent à la main, et la part manuelle reste majoritaire dans un audit sérieux.
Sur mobile, deux points spécifiques reviennent constamment. Le premier concerne l’orientation : bloquer une application en mode portrait pénalise les personnes dont le support est fixé sur un fauteuil. Le second concerne les gestes complexes, balayage à deux doigts, appui long, tracé continu, qui doivent toujours proposer une alternative simple, un bouton par exemple.
Par où commencer quand rien n’a été fait
Un service existant se remet à niveau par étapes, sans tout reprendre.
- Identifier les parcours critiques : création de compte, recherche, paiement, contact.
- Auditer ces parcours seulement, avec les critères RGAA correspondants.
- Corriger les obstacles bloquants avant les défauts cosmétiques.
- Rédiger la déclaration d’accessibilité à partir du résultat réel, sans l’embellir.
- Publier le schéma pluriannuel et le premier plan d’actions.
L’ordre compte. Une déclaration honnête annonçant une non-conformité assumée, accompagnée d’un plan daté, vaut mieux qu’un silence prolongé sur une page d’accueil.
Le réflexe qui change tout se situe encore plus en amont : poser la contrainte au moment où l’idée se transforme en cahier des charges, comme vous le feriez pour valider une idée de produit avant d’écrire la première ligne de code. Prochaine étape concrète : choisir un parcours critique, le traverser au clavier sans souris, et noter chaque point de blocage. Une heure suffit pour obtenir la liste qui structurera les six mois suivants.