Barrierefreie-Informationstechnik-Verordnung (BITV 2.0)

• Nationale Entwicklung der BITV: Die erste Fassung der Barrierefreie-Informationstechnik-Verordnung wurde 2002 kurz nach Inkrafttreten des BGG erlassen. Damals griff man die gerade veröffentlichten internationalen Web Content Accessibility Guidelines in Version 1.0 (WCAG 1.0 von 1999) auf und legte sie als Maßstab für Barrierefreiheit fest. Die BITV 1.0 war allerdings in ihrem Anwendungsbereich begrenzt und zunächst nicht unmittelbar verbindlich für alle Webauftritte der Bundesbehörden – die tatsächliche Umsetzung erfolgte schrittweise und wurde Ende 2003 für bestimmte Angebote verpflichtend. Mit der rasanten technischen Weiterentwicklung des Webs und neuen Versionen der WCAG (WCAG 2.0 wurde 2008 veröffentlicht) wurde eine Überarbeitung nötig. 2011 trat schließlich die grundlegende Neufassung als BITV 2.0 in Kraft. Diese Version bezog sich inhaltlich auf die Prinzipien und Erfolgskriterien der WCAG 2.0 und übernahm deren Schwerpunkt auf moderne Web-Technologien, Layout und Interaktionen. Die Anforderungen wurden in der Verordnung in Form von Anhängen konkret aufgelistet – unterteilt nach Priorität I (entspricht im Wesentlichen WCAG-Stufe A) und Priorität II (WCAG-Stufe AA). Damit wurde ein gestufter Standard eingeführt: „Muss“-Kriterien (Priorität I) und „Sollte“-Kriterien (Priorität II), wobei grundsätzlich alle Priorität-II-Anforderungen ebenfalls zu erfüllen waren, sofern kein unverhältnismäßiger Aufwand entgegenstand. In den Folgejahren floss praktische Erfahrung und Feedback von Behindertenverbänden in die weitere Entwicklung ein. Zudem nahm Deutschland verstärkt internationale Impulse auf: Die UN-Behindertenrechtskonvention (UN-BRK), die hierzulande seit 2009 gilt, betont in Art. 9 die Bedeutung der barrierefreien Informations- und Kommunikationstechnologie. Die Bundesregierung initiierte einen Nationalen Aktionsplan zur Umsetzung der UN-BRK, in dessen Rahmen eine Evaluation des BGG vorgenommen wurde. Dies führte 2016 zur Novellierung des BGG („Gesetz zur Weiterentwicklung des Behindertengleichstellungsrechts“), um weitere Fortschritte bei der Barrierefreiheit zu erzielen. Im Zuge dieser Novelle wurde u.a. der Behinderungsbegriff modernisiert und das Konzept der angemessenen Vorkehrungen aus der UN-BRK ausdrücklich ins BGG aufgenommen. Wichtig war auch die Stärkung der Leichten Sprache: Behörden des Bundes wurden verpflichtet, auf Anforderung Informationen in Leichter Sprache bereitzustellen. Ferner schuf man mit § 13 BGG die Bundesfachstelle für Barrierefreiheit, die als Beratungsstelle die Behörden bei der Umsetzung von Barrierefreiheit unterstützt und auch bei freiwilligen Zielvereinbarungen mitwirken kann. Schließlich wurde mit § 16 BGG ein Schlichtungsverfahren etabliert, das es Menschen mit Behinderungen ermöglicht, Streitigkeiten über fehlende Barrierefreiheit außergerichtlich zu lösen (dazu später mehr). Die BITV 2.0 profitierte von diesen Änderungen indirekt, da das Bewusstsein für Barrierefreiheit wuchs und die rechtlichen Strukturen für ihre Durchsetzung verbessert wurden.

• Europarechtliche Vorgaben (EU-Webseitenrichtlinie 2016): Ein maßgeblicher externer Impuls für die Weiterentwicklung der BITV war die Verabschiedung der EU-Richtlinie 2016/2102 über den barrierefreien Zugang zu Websites und mobilen Anwendungen öffentlicher Stellen. Diese Richtlinie gab einen EU-weiten Mindeststandard für die Web-Barrierefreiheit im öffentlichen Sektor vor. Sie musste bis September 2018 in nationales Recht umgesetzt werden. Deutschland kam dieser Verpflichtung nach, indem es 2018 das BGG erneut änderte und anschließend die BITV 2.0 im Jahr 2019 aktualisierte. Die Novelle der BITV 2.0, die am 25.

• Dynamische Verweisung auf harmonisierte Normen: Anstatt starre Prüfkriterien in Anhängen aufzuführen, verweist die neue BITV 2.0 jetzt auf die jeweils einschlägigen harmonisierten europäischen Normen. Konkret bedeutet dies, dass die technischen Anforderungen an die Barrierefreiheit sich an der Norm EN 301 549 orientieren. Diese europäische Norm beinhaltet die WCAG 2.1 in den für Webinhalte relevanten Teilen (Kapitel 9 der EN 301 549 entspricht WCAG 2.1 Level AA). Durch diese Verweisung stellen BITV 2.0 und BGG sicher, dass immer der aktuelle Stand der Technik maßgeblich ist, ohne jede Aktualisierung im Detail nachziehen zu müssen. So wurde z.B. die im Juni 2018 erschienene WCAG 2.1 durch die EN 301 549 automatisch Teil der deutschen Anforderungen, obwohl die BITV formal weiterhin „WCAG 2.0“ erwähnt – die harmonisierte Norm überlagert dies mit WCAG 2.1. Der deutsche Gesetzgeber dokumentierte diese Änderung in der Verordnungsbegründung, um Klarheit zu schaffen (siehe Bekanntmachung der Begründung zur Verordnung zur Änderung der BITV im Bundesanzeiger).

• Barrierefreiheitserklärung und Feedback-Mechanismus: Gemäß der EU-Richtlinie muss jede betroffene Website eine Erklärung zur Barrierefreiheit veröffentlichen, in der der Stand der Zugänglichkeit dargelegt wird. Die BITV 2.0 verlangt daher nun, dass bis spätestens 23. September 2020 (bzw. 2019 für neuere Websites) eine solche Erklärung auf den Webseiten bereitgestellt wurde. Zudem muss diese Erklärung regelmäßig – mindestens jährlich – aktualisiert werden. Ein weiterer neuer Aspekt ist der Feedback-Mechanismus: Nutzer sollen eine einfache Möglichkeit haben, der öffentlichen Stelle Mängel in der Barrierefreiheit mitzuteilen oder barrierefreie Inhalte anzufragen. § 7 Abs. 2 BITV 2.0 in der Fassung 2019 verpflichtet die Einrichtungen, eine Kontaktoption anzugeben, über die Nutzer direkt Rückmeldung geben können, falls bestimmte Inhalte nicht barrierefrei sind. Diese Rückmeldungen müssen innerhalb angemessener Frist beantwortet werden. Der Feedback-Mechanismus stellt sicher, dass Probleme nicht im luftleeren Raum bleiben, sondern die verantwortliche Stelle direkt erreichen.

• Gebärdensprache und Leichte Sprache: Eine besondere Anforderung in Deutschland – die über die EU-Mindeststandards hinausgeht – ist die Pflicht, wesentliche Informationen auch in Deutscher Gebärdensprache (DGS) und in Leichter Sprache anzubieten. Bereits die ursprüngliche BITV (2002) enthielt einen Hinweis auf “Inhalte in Gebärdensprache und in leichter Sprache”, doch erst mit der Zeit und der Verankerung der Leichten Sprache im BGG 2016 wurde dies konkretisiert. Die aktualisierte BITV 2.0 schreibt nun vor, dass die Erklärung zur Barrierefreiheit selbst in DGS und Leichter Sprache verfügbar sein muss. Praktisch bedeutet dies: Auf der Startseite (und jeder Unterseite, z.B. im Footer) soll ein Link zu Informationen in Gebärdensprache und Leichter Sprache bereitgestellt werden. In der Regel stellen Behörden hierfür ein kurzes Video in Gebärdensprache bereit, das die Funktion der Website und die wichtigsten Inhalte erklärt, sowie einen Text in leicht verständlicher Sprache mit denselben Informationen. Damit wird dem Personenkreis der gehörlosen Menschen und der Menschen mit Lernschwierigkeiten ein wichtiger Zugang eröffnet. Diese Vorgabe geht über WCAG 2.1 AA hinaus (dort ist leichte Sprache lediglich ein AAA-Kriterium, und Gebärdensprache gar nicht ausdrücklich gefordert). Deutschland hat damit bewusst einen höheren Standard gesetzt, um kommunikative Barrieren abzubauen und der Verpflichtung aus Art. 9 UN-BRK gerecht zu werden.

• Erweiterter Anwendungsbereich: Schon vor der EU-Richtlinie hatte die BITV 2.0 Websites, grafische Programmoberflächen und elektronische Verwaltungsabläufe erfasst. Die EU-Vorgaben präzisierten zusätzlich, dass auch mobile Anwendungen (Apps) der Behörden barrierefrei gestaltet werden müssen. Dies hat Deutschland eins-zu-eins übernommen. Ebenso wurden bislang ausgenommene Bereiche – etwa Extranets und Intranets – nachgezogen: Seit der BGG-Novelle 2018/2019 unterliegen nun auch interne Websites (Intranet) und extranetartige Angebote (z.B. passwortgeschützte Portale für bestimmte Nutzergruppen) der Barrierefreiheitsverpflichtung, sofern sie nach dem Stichtag 23. September 2019 neu eingeführt oder grundlegend überarbeitet wurden. Ältere Intranets blieben noch ausgenommen, solange sie unverändert blieben, aber bei Aktualisierung greift die Pflicht. Insgesamt hat sich der Geltungsbereich durch die EU-Regelung also erweitert und klarer definiert.

• Ausnahmen und „unverhältnismäßige Belastung“: Die EU-Webseitenrichtlinie erlaubt den Mitgliedstaaten, bestimmte Inhalte von den Barrierefreiheitsanforderungen auszunehmen, z.B. Archiv-Inhalte (älteres nicht mehr benötigtes Material), Live-Videos, Online-Karten, Drittinhalte, die nicht vom Anbieter selbst finanziert oder kontrolliert sind, etc. Deutschland hat diese Ausnahmen in der BITV 2.0 aufgeführt. So müssen z.B. Videos, die live gestreamt werden, nicht live untertitelt werden (ein Archivvideo hingegen schon mit Untertiteln versehen innerhalb einer Frist). PDF-Dokumente, die vor 2018 veröffentlicht wurden und für aktuelle Service-Angebote nicht benötigt werden, können ebenfalls ausgenommen sein. Wichtig ist auch der Grundsatz der unverhältnismäßigen Belastung (“undue burden”): Wenn eine öffentliche Stelle nachweisen kann, dass die vollständige Barrierefreiheit in einem bestimmten Punkt mit unverhältnismäßig großem Aufwand oder Kosten verbunden wäre, darf sie hiervon abweichen – muss dies aber in der Erklärung zur Barrierefreiheit begründen. Dieser Mechanismus verhindert, dass kleine Behörden oder sehr ressourcenintensive Spezialfälle (z.B. komplexe datenbankgestützte ältere Anwendungen) rein formal wegen Nichterfüllung einzelner Kriterien sofort rechtswidrig sind. Allerdings wird die Hürde, Unverhältnismäßigkeit geltend zu machen, relativ hoch gelegt und unterliegt ebenfalls der Kontrolle (durch Monitoring-Stellen und ggf. die Schlichtungsstelle).

Es steht die BITV 2.0 heute in engem Zusammenhang mit internationalen Standards und EU-rechtlichen Vorgaben. Sie bildet das Bindeglied zwischen den WCAG (dem fachlichen Standard) und der rechtlichen Verpflichtung zur Barrierefreiheit in Deutschland. Die Normadressaten – primär öffentliche Stellen des Bundes – werden verpflichtet, den jeweils aktuellen Stand der Technik (WCAG 2.1 Level AA gemäß EN 301 549) umzusetzen. Gleichzeitig betont die Verordnung nationale Akzente wie Gebärdensprache und Leichte Sprache, die aus der hiesigen Rechtskultur und dem Einfluss der UN-BRK resultieren.

Die BITV 2.0 lässt sich inhaltlich entlang der vier grundlegenden Prinzipien der Barrierefreiheit strukturieren: Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit. Diese Prinzipien stammen aus den WCAG 2.0/2.1 und bilden das konzeptionelle Gerüst, dem die konkreten Anforderungen zugeordnet sind.

