QualiBooth

compliance

UK-Barrierefreiheitsvorschriften: Ein PSBAR-Leitfaden

Ein vollständiger Leitfaden zu den britischen Public Sector Bodies Accessibility Regulations (PSBAR): wer betroffen ist, was verlangt wird, Durchsetzung und Umsetzung.

10 min read QualiBooth
Der Palace of Westminster und Big Ben mit überlagerten leuchtenden Barrierefreiheits-Symbolen, die die britischen PSBAR-Vorschriften darstellen.

Was sind die britischen Public Sector Bodies Accessibility Regulations?

Die Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 — gemeinhin PSBAR, die PSB-Regulations oder einfach „die britischen Barrierefreiheitsvorschriften” genannt — trat im September 2018 in Kraft. Sie setzt die EU-Richtlinie über die Barrierefreiheit von Websites (WAD) in britisches Recht um und gilt auch nach dem Brexit im Rahmen des von Großbritannien übernommenen EU-Rechts weiter.

PSBAR verpflichtet öffentliche Einrichtungen, ihre Websites und mobilen Anwendungen für Menschen mit Behinderungen zugänglich zu machen. Die Konformität wird an den Web Content Accessibility Guidelines (WCAG) 2.1 Level AA gemessen, und alle betroffenen Organisationen müssen eine Erklärung zur Barrierefreiheit veröffentlichen und pflegen.

Wer muss die Vorgaben erfüllen?

PSBAR gilt für öffentliche Einrichtungen im Sinne der Vorschriften. Das ist eine breite Kategorie, die Folgendes umfasst:

  • Zentrale Regierungsministerien und Exekutivbehörden
  • Nicht-ministerielle öffentliche Einrichtungen (NDPBs) und ausgelagerte Stellen
  • Kommunalbehörden und Gemeinderäte
  • NHS-Trusts und Gesundheitseinrichtungen
  • Universitäten und Weiterbildungseinrichtungen (mit gewissen Nuancen)
  • Polizei, Feuerwehr und andere Notdienste
  • Staatlich getragene Schulen und Multi-Academy-Trusts
  • Bibliotheken, Museen und von öffentlichen Einrichtungen betriebene Kultureinrichtungen

Organisationen des Privatsektors fallen nicht unter PSBAR. Wenn jedoch ein privates Unternehmen digitale Dienste im Auftrag einer öffentlichen Einrichtung erbringt — etwa das Online-Zahlungsportal einer Kommune betreibt —, bleibt die öffentliche Einrichtung dafür verantwortlich, dass diese Dienste barrierefrei sind.

Was bedeutet „im Anwendungsbereich” für Inhalte?

Die Vorschriften erfassen alle öffentlich zugänglichen Websites und mobilen Anwendungen, die von öffentlichen Einrichtungen betrieben werden. Dazu zählen auch Intranets und Extranets, sofern sie öffentlich zugänglich sind.

Mehrere Inhaltskategorien sind jedoch ausdrücklich ausgenommen:

  • Office-Dateiformate (PDFs, Word-Dokumente, Tabellenblätter), die vor dem 23. September 2018 veröffentlicht wurden, außer sie werden zur Nutzung eines Dienstes benötigt
  • Vorab aufgezeichnete zeitbasierte Medien (Video, Audio), die vor dem 23. September 2020 veröffentlicht wurden
  • Live-Video (Live-Untertitel sind nicht vorgeschrieben, sollten aber nach bester Praxis wo möglich bereitgestellt werden)
  • Online-Karten — solange wesentliche Navigationsinformationen barrierefrei bereitgestellt werden
  • Inhalte Dritter, die die öffentliche Einrichtung nicht finanziert, entwickelt oder kontrolliert
  • Kulturerbe-Sammlungen und archivierte Inhalte, die ohne unverhältnismäßigen Aufwand nicht barrierefrei gemacht werden können
  • Intranets und Extranets, deren Inhalte vor September 2019 datieren und nicht wesentlich überarbeitet wurden

