Réglementation d'accessibilité au Royaume-Uni : guide PSBAR

Qu’est-ce que le PSBAR britannique ?

Les Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 — communément appelées PSBAR, PSB Regulations, ou simplement « la réglementation d’accessibilité britannique » — sont entrées en vigueur en septembre 2018. Elles transposent la directive européenne sur l’accessibilité du web (WAD) dans le droit britannique et continuent de s’appliquer après le Brexit dans le cadre du droit européen retenu par le Royaume-Uni.

Le PSBAR exige que les organismes du secteur public rendent leurs sites web et applications mobiles accessibles aux personnes en situation de handicap. La conformité est mesurée par rapport aux Web Content Accessibility Guidelines (WCAG) 2.1 niveau AA, et toutes les organisations concernées doivent publier et tenir à jour une déclaration d’accessibilité.

Qui doit s’y conformer ?

Le PSBAR s’applique aux organismes du secteur public tels que définis dans la réglementation. Il s’agit d’une catégorie large qui comprend :

Les ministères et agences exécutives du gouvernement central
Les organismes publics non ministériels (NDPB) et organismes déconcentrés
Les collectivités locales et conseils municipaux
Les trusts et organismes de santé du NHS
Les universités et établissements d’enseignement supérieur (avec certaines nuances)
La police, les pompiers et autres services d’urgence
Les écoles publiques et les multi-academy trusts
Les bibliothèques, musées et institutions culturelles gérées par des organismes publics

Les organisations du secteur privé ne sont pas couvertes par le PSBAR. Toutefois, si une entreprise privée fournit des services numériques au nom d’un organisme du secteur public — par exemple en exploitant le portail de paiement en ligne d’une collectivité — l’organisme du secteur public reste responsable de veiller à ce que ces services soient accessibles.

Que signifie « dans le périmètre » pour le contenu ?

La réglementation couvre l’ensemble des sites web et applications mobiles accessibles au public exploités par des organismes du secteur public. Cela inclut les intranets et extranets lorsqu’ils sont accessibles au public.

Cependant, plusieurs catégories de contenu sont explicitement exemptées :

Les formats de fichiers bureautiques (PDF, documents Word, feuilles de calcul) publiés avant le 23 septembre 2018, sauf s’ils sont nécessaires à l’utilisation d’un service
Les médias temporels préenregistrés (vidéo, audio) publiés avant le 23 septembre 2020
La vidéo en direct (les sous-titres en direct ne sont pas obligatoires, bien que la bonne pratique consiste à les fournir lorsque c’est possible)
Les cartes en ligne — à condition que les informations de navigation essentielles soient fournies de manière accessible
Le contenu tiers que l’organisme du secteur public ne finance, ne développe ni ne contrôle
Les collections patrimoniales et le contenu archivé qui ne peut être rendu accessible sans charge disproportionnée
Les intranets et extranets dont le contenu est antérieur à septembre 2019 et n’a pas fait l’objet d’une révision substantielle

L’exemption pour les anciens fichiers bureautiques est fréquemment mal comprise. Elle s’applique aux documents publiés avant la date concernée — pas à tous les PDF sans exception. Tout nouveau document, ou tout document existant mis à jour après la date d’entrée en vigueur, doit respecter la norme.

La norme technique : WCAG 2.1 niveau AA

Le PSBAR exige la conformité au WCAG 2.1 niveau AA. Cette norme, publiée par le W3C, couvre 50 critères de succès organisés autour de quatre principes :

Perceptible — les informations et les composants d’interface doivent pouvoir être présentés de façons que les utilisateurs peuvent percevoir. Exigences clés :

Des alternatives textuelles pour le contenu non textuel (images, icônes, graphiques)
Des sous-titres pour le contenu vidéo
Un contraste de couleur suffisant (4,5:1 pour le texte normal, 3:1 pour le texte large et les composants d’interface)
Un contenu pouvant être présenté de différentes façons sans perte d’information