• Wahrnehmbarkeit (Perceivability): Informationen und Benutzeroberflächen-Komponenten müssen für alle Sinne wahrnehmbar sein, d.h. es muss alternative Darstellungsformen geben, wenn ein Sinn ausfällt. Zentral ist hier die Bereitstellung von Textäquivalenten für Nicht-Text-Inhalte. Konkret muss jede bedeutungstragende Grafik oder Bild mit einem aussagekräftigen Alternativtext (Alt-Attribut) versehen sein. Ein blinder Nutzer soll durch seinen Screenreader vermittelt bekommen, was ein Bild darstellt oder welche Funktion es hat. Ähnliches gilt für Bedienelemente mit grafischer Beschriftung (Icons, Buttons): diese benötigen textliche Labels oder ARIA-Labels, damit sie wahrgenommen werden können. Für Video- und Audioinhalte verlangt die BITV 2.0 (in Umsetzung der WCAG 2.1 AA) zum Beispiel Untertitel für Videos mit Ton sowie Transkriptionen oder Audiodeskriptionen, sofern es sich nicht um live gestreamte Medien handelt. Farben dürfen nicht der alleinige Informationsträger sein – etwa Hinweise "rot markiert" müssen zusätzlich für farbenblinde erkennbar gemacht werden. Kontrastanforderungen: Texte und grafische Elemente müssen einen ausreichend hohen Kontrast zum Hintergrund aufweisen (mindestens 4,5:1 für normalen Text), um von sehschwachen Personen gelesen werden zu können. Die BITV fordert damit die Einhaltung internationaler Kontraststandards, was z.B. die Prüfung mit Kontrastmess-Werkzeugen einschließt. Inhalte müssen auch vergrößerbar sein: Der Benutzer soll die Schriftgrößen auf 200% skalieren können, ohne dass Inhalte abgeschnitten oder unlesbar werden. All dies dient der Wahrnehmbarkeit für unterschiedliche Sinnesfähigkeiten. In der Praxis bedeutet dies für Webangebote, dass Entwickler bei jedem Nicht-Text-Element prüfen müssen: Wie kann dieser Inhalt alternativ bereitgestellt werden (etwa Bildbeschreibung)? – und Gestalter müssen Farbschemata und Layouts so wählen, dass genug Kontrast und Flexibilität besteht.

• Bedienbarkeit (Operability): Nutzer müssen die Website und alle ihre Funktionen bedienen können, unabhängig davon, ob sie eine Maus verwenden können oder nicht. Insbesondere ist die Tastatur-Zugänglichkeit ein zentrales Kriterium: Sämtliche interaktiven Elemente (Links, Buttons, Formulareingabefelder, Menüs usw.) müssen über die Tastatur erreichbar und steuerbar sein. Dies ist relevant für Personen, die keine Maus nutzen können (z.B. sehbehinderte oder motorisch eingeschränkte Menschen, die per Tastatur oder alternativen Eingabegeräten navigieren). Die BITV 2.0 schreibt daher vor, dass kein Bedienelement einen sogenannten Tastaturfokus ausschließt. Auch versteckte Funktionen (z.B. sich erst bei Hover öffnende Menüs) müssen per Tastatur zugänglich gemacht werden. Ergänzend sind Mechanismen wie ein „Skip-Link“ vorgeschrieben: Ein Sprunglink „Zum Inhalt“ am Seitenanfang ermöglicht es Tastaturnutzern, die umfangreichen Navigationsmenüs zu überspringen und direkt zum Hauptinhalt zu springen. Dies verbessert die Bedienbarkeit erheblich, wie auch die BITV anerkennt. Weiterhin müssen Zeitbegrenzungen (etwa automatische Logout-Timer) anpassbar oder abschaltbar sein, damit langsamere Nutzer nicht benachteiligt werden. Inhalte, die sich bewegen, blinken oder automatisch aktualisieren (wie Slider, Autoscroll-Text, etc.) müssen pausierbar sein, um nicht vom Nutzererlebnis abzulenken oder Personen mit kognitiven Beeinträchtigungen zu überfordern. Ein oft übersehenes Detail: Die Fokusmarkierung – wenn man mit Tab durch die Seite geht, muss der aktuell fokussierte Link oder Button visuell hervorgehoben sein. Das erleichtert nicht nur die Orientierung (z.B. durch einen sichtbaren Rahmen oder Farbhighlight), sondern ist auch eine BITV-Anforderung. Die Verordnung verlangt also eine bewusste Gestaltung der Tastatur-Navigation. Für Websites bedeutet dies u.a., dass bei Verwendung von Skripten für Menüs oder Dialogfenster immer darauf geachtet werden muss, dass diese per Tab steuerbar sind und der Fokus nicht „steckenbleibt“ (kein Keyboard-Trap). Entwickler greifen hier oft auf ARIA-Attribute und JS-Event-Handling zurück, um komplexe Widgets tastaturfreundlich zu gestalten.

• Verständlichkeit (Understandability): Inhalte und Bedienung müssen verständlich sein. Dies hat verschiedene Facetten: Zum einen die sprachliche Verständlichkeit – Texte sollten möglichst klar und einfach formuliert sein. Für Behördenwebseiten ist hier die Leichte Sprache ein wichtiges Element, allerdings betrifft das oft separate Angebote. Auf regulären Webseiten sollte zumindest die Alltagssprache barrierearm sein (Vermeidung von unnötig komplizierten Formulierungen, Abkürzungen erklären etc.). Zum anderen geht es um die Vorhersehbarkeit und Konsistenz der Bedienung: Die Navigation und Seitenstruktur sollten konsistent sein, damit sich Nutzer nicht neu orientieren müssen. Wiederkehrende Bedienelemente (z.B. Suchfeld, Menü) sollen auf allen Seiten an derselben Stelle und in gleicher Weise funktionieren (Stichwort konsistente Navigation). Formulare müssen klar beschriftet sein: Eingabefelder benötigen deutliche Labels oder Hilfetexte, damit der Nutzer weiß, welche Information einzutragen ist. Platzhaltertexte allein genügen in der Regel nicht, da sie verschwinden, sobald man zu tippen beginnt – daher fordern die Standards explizite Beschriftungen (ggf. versteckt für Screenreader). Fehlermeldungen sollten eindeutig beschreiben, was falsch war und idealerweise einen Korrekturvorschlag bieten. Die BITV 2.0 legt Wert darauf, dass Fehleingaben barrierefrei kommuniziert werden – z.B. nicht nur farblich rot markieren (für farbenblinde unkenntlich), sondern auch durch Text oder Symbole mit Textalternative kennzeichnen. Darüber hinaus ist die Sprungziel-Verständlichkeit wichtig: Linktexte sollen selbsterklärend sein – „hier klicken“ ist unzureichend; besser „Details zum Programm anzeigen“. Insgesamt zielt dieses Prinzip darauf ab, die Seite so zu gestalten, dass Benutzerführung intuitiv und die Informationserfassung möglichst einfach ist. Ein besonderer Aspekt der Verständlichkeit ist die sprachliche Anpassung an Nutzerbedürfnisse. Hier spielt die Pflicht, Inhalte in Gebärdensprache und Leichter Sprache anzubieten, eine große Rolle. Die BITV 2.0 verankert im deutschen Kontext diese Anforderungen, um die Verständlichkeit für Menschen mit kognitiven Einschränkungen (Leichte Sprache) und für Gehörlose (Gebärdensprache) zu verbessern. So muss z.B. die Erklärung zur Barrierefreiheit selbst leicht verständlich erklären, wo es ggf. noch Probleme gibt und an wen man sich wenden kann. Auch wenn die gesamte Website nicht in Leichter Sprache verfasst sein muss, gilt doch: je klarer die Sprache, desto eher wird sie den Barrierefreiheitsgeboten gerecht (WCAG 2.1 sieht “einfache Sprache” als AAA-Kriterium, aber die BITV fördert dies indirekt durch die Schaffung entsprechender Angebote).

• Robustheit (Robustness): Inhalte müssen so robust und technisch sauber umgesetzt sein, dass sie von unterschiedlichen Ausgabegeräten und Assistenztechnologien zuverlässig interpretiert werden können. Das bedeutet im Kern standardkonformes HTML/CSS – der Code darf keine gravierenden Fehler enthalten, die z.B. Screenreader aus dem Tritt bringen könnten. Jede interaktive Komponente muss für Technologien wie Screenreader, Screenreader-Modi, Spracherkennungssoftware etc. “verständlich” sein, indem Name, Rolle und Wert der Elemente maschinenlesbar hinterlegt sind. Beispielsweise soll ein Screenreader erkennen können, dass ein Element ein Menü ist, welche Einträge es hat und welcher gerade ausgewählt ist. Dafür kommen ARIA-Rollen und -Attribute zum Einsatz, wenn natives HTML nicht ausreicht. Ein einfaches Beispiel: Hat man einen selbstprogrammierten Tab-Reiter, muss man ARIA-Tabs und ARIA-selected entsprechend setzen, damit ein Screenreader-Nutzer versteht, welche Registerkarte aktiv ist. Robustheit bedeutet auch Kompatibilität mit verschiedenen Browsern und Geräten: Eine barrierefreie Website sollte in unterschiedlichen Umgebungen (mobile Devices, verschiedene Browser, mit/ohne CSS usw.) noch zugänglich sein. Außerdem darf sie keine Technologien verwenden, die pauschal unzugänglich sind – z.B. Captchas ohne barrierefreie Alternative, oder PDF-Dokumente, die nicht PDF/UA-konform sind. Die BITV verlangt demnach implizit auch barrierefreie Dokumente: Wenn PDFs oder andere Download-Dokumente auf der Website angeboten werden, müssen auch diese in einer zugänglichen Form vorliegen (oder es muss zumindest eine barrierefreie Alternative auf Anfrage bereitgestellt werden). Im Sinne der Robustheit wird auch gefordert, dass die Programmierlogik keine Barrieren aufbaut: z.B. soll ein Link, der per JavaScript generiert wird, auch ohne JavaScript erreichbar sein (oder ein Fallback vorhanden sein). Insgesamt ist Robustheit ein eher technisch orientiertes Prinzip, das gewährleistet, dass die schöne Theorie barrierefreier Inhalte in der Praxis auch ankommt – nämlich “in as many user agents as possible”, wie es die WCAG formuliert.

Über diese vier Prinzipien und die ihnen zugeordneten Erfolgskriterien hinaus sind in der BITV 2.0 einige transversale Pflichten festgehalten: Die bereits erwähnte Erklärung zur Barrierefreiheit ist Pflichtbestandteil jeder Website einer öffentlichen Stelle. Darin muss (in deutscher Sprache) der Erfüllungsstand (kompatibel zu EN 301 549/WCAG 2.1 AA) angegeben sein: z.B. “Diese Website ist teilweise barrierefrei. Nicht barrierefrei sind folgende Inhalte: …”. Es müssen die konkreten Ausnahmen oder noch bestehenden Mängel benannt werden. Außerdem enthält die Erklärung die Kontaktmöglichkeit für Nutzerfeedback (E-Mail oder Kontaktformular) und den Hinweis auf die Schlichtungsstelle für den Fall, dass die Antwort unbefriedigend ist. Diese Erklärung selbst, wie oben erwähnt, muss auch in Gebärdensprache und Leichter Sprache zur Verfügung stehen – allerdings beschränkt sich das auf die “wesentlichen Inhalte” der Erklärung, nicht die gesamte Website. Üblich ist es, dass Behörden zwei zusätzliche Seiten anbieten: eine Leichte-Sprache-Seite („Erklärung zur Barrierefreiheit in Leichter Sprache“) und eine DGS-Seite (ein eingebettetes Video mit Übersetzung der Erklärung in Gebärdensprache). Beide sollten von der normalen Erklärung aus und von jeder Seite (über Footer-Links) erreichbar sein. Schließlich sieht die BITV 2.0 auch eine Monitoring- und Berichtspflicht vor (entsprechend der EU-Richtlinie). Die Mitgliedstaaten müssen regelmäßig stichprobenartig Websites und Apps überprüfen und der EU-Kommission Bericht erstatten. In Deutschland übernimmt dies auf Bundesebene z.B. die Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik (BFIT-Bund) gemeinsam mit der Bundesfachstelle. Für die betroffenen Stellen bedeutet dies, dass sie damit rechnen müssen, dass ihre Angebote geprüft werden – was einen zusätzlichen Anreiz zur Einhaltung der BITV-Vorgaben schafft. Es schreibt die BITV 2.0 also vor, dass öffentliche Websites und Apps barrierefrei im Sinne von WCAG 2.1 AA sein müssen, ergänzt um national spezielle Anforderungen wie Gebärdensprach- und Leichtsprach-Angebote. Durch die Verweisung auf EN 301 549 ist klargestellt, dass sowohl Websites als auch mobile Anwendungen, elektronische Dokumente und Software-Oberflächen den jeweils einschlägigen technischen Standards genügen müssen. Praktisch orientieren sich Entwickler und Prüfer in Deutschland meist am sogenannten “BITV-Test”, einem Prüfraster (entwickelt z.B. vom Projekt BIK – Barrierefrei Informieren und Kommunizieren), das die WCAG-Kriterien in ca. 60 Prüfschritten operationalisiert. Dieser Test dient vielen öffentlichen Stellen als Grundlage, um ihre Websites vor Veröffentlichung oder im Betrieb auf Konformität zu überprüfen. Er ist zwar kein rechtlicher Text, aber eng mit BITV 2.0 verknüpft und wird hier teilweise herangezogen, um die Anwendung der Verordnung auf konkrete Websites zu veranschaulichen.