Die Ausnahme für Alt-Office-Dateien wird häufig missverstanden. Sie gilt für vor dem jeweiligen Stichtag veröffentlichte Dokumente — nicht für alle PDFs überhaupt. Jedes neue Dokument oder jedes bestehende Dokument, das nach dem Stichtag aktualisiert wird, muss den Standard erfüllen.

Der technische Standard: WCAG 2.1 Level AA

PSBAR verlangt Konformität mit WCAG 2.1 Level AA. Dieser vom W3C veröffentlichte Standard umfasst 50 Erfolgskriterien, gegliedert in vier Prinzipien:

Wahrnehmbar — Informationen und UI-Komponenten müssen so darstellbar sein, dass Nutzende sie wahrnehmen können. Wichtige Anforderungen umfassen:

  • Textalternativen für Nicht-Text-Inhalte (Bilder, Icons, Diagramme)
  • Untertitel für Videoinhalte
  • Ausreichenden Farbkontrast (4,5:1 für normalen Text, 3:1 für großen Text und UI-Komponenten)
  • Inhalte, die auf verschiedene Weisen dargestellt werden können, ohne Information zu verlieren

Bedienbar — UI-Komponenten und Navigation müssen bedienbar sein. Wichtige Anforderungen umfassen:

  • Vollständige Tastaturbedienbarkeit — sämtliche Funktionalität muss ohne Maus funktionieren
  • Keine Tastaturfallen
  • Kein Inhalt, der häufiger als dreimal pro Sekunde blinkt
  • Beschreibende Seitentitel, Überschriften und Linktexte
  • Ein sichtbarer Fokusindikator für die Tastaturnavigation

Verständlich — Inhalt und UI müssen verständlich sein. Wichtige Anforderungen umfassen:

  • Im HTML angegebene Sprache (lang-Attribut)
  • Konsistente Navigation und Beschriftung
  • Beschreibende Fehlermeldungen mit Korrekturanweisungen
  • Beschriftungen und Anweisungen für alle Formularfelder

Robust — Inhalte müssen robust genug für die Interpretation durch assistive Technologien sein. Wichtige Anforderungen umfassen:

  • Valides, gut strukturiertes HTML
  • Korrekte Verwendung von ARIA-Rollen, -Zuständen und -Eigenschaften
  • Statusmeldungen, die assistiven Technologien mitgeteilt werden, ohne Fokus zu erfordern

WCAG 2.1 fügte gegenüber WCAG 2.0 17 neue Erfolgskriterien hinzu, mit besonderem Fokus auf Barrierefreiheit auf Mobilgeräten, Sehbehinderung sowie kognitive und Lernbehinderungen. Zu den neuen Kriterien zählen:

  • 1.3.4 Ausrichtung — Inhalte dürfen nicht auf eine einzige Bildschirmausrichtung festgelegt sein
  • 1.3.5 Zweck der Eingabe identifizieren — Formularfelder, die personenbezogene Daten erfassen, müssen Autocomplete-Attribute nutzen
  • 1.4.10 Umfließen (Reflow) — Inhalte müssen bei 320px ohne horizontales Scrollen umfließen
  • 1.4.11 Nicht-Text-Kontrast — UI-Komponenten und grafische Objekte müssen 3:1 Kontrast erreichen
  • 1.4.12 Textabstand — Nutzende müssen den Textabstand anpassen können, ohne Inhalt zu verlieren
  • 1.4.13 Inhalt bei Hover oder Fokus — durch Hover oder Fokus ausgelöste zusätzliche Inhalte müssen schließbar und bestehen bleibend sein
  • 2.5.3 Beschriftung im Namen — der zugängliche Name einer Komponente muss den sichtbaren Textlabel enthalten

Die Pflicht zur Erklärung zur Barrierefreiheit

Eine der markantesten Pflichten von PSBAR — und eine, bei der viele öffentliche Einrichtungen zurückbleiben — ist die verpflichtende Erklärung zur Barrierefreiheit.