Utilisable — les composants d’interface et la navigation doivent être utilisables. Exigences clés :

Une accessibilité clavier complète — toutes les fonctionnalités doivent fonctionner sans souris
Aucun piège au clavier
Aucun contenu clignotant plus de trois fois par seconde
Des titres de page, titres de section et textes de lien descriptifs
Un indicateur de focus visible pour la navigation au clavier

Compréhensible — le contenu et l’interface doivent être compréhensibles. Exigences clés :

La langue déclarée dans le HTML (attribut lang)
Une navigation et un étiquetage cohérents
Des messages d’erreur descriptifs avec des instructions de correction
Des étiquettes et instructions pour tous les champs de formulaire

Robuste — le contenu doit être suffisamment robuste pour être interprété par les technologies d’assistance. Exigences clés :

Un HTML valide et bien structuré
Une utilisation correcte des rôles, états et propriétés ARIA
Des messages de statut communiqués aux technologies d’assistance sans nécessiter le focus

Le WCAG 2.1 a ajouté 17 nouveaux critères de succès par rapport au WCAG 2.0, avec un accent particulier sur l’accessibilité mobile, les utilisateurs malvoyants et les handicaps cognitifs et d’apprentissage. Les nouveaux critères comprennent :

1.3.4 Orientation — le contenu ne doit pas être verrouillé à une seule orientation d’écran
1.3.5 Identifier la finalité de la saisie — les champs de formulaire collectant des informations personnelles doivent utiliser des attributs autocomplete
1.4.10 Réorganisation — le contenu doit se réorganiser à 320px sans défilement horizontal
1.4.11 Contraste non textuel — les composants d’interface et objets graphiques doivent respecter un contraste de 3:1
1.4.12 Espacement du texte — les utilisateurs doivent pouvoir ajuster l’espacement du texte sans perte de contenu
1.4.13 Contenu au survol ou au focus — le contenu supplémentaire déclenché par le survol ou le focus doit pouvoir être fermé et rester persistant
2.5.3 Étiquette dans le nom — le nom accessible des composants doit contenir l’étiquette textuelle visible

L’obligation de déclaration d’accessibilité

L’une des obligations les plus distinctives du PSBAR — et l’une de celles où de nombreux organismes du secteur public sont en défaut — est la déclaration d’accessibilité obligatoire.

Chaque site web et application mobile concerné doit publier une déclaration d’accessibilité qui :

Indique quelle norme le site vise à respecter — généralement le WCAG 2.1 AA
Liste les problèmes d’accessibilité connus — les obstacles spécifiques identifiés et non encore résolus, avec une description de chacun
Inclut une revendication de charge disproportionnée (le cas échéant) — une justification documentée expliquant pourquoi certains contenus n’ont pas été rendus accessibles
Fournit un mécanisme de retour — un moyen pour les utilisateurs de contacter l’organisation afin de signaler des obstacles d’accessibilité ou de demander des alternatives accessibles
Indique la procédure d’application — orientant les utilisateurs insatisfaits de la réponse vers l’organisme d’application compétent
Indique la date de révision — la dernière mise à jour de la déclaration

Le Government Digital Service (GDS) publie un modèle standard de déclaration d’accessibilité. Les organismes du secteur public sont encouragés (et en pratique attendus) à utiliser ce modèle ou un modèle couvrant tous les éléments requis.

Erreurs courantes dans les déclarations d’accessibilité :

Revendiquer une conformité totale au WCAG 2.1 AA sans preuve
Ne lister aucun problème connu alors que des problèmes existent manifestement
Fournir un mécanisme de contact qui est lui-même inaccessible
Publier une déclaration qui n’a pas été révisée depuis plus d’un an
Utiliser une déclaration générique copiée d’une autre organisation sans l’adapter au site réel

Une déclaration d’accessibilité qui présente de manière inexacte la conformité n’est pas seulement non conforme — elle mine la confiance des utilisateurs et crée un risque réputationnel lorsque les obstacles réels sont signalés.