Die praktische Umsetzung der BITV 2.0 auf Websites erfordert ein interdisziplinäres Vorgehen: Webentwickler, Designer, Redakteure und Qualitätssicherer müssen zusammenwirken, um die zahlreichen Anforderungen zu erfüllen. Im Folgenden werden wichtige Aspekte der Anwendung auf Websites beleuchtet – von Planungsfragen über Entwicklungspraktiken bis hin zur Evaluation des Ergebnisses.

• Planung und Konzeption: Bereits bei der Konzeption einer Website sollten Barrierefreiheitsaspekte berücksichtigt werden (“barrierefrei by design”). Dies beginnt mit der Entscheidung für ein Content-Management-System (CMS) oder Web-Framework, das Accessibility unterstützt. Viele moderne CMS bieten z.B. eingebaute Funktionen für zugängliche Navigation oder Ausgabe von ALT-Attributen bei Bildern. In der Konzeptionsphase legt man die Struktur der Website fest – hier ist darauf zu achten, dass die Navigationspfade logisch sind und mehrere Wege zum Ziel ermöglichen (Suche, Sitemap, Breadcrumbnavigation etc.), was insbesondere Nutzern mit kognitiven Einschränkungen oder Screenreader-Nutzern zugutekommt. Auch sollte frühzeitig bedacht werden, wie Pflichtbestandteile wie die Erklärung zur Barrierefreiheit, Gebärdensprach-Video und Leichte-Sprache-Text eingebunden werden. Erfahrungsgemäß ist es sinnvoll, diese Barrierefreiheits-Seiten von Anfang an einzuplanen, damit sie zum Launch verfügbar sind und nicht nachträglich in Hektik erstellt werden.

• Gestaltung (Design): Im Webdesign sind einige Grundregeln zu beachten: Genügend Kontrast bei Text und wichtigen Grafiken; ausreichend große Schriftgrößen und klickbare Flächen; klare visuelle Hierarchie (Überschriften sollen sich deutlich abheben); keine Inhalte ausschließlich durch Farbe codieren (z.B. rote Pflichtfelder zusätzlich mit Symbol oder Text kennzeichnen); Verzicht auf zu verspielte Effekte, die ablenken. Wichtig ist die Auswahl der Farben und Fonts im Hinblick auf Lesbarkeit. Ein guter Designer testet Farbkombinationen mit Tools auf Kontrast (mind. 4,5:1) und bedenkt auch den Dark Mode oder High-Contrast-Mode (manche Nutzer oder Betriebssysteme invertieren Farben). Des Weiteren sollten Responsivität und Zoom-Fähigkeit gewährleistet sein: Ein barrierefreies Design bricht bei Vergrößerung oder auf kleinen Bildschirmen nicht auseinander, sondern passt sich an (Responsive Design unterstützt Barrierefreiheit, da Nutzer z.B. auf Tablets oder per Zoom vergrößern). Auch Animationen sind vorsichtig einzusetzen – blinkende oder sich schnell bewegende Inhalte können für Epileptiker gefährlich und für alle Nutzer irritierend sein; die BITV konform umzusetzen heißt hier, entweder ganz auf Flackern > 3 Hertz zu verzichten oder dem Nutzer eine Abschaltmöglichkeit zu geben.

• Semantisches HTML: Die Verwendung semantisch korrekter HTML-Tags ist fundamental. Überschriften gehören in <h1> ... <h6>-Tags in der richtigen Reihenfolge, Listen in <ul>/<ol> und <li> usw. Dies stellt sicher, dass Screenreader den Aufbau der Seite vermitteln können. Ein häufiger Fehler ist z.B., visuell große Texte lediglich mit <div style="font-size:xx-large"> zu formatieren anstatt mit einer echten Überschrift – für sehende Nutzer mag das gleich aussehen, für Blinde jedoch bleibt die Überschriftenstruktur unsichtbar. BITV-konform ist nur eine saubere semantische Auszeichnung.

• Formularbeschriftungen: Jedes <input>-Feld braucht ein zugeordnetes <label> (oder ein ARIA-Label). Entwickler nutzen idealerweise das native Label-Element, das per for-Attribut an das Eingabefeld gebunden wird. Das erfüllt bereits die meisten Anforderungen. Bei komplexeren Steuerelementen (z.B. Suchfelder mit Buttons) sorgen ARIA-Attribute wie aria-label oder aria-describedby für zusätzliche Klarheit, falls kein sichtbarer Text vorhanden ist.

• Tastaturbedienung sicherstellen: Dies betrifft vor allem Skripte. Dropdown-Menüs, Modale Dialoge, Tabs, Slideshows – all das muss per Tastatur funktionieren. Entwickler sollten hierzu etablierte ARIA-Patterns nutzen (WAI-ARIA Authoring Practices), z.B. Menü mit role="menu" und Pfeiltasten-Navigation, oder Tablist mit role="tablist" und role="tab". Wichtig ist auch das Management des Tastaturfokus: Wenn z.B. ein modales Fenster geöffnet wird, sollte der Fokus ins Fenster springen und beim Schließen wieder zum auslösenden Element zurückkehren. Ohne solche Maßnahmen entsteht leicht eine “Fokus-Falle” oder ein Fokusverlust, was gegen BITV verstoßen würde.

• Alternativtexte und Medienäquivalente einbauen: Entwickler müssen im CMS oder im Code dafür sorgen, dass bei jedem Bildfeld ein ALT-Text hinterlegt werden kann und Redakteure gezwungen werden, diesen auszufüllen (oder bewusst leer zu lassen, wenn das Bild rein dekorativ ist). Für Multimedia sollten die -Elemente für Untertitel in Videos genutzt werden oder es muss auf externe Lösungen (wie YouTube-Untertitel) zurückgegriffen werden. Audiodeskriptionen oder Volltexte für Videos müssen bereitgestellt werden. Hier ist oft redaktionelle Arbeit gefragt (Transkription erstellen etc.), aber technisch muss die Plattform das zumindest ermöglichen (z.B. Upload eines Transkript-Dokuments oder Bereitstellung alternativer Audio-Datei).

• Prüfen der Robustheit: Vor dem Livegang sollte der Code durch Validatoren laufen (W3C Markup Validation). Zwar garantiert ein gültiger HTML-Code allein noch keine Barrierefreiheit, aber grobe Schnitzer (fehlende schließende Tags, verschachtelte Formulare etc.) werden damit aufgedeckt. Ebenso sollten gängige Screenreader (NVDA, JAWS oder VoiceOver) testweise benutzt werden, um sicherzustellen, dass alle Inhalte ausgegeben werden. Automatische Tools wie WAVE oder Axe können zusätzlich helfen, typische Fehler zu identifizieren (fehlende ALT-Texte, fehlerhafte ARIA-Verwendung etc.). Ein Aspekt der Robustheit ist auch die Performance: Webseiten sollten nicht so „schwer“ oder langsam sein, dass assistive Technologien in Timeout laufen – dies ist selten ein Problem, kann aber bei extrem komplexen Webapps relevant werden.

Um die BITV-Konformität sicherzustellen, bietet es sich an, eine BITV-Prüfung durchführen zu lassen. In Deutschland existieren spezialisierte Dienstleister und Testteams (teils mit Experten mit Behinderungen), die nach dem “BITV-Test” Verfahren Websites prüfen und ein detailliertes Ergebnisprotokoll erstellen. Ein solcher Test bewertet z.B. jeden Prüfschritt mit „erfüllt“, „teilweise erfüllt“ oder „nicht erfüllt“ und vergibt eine Punktzahl. Viele öffentliche Stellen streben dabei das Siegel “BITV-konform” an (häufig definiert als 90 von 100 Punkten im BITV-Test). Auch intern kann man anhand der öffentlich verfügbaren Prüfschrittbeschreibungen (siehe z.B. bik-fuer-alle.de) seine Website selbst einschätzen. Hierbei werden u.a. folgende Fragen gestellt: Sind alle Grafiken mit angemessenem Alternativtext versehen? Ist die Navigation konsistent und per Tab erreichbar? Sind Überschriften logisch geschachtelt? Gibt es für eingebettete Videos Untertitel? Ist die Kontrastanforderung überall eingehalten (auch in Grafiken, Icons, Buttons)? Sind alle Linktexte aussagekräftig? etc. Durch dieses systematische Vorgehen stellt man fest, wo Nachbesserungsbedarf besteht.

• PDF-Dokumente und Office-Dateien: Viele Websites – gerade von Behörden – stellen Formulare, Informationsblätter oder Berichte als PDF bereit. Nach BITV müssen neu eingestellte PDFs barrierefrei sein, d.h. getaggt, mit Lesezeichen, Alternativtexten für Abbildungen und korrekter Tabellenauszeichnung. Oftmals hapert es hier in der Praxis. Es empfiehlt sich, wichtige PDFs zusätzlich als barrierefreie HTML-Seiten anzubieten oder – wo möglich – auf PDF ganz zu verzichten und stattdessen Webformulare oder HTML-Inhalte bereitzustellen. Alternativ muss ein Prozess vorhanden sein, um auf Anfrage die Inhalte in zugänglicher Form zu liefern.

• Karten und Geodaten: Interaktive Karten (z.B. Stadtpläne) sind schwer vollständig barrierefrei zu gestalten. Hier greift meist eine Ausnahme: man muss sicherstellen, dass die wesentlichen Informationen (z.B. Adressen, Wegbeschreibungen) in Textform als Alternative vorhanden sind. Gleiches gilt für komplexe Diagramme oder Infografiken – wenn sie unverzichtbar sind, sollte zumindest eine Textbeschreibung oder Datentabelle mit den Schlüsselinformationen vorhanden sein.

• CAPTCHAs: Um Spam zu vermeiden, setzen einige Websites CAPTCHA-Rätsel ein. Diese stellen oft eine Barriere dar (v.a. Bilder mit Text erkennen). Die BITV erlaubt CAPTCHAs nur, wenn es auch eine barrierefreie Alternative gibt (z.B. Audio-CAPTCHA und die Möglichkeit, auf anderem Weg zu verifizieren oder eben moderne non-intrusive Verfahren wie reCAPTCHA, das auf Nutzerverhalten basiert).

• Mehrsprachigkeit: Hat die Website Inhalte in mehreren Sprachen, muss der Sprachwechsel im Code angegeben werden (per lang-Attribut). Für deutschsprachige Seiten ist lang="de" im <html>-Tag Pflicht. Wenn innerhalb eines deutschen Satzes ein englischer Fachbegriff oder ein ganzer Absatz in Englisch steht, soll ebenfalls lang="en" dran, damit Screenreader die Aussprache umstellen. WCAG verlangt die Angabe der Hauptsprache (A-Kriterium) und der Wechsel (AA-Kriterium). In deutschen Behörden-Websites wird dies teils vernachlässigt, aber strenggenommen gehört es zur BITV-Konformität dazu.

• Content-Management und Redaktionsrichtlinien: Die beste technische Vorbereitung nützt wenig, wenn Redakteure im Alltag Barrierefreiheit nicht mitdenken. Daher gehört zur Anwendung der BITV auch die Schulung der Inhaltsredakteure: Sie müssen wissen, dass Überschriften nicht einfach durch fetten Text simuliert werden dürfen, dass jeder Bild-Upload einen Alternativtext erfordert, dass Videos nicht ohne Untertitel eingebunden werden dürfen, etc. Es sollten interne Richtlinien existieren, die dies festhalten. Ebenso ist ein Workflow ratsam, der vor Veröffentlichung eine einfache Accessibility-Prüfung durchlaufen lässt (manche CMS haben Plugins dafür).