Jede betroffene Website und mobile Anwendung muss eine Erklärung zur Barrierefreiheit veröffentlichen, die:

  1. angibt, welchen Standard die Website anstrebt — in der Regel WCAG 2.1 AA
  2. bekannte Barrierefreiheitsprobleme aufführt — konkrete identifizierte, noch nicht gelöste Barrieren, mit einer Beschreibung jeder einzelnen
  3. einen Anspruch auf unverhältnismäßigen Aufwand enthält (falls zutreffend) — eine dokumentierte Begründung, warum bestimmte Inhalte nicht barrierefrei gemacht wurden
  4. einen Feedback-Mechanismus bereitstellt — eine Möglichkeit für Nutzende, die Organisation zu kontaktieren, um Barrieren zu melden oder barrierefreie Alternativen anzufordern
  5. das Durchsetzungsverfahren angibt — Nutzende, die mit der Antwort nicht zufrieden sind, an die zuständige Durchsetzungsstelle verweist
  6. das Überprüfungsdatum zeigt — wann die Erklärung zuletzt aktualisiert wurde

Der Government Digital Service (GDS) veröffentlicht eine Standardvorlage für Erklärungen zur Barrierefreiheit. Öffentliche Einrichtungen werden ermutigt (und in der Praxis erwartet), diese Vorlage oder eine gleichwertige, alle erforderlichen Elemente abdeckende Vorlage zu verwenden.

Häufige Fehler in Erklärungen zur Barrierefreiheit:

  • Behauptung vollständiger WCAG-2.1-AA-Konformität ohne Nachweis
  • Keine bekannten Probleme aufführen, obwohl offensichtlich Probleme bestehen
  • Ein Kontaktmechanismus, der selbst nicht barrierefrei ist
  • Veröffentlichung einer Erklärung, die seit über einem Jahr nicht überprüft wurde
  • Verwendung einer von einer anderen Organisation kopierten generischen Erklärung, ohne sie an die tatsächliche Website anzupassen

Eine Erklärung zur Barrierefreiheit, die die Konformität falsch darstellt, ist nicht nur nicht konform — sie untergräbt das Vertrauen der Nutzenden und schafft ein Reputationsrisiko, wenn die tatsächlichen Barrieren gemeldet werden.

Unverhältnismäßiger Aufwand

PSBAR erlaubt öffentlichen Einrichtungen, für bestimmte Inhalte eine Ausnahme wegen unverhältnismäßigen Aufwands zu beanspruchen, wenn die Kosten oder der Aufwand, sie barrierefrei zu machen, in keinem angemessenen Verhältnis zum Nutzen für Menschen mit Behinderungen stünden. Dies ist keine pauschale Ausnahme und muss auf konkrete, identifizierte Inhalte angewendet werden — nicht auf eine gesamte Website.

Um unverhältnismäßigen Aufwand zu beanspruchen, muss die Organisation:

  1. eine formelle Bewertung durchführen, die die Kosten der Barrierefreiheit gegen den Nutzen für Menschen mit Behinderungen abwägt
  2. die Größe, die Ressourcen und die Art der Inhalte der Organisation berücksichtigen
  3. die Bewertung dokumentieren
  4. den Anspruch in der Erklärung zur Barrierefreiheit angeben und dabei die Inhalte und die Grundlage des Anspruchs benennen
  5. den Anspruch regelmäßig überprüfen

Die GDS-Leitlinien stellen klar, dass unverhältnismäßiger Aufwand nicht genutzt werden darf, um zentrale Nutzerabläufe von der Barrierefreiheit auszunehmen. Ein Anspruch auf unverhältnismäßigen Aufwand für ein Zahlungsformular oder einen Antragsdienst würde nicht als gültig angesehen.

Durchsetzung im Vereinigten Königreich

