Diesen Sommer ist das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft getreten. Im Kern geht es darum, dass möglichst viele Menschen digitale Angebote sinnvoll und komfortabel nutzen können. Gleichzeitig wird für viele Websites Barrierefreiheit zur Pflicht.
Wir haben im letzten Jahr unseren Website-Prozess überarbeitet, um besser mit Barrierefreiheits-Anforderungen umzugehen. Hier haben wir ein paar Ansätze für Projektmanager:innen und Website-Betreiber:innen festgehalten, um selbst in das Projekt barrierefreie Website einzusteigen.
Kurz vorweg: Du bist nicht allein
Natürlich wäre es schöner zu erzählen, dass wir schon immer alles richtig gemacht haben. Stimmt leider nicht – wir haben uns selbst im letzten Jahr ganz gut für ein paar ältere Websites geschämt. Aber von dem Gefühl wollten wir uns nicht dazu bringen lassen, das Thema zur Seite zu schieben. Deshalb zur Motivation eine kleine Statistik für den Zeitraum 2022 bis 2024:
Von 7.230 getesteten Websites aus dem öffentlichen Sektor in Deutschland waren 9 vollständig zugänglich. Kein Angebot erfüllte alle WCAG-Kriterien.
Für die Seiten öffentlicher Stellen gilt, nebenbei bemerkt, schon deutlich länger das Behindertengleichstellungsgesetz (BGG), das ähnliche Vorgaben macht wie das BFSG. Also: Du bist nicht allein – was definitiv kein Grund zur Freude ist. Aber ein Grund mehr, sich auf den Weg zu machen.
Schritt 1: Perspektivwechsel
Die meisten Menschen mit einer Website haben eine ungefähre Vorstellung davon, wer sie wie verwendet. Nutzungsszenarien sind auch ein guter Ansatz, um über Accessibility nachzudenken – wenn man sie um die damit verbundenen Anforderungen erweitert.
Ein praktisches Hilfsmittel können accessibility personas sein, die den Kopf für verschiedene Bedürfnis-Szenarien öffnen. Einen Startpunkt bietet etwa die Sammlung Stories of Web Users der W3C, oder das (schon etwas ältere) Toolkit des Accessibility Teams der britischen Government Digital Services.
Ein erstes Gefühl für die Wahrnehmung einer Website mit unterschiedlichen assistiven Technologien geben die Kurzvideos von Tetralogical. Die Empfehlung stammt aus dem (insgesamt sehr empfehlenswerten) Online-Kurs Practical Accessibility von Sara Soueidan.
Den besten Überblick zum praktischen Umgang mit assistiven Technologien haben natürlich Menschen, die sie im Alltag einsetzen – etwa aus der eigenen Belegschaft. Sie können wichtige Verbündete im Prozess werden, als Expert:innen oder Tester:innen.
Schritt 2: Scope des Projekts
Was muss konkret getan werden? Das ist in unserer Erfahrung der Schritt, in dem sich externe Beratung am meisten lohnt. Leider gibt es Barrierefreiheit nicht “out-of-the-box”. Lösungen wie Overlays oder Widgets führen selbst oft zu neuen Barrieren. Die zentralen Fragen:
- Welche meiner Produkte (oder welche Teile) fallen unter BGG oder BFSG – und welche weiteren sollten sinnvollerweise optimiert werden? Das können neben einer Website selbst beispielsweise auch verlinkte PDF-Dokumente sein. Einen ersten Überblick zum Geltungsbereich der Gesetze gibt es auf der BFSG-Website, hilfreiche Erläuterungen hier von einem Fachanwalt.
- Welche Personen aus dem Team sind von Anpassungen betroffen? Wer baut zum Beispiel Inhalte in eine Website ein oder erstellt digitale Dokumente auf Basis von Vorlagen – und muss entsprechend geschult werden?
- Welche weiteren Gewerke und Dienstleister:innen sind beteiligt – wer kümmert sich um Content, Design und Code und sollte im Prozess einbezogen werden?
Schritt 3: Audit und Maßnahmenkatalog
Jetzt geht es um die Praxis: Was muss konkret entwickelt oder angepasst werden? Maßgeblich für Barrierefreiheit nach BFSG sind die Erfolgskriterien der Web Content Accessibility Guidelines (WCAG). Diese korrekt zu interpretieren setzt aber etwas technisches Know-how voraus.
Einen ersten Eindruck für Schwachstellen einer Website können automatisierte Tests wie die WAVE-Browser-Extension liefern. Diese decken zumindest einen Teil der relevanten Regelungen ab. Wir empfehlen neben automatisierten Tests in jedem Fall manuell mit verschiedenen assistiven Technologien zu testen (zum Beispiel mit den relevantesten Screenreader-/Browser-Kombinationen). Dabei sollten Menschen als Tester:innen einbezogen werden, die selbst im Alltag mit assistiver Technologie arbeiten.
Auf Grundlage eines Audits kann ein konkreter Maßnahmenkatalog entlang der WCAG-Kriterien entwickelt werden – also welche Kriterien nicht erfüllt werden, und wie das Problem behoben werden kann. Wir haben allerdings festgestellt, dass ein iterativer Prozess hier oft effizienter ist: Statt eines großen Audits werden nach jeder Testrunde Fehler direkt behoben – und tauchen dann in Folgetests nicht wieder auf.
Das Team steht, der Auftrag ist klar, dann kann es losgehen. Wir freuen uns, dass du dich auf den Weg machst, um dein digitales Angebot für mehr Menschen zugänglich zu machen.
Falls du bei einem der Schritte Unterstützung brauchst: Schreib uns: info@diebrueder.com