Die BITV 2.0 auf Websites umzusetzen, bedeutet, die gesamte Entwicklungskette unter das Leitbild der Barrierefreiheit zu stellen – von der ersten Konzeptskizze bis zum fortlaufenden Betrieb und der Aktualisierung der Inhalte. Es handelt sich um einen kontinuierlichen Prozess: Websites entwickeln sich weiter, neue Inhalte kommen hinzu, gesetzliche Standards können angepasst werden (z.B. steht WCAG 2.2 in den Startlöchern). Daher muss Barrierefreiheit als Qualitätsmerkmal dauerhaft verankert sein. Viele öffentliche Stellen etablieren daher auch Accessibility-Beauftragte oder ziehen externe Expertise hinzu, um den Anforderungen gerecht zu werden. Zusammengefasst gilt: Eine Website ist dann BITV-konform, “wenn sie der EN 301 549 entspricht”, sprich alle Level A- und AA-Erfolgskriterien der WCAG 2.1 erfüllt – abgesehen von explizit ausgenommenen Inhalten.

Die Umsetzung digitaler Barrierefreiheit bringt in der Praxis einige Herausforderungen mit sich. Für öffentliche Stellen, die durch BITV 2.0 gebunden sind, stellen sich vor allem organisatorische und finanzielle Fragen: Nicht alle Behörden verfügten von Beginn an über das technische Know-how oder die Ressourcen, um ihre Webauftritte umgehend vollständig barrierefrei zu gestalten. Insbesondere kleinere oder spezialisierte Einrichtungen mussten oft erst Expertise aufbauen. Hier half in den letzten Jahren die Bundesfachstelle für Barrierefreiheit und verschiedene Förderprojekte, um Schulungen anzubieten und Werkzeuge bereitzustellen. Technische Schwierigkeit bereiten zum Teil ältere Altsysteme – z.B. ein altes Content-Management-System, das Barrierefreiheit nicht gut unterstützt. Deren Ablösung oder Anpassung kann aufwendig sein. Auch komplexe Webanwendungen (etwa Online-Antragsverfahren mit vielen Spezialfunktionen) erfordern beträchtlichen Aufwand, um alle BITV-Kriterien zu erfüllen. Die Erfahrung zeigt, dass eine schrittweise Optimierung hier oft praktiziert wird: Zuerst werden die größten Barrieren beseitigt (etwa fehlende ALT-Texte, grundlegende Tastatursteuerung), dann Detailverbesserungen vorgenommen (ARIA-Optimierungen etc.), bis man Level AA erreicht. Eine weitere Herausforderung ist das Bewusstsein innerhalb der Organisation: Barrierefreiheit konkurriert oft mit anderen Prioritäten (Launch-Termine, Designwünsche, Budgetgrenzen). Intern musste daher häufig Überzeugungsarbeit geleistet werden, dass Barrierefreiheit keine „lästige Pflicht“ ist, sondern einen Qualitätsgewinn darstellt – “ein Gewinn für alle Nutzer”, wie es FM-Connect auf seiner Website formuliert. Diese Einsicht setzt sich zunehmend durch, zumal barrierearmes Design z.B. auch auf Mobilgeräten besser funktioniert und suchmaschinenfreundlicher ist. Nichtsdestotrotz bleiben Zeit- und Kostendruck reale Hindernisse: Eine gründliche Barrierefreiheitsprüfung und Nachbesserung kostet Geld. Öffentliche Haushalte mussten dafür Mittel bereitstellen; vielerorts wurde dies aber als Teil der Digitalisierungsstrategie verbucht, da Barrierefreiheit eine Voraussetzung für nutzerfreundliche E-Government-Angebote ist. Für privatwirtschaftliche Anbieter stellten sich lange Zeit andere Fragen, da sie bis vor Kurzem keiner allgemeinen gesetzlichen Barrierefreiheitspflicht unterlagen. Viele Unternehmen nahmen das Thema dennoch freiwillig in Angriff – oft aus Corporate Social Responsibility-Motiven oder um Kundengruppen besser zu erreichen (z.B. bieten einige Banken barriereoptimierte Online-Banking-Portale an, um auch älteren und behinderten Kunden gerecht zu werden). Doch wo kein Zwang ist, wird Barrierefreiheit in der Privatwirtschaft leider oft vernachlässigt. Ein “Nur-Behörden müssen barrierefrei sein”-Denken war weit verbreitet, auch wenn z.B. das Allgemeine Gleichbehandlungsgesetz (AGG) im Bereich privater Dienstleistungen indirekt Relevanz haben kann (Verweigerung einer zugänglichen Website könnte als mittelbare Diskriminierung gesehen werden, ist aber juristisch schwer durchzusetzen). Einige größere Firmen gingen Partnerschaften mit Behindertenverbänden ein und schlossen Zielvereinbarungen: Das BGG ermöglicht nämlich seit 2002, dass Unternehmen freiwillig verbindliche Vereinbarungen über Barrierefreiheit treffen, die dann quasi Vertragscharakter haben. Darin wird z.B. festgeschrieben, bis wann welche Angebote barrierefrei gestaltet werden und welche Sanktionen bei Nichteinhaltung greifen. Allerdings blieb die Zahl solcher Zielvereinbarungen überschaubar – es ist eher ein Instrument für Pionierunternehmen gewesen.

• Ein grundlegender Wandel steht jedoch bevor: Mit dem Europäischen Rechtsakt zur Barrierefreiheit (Directive (EU) 2019/882, European Accessibility Act) werden erstmals breite Teile der Privatwirtschaft zu Barrierefreiheit verpflichtet. Diese Richtlinie betrifft bestimmte Produkte und Dienstleistungen, z.B. Hardware, Selbstbedienungsterminals, E-Book-Reader, Bankdienstleistungen, E-Commerce, Online-Banking, Telekommunikationsdienste u.a. – auch immer in Bezug auf deren Websites und Apps. Deutschland hat diese Vorgaben mit dem Barrierefreiheitsstärkungsgesetz (BFSG) vom 22. Juni 2021 in nationales Recht umgesetzt. Das BFSG tritt am 28. Juni 2025 in Kraft und verpflichtet private Unternehmen in den genannten Sektoren, ihre digitalen Angebote barrierefrei zu gestalten. Damit endet faktisch die bisherige Privilegierung vieler privater Anbieter. Ab 2025 müssen z.B. Online-Shops, große E-Commerce-Plattformen, Anbieter von Bank- und Versicherungsleistungen, Verkehrsdienstleister (Flug-/Bahn-Buchungssysteme) u.v.m. die EN 301 549 / WCAG 2.1 AA erfüllen. Das BFSG ist somit das Pendant zur BITV für die Privatwirtschaft. Zwar sind nicht alle Webseiten erfasst (kleine Unternehmen, die nicht in den aufgezählten Bereichen tätig sind, bleiben außen vor), doch viele kundenorientierte Angebote großer Firmen werden darunterfallen. Dies stellt die Privatwirtschaft nun vor ähnliche Herausforderungen, mit denen Behörden vor einigen Jahren konfrontiert waren.

• Herausforderungen für private Betreiber sind insbesondere: Know-how-Aufbau, Budgetierung und Systemumstellung. Viele Unternehmen müssen zunächst intern Kompetenz schaffen oder einkaufen. Webagenturen, die für Unternehmen Websites erstellen, müssen ihre Entwickler schulen, um barrierefreie Templates zu liefern. Ein praktisches Problem ist oft die Altlast – bestehende Websites, die inhaltlich und technisch gewachsen sind, aber nie auf Barrierefreiheit getrimmt wurden. Diese innerhalb kurzer Zeit nachzurüsten, kann komplex sein. Unternehmen stehen vor der Abwägung, ob sie eine Neuentwicklung barrierefrei starten (was langfristig oft effizienter ist) oder die Bestandssysteme überarbeiten (was kurzfristig weniger Kosten verursacht, aber unter Umständen suboptimale Ergebnisse liefert).

• Ein weiterer Aspekt ist die Durchsetzung und Kontrolle: Während bei Behörden Druck durch Gesetz, Ministerien und Öffentlichkeit besteht, ist bei privaten zunächst Unklarheit, wer die Einhaltung kontrolliert. Das BFSG sieht aber vor, dass es Marktüberwachungsbehörden gibt und Sanktionsmechanismen (z.B. ordnungsrechtliche Anordnungen, Bußgelder) greifen, wenn ein Unternehmen seinen Pflichten nicht nachkommt. Dies ist neu – ein privates Unternehmen konnte bisher kaum direkt sanktioniert werden, wenn sein Webshop nicht barrierefrei war. Ab 2025 drohen hier z.B. Bußgelder, ähnlich wie im Verbraucherschutz. Die genaue Ausgestaltung bleibt zu beobachten, aber alleine die Möglichkeit von Strafen erhöht die Motivation zur Einhaltung.

• Nicht zu unterschätzen ist auch die Herausforderung im Umgang mit Drittsystemen: Viele private Websites binden externe Services ein (z.B. Social Media Plugins, Payment-Gateways, Kartendienste). Wenn diese nicht barrierefrei sind, zieht das das eigene Angebot runter. Unternehmen müssen daher ihre Dienstleister und Partner in die Pflicht nehmen, ebenfalls Accessibility zu beachten.

• Zudem gibt es branchenspezifische Hürden: Im E-Commerce-Bereich etwa sind die Produktdarstellungen mit vielen Bildern, Galerien, 3D-Ansichten etc. Eine barrierefreie Gestaltung (mit Beschreibung all dieser visuellen Inhalte) erfordert erheblichen redaktionellen Aufwand. Im Mediensektor (Streamingdienste) müssen Unmengen an Videos mit Untertiteln versehen werden. Für Banken heißt es, teils seit Jahrzehnten gewachsene Online-Banking-Oberflächen neu zu evaluieren. Die Spanne der Herausforderungen ist entsprechend groß.

• Dennoch kann die Privatwirtschaft auch von positiven Erfahrungen der öffentlichen Hand profitieren: Es existieren inzwischen Best Practices und Tools. Zahlreiche Accessibility-Agenturen und Beratende stehen zur Verfügung. Und nicht zuletzt zeigen Beispiele, dass Barrierefreiheit Mehrwert bringt: So haben Untersuchungen ergeben, dass barrierefreie Webseiten oft bessere SEO (Suchmaschinen-Rankings) haben und eine höhere Nutzerzufriedenheit erzielen – einfach weil sie klarer strukturiert sind und auf Usability achten. Unternehmen, die früh auf Barrierefreiheit setzen, können dies auch werbewirksam einsetzen, um ihr Image als inklusiv und kundenfreundlich zu stärken.

• Unwissenheit/Schulungsbedarf: Viele Entwickler und Designer mussten/müssen erst lernen, was BITV/WCAG im Detail erfordert.

• Initialkosten: Anfangsinvestitionen in Audits, neue Templates, eventuell Tools (z.B. für Untertitel, PDF-Accessibility).

• laufender Pflegeaufwand: Barrierefreiheit ist kein einmaliges Projekt, sondern verlangt ständige Qualitätssicherung (z.B. bei jeder neuen Inhalteinstellung prüfen, ob Alt-Text da ist; regelmäßige User-Tests etc.).

• Trade-offs mit Design/Marketing: Manche Marketing-Elemente (aufwändige Animationen, bestimmte Corporate-Design-Farbkontraste) kollidieren mit Accessibility. Hier gilt es, Kompromisse zu finden, die die Marke nicht beschädigen aber dennoch Mindeststandards einhalten (Beispiel: ein CI-Blau kann zu dunkel sein für weißen Text; Lösung: Umriss oder leichte Aufhellung nur auf Web für Kontrast).

• Vielfalt der Endgeräte: Sicherzustellen, dass etwas auf Desktop und Mobile barrierefrei ist, bedeutet doppelte Testaufwände – Responsive Design birgt neue Fehlerquellen (z.B. kann eine mobile Ansicht aus Unachtsamkeit manche ARIA-Labels verlieren, wenn andere Komponenten geladen werden).

• Externe Komponenten: Nicht immer hat man Kontrolle über jeden Teil der Website (z.B. eingebettete YouTube-Videos oder externe Widgets können Barrieren haben, die man selbst nicht beheben kann – hier hilft nur, Alternativen anzubieten oder Druck auf Anbieter auszuüben).

Da privatwirtschaftliche Anbieter zunehmend in den Fokus rücken (politisch ist – Stand 2025 – sogar angedacht, generell eine Barrierefreiheitsverpflichtung für die Privatwirtschaft einzuführen, über die EU-Anforderungen hinaus), sind die kommenden Jahre entscheidend. Viele Unternehmen werden Neuland betreten müssen. Es liegt auch an der öffentlichen Verwaltung und der Zivilgesellschaft, hier unterstützend zu wirken und aufzuklären. Initiativen wie “Woche der Barrierefreiheit” oder Auszeichnungen für barrierefreie Websites könnten helfen, Motivation zu schaffen.