Die Durchsetzung von PSBAR unterscheidet sich von Barrierefreiheitsklagen in den USA. Das Vereinigte Königreich verfügt über kein privates Klagerecht analog zu ADA Title III für Website-Barrierefreiheit. Stattdessen ist die Durchsetzung um Folgendes strukturiert:

Überwachung durch den Government Digital Service (GDS) — GDS ist für die Überwachung der PSBAR-Konformität öffentlicher Einrichtungen verantwortlich. Er führt stichprobenartige Audits von Websites und mobilen Anwendungen durch und meldet Konformitätsbefunde an die Europäische Kommission (für Berichtszeiträume vor dem Brexit) und nun im Rahmen der von Großbritannien übernommenen Pflichten.

Das Cabinet Office überwacht das gesamte Konformitätsrahmenwerk, einschließlich der Pflicht für Ministerien, Barrierefreiheitspläne vorzuhalten.

Der Equality Act 2010 bietet einen parallelen Weg. Der Equality Act verpflichtet Dienstleister (einschließlich öffentlicher Einrichtungen), für Menschen mit Behinderungen angemessene Vorkehrungen zu treffen. Eine Website des öffentlichen Sektors mit Barrieren, die eine Person mit Behinderung am Zugang zu Dienstleistungen hindert, kann eine rechtswidrige Diskriminierung nach dem Gesetz darstellen. Anders als PSBAR unterstützt der Equality Act individuelle Klagen — Nutzende mit Behinderungen können Fälle vor ein Arbeitsgericht oder ein County Court bringen.

Ofcom übernimmt die Durchsetzung für rundfunkbezogene Anforderungen. Die Financial Conduct Authority (FCA) und andere Branchenregulierer können ebenfalls branchenspezifische Barrierefreiheitserwartungen anwenden.

In der Praxis war die PSBAR-Durchsetzung eher zurückhaltend — GDS veröffentlicht Konformitätsdaten und arbeitet mit Organisationen an Verbesserungen, statt formelle Durchsetzungsmaßnahmen zu verfolgen. Dies verringert jedoch nicht die rechtliche Pflicht, und Ansprüche nach dem Equality Act bleiben ein reales Risiko.

Status nach dem Brexit

PSBAR wurde aus der EU-Richtlinie über die Barrierefreiheit von Websites im Rahmen des European Communities Act in britisches Recht umgesetzt. Nach dem Brexit bleibt sie als britisches innerstaatliches Recht im Rahmen des Retained EU Law (Revocation and Reform) Act 2023 erhalten. Die Vorschriften bleiben vollständig in Kraft; nach dem Brexit ist das Vereinigte Königreich nicht mehr verpflichtet, Aktualisierungen der EU-WAD oder der harmonisierten Norm EN 301 549 zu folgen, doch WCAG 2.1 AA bleibt der anwendbare technische Standard.

Organisationen, die sowohl im Vereinigten Königreich als auch in der EU tätig sind, müssen sowohl PSBAR als auch die einschlägigen Umsetzungen der Web-Zugänglichkeitsrichtlinie in den jeweiligen EU-Mitgliedstaaten erfüllen — die ebenfalls auf WCAG 2.1 AA verweisen, was in der Praxis zu Übereinstimmung führt.

Mobile Anwendungen

PSBAR gilt neben Websites auch für mobile Anwendungen. Von öffentlichen Einrichtungen betriebene mobile Apps müssen:

  • die WCAG-2.1-Level-AA-Erfolgskriterien erfüllen, soweit auf native mobile Apps anwendbar
  • eine Erklärung zur Barrierefreiheit haben (die im Web, innerhalb der App oder im App-Store-Eintrag veröffentlicht werden kann)
  • mit plattformspezifischen Barrierefreiheitsfunktionen kompatibel sein (VoiceOver unter iOS, TalkBack unter Android)

Die Barrierefreiheit von Mobil-Apps wird an EN 301 549 gemessen, die WCAG 2.1 einbezieht und mobilspezifische Anforderungen zu Berührungszielgröße, Ausrichtung und Nutzung von Plattform-APIs hinzufügt.