Charge disproportionnée

Le PSBAR permet aux organismes du secteur public de revendiquer une exemption de charge disproportionnée pour un contenu spécifique lorsque le coût ou l’effort de le rendre accessible serait disproportionné par rapport au bénéfice pour les utilisateurs en situation de handicap. Il ne s’agit pas d’une exemption générale et elle doit s’appliquer à un contenu spécifique et identifié — pas à un site entier.

Pour revendiquer une charge disproportionnée, l’organisation doit :

Réaliser une évaluation formelle pesant les coûts de la mise en accessibilité par rapport au bénéfice pour les utilisateurs en situation de handicap
Prendre en compte la taille de l’organisation, ses ressources, et la nature du contenu
Documenter l’évaluation
Formuler la revendication dans la déclaration d’accessibilité, en identifiant le contenu et le fondement de la revendication
Réviser périodiquement la revendication

Les directives du GDS sont claires : la charge disproportionnée ne peut pas être utilisée pour éviter de rendre accessibles les parcours utilisateurs essentiels. Revendiquer une charge disproportionnée pour un formulaire de paiement ou une demande de service ne serait pas considéré comme valide.

L’application au Royaume-Uni

L’application du PSBAR est gérée différemment du contentieux d’accessibilité aux États-Unis. Le Royaume-Uni ne dispose pas d’un droit d’action privé analogue au Titre III de l’ADA pour l’accessibilité des sites web. L’application est plutôt structurée autour de :

La surveillance du Government Digital Service (GDS) — le GDS est responsable de la surveillance de la conformité des organismes du secteur public au PSBAR. Il mène des audits par échantillonnage des sites web et applications mobiles, et rend compte des constats de conformité à la Commission européenne (pour les périodes de reporting antérieures au Brexit) et désormais dans le cadre des obligations retenues par le Royaume-Uni.

Le Cabinet Office supervise le cadre de conformité global, y compris l’exigence pour les ministères de disposer de plans d’accessibilité.

L’Equality Act 2010 offre une voie parallèle. L’Equality Act exige que les prestataires de services (y compris les organismes du secteur public) procèdent à des aménagements raisonnables pour les personnes en situation de handicap. Un site web du secteur public présentant des obstacles d’accessibilité qui empêchent une personne en situation de handicap d’accéder à des services peut constituer une discrimination illégale au titre de cette loi. Contrairement au PSBAR, l’Equality Act permet des recours individuels — les utilisateurs en situation de handicap peuvent saisir un tribunal du travail ou une county court.

L’Ofcom gère l’application des exigences liées à la radiodiffusion. La Financial Conduct Authority (FCA) et d’autres régulateurs sectoriels peuvent également appliquer des attentes d’accessibilité spécifiques à leur secteur.

En pratique, l’application du PSBAR a été relativement légère — le GDS publie des données de conformité et travaille avec les organisations pour qu’elles progressent, plutôt que d’engager une action formelle. Cela ne réduit toutefois pas l’obligation légale, et les recours au titre de l’Equality Act restent un risque réel.

Statut post-Brexit

Le PSBAR a été transposé à partir de la directive européenne sur l’accessibilité du web dans le cadre de l’European Communities Act. Après le Brexit, il est retenu en tant que droit interne britannique au titre du Retained EU Law (Revocation and Reform) Act 2023. La réglementation reste pleinement en vigueur ; après le Brexit, le Royaume-Uni n’est plus tenu de suivre les mises à jour de la directive européenne WAD ou de la norme harmonisée EN 301 549, mais le WCAG 2.1 AA reste la norme technique applicable.

Les organisations opérant à la fois au Royaume-Uni et dans l’UE doivent se conformer à la fois au PSBAR et aux transpositions nationales pertinentes de la directive sur l’accessibilité du web dans les États membres de l’UE — qui font également référence au WCAG 2.1 AA, créant un alignement en pratique.