Rechtliche Konsequenzen: Wenn eine verpflichtete öffentliche Stelle (Bundesbehörde etc.) die Vorgaben der BITV 2.0 nicht einhält, stellt dies einen Rechtsverstoß dar. Allerdings ist die BITV zunächst eine Verwaltungsvorschrift – das heißt, es gibt nicht sofort Bußgelder oder Strafen wie im Ordnungsrecht.

• Beschwerde und Feedback: Die erste Stufe ist niedrigschwellig. Nutzer, die auf Barrieren stoßen, können die betreffende Stelle direkt über den in der Barrierefreiheitserklärung vorgesehenen Kontaktweg informieren und Abhilfe verlangen. Die Behörde ist verpflichtet zu antworten, meist innerhalb von vier Wochen. Oft lassen sich kleinere Probleme so bereits lösen (z.B. liefert die Behörde das gewünschte barrierefreie Dokument oder behebt einen Website-Fehler).

• Schlichtungsverfahren nach § 16 BGG: Bleibt die Antwort aus oder unbefriedigend, können sich Betroffene an die Schlichtungsstelle BGG wenden. Diese Stelle ist beim Bundesbehindertenbeauftragten angesiedelt. Im Schlichtungsverfahren wird versucht, zwischen dem Antragsteller (i.d.R. dem Menschen mit Behinderung) und der öffentlichen Stelle eine Einigung zu erzielen. Die Schlichtungsstelle kann Vorschläge machen, wie die Barriere beseitigt werden kann. Das Verfahren ist für Antragsteller kostenlos und formlos, was die Hürde gering hält. Seit 2016 wird dieses Verfahren rege genutzt und gilt als Erfolg, um pragmatische Lösungen zu finden. Wenn etwa eine Behörde eine unzugängliche PDF-Datei online hat, könnte die Einigung sein, dass sie binnen einer Frist eine barrierefreie Version nachliefert.

• Verbandsklage nach § 15 BGG: Unabhängig vom individuellen Schlichtungsverfahren haben anerkannte Behindertenverbände das Recht, Verbandsklage zu erheben, wenn gegen Barrierepflichten verstoßen wird. Allerdings ist die Ausgestaltung begrenzt: Die Verbandsklage kann nur auf Feststellung eines Gesetzesverstoßes gerichtet werden, nicht direkt auf Beseitigung der Barriere. D.h., ein Verband (z.B. der Deutsche Blinden- und Sehbehindertenverband) kann vor dem Verwaltungsgericht feststellen lassen, dass eine bestimmte Bundesbehörde gegen die BITV 2.0 verstößt. In der Praxis wurde dieses Instrument bisher selten eingesetzt. Gründe sind u.a., dass nur eine Feststellung erreicht wird und keine unmittelbare Verpflichtung zur Abstellung erwirkt werden kann. Dennoch hat die Feststellungsklage symbolischen und politischen Druck: Eine Behörde, die vor Gericht unterliegt, wird öffentlich wahrgenommen und dürfte angehalten sein, den Missstand zu beheben. Die Evaluation des BGG zeigte aber, dass viele Verbände den Aufwand scheuen, da das Schlichtungsverfahren oft schneller zum Ziel führt.

• Individualklage (mittelbar): Direkt können Einzelpersonen nur in Ausnahmefällen klagen, da das BGG keine subjektiven Rechte im klassischen Sinne einräumt (außer z.B. bei Diskriminierungstatbeständen). Allerdings wäre theoretisch denkbar, dass sich ein Mensch mit Behinderung auf Gleichbehandlungsgrundsätze beruft und im Wege einer Leistungsklage Zugang zu bestimmten Informationen einfordert, wenn diese nur in nicht-barrierefreier Form vorliegen. Ein Beispiel: Wenn ein Verwaltungsverfahren ausschließlich online (ohne barrierefreie Gestaltung) möglich ist, könnte argumentiert werden, das verletze das Recht auf gleichberechtigten Zugang zu öffentlichen Leistungen. Die Gerichte könnten dann die Behörde verpflichten, einen barrierefreien Zugang zu schaffen oder einen alternativen Weg anzubieten. Solche Klagen sind bislang kaum dokumentiert – meist wird der Weg über Schlichtung und Verbandsklage vorgezogen, da dies im BGG so vorgesehen ist. Zu erwähnen ist jedoch ein möglicher Umweg: Diskriminierungsklagen nach AGG. Ein öffentlich zugängliches Angebot (z.B. Online-Bibliothek oder Museumskatalog) könnte als “Alltagsgeschäft” gelten, bei dem niemand wegen einer Behinderung benachteiligt werden darf. Wäre es vollständig unbedienbar für Blinde, könnte ein Blinder klagen und ggf. Schadensersatz fordern. In der Praxis sind uns hier aber wenige Präzedenzfälle bekannt – häufig scheitert es an der Definition, ob das AGG im Einzelfall greift und ob Inaccessibility als Diskriminierung gewertet wird.

• Administrativ und politisch: Neben juristischen Verfahren gibt es auch administrative Konsequenzen. Die Monitoring-Stellen (z.B. BFIT-Bund) führen Stichprobenprüfungen durch und erstellen Berichte, die veröffentlich werden. Wenn dabei erhebliche Mängel bei bestimmten Websites festgestellt werden, geraten diese Behörden intern unter Druck, dies zu korrigieren. Auch der Bundesbeauftragte für die Belange von Menschen mit Behinderungen kann auf Missstände hinweisen und öffentlichkeitswirksam anmahnen, Barrieren abzubauen. Solche öffentlichen Berichte wirken erfahrungsgemäß als „soft power“: Behörden möchten nicht auf Negativlisten erscheinen, zumal Barrierefreiheit mittlerweile ein Indikator für bürgerfreundliche Digitalisierung ist.

• Sanktionen: Klassische Sanktionen wie Bußgelder existieren im Bereich der BITV für Bundesbehörden nicht – es wäre auch ungewöhnlich, einer Behörde ein Bußgeld aufzuerlegen, weil sie einer Verordnung nicht nachkommt, die für sie selbst gilt. Stattdessen greift hier das interne Verwaltungsmanagement. Allerdings: Sollten z.B. erhebliche Barrierefreiheitsmängel auch nach Rügen und Fristen nicht behoben werden, könnte es im Extremfall disziplinarische Konsequenzen für Verantwortliche geben (Dienstaufsichtsbeschwerde etc.), oder Mittel können umgeschichtet werden, um dies doch noch zu erreichen. In der Praxis bemühen sich die meisten öffentlichen Stellen um Compliance, schon um negative Presse zu vermeiden.

• Konsequenzen für private Anbieter: Für private ab 2025 verpflichtete Unternehmen wird es hingegen sanktionsbewehrte Vorschriften geben. Das BFSG sieht vor, dass Aufsichtsbehörden die Einhaltung prüfen und bei Verstößen Maßnahmen wie Verwarnungen, Fristsetzungen und in letzter Konsequenz Bußgelder verhängen können. Die genaue Zuständigkeit liegt je nach Bereich bei unterschiedlichen Stellen (etwa Bundesnetzagentur für Telekommunikation, Bafin für Bankdienstleistungen, etc., analog zu deren Regulierungskompetenz). Ein Online-Shop-Betreiber, der ab Juli 2025 seine Website immer noch nicht barrierefrei gestaltet hat, könnte z.B. eine Verfügung erhalten, innerhalb von X Monaten nachzubessern, und bei Nichtbefolgung ein hohes Bußgeld zahlen müssen. Damit erhalten die BITV-Vorgaben in der Privatwirtschaft einen ganz anderen Nachdruck als zuvor.

• Darüber hinaus stehen auch Unternehmen vor Reputationsrisiken: Eine öffentlich bekannt gewordene Barriere (z.B. „Blinder Kunde kann nicht im Shop XY einkaufen, weil Website ihn aussperrt“) kann gerade in Zeiten von Social Media einen Shitstorm auslösen und Markenimage schädigen. Schon vor gesetzlichen Pflichten sah man Fälle, wo nach Medienberichten über Barrieren (etwa fehlende Untertitel in Mediatheken) die Anbieter schnell reagierten, um Schaden abzuwenden.

• Positivpflichten und zukünftige Entwicklungen: Es sei erwähnt, dass die aktuelle Bundesregierung plant, das BGG so zu reformieren, dass auch die Privatwirtschaft generell zur Barrierefreiheit verpflichtet wird, sofern sie Produkte oder Dienstleistungen anbietet (über die EU-Vorgaben hinaus). Dies wäre eine erhebliche Ausweitung und würde alle Branchen erfassen – etwa Restaurants, Einzelhandel mit Webauftritt, etc. Sollte dies umgesetzt werden, müssten langfristig alle kommerziellen Websites ebenfalls BITV/EN 301 549-Standards einhalten, womit Barrierefreiheit vom „nice-to-have“ zum verbindlichen Standard würde. Die Konsequenzen bei Verstößen wären dann vermutlich ähnlich wie im BFSG (aufsichtsrechtliche Sanktionen).

• Zusammengefasst: Bei öffentlichen Stellen führt ein Verstoß gegen BITV 2.0 zunächst zu Dialogpflichten (Feedback beantworten), dann zu Schlichtung und ggf. einer gerichtlichen Feststellung des Verstoßes. Während unmittelbare Strafen selten sind, entsteht durch diese Mechanismen und öffentliche Aufmerksamkeit ein erheblicher Druck zur Nachbesserung. In der Privatwirtschaft greifen ab 2025 direkte Sanktionsmöglichkeiten (Behördenkontrolle, Bußgelder). In beiden Bereichen können Verstöße neben rechtlichen Folgen auch Imageschäden und Vertrauensverluste bei Kunden nach sich ziehen. Aus juristischer Sicht ist der Trend klar: Barrierefreiheit wandelt sich von einer sozialen Verantwortung zu einer rechtlich einklagbaren Pflicht, flankiert von Instrumenten, um diese Pflicht wirksam durchzusetzen.

• Praktische Konsequenzen bei Verstößen: Für Betroffene bedeutet das heutige System immerhin, dass sie nicht völlig hilflos vor Barrieren stehen. Sie können ihr Recht auf Zugänglichkeit geltend machen, zunächst formlos, dann formal. Obwohl die Wege manchmal mühsam sein mögen, gibt es erfolgreiche Beispiele: Viele Behörden haben nach Schlichtungsanträgen kurzfristig Inhalte in Brailleschrift oder Leichter Sprache bereitgestellt. Die Verbandsklage bleibt ein scharfes Schwert im Hintergrund – wenig genutzt, aber im Prinzip verfügbar, um notfalls auch Grundsatzfragen zu klären. Perspektivisch wird dieses Gefüge weiterentwickelt werden müssen, vor allem, wenn künftig hunderte private Unternehmen überwacht werden müssen. Hier stehen die Aufsichtsinstitutionen vor der Herausforderung, einheitliche Standards der Kontrolle zu etablieren und zugleich pragmatische Hilfestellung zu bieten. Die Erfahrung aus dem öffentlichen Sektor zeigt jedenfalls: Rechtliche Verpflichtungen allein bewirken noch keine Barrierefreiheit – es braucht immer das Zusammenspiel von Klare Normen + Kontrolle + Beratung + Bewusstseinsbildung. Die BITV 2.0 liefert die Normen, Monitoring und Schlichtung die Kontrolle, Institutionen wie die Bundesfachstelle die Beratung, und der gesellschaftliche Diskurs die Bewusstseinsbildung.

Im Anhang folgt nun eine konkrete Fallanalyse, welche die zuvor beschriebenen Anforderungen exemplarisch überprüft. Anhand der Website FM-Connect.com wird untersucht, wie gut eine privatwirtschaftliche Seite (die sich freiwillig Barrierefreiheit auf die Fahnen schreibt) den BITV 2.0 Kriterien entspricht.

FM-Connect.com ist die Website eines privaten Beratungs- und Ingenieurnetzwerks im Bereich Facility Management. Obwohl private Anbieter (noch) nicht gesetzlich verpflichtet sind, BITV 2.0 umzusetzen, hat FM-Connect auf seiner Seite ein Bekenntnis zur Barrierefreiheit abgelegt. Es existiert eine Informationsseite “Barrierefrei”, auf der das Unternehmen seine Maßnahmen für eine barrierefreie Website beschreibt. Dies bietet die Gelegenheit, den Anspruch mit der Realität zu vergleichen: Inwiefern erfüllt FM-Connect.com tatsächlich die Anforderungen der BITV 2.0 (bzw. WCAG 2.1 AA)? Im Folgenden wird dies entlang der vier Prinzipien – Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit, Robustheit – untersucht. Dabei wird auf konkrete Erfolgskriterien und BITV-Prüfschritte eingegangen.