Ein praktischer Fahrplan zur PSBAR-Konformität

1. Prüfen Sie Ihre aktuelle Konformität

Beginnen Sie mit einer ehrlichen Einschätzung Ihres aktuellen Stands. Automatisierte Scan-Tools können einen erheblichen Teil der WCAG-Verstöße schnell identifizieren — Farbkontrastprobleme, fehlenden Alternativtext, Probleme bei der Formularbeschriftung. Automatisierte Tools erfassen jedoch verlässlich nur 30–40 % der Barrierefreiheitsprobleme. Ein manuelles Barrierefreiheits-Audit mit Screenreadern und reiner Tastaturnavigation ist für ein vollständiges Bild unerlässlich.

2. Priorisieren Sie Ihre Behebungen

Beheben Sie zuerst die Barrieren, die Nutzende am direktesten daran hindern, auf zentrale Dienste zuzugreifen. Für eine Kommunalverwaltung könnte das sein: das Bauantragsportal, das Wohngeldformular, die Kontaktseite und die Hauptnavigation. Behandeln Sie transaktionale Abläufe vor informativen Inhalten.

3. Veröffentlichen Sie eine konforme Erklärung zur Barrierefreiheit

Verwenden Sie die GDS-Vorlage. Seien Sie ehrlich über bekannte Probleme. Stellen Sie einen funktionierenden Kontaktmechanismus bereit. Wenn Sie für einen Inhalt unverhältnismäßigen Aufwand beanspruchen, dokumentieren Sie die Bewertung und geben Sie sie klar an.

4. Beheben und erneut testen

Verifizieren Sie nach jeder Behebung, dass die Korrektur das Problem löst und keine Regressionen eingeführt hat. Das erfordert sowohl automatisiertes erneutes Testen als auch manuelle Verifizierung mit assistiver Technologie.

5. Verankern Sie Barrierefreiheit in Ihrem Veröffentlichungsworkflow

Jede neu veröffentlichte Seite, jedes hochgeladene Dokument, jede ausgerollte Funktion kann neue Barrieren einführen. Schulungen zum Content-Management, Checklisten vor der Veröffentlichung und automatisiertes Scannen im Veröffentlichungsworkflow fangen Probleme ab, bevor sie Nutzende erreichen.

6. Überprüfen Sie Ihre Erklärung zur Barrierefreiheit jährlich

Die Erklärung muss den aktuellen Stand Ihrer Website widerspiegeln. Eine jährliche Überprüfung — kombiniert mit einem erneuten Audit — hält sie akkurat und zeigt fortlaufendes Engagement.

Zusammenfassung

PSBAR ist eine verbindliche rechtliche Pflicht für öffentliche Einrichtungen im Vereinigten Königreich. Sie verlangt WCAG-2.1-Level-AA-Konformität über Websites und mobile Anwendungen hinweg und schreibt für jede betroffene Website eine akkurate, aktuelle Erklärung zur Barrierefreiheit vor.

Die Vorschriften sind keine unverbindliche Empfehlung — sie sind Gesetz, verstärkt durch die Pflicht des Equality Act 2010 zu angemessenen Vorkehrungen. Öffentliche Einrichtungen, die Barrierefreiheit als kontinuierliche Qualitätspraxis behandeln, statt als Häkchen auf einer Konformitätsliste, werden es leichter finden, den Standard zu erfüllen, auf das GDS-Monitoring zu reagieren und die gesamte Bandbreite ihrer Nutzenden zu bedienen.

Wenn Sie eine Website des öffentlichen Sektors betreiben und sich über Ihre aktuelle Konformität unsicher sind, ist ein kostenloser Barrierefreiheits-Scan der schnellste erste Schritt. Für ein vollständiges Audit, das WCAG 2.1 AA und die PSBAR-Anforderungen abbildet, kontaktieren Sie unser Team.

Prüfen Sie die Barrierefreiheit Ihrer Website des öffentlichen Sektors