Applications mobiles

Le PSBAR s’applique aux applications mobiles autant qu’aux sites web. Les applications mobiles exploitées par des organismes du secteur public doivent :

Respecter les critères de succès WCAG 2.1 niveau AA applicables aux applications mobiles natives
Disposer d’une déclaration d’accessibilité (qui peut être publiée sur le web, dans l’application, ou dans la fiche de l’application sur la boutique)
Être compatibles avec les fonctionnalités d’accessibilité de la plateforme (VoiceOver sur iOS, TalkBack sur Android)

L’accessibilité mobile est évaluée par rapport à la norme EN 301 549, qui incorpore le WCAG 2.1 et ajoute des exigences spécifiques au mobile concernant la taille des cibles tactiles, l’orientation, et l’utilisation des API de la plateforme.

Une feuille de route pratique de mise en conformité PSBAR

1. Auditez votre conformité actuelle

Commencez par une évaluation honnête de votre situation. Les outils d’analyse automatisée peuvent identifier rapidement une part importante des défaillances WCAG — problèmes de contraste de couleur, texte alternatif manquant, problèmes d’étiquetage de formulaire. Mais les outils automatisés ne détectent de manière fiable que 30 à 40 % des problèmes d’accessibilité. Un audit manuel d’accessibilité utilisant des lecteurs d’écran et une navigation uniquement au clavier est essentiel pour obtenir une image complète.

2. Priorisez vos corrections

Corrigez en premier les obstacles qui empêchent le plus directement les utilisateurs d’accéder aux services essentiels. Pour une collectivité locale, cela peut être : le portail de demande d’urbanisme, le formulaire d’aide au logement, la page de contact, et la navigation principale. Traitez les parcours transactionnels avant le contenu informationnel.

3. Publiez une déclaration d’accessibilité conforme

Utilisez le modèle du GDS. Soyez honnête sur les problèmes connus. Fournissez un mécanisme de contact fonctionnel. Si vous revendiquez une charge disproportionnée pour un contenu, documentez l’évaluation et formulez-la clairement.

4. Corrigez et retestez

Après chaque correction, vérifiez qu’elle résout bien le problème et n’a introduit aucune régression. Cela nécessite à la fois un nouveau test automatisé et une vérification manuelle avec une technologie d’assistance.

5. Intégrez l’accessibilité dans votre flux de publication

Chaque nouvelle page publiée, chaque document téléversé, chaque fonctionnalité déployée peut introduire de nouveaux obstacles. La formation à la gestion de contenu, les checklists avant publication, et l’analyse automatisée intégrée au flux de publication permettent de détecter les problèmes avant qu’ils n’atteignent les utilisateurs.

6. Révisez votre déclaration d’accessibilité chaque année

La déclaration doit refléter l’état actuel de votre site. Une révision annuelle — combinée à un nouvel audit — la maintient exacte et démontre un engagement continu.

Résumé

Le PSBAR constitue une obligation légale contraignante pour les organismes du secteur public britanniques. Il exige une conformité WCAG 2.1 niveau AA pour les sites web et applications mobiles, et impose une déclaration d’accessibilité exacte et à jour pour chaque site concerné.

La réglementation n’est pas une orientation aspirationnelle — c’est une loi, renforcée par l’obligation d’aménagement raisonnable de l’Equality Act 2010. Les organismes du secteur public qui traitent l’accessibilité comme une pratique de qualité continue, plutôt qu’une case de conformité à cocher, trouveront plus facile de respecter la norme, de répondre à la surveillance du GDS, et de servir l’ensemble de leurs utilisateurs.

Si vous exploitez un site du secteur public et n’êtes pas sûr de votre position de conformité actuelle, une analyse d’accessibilité gratuite est la première étape la plus rapide. Pour un audit complet mappé au WCAG 2.1 AA et aux exigences du PSBAR, contactez notre équipe.