• Alternativtexte für Bilder: FM-Connect behauptet, dass “alle auf unseren Websites verwendeten Bilder mit detaillierten Alternativtexten versehen” sind. Ein Schnelltest bestätigt, dass viele Grafiken tatsächlich ALT-Attribute haben. So führt z.B. das Logo-Bild den Alternativtext “FM-Solutionmaker: Gemeinsam Facility Management neu denken” – was allerdings weniger eine Beschreibung, sondern einen Slogan darstellt. Hier wäre ein präziserer ALT-Text wie “Logo FM-Connect.com – Das FM-Beratungs- und Ingenieurnetzwerk” sinnvoller. Einige Grafiken auf der Startseite erscheinen bei Text-Inspektion als leere Verweise (z.B. ein Dekorationselement neben der Überschrift “Gemeinsam Zukunft gestalten” wird als 【40† 】 angezeigt). Vermutlich handelt es sich um dekorative Icons mit leerem ALT-Attribut – was konform ist, solange sie wirklich nur Zierde sind. Insgesamt scheint FM-Connect bemüht, Textäquivalente bereitzustellen. Auffällig ist jedoch, dass bei bestimmten verlinkten Grafiken der Screenreader nur "Image: logo-fm-connenct" vorliest – das deutet darauf hin, dass hier der Dateiname im ALT-Attribut steht oder kein aussagekräftiger Text vergeben wurde. Ein solches Vorkommen widerspricht dem eigenen Anspruch “detaillierter Alternativtext” und wäre nach BITV nicht ausreichend. Es sollte geprüft werden, ob es sich um einen Fehler handelt (evtl. Tippfehler “connenct” im ALT-Text, was nutzlos ist). Empfehlung: Durchgehen aller <img>-Tags und Sicherstellung, dass ALT aussagekräftig oder leer (bei rein dekorativen Bildern) ist.

• Text statt Grafiken für Schrift: Das Logo ist als Bild eingebunden (weil es stylisierte Schrift enthält). Dies fällt unter die Ausnahme “Logotyp” – grafische Darstellung des Markenamens ist zulässig, wenn ALT-Text vorhanden ist. Ansonsten scheint FM-Connect konsequent Schrift als echte Schrift zu nutzen (z.B. Slogans, Überschriften sind als Text umgesetzt und nicht Teil von Bildern). Das entspricht WCAG 2.1 Kriterium 1.4.5 (Verzicht auf Bilder von Text, außer erforderlich). Hier gibt es keine Beanstandung.

• Farben und Kontrast: Die Seite verwendet ein Weiß/Grau-Oranges Design. Schwarzer Text auf weißem Hintergrund (z.B. Fließtext) erfüllt die Kontrastanforderung problemlos. Orange als Akzentfarbe (etwa für Icons oder Links) müsste auf hellem Hintergrund geprüft werden. Ein Beispiel: Der Linktext “Lösungen” ist orange auf weiß – dieser Kontrast scheint mit bloßem Auge gerade ausreichend, müsste aber gemessen werden. Die Betreiber geben an, dass “Farben und Kontraste mithilfe eines Kontrastberaters überprüft und optimiert” wurden. Wahrscheinlich erfüllen sie das Mindestkontrastverhältnis von 4,5:1. Überschriften in dunkelgrau auf weiß sind ebenfalls okay (Kontrast vermutlich > 7:1). Negativ fällt nichts offensichtlich auf. Es gibt keine Farbkombinationen, die problematisch wären (kein Text auf orange o.ä.). Somit wahrscheinlich konform zu Erfolgskriterium 1.4.3. Farbfehlsichtigkeit: Wichtige Inhalte sind nicht nur durch Farbe ausgezeichnet – z.B. im Menü wird aktive Seite nicht allein farbig markiert, sondern durch Unterstreichung oder Symbol? (Das müsste man noch prüfen; auf den ersten Blick ist das Hauptmenü rein textbasiert, keine z.B. rote Fehlertexte o.ä.). Insgesamt scheint die farbliche Gestaltung ordentlich.

• Skalierbarkeit: FM-Connect schreibt, dass Texte “ohne Qualitätsverlust vergrößert werden können” und die Struktur übersichtlich bleibt. Ein Test mit Browser-Zoom (200%) zeigt, dass das Layout responsiv reagiert: Bei Vergrößerung auf 200% wird vermutlich ein mobile Layout aktiv (Menü klappt ein etc.), doch Inhalte bleiben zugänglich. Nichts deutet darauf hin, dass Inhalt abgeschnitten würde oder horizontales Scrollen nötig wäre. Damit dürfte Kriterium 1.4.4 (Textgröße anpassbar) erfüllt sein. Auch Nutzer mit Sehbehinderung können also mit Zoom arbeiten.

• Multimedia: Hat die Seite relevante Medieninhalte? Auf der Startseite sind keine Videos oder Audios eingebettet. Es gibt jedoch ein Angebot namens “FM Power Hour” (wöchentliches Online-Forum) – möglicherweise werden dort Videos (Webinare) bereitgestellt. Sollte die Seite Videos enthalten, stellt sich Frage nach Untertiteln oder Transkripten. Da im “Barrierefrei”-Text der Firma keine Erwähnung von Videos oder Audiotranskripten ist, könnte das bedeuten, dass entweder keine solchen Inhalte vorhanden sind oder dies übersehen wurde. Wenn FM-Connect Videos anbietet, müssten gemäß BITV 2.0 dafür Untertitel bzw. Audiodeskriptionen bereitgestellt werden (Erfolgskriterium 1.2.2 für Untertitel und 1.2.5 für Audiodeskription bei aufgezeichneten Videos). Ohne konkrete Videos lässt sich das nicht prüfen; wir gehen daher davon aus, dass (noch) kein Video-Content vorliegt, andernfalls wäre dieser Punkt kritisch.

• Strukturierung für Wahrnehmbarkeit: Überschriftenstruktur ist Teil von Wahrnehmbarkeit (und Verständlichkeit). Die Homepage hat einen <h1> (“FM-Connect.com. Das FM-Beratungs- und Ingenieurnetzwerk”) und mehrere <h2> für Sektionen wie “Facility Management. Wertschöpfung mit Wertschätzung. Partnerschaftlich.” etc. Das sieht in der Textstruktur schlüssig aus – keine Überschriften springen unlogisch von H2 zu H4 etc., soweit ersichtlich. Dies erfüllt Kriterium 1.3.1 (Information und Beziehungen programmatisch erfassbar, also sinnvolle Gliederung).

• Zusammenfassung Wahrnehmbarkeit: FM-Connect.com erzielt hier insgesamt gute Ergebnisse mit kleineren Schönheitsfehlern. Positiv sind konsequente ALT-Texte (wenn auch Qualität im Einzelfall zu prüfen), ausreichende Kontraste und skalierbarer Text. Kein elementarer Verstoß gegen BITV-Prinzipien wurde festgestellt. Empfehlung: Den ALT-Text des Logos korrigieren und sicherstellen, dass wirklich alle Bilder, auch Icons, entweder leeres ALT oder erklärenden Text haben. Außerdem Vorsicht bei künftigen Medien: falls Videos eingestellt werden, frühzeitig für Untertitel sorgen.

• Tastatur-Navigation: Ein herausragendes positives Merkmal der Seite ist der sofort sichtbare Link “Zum Inhalt springen” am oberen Seitenrand. Sobald man mit Tab navigiert, erscheint dieser deutlich (laut FM-Connect: “beim ersten Drücken der Tab-Taste erscheint ein gut sichtbarer Link”). Das ist vorbildlich und erfüllt BITV-Prüfschritt 2.4.1 Bypass Blocks. Im Test funktioniert der Sprunglink und fokussiert den Hauptinhalt. Alle Hauptmenüpunkte sind per Tab erreichbar. Die Untermenüpunkte (z.B. unter “FM-Connect.com” -> “Networking”, “Partnerschaft mit Endkunden” etc.) klappen per Hover auf. Frage: Sind diese auch per Tastatur zugänglich? Beim Durchtabben werden die Menüpunkte sequentiell fokussiert; ob Submenüs sich öffnen, wenn man per Enter oder Pfeil navigiert, konnte nicht abschließend verifiziert werden. Die Barrierefrei-Erklärung der Seite behauptet, alle interaktiven Elemente seien vollständig mit Tastatur bedienbar. Hoffentlich wurde hier auch an die Menüs gedacht. Möglicherweise sind die Submenüs als separate Seitenstruktur ebenfalls ansteuerbar (man sieht z.B., dass der Menüpunkt “FM-Connect.com” selbst klickbar ist, führt auf eine Übersichtsseite). Wenn man diese Seite ansteuert, sieht man dort die Unterpunkte verlinkt. Somit gibt es zumindest einen Pfad, alle Inhalte ohne Hover zu erreichen – entweder via die Hauptseite oder im Inhaltsverzeichnis (es gibt auch eine Sitemap im Footer). Daher würden wir kein Scheitern an Kriterium 2.1.1 (Tastatur) diagnostizieren, auch wenn idealerweise die Dropdowns per Tastatur aufklappbar wären.

• Fokus und sichtbare Markierung: Beim Tabben durch die Seite erhält das fokussierte Element einen sichtbaren Rand in Orange (im Test erkennbar). Das wird von FM-Connect selbst hervorgehoben: “Buttons und andere interaktive Elemente erhalten bei Tastatur-Fokus eine visuelle Hervorhebung.”. Somit ist Kriterium 2.4.7 (Fokus sichtbar) erfüllt. Positiv fällt auf, dass auch Links im Fließtext fokussierbar sind und dann unterstrichen bzw. farblich markiert werden – nichts verschwindet im Nirwana.

• Keine Keyboard-Traps: Ein Keyboard-Trap liegt vor, wenn man in einem Element gefangen bleibt (z.B. in einem Dialog-Fenster, das sich nicht schließen lässt). Auf FM-Connect sind derzeit keine modalen Dialoge bekannt (bis auf den Cookie-Hinweis vielleicht; dieser ließe sich per Tab schließen). Der Chat-Assistent unten rechts könnte einen potenziellen Fall darstellen: Wenn man ihn fokussiert und er sich öffnet, muss man auch wieder herausnavigieren können. Hier könnte eine Gefahr bestehen, falls die Chat-Box nicht richtig implementiert ist. Mangels Zugriff auf den Chat per Tastatur (evtl. muss man Enter drücken auf "FM-Connect Chat"), können wir das nicht voll prüfen. Aber da der Chat-Button das letzte Element im DOM ist (unten im Footer nach Adresse), kommt man danach zum Browser-Ende. Ein Trap wäre, wenn der Fokus zyklisch darin gefangen wäre – unwahrscheinlich. Also vermutlich okay.

• Zeitsteuerung und Auto-Updates: Die Seite hat keinen offensichtlichen automatischen Inhalt, der sich bewegt. Ein Slider mit wechselnden Bildern scheint nicht vorhanden zu sein (auch wenn im Barrierefrei-Text “von Slidern über den Kalender bis zum Dokumentenshop, alles per Tastatur bedienbar” steht – das impliziert, es gibt tatsächlich Slider und einen Kalender). Vermutlich existieren an anderer Stelle dynamische Komponenten. Beispiel: Ein Kalender-Widget könnte im Event-Bereich sein. Die Aussage, es sei komplett per Tastatur bedienbar, ist erfreulich, aber hier müsste ein intensiver Test erfolgen. Nehmen wir es als gegeben hin, dass FM-Connect das bedacht hat. Bei evtl. automatischen Inhalten (Slider) sollte auch eine Pause-Funktion vorhanden sein (WCAG 2.2.2). Da uns kein autoscrollender Inhalt aufgefallen ist, ist dies kein Problem.

• Navigation und Orientierung: Der Aufbau der Navigation ist hierarchisch gut gegliedert (Hauptmenü + Untermenüs + A-Z Index + Sitemap). Das entspricht dem Kriterium der mehrfachen Wege (WCAG 2.4.5, zwar nur AA optional, aber hier gegeben: es gibt eine Sitemap und ein A-Z Verzeichnis, also zwei alternative Wege). Die Seite setzt auch Breadcrumbs ein? Nicht offensichtlich im UI, aber evtl. auf Unterseiten wie “Themenpartnerschaft” wird Pfad angezeigt (nicht verifiziert). Auf der Startseite ist keins nötig. Jedenfalls die Sitemap im Footer ist vorhanden. Das ist ein Plus.

• Links und Buttons: Sämtliche interaktive Elemente sollten mindestens durch die sichtbare Beschriftung oder ARIA eine eindeutige Beschreibung haben. Beispielsweise der Such-Button (Lupe-Symbol “Suchen” im Header) – hier ist tatsächlich der sichtbare Text “Suchen” vorhanden, gut. Wenn er ein togglen des Suchfelds auslöst, sollte das mit ARIA-Expanded markiert sein – unsichtbar für uns, aber zu hoffen. Der Cookie-Einstellungs-Dialog vermutlich hat klare Buttons (Zustimmen/Ablehnen). Externe Links sind kenntlich gemacht? Der Footer hat z.B. Adresse “Am Altenfeldsdeich 16, …” mit einem Link auf Google Maps. Dieser Linktext ist die Adresse selbst – soweit okay, auch wenn nicht jeder erkennt, dass dies zu Google Maps führt. BITV fordert keine Kennzeichnung externer Links, lediglich dass der Linkzweck erkennbar ist. Hier könnte man diskutieren, ob “04125… [Adresse]” als Link textlich ausreichend ist – wahrscheinlich ja, da es die Adresse ist und der Nutzer kontextuell versteht, ein Klick öffnet diese in Maps (trotzdem könnte man ein Icon “↗” für extern ergänzen).

• Formulare: Es gibt ein Kontaktformular (erreichbar über “Kontakt”). Dieses sollte nach WCAG ordentlich beschriftet sein. Ein kurzer Check zeigt: Die Kontakt-Seite hat Felder wie Name, E-Mail, Nachricht. Sind dort <label> Elemente vorhanden? Visuell vermutlich ja, da Platzhaltertexte allein unsauber wären. Falls Labels unsichtbar sein sollten, hoffe ich auf ARIA-Labels. Der Barrierefrei-Text versichert, dass “alle Eingabefelder mit ARIA-Labels ausgestattet” sind. Das klingt so, als hätten sie interne Labeling via ARIA gemacht, möglicherweise falls die visuelle Gestaltung Labels unpraktisch fand. Besser wären normale <label>. Solange Screenreader den Feldnamen ansagen, ist es BITV-konform. Zur Fehlerbehandlung: Schickt man das Formular leer ab, erscheinen Fehlermeldungen? Idealerweise sollten Fehlertexte erscheinen und dem Fokus zugeführt werden. Unklar, ob implementiert. Mangels Möglichkeit, das hier zu testen, bleibt das offen. Aber da Formulare ein kritischer Bereich sind, wäre zu empfehlen, dies zu prüfen – BITV erfordert zugängliche Fehleranzeige (Kriterium 3.3.1, 3.3.3) und verständliche Beschriftungen (3.3.2).

• Bedienung mit verschiedenen Geräten: Eine Unterkategorie – Bedienbarkeit mit Screenreader & Screenreader-Modus. Hier gibt es inhaltliche Überlappung mit Robustheit, aber erwähnen wir: FM-Connect hat etliche ARIA-Attribute eingebaut laut eigener Aussage (z.B. ARIA-Labels). Das ist gut, muss aber auch korrekt sein. Falsche ARIA kann die Bedienung verschlechtern. Ohne einen intensiven Test lässt sich nur sagen: Sie haben zumindest das Bewusstsein, ARIA einzusetzen, was eher positiv ist.

• Zusammenfassung Bedienbarkeit: FM-Connect.com zeigt viele Best Practices (Skiplink, Fokus-Styles, Tastaturbedienbarkeit) und dürfte damit die meisten Operability-Kriterien erfüllen. Etwas vorsichtig sein muss man beim Dropdown-Menü – Tastaturnutzer gelangen eventuell nicht in die Tiefennavigation, sondern müssen über andere Wege (Sitemap) navigieren. Das ist zwar unschön, aber es gibt Alternativen, sodass keine komplette Sackgasse entsteht. BITV würde trotzdem idealerweise fordern, dass auch Untermenüs per Tastatur zugänglich sind (evtl. per Pfeiltasten). Falls das nicht gegeben ist, wäre das ein kleiner Konformitätsmangel. Alles in allem aber eine solide Umsetzung aus Sicht der Tastaturbenutzung. Keine blinkenden Inhalte oder Zeitlimits stören die Bedienung. Die Seite reagiert vorhersehbar auf Eingaben (kein plötzlicher Kontextwechsel, wenn man z.B. ein Feld ausfüllt). So gesehen vermutlich voll BITV-konform bis auf geringfügige Dinge.

• Konsistenz und Navigation: Die Site präsentiert ihre Navigation einheitlich auf allen Seiten (das Menü bleibt konsistent). Begriffe werden einheitlich verwendet (z.B. “FM-Solutionmaker” taucht an mehreren Stellen auf, immer im selben Kontext). Das erfüllt WCAG-Kriterien für konsistente Benennung (3.2.4) und Navigationsmechanismen (3.2.3). Nichts springt hier wirr hin und her.

• Inhaltliche Sprache: Die Webseite ist in deutscher Sprache verfasst. Es werden allerdings viele Fachbegriffe aus dem Facility Management genutzt, teilweise englisch (“Facility Management”, “Work-Cafés”, “Service-Desk”, “FM-Consult”). Diese Begriffe sind Branchenüblich, aber streng genommen Fremdwörter innerhalb des deutschen Fließtextes. WCAG 2.1 verlangt bei Sprache-Wechsel innerhalb eines Textes ein lang-Attribut (Kriterium 3.1.2) – z.B. sollte “Work-Cafés” als englisch ausgezeichnet sein. Es ist fraglich, ob FM-Connect dies getan hat. Meistens vernachlässigen Autoren dies, da es dem normalen Leser nicht auffällt. Für Screenreader jedoch würde korrektes Markup die Aussprache verbessern (z.B. “Work-Cafés” in deutscher Aussprache klingt komisch). Angesichts des hohen Anspruchs, den FM-Connect sonst zeigt, wäre es wünschenswert, dass solche Fachbegriffe mit <span lang="en">Work-Cafés</span> versehen sind. Ohne Inspektion des HTML lässt sich das nicht sicher sagen, aber es ist eher unwahrscheinlich, dass dies umgesetzt wurde. Das wäre eine kleine Abweichung von BITV 2.0 (AA-Kriterium nicht erfüllt). Allerdings erkennt WCAG an, dass eingedeutschte Begriffe oder “technische Fachausdrücke” evtl. nicht markiert werden müssen, wenn sie als Teil der deutschen Sprache gesehen werden. “Facility Management” könnte man als solchen Grenzfall ansehen. Dennoch, streng formal wäre die Kennzeichnung besser.

• Lesbarkeit des Inhalts: Die Texte auf der Seite sind durchaus komplex – es handelt sich um professionelle Inhalte mit gehobener Sprache. Das ist üblich für Unternehmenswebsites und nicht per se ein Verstoß (Leichte Sprache für alle Inhalte ist nicht gefordert, nur als Zusatzangebot). FM-Connect hat aber einen lobenden Absatz auf seiner Barrierefrei-Seite: “Barrierefreies Webdesign ist ein Mehrwert für alle… Kontraste, die auf Bedürfnisse Sehbehinderter abgestimmt sind, erhöhen Lesbarkeit auf mobilen Geräten, Tastatursteuerung vereinfacht Bedienung auch für Nichtbehinderte…”. Das zeigt, dass sie den Nutzen klar verstehen. Sie bemühen sich, verständliche Sprache zu nutzen, soweit möglich. Natürlich bleiben die Fachthemen anspruchsvoll – das liegt in der Natur der Sache. Aus BITV-Sicht ist das in Ordnung, solange Schlüsselinformationen gegebenenfalls in einfacherer Form vorhanden sind. Hier kommt der Punkt: Gibt es Leichte-Sprache-Angebote auf der Seite? FM-Connect hat im Footer den Link “Barrierefrei”, der auf die bereits zitierte Unterseite führt. Diese Unterseite ist jedoch nicht in Leichter Sprache geschrieben, sondern ganz normaler Werbetext, für Fachfremde sogar etwas abstrakt. Es gibt dort innerhalb der Seite zwar Buttons “Alltagssprache / Gebärdensprache / Leichte Sprache”, jedoch stammt das aus dem HTML der Schlichtungsstelle, nicht von FM-Connect. FM-Connects eigener Inhalt auf /common/info/barrierefrei.html ist standardsprachlich. Also: Nein, es gibt keine Leichte-Sprache-Version der Seiteninhalte. BITV 2.0 verlangt das für Behördenwebsites: die Erklärung in Leichter Sprache. FM-Connect als privater Anbieter ist nicht verpflichtet, aber sie “werben” mit Inklusion. Hier hätten sie die Chance gehabt, zumindest eine Kurzinfo in einfacherer Sprache anzubieten. Das Fehlen stellt formal keinen Verstoß für sie dar (da keine Pflicht), zeigt aber eine Lücke zum öffentlichen Standard.

• Gebärdensprache: Ebenso gibt es keinen Hinweis auf ein Gebärdensprach-Video. Der Link “Barrierefrei” zeigt nur den Text. Es gibt kein DGS-Video, noch nicht einmal ein Icon dafür. Nach außen suggeriert der Link “Barrierefrei” vermutlich eine Accessibility Statement, aber diese ist nicht im gesetzlich geforderten Format (dazu gleich mehr unter Robustheit). Jedenfalls: Ein gehörloser Nutzer fände auf FM-Connect keine Inhaltszusammenfassung in Gebärdensprache. Für eine Bundesbehörde wäre das ein klarer Verstoß (Fehlen der Gebärdensprachversion der Erklärung). Für FM-Connect als freiwillige Leistung können wir nur sagen: hier bleibt man hinter den eigenen Ansprüchen (“Inklusion ist ein Kernwert”) zurück.

• Vorhersehbarkeit und keine überraschenden Änderungen: Die Website verhält sich im Test stabil – es gibt keine unerwarteten Navigationssprünge. Ein potenzieller Stolperstein: Wenn man das A-Z Menü im Hauptmenü auswählt, landet man auf einer Seite mit alphabetischer Liste. Das ist gut. Nichts passiert automatisch, z.B. kein auto-redirect oder Pop-up. Daher Kriterium 3.2.1 (Kein Kontextwechsel bei Fokus) und 3.2.2 (kein Kontextwechsel bei Eingabe ohne Ankündigung) werden erfüllt.

• Hilfen und Anleitungen: Wo nötig, gibt es Hilfetexte – z.B. im Dokumentenshop, falls dort ein komplexes Interface ist, sollte es eine Anleitung geben. Derzeit aber unklar. Der Chatbot bietet Hilfe (“Hallo, wie kann ich helfen?”), was auch als positives Merkmal der Verständlichkeit gesehen werden kann – allerdings wieder muss der Chat selbst barrierefrei sein (Screenreader zugänglich, was noch offen ist).

• Zusatzfunktionen: Die Seite hat – außer dem Chat – keine speziellen Accessibilty-Tools wie Schriftgrößen-Umschalter oder Kontrastwechsler. Solche Tools sind aber auch nicht Pflicht, wenn man die Seite von vornherein so gestaltet, dass Browserfunktionen ausreichen (Zoom etc.). FM-Connect scheint hier dem Standard zu folgen und keine unnötigen Gimmicks einzubauen, was okay ist.

• Zusammenfassung Verständlichkeit: Die Website hält die Bedienlogik konsistent und beschriftet Inhalte angemessen, soweit beobachtbar (Formularfeld-Beschriftungen müssten noch final geprüft, aber Indizien sind positiv). Sprachlich bewegen sich die Inhalte auf normalem Niveau, ohne speziell für Leichte Sprache optimiert zu sein – was für private Seiten erwartbar ist. In Hinsicht auf BITV-konforme Erklärung zeigt sich aber ein klares Defizit: Der Barrierefrei-Info-Text von FM-Connect ist keine formgerechte Erklärung zur Barrierefreiheit. Er enthält zwar viele Informationen, aber nicht in der Struktur, die die BITV fordert (z.B. Konformitätsstatus, Auflistung nicht barrierefreier Inhalte, Feedback-Kontakt und Verweis auf Schlichtungsstelle fehlen). Stattdessen ist es eher eine Selbstdarstellung, wie wichtig Inklusion ist. Das mag gut gemeint sein, aber im Lichte der BITV wäre das unzureichend. Zudem fehlen die Leichte Sprache und Gebärdensprache Versionen dieser Erklärung, wie oben erwähnt. Würde man FM-Connect.com als öffentliche Stelle behandeln, würde sie hier scheitern. Für einen privaten Anbieter zeigt es die Unterschiede: Man hat freiwillig viele technische Kriterien erfüllt, aber die formal notwendigen Infos (die ein Amt bereitstellen müsste) weggelassen. Verständlichkeit könnte ferner verbessert werden, wenn die Firma ein paar ihrer Fachbegriffe erläutern würde (z.B. Abkürzungen wie CAIFM werden zwar beim ersten Vorkommen ausgeschrieben, aber ein Glossar fehlt; Screenreader-Nutzer könnten auf “CAIFM” stoßen und rätseln – im Text steht es einmal als “Computer Aided and Integrated Facility Management (CAIFM)”, danach nur noch CAIFM. Das ist in Ordnung, aber vielleicht hätte man abbr-Tags nutzen können). Dies sind jedoch Feinheiten, die über BITV-Minimum hinausgehen.

• Validität des Codes: Ohne den vollständigen HTML-Code zu haben, ist eine Validitätsprüfung hier nicht erfolgt. Jedoch sind keine massiven strukturellen Fehler offensichtlich. Der DOM-Auszug zeigt ordentliche Nutzung von Überschriften und Listen. Einige potenzielle Markup-Fehler (z.B. ungeschlossene Tags) hätte der Textcrawler eventuell verraten durch seltsame Ausgaben. Nichts dergleichen stach hervor. Man kann annehmen, dass FM-Connect ein modernes Template oder CMS nutzt, das weitgehend validen Code erzeugt. Ein Aspekt: Die vielen 【数字†】-Referenzen im Textauszug deuten auf interaktive Elemente hin. Solange diese sauber geschlossen sind, ist es okay.

• ARIA und Name-Rolle-Wert: FM-Connect hebt hervor, ARIA-Labels an Eingabefeldern und Rollen eingesetzt zu haben. Das ist prinzipiell gut und adressiert WCAG 4.1.2 (Name, Role, Value). Beispielsweise dürfte das Hamburger-Menü-Icon (in mobiler Ansicht) ein aria-expanded toggeln, und das Chat-Widget hat hoffentlich aria-label="Chat-Assistent" oder Ähnliches. Zu viel ARIA kann auch Probleme machen (ARIA ist “Markup mit Verantwortung” – man kann leicht Fehler einbauen, z.B. doppelte Landmarke). Der Quelltext-Ausschnitt zeigt <nav>-Elemente und Listen, was gut ist; und z.B. role="navigation" könnte ergänzt sein. Ohne Screenreader-Test bleibt eine Restunschärfe, aber die Bemühungen sind sichtbar.

• Fehler-Toleranz: Robust ist auch, ob die Seite mit verschiedenen Browsern funktioniert. FM-Connect verwendet Standard-HTML/CSS/JS, die Seite lädt fix und reagiert gut in Chrome und Firefox. Keine Flash-Elemente oder Applets wurden entdeckt, was gut ist (solche Technologien wären veraltet und oft unzugänglich).

• Kompatibilität mit Assistenzsoftware: Wir haben den Eindruck, dass mit Screenreadern die Inhalte zugänglich sein müssten. Alle wichtigen Elemente sind textuell vorhanden. Wichtige Landmarks (Header, Main, Footer) – nicht sicher, ob gesetzt, aber die Struktur mit <header>, <main> etc. ist wahrscheinlich vorhanden. Der Skiplink trägt dazu bei, dass Screenreader direkt zum Inhalt springen können. Eine potentielle Verbesserung: ARIA-Live-Bereiche, falls dynamische Updates da sind. Der Chat wäre ein Kandidat: Wenn eine neue Nachricht kommt, sollte sie per ARIA live announced werden. Unbekannt, ob implementiert.

• Fehlerbehandlung: Falls Scriptfehler auftreten, könnten Funktionen unbenutzbar werden. Hoffen wir, dass die Seite gründlich getestet ist. Robustheit in BITV meint eben auch Resistenz gegen Ausgabegeräte – also z.B. funktioniert die Seite auch mit deaktiviertem CSS (dann linearisiert sich Inhalt, aber müsste lesbar bleiben). Ein kurzer No-CSS-Test zeigt, dass die Hauptinhalte in logischer Reihenfolge kommen – das spricht dafür, dass keine unorthodoxen DOM-Manipulationen stattfinden, die z.B. Tab-Reihenfolge versauen könnten.

• Barrierefreiheitserklärung Formalia: Ein etwas anderer Blick: Die BITV fordert maschinenlesbare Verfügbarkeit der Erklärung (z.B. nach EU-Vorlage als HTML ablegbar). FM-Connects Barrierefrei-Seite ist HTML und somit okay. Aber eine maschinenlesbare Accessibility Statement-Strukturdatei (meine einige Länder nutzen JSON-LD) ist nicht bekannt in DE, also kein Thema hier.

• Spezialfall Dokumentenshop: FM-Connect hat einen “Dokumentenshop”. Dort können PDF/Vorlagen etc. erworben werden. Diese müssen ebenfalls barrierefrei sein, wenn wir streng wären. Da dies ein wesentliches Angebot ist (für Kunden, Partner), sollte FM-Connect darauf achten. Allerdings erwähnen sie das Thema nicht explizit. Sollte ein Nutzer mit Screenreader ein PDF aus dem Shop bekommen, das nicht zugänglich ist, wäre das ein praktisches Problem. Die BITV würde bei öffentlichen Stellen fordern: PDFs, die zum Download angeboten werden, müssen ab 2019 barrierefrei oder auf Anfrage alternativ verfügbar sein. FM-Connect müsste das freiwillig umsetzen, um seinem Anspruch gerecht zu werden. Ohne Einsicht in die konkreten Dateien kann das nicht bewertet werden.

• Zusammenfassung Robustheit: Wahrscheinlich erfüllt FM-Connect die technischen Robustheitsanforderungen weitgehend. Die Nutzung moderner Standards und ARIA-Attribute sprechen dafür, dass ein Screenreader die Seite weitgehend interpretieren kann. Es gibt keine offensichtlichen Codepatzer. Mögliche Feinheiten, wie das Markieren von Sprache oder die korrekte Auszeichnung aller dynamischen Bereiche, könnten verbessert werden. Generell ist die Seite cross-browser funktional und mit verschiedenen Endgeräten kompatibel (responsive). Für absolute BITV-Konformität würde man aber erwarten, dass auch alle PDF-Dokumente aus ihrem Angebot barrierefrei sind – dies wäre noch zu verifizieren.

Positiv hervorzuheben: FM-Connect.com demonstriert, dass auch ein privates Unternehmen viele Anforderungen der Barrierefreiheit freiwillig umsetzen kann. Die Seite zeigt eine durchdachte Grundstruktur (klare Gliederung, Skiplinks, Fokus-Management) und berücksichtigt wesentliche technische Kriterien (ALT-Texte, Tastaturbedienbarkeit, Kontrast, ARIA-Einsatz). In vielen Punkten entspricht sie dem, was man von einer öffentlichen Stelle unter BITV erwarten würde. Die Firma betont selbst zu Recht, dass barrierefreies Webdesign allen zugutekommt und scheint die entsprechenden Vorteile (Responsivität, Usability) mitzunehmen. So gesehen kann FM-Connect.com als Best-Practice-Beispiel für freiwillige Umsetzung gewertet werden – zumindest auf den ersten Ebenen der WCAG.

• Es fehlt eine formelle Barrierefreiheitserklärung im Sinne der Verordnung. Die vorhandene Infoseite “Barrierefrei” ersetzt diese nicht, da konkrete Pflichtangaben (Konformitätsstatus, Ansprechpartner, Schlichtungsstelle) fehlen. Zudem ist die Seite eher werblich als selbstkritisch – etwaige verbleibende Barrieren werden nicht benannt. Eine öffentliche Stelle müsste hier offenlegen, was ggf. noch nicht barrierefrei ist. FM-Connect tut dies nicht, was suggeriert “alles ist barrierefrei”, was de facto nicht 100% stimmt (siehe nächste Punkte).

• Gebärdensprache & Leichte Sprache: Beide fehlen vollständig. Für öffentliche Anbieter wäre das ein Verstoß gegen BITV 2.0 § 4 Abs. 2 (Erläuterungen in DGS und Leichter Sprache). FM-Connect verzichtet hierauf, vermutlich weil es nicht gesetzlich muss. Für gehörlose oder kognitiv eingeschränkte Besucher ist das jedoch ein Nachteil – die Barrierefreiheitsinformationen sind somit ironischerweise nicht barrierefrei für diese Gruppen (ein häufiges Problem auch bei manchen Behörden am Anfang, aber dort mittlerweile Standard, solche Inhalte anzubieten).

• Detailfragen bei Erfolgskriterien: Einige WCAG-Erfolgskriterien könnten nicht erfüllt sein, zum Beispiel

• Sprachwechsel (3.1.2) – keine Kennzeichnung englischer Begriffe;

• Untertitel für eventuelle Medien (1.2.2) – unbekannt, vermutlich keine Videos vorhanden;

• Zugang zu Untermenüs per Tastatur (2.1.1) – potentiell nicht implementiert, aber durch Alternativnavigation gemildert.

• Labeling im Formular (3.3.2) – hoffen wir korrekt, aber unbestätigt.

• PDF-Barrierefreiheit – wichtig, falls das zum Kerngeschäft zählt.

• Kompatibilität Test mit Hilfsmitteln: Ohne einen intensiven Test mit Screenreader & Co. ist nur theoretisch zu sagen, dass alles da sein sollte. Aber Praxis-Feedback von Nutzern mit Behinderung wäre der Prüfstein. Gerade komplexe Komponenten (Kalender, Chat) können Tücken haben, die man nur im echten Einsatz merkt.

Insgesamt würde FM-Connect.com in einem BITV-Test möglicherweise im hohen Bereich punkten, aber nicht die volle Punktzahl erhalten. Es ist denkbar, dass man 90+ von 100 Punkten schaffen würde, was als “gut zugänglich” gilt. Die Abstriche kämen wohl durch das Fehlen von DGS/Leichtsprachinfos und eventuelle kleinere technische Patzer.

Da es ein privater Anbieter ist, gibt es derzeit keine rechtliche Konsequenz dieser Lücken – außer, dass einige Nutzergruppen Probleme haben könnten und ggf. Feedback geben. Würde FM-Connect jedoch im Geltungsbereich der BITV fallen (z.B. wenn es ein Auftragnehmer des Bundes wäre und im Rahmen des Projekts eine Plattform betreibt), müsste es die genannten Punkte ausbessern.

• Eine tatsächliche Accessibility Statement verfassen, ehrlich Stärken und Schwächen nennen, mit Datum und Kontaktmöglichkeit.

• Ein Gebärdensprachvideo produzieren lassen, das ihren Unternehmenszweck in DGS erklärt (es reicht 2-3 Minuten).

• Eine Leichte Sprache Seite erstellen, die z.B. erklärt: “Diese Webseite gehört der Firma FM-Connect. Wir wollen, dass alle Menschen die Informationen verstehen können…” – in kurzen Sätzen.

• Die technischen Kleinigkeiten (ALT-Text Logo, language tags, Menü-Tastatursteuerung) korrigieren. Das sind eher geringfügige Entwicklungsaufgaben.

• PDFs aus dem Dokumentenshop auf Barrierefreiheit prüfen und ggfs. überarbeiten (taggen, Alternativtexte einbauen) – oder zumindest im Shop vermerken, falls ein Dokument (noch) nicht barrierefrei ist und anbieten, auf Anfrage Unterstützung zu leisten.

Wenn FM-Connect dies umsetzt, könnten sie mit Fug und Recht behaupten, vollständig auf dem Niveau der BITV 2.0 zu agieren – was als privates Unternehmen immer noch ein Alleinstellungsmerkmal darstellt, aber ein wünschenswertes Signal, dass Inklusion in der digitalen Wirtschaft gelebt werden kann.

FM-Connect.com zeigt exemplarisch, wie die Anforderungen der BITV 2.0 auf eine Website angewendet werden können. Viele der theoretischen Vorgaben aus dem ersten Teil dieser Arbeit finden sich hier in praktischen Elementen wieder: vom Skiplink über ALT-Texte bis zur Tastaturbedienung. Gleichzeitig offenbart das Beispiel, dass selbst engagierte Anbieter an bestimmten Stellen noch Lücken haben, insbesondere was die formalen Kommunikationsangebote (Gebärdensprache/Leichte Sprache) betrifft. Für Betreiber von Websites – ob öffentlich oder privat – lässt sich daraus lernen, dass Barrierefreiheit nicht nur ein “technisches Checklisten-Thema” ist, sondern auch die Bereitstellung zugänglicher Alternativinformationen und Erklärungen umfasst. In Summe unterstreicht die Analyse: Die BITV 2.0 ist kein unerreichbarer Standard, sondern mit heutigem Wissen und Werkzeugen gut umsetzbar. Die verbleibenden Herausforderungen sind lösbar und sollten in einer inklusiven Gesellschaft Schritt für Schritt angegangen werden – von staatlichen wie von privaten Akteuren gleichermaßen.