Accessibility-Overlays oder echte Behebung: So bewerten Sie Angebote

Wenn Sie zwischen einem Accessibility-Overlay und der Behebung von Barrieren entscheiden, vergleichen Sie nicht zuerst Funktionslisten oder Lizenzmodelle. Verlangen Sie einen Nachweis, dass Nutzer:innen Ihre wesentlichen Aufgaben tatsächlich erledigen können: Informationen finden, ein Konto verwenden, ein Formular korrigieren oder einen Kauf abschließen. Ein zusätzliches Bedienfeld kann einzelne Einstellungen erleichtern. Es beweist aber weder die Zugänglichkeit dieser Abläufe noch die Erfüllung rechtlicher Anforderungen. Entscheidend sind die Wirkung im konkreten System, die Grenzen der Lösung und die überprüfbare Verantwortung für verbleibende Barrieren.

Für die Beschaffung bedeutet das: Bevorzugen Sie Angebote, die Ursachen, Eingriffe, Tests und Betrieb nachvollziehbar verbinden. Eine technische Zusatzschicht kann dabei eine begrenzte Rolle spielen; sie darf jedoch nicht die Prüfung der eigentlichen Website ersetzen. Die folgenden Beispiele sind ausdrücklich hypothetische Beschaffungssituationen und keine dokumentierten Kund:innenergebnisse.

1. Klären Sie zuerst, was tatsächlich angeboten wird

Der Begriff Overlay wird für unterschiedliche Produkte verwendet. Manche stellen ein Bedienfeld für Schriftgröße, Kontrast oder Bewegungsreduktion bereit. Andere verändern nach dem Laden Seitenelemente, ergänzen Attribute oder versuchen, Fehler automatisch zu korrigieren. Wieder andere Angebote kombinieren Software mit manueller Prüfung und Entwicklungsleistungen. Bewerten Sie deshalb die einzelnen Leistungen statt nur die Produktbezeichnung. Lassen Sie erläutern, welche Änderungen tatsächlich stattfinden, wann sie ausgeführt werden und welche Seitenteile unberührt bleiben.

Mit echter Behebung ist hier eine Korrektur an der verantwortlichen Quelle gemeint: etwa am HTML, an einer gemeinsamen Komponente, an CSS-Regeln, an redaktionellen Inhalten oder an der Prozesslogik. Ein Formularfeld erhält beispielsweise eine korrekt verknüpfte Beschriftung im Template statt nur einen nachträglich erratenen Namen. Auch eine Quellkorrektur braucht Tests. Ihr Vorteil ist nicht automatische Fehlerfreiheit, sondern eine nachvollziehbare Grundlage, die unabhängig von einem zusätzlichen Laufzeitskript gepflegt werden kann.

2. Machen Sie Nutzerwege zur Grundlage der Ausschreibung

Eine Liste von URLs reicht als Leistungsbeschreibung selten aus. Beschreiben Sie Aufgaben mit Startpunkt, notwendigen Schritten und erwartetem Ergebnis. Für einen hypothetischen Onlineshop könnte ein Weg von der Produktsuche über die Variantenauswahl bis zur Bestellprüfung führen. Dazu gehören auch ausverkaufte Varianten, leere Suchergebnisse, ungültige Eingaben und eine abgelaufene Sitzung. Gerade diese Zustände fehlen häufig in Vorführungen, obwohl sie über die selbstständige Nutzung entscheiden.

Halten Sie zusätzlich fest, welche gemeinsamen Komponenten, Sprachen, Dokumente und externen Dienste im Umfang liegen. Fragen Sie ausdrücklich nach eingebetteten Zahlungsdiensten, Terminbuchungen und Cookie-Dialogen. Wenn ein Angebot nur die Startseite oder ausgewählte Standardzustände untersucht, ist das kein gleichwertiger Ersatz für einen prozessorientierten Audit. Eine repräsentative Stichprobe kann sinnvoll sein, muss ihre Auswahl und Grenzen aber offenlegen. Das Abnahmeprotokoll sollte später dieselben Nutzerwege wieder aufgreifen.

3. Trennen Sie Komfortfunktionen von notwendiger Zugänglichkeit

Zusätzliche Einstellungen können nützlich sein, etwa wenn jemand direkt auf einer Website größere Schrift wählen möchte. Viele Nutzer:innen verwenden jedoch bereits Browser-Zoom, Betriebssystemeinstellungen, eigene Farbschemata oder assistive Technologien. Eine Website sollte diese Arbeitsweisen unterstützen, ohne dass zuerst ein spezielles Menü gefunden und verstanden werden muss. Ein zweites Einstellsystem kann vorhandene Präferenzen ergänzen, sollte sie aber nicht unbemerkt überschreiben oder eine notwendige Grundfunktion verstecken.

Prüfen Sie deshalb die zugrunde liegende Darstellung ohne aktiviertes Zusatzprofil. Die WCAG 2.2 behandeln unter anderem Textvergrößerung auf 200 Prozent und Reflow bei einer Breite von 320 CSS-Pixeln, jeweils im Rahmen der betreffenden Kriterien und Ausnahmen. Sie schreiben keine bestimmte Schriftfamilie vor. Auch die Anforderungen an Textabstände bedeuten, dass entsprechende Nutzer:innenanpassungen ohne Inhalts- oder Funktionsverlust möglich sein müssen, nicht dass jede Website diese Abstände standardmäßig verwenden muss. Ein angebotenes Schriftmenü belegt diese Eigenschaften nicht.

4. Lassen Sie jede Korrektur technisch erklären

Verlangen Sie für typische Fehler eine Gegenüberstellung: Was ist die Ursache, welcher Eingriff erfolgt und woran wird die Wirkung erkannt? Wenn ein Symbolbutton keinen zugänglichen Namen besitzt, kann eine gezielte Ergänzung helfen. Ein automatisch erzeugter Name ist jedoch nur dann brauchbar, wenn er die tatsächliche Funktion beschreibt. Bei zwei identischen Symbolen für unterschiedliche Aktionen kann aus dem Aussehen allein keine verlässliche Bedeutung abgeleitet werden. Die fachliche Entscheidung bleibt notwendig.

Laufzeitkorrekturen können außerdem von Ladefolge, Selektoren und dynamischen Aktualisierungen abhängen. Fragen Sie, ob eine Korrektur nach einem Filterwechsel erhalten bleibt, ob sie beim erneuten Öffnen eines Dialogs doppelt ausgeführt wird und wie Änderungen am Frontend erkannt werden. Eine dokumentierte Zwischenlösung kann bei einem schwer veränderbaren Altsystem vertretbar sein. Sie benötigt jedoch einen klaren Geltungsbereich, Regressionstests und einen Plan für ihre Ablösung oder dauerhafte Wartung. „Automatisch behoben“ ist ohne diese Informationen keine belastbare Leistungsbeschreibung.

5. Verlangen Sie mehr als einen automatischen Prüfbericht

Automatisierte Prüfungen sind wertvoll, um bestimmte technische Auffälligkeiten schnell und wiederholbar zu finden. Sie können beispielsweise auf fehlende Beschriftungen oder bestimmte Kontrastprobleme hinweisen. Sie entscheiden aber nicht zuverlässig, ob eine Beschriftung verständlich ist, eine Fokusreihenfolge sinnvoll bleibt oder eine Aufgabe insgesamt gelingt. Die W3C-Hinweise zur Auswahl von Evaluierungswerkzeugen stellen klar, dass Werkzeuge nicht alle Aspekte der Barrierefreiheit bewerten können und menschliche Prüfung notwendig bleibt.

Ein überzeugendes Angebot benennt deshalb automatisierte und manuelle Verfahren getrennt. Es beschreibt Tastaturtests, die Prüfung mit ausgewählten Screenreader-Browser-Kombinationen sowie die Kontrolle bei Vergrößerung und schmalen Ansichten. Fordern Sie zu jedem Befund reproduzierbare Schritte, den betroffenen Zustand, die Auswirkung und eine begründete Zuordnung zum Prüfmaßstab. Ein grünes Dashboard oder ein einzelner Gesamtscore ersetzt diese Evidenz nicht. Umgekehrt beweist die Begrenzung automatisierter Tests nicht, dass jedes Overlay schädlich wäre; sie begrenzt lediglich, welche Aussagen sich daraus ableiten lassen.

6. Prüfen Sie Formulare bis zur erfolgreichen Korrektur

Angenommen, ein hypothetisches Anfrageformular markiert eine ungültige Telefonnummer nur durch einen roten Rahmen. Ein Zusatzmodus könnte die Farben ändern, löst damit aber weder die fehlende Fehlermeldung noch deren Zuordnung zum Feld. Eine belastbare Behebung umfasst eine verständliche Beschriftung, erforderliche Hinweise und eine konkrete Korrekturanweisung. Bereits eingegebene Daten sollten bei der Fehlerkorrektur erhalten bleiben. Die WAI Forms Tutorial erläutern die Zusammenhänge zwischen Beschriftungen, Gruppierung, Anleitung und Rückmeldungen.

Für die Abnahme lassen Sie die prüfende Person bewusst einen Fehler auslösen, ihn mit Tastatur und Screenreader erkennen und anschließend korrigieren. Dokumentiert werden nicht nur die sichtbare Meldung, sondern auch ihre programmatische Beziehung und die erfolgreiche Fortsetzung. Danach folgt der Erfolgszustand: Ist klar, ob die Anfrage übermittelt wurde? Kann eine notwendige Bestätigung wahrgenommen werden? Diese Prüfung verhindert, dass ein Angebot nur den fehlerfreien Idealablauf verbessert und gerade jene Situationen ausspart, in denen Nutzer:innen Unterstützung benötigen.

7. Testen Sie Dialoge und dynamische Zustände

Ein hypothetischer Warenkorb öffnet sich als modaler Dialog. Obwohl die Schließen-Schaltfläche nun einen Namen hat, springt der Tastaturfokus weiterhin in den dahinterliegenden Seiteninhalt. Das Problem ist damit nicht behoben. Ein modaler Dialog benötigt ein stimmiges Verhalten beim Öffnen, eine passende anfängliche Fokusposition, eine innerhalb des Dialogs geführte Tab-Navigation und eine sinnvolle Rückgabe des Fokus beim Schließen. Die ARIA Authoring Practices Guide: Dialog (Modal) Pattern beschreiben dieses Zusammenspiel einschließlich des Schließens mit Escape. ARIA-Attribute allein implementieren es nicht.

Die Abnahme sollte den Dialog öffnen, vollständig bedienen, schließen und erneut öffnen. Zusätzlich sind unterschiedliche Inhalte zu prüfen, etwa ein leerer Warenkorb und eine Fehlermeldung nach einer Mengenänderung. Bei dynamischen Filterergebnissen ist gesondert zu bewerten, ob eine qualifizierende Statusmeldung ohne Fokusverschiebung programmatisch erkennbar ist. Nicht der gesamte neue Ergebnisinhalt muss automatisch vorgelesen werden. Entscheidend ist eine Rückmeldung, mit der Nutzer:innen die Änderung verstehen und ihren nächsten Schritt selbst bestimmen können.

8. Bewerten Sie Drittanbieterrisiken unabhängig vom Werbeversprechen

Ein extern geladenes Skript erweitert die technische Abhängigkeit Ihrer Website. Klären Sie, welche Daten verarbeitet werden, welche Netzwerkverbindungen entstehen, welche Unterauftragnehmer beteiligt sind und ob Konfigurationen oder Nutzungsereignisse an den Anbieter übertragen werden. Das sind Prüfaufträge, keine Unterstellung eines bestimmten Verhaltens. Datenschutz, Informationssicherheit und Entwicklung sollten diese Fragen gemeinsam beurteilen. Auch Konflikte mit Content Security Policy, Consent-Management und anderen Skripten gehören auf die Prüfliste.

Testen Sie außerdem den Ausfall: Was passiert, wenn der Dienst blockiert ist, langsam antwortet oder nicht mehr lizenziert wird? Kritische Aufgaben sollten nicht unbemerkt von einer vermeintlichen Komfortfunktion abhängig werden. Vereinbaren Sie einen kontrollierten Abschaltweg, Zuständigkeiten bei Störungen und Informationen über relevante Produktänderungen. Wenn ein Anbieter seine Wirkung ausschließlich bei aktivierter Erweiterung vorführt, verlangen Sie zusätzlich einen Vergleich ohne Erweiterung. Nur so wird sichtbar, welche grundlegenden Barrieren bestehen bleiben und welches Risiko nach einem Vertragsende zurückkehrt.

9. Übersetzen Sie Leistungsversprechen in Vertragsbestandteile

Ein Vertrag sollte nicht nur „Barrierefreiheit verbessern“ versprechen. Er sollte den Prüfmaßstab, die untersuchten Bestandteile, die zu behebenden Befunde und die geforderten Nachweise benennen. Bei WCAG 2.2 AA gehören die jeweils anwendbaren Erfolgskriterien der Stufen A und AA dazu. EN 301 549 ist damit nicht austauschbar. Ebenso ist ein technischer Audit keine vollständige rechtliche Konformitätsprüfung. Trennen Sie technische Abnahme, organisatorische Pflichten und gegebenenfalls erforderliche rechtliche Beratung.

Für Österreich gilt das BaFG seit 28. Juni 2025 für die erfassten Dienstleistungen, nicht automatisch für jede Website. Für die Einordnung Ihres Angebots nutzen Sie den Österreich-Leitfaden zur barrierefreien Website, statt aus der Existenz eines Webauftritts allein eine Verpflichtung abzuleiten. Im Beschaffungsvertrag sollten außerdem Nachbesserung, Retest, Zugang zum Issue-Tracker und Übergabe der Änderungen geregelt sein. Lassen Sie offene Punkte ausdrücklich ausweisen, statt sie unter einer pauschalen Aussage wie „vollständig abgesichert“ verschwinden zu lassen.

10. Vereinbaren Sie eine Abnahme, die Fehler wiederfinden kann

Ein brauchbarer Nachweis enthält eine Befundkennung, die betroffene Version, Voraussetzungen, Prüfschritte, erwartetes Verhalten und tatsächliches Ergebnis. Screenshots können ergänzen, reichen für Fokusverhalten oder Screenreader-Ausgaben aber allein nicht aus. Halten Sie deshalb die verwendete Testumgebung und die Beobachtungen fest. Ein Befund darf erst geschlossen werden, wenn dieselbe zuvor blockierte Aufgabe nachweislich gelingt und die Änderung keine erkennbaren neuen Probleme im zugehörigen Ablauf erzeugt.

Beim Retest werden sowohl die konkreten Korrekturen als auch benachbarte Zustände geprüft. Wurde eine gemeinsame Button-Komponente geändert, betrifft die Kontrolle nicht nur den ursprünglich gemeldeten Button. Wurde ein Formular umgebaut, prüfen Sie auch Fehlermeldungen und Bestätigung. Vereinbaren Sie, wer die Retests durchführt und wie Meinungsverschiedenheiten bewertet werden. Eine unabhängige Prüfung kann hilfreich sein, ist aber kein Ersatz für präzise Kriterien. Auch Nutzer:innentests ergänzen die technische Bewertung sinnvoll, ohne sämtliche Kriterien allein abzudecken.

11. Vergleichen Sie den gesamten Betriebsaufwand

Stellen Sie wiederkehrende Lizenzkosten, initiale Analyse, Entwicklungsaufwand, Tests, redaktionelle Arbeit und Wartung getrennt gegenüber. Eine scheinbar kleine Einführung kann dauerhafte Abhängigkeiten schaffen; eine umfangreichere Quellenkorrektur kann ihrerseits regelmäßige Pflege benötigen. Ohne erfundene Einsparungszahlen lässt sich dennoch sinnvoll vergleichen: Welche wiederkehrenden Tätigkeiten entstehen, wer übernimmt sie und welche Änderungen lösen neue Tests aus? Besonders wichtig ist der Aufwand nach einem Relaunch oder dem Austausch eines Drittanbieterdienstes.

Verlangen Sie einen Übergabeplan für Komponenten, Dokumentation und redaktionelle Regeln. Die W3C-Empfehlungen zu Sustaining Accessibility betonen die dauerhafte Verankerung durch Verantwortlichkeiten, Prüfungen und Kompetenzaufbau. WCAG schreibt dabei keinen universellen monatlichen oder jährlichen Audit-Takt vor. Wählen Sie Ihre Prüfroutine nach Änderungsfrequenz und Risiko: Ein neuer Checkout benötigt andere Aufmerksamkeit als eine unveränderte Kontaktseite. Entscheidend ist, dass relevante Änderungen nicht ungeprüft in den Betrieb gelangen.

12. Treffen Sie die Entscheidung anhand offener Nachweise

Eine praktische Vergleichsmatrix verbindet jeden wichtigen Nutzerweg mit Ursache, vorgeschlagener Maßnahme, Eingriffsort, verantwortlicher Stelle und Abnahmenachweis. Ergänzen Sie Abhängigkeiten und verbleibende Einschränkungen. Dadurch werden unterschiedliche Angebote vergleichbar: Ein Bedienfeld mit Präferenzen, eine temporäre Laufzeitkorrektur und eine nachhaltige Komponentenüberarbeitung lösen möglicherweise verschiedene Aufgaben. Sie müssen nicht künstlich als gleichwertige Alternativen behandelt werden. Auch ein kombiniertes Angebot kann sinnvoll sein, wenn seine Leistungen sauber getrennt und überprüfbar sind.

Warnsignale sind nicht allein bestimmte Produktkategorien, sondern unbegrenzte Versprechen ohne definierten Umfang, verweigerte Testdetails und eine Abnahme ausschließlich anhand eines Scores. Positiv sind dagegen klare Grenzen, nachvollziehbare Fehlerbeispiele und die Bereitschaft, einen kritischen Nutzerweg im Pilotversuch prüfen zu lassen. Beauftragen Sie zunächst die Evidenz, die Ihnen für die Entscheidung fehlt. Das kann ein unabhängiger Audit, ein begrenzter technischer Versuch oder die Prüfung einer besonders wichtigen Komponente sein.

Häufige Fragen

Ist jedes Accessibility-Overlay ungeeignet?

Nein. Einzelne Funktionen können hilfreich sein. Entscheidend ist, welche Probleme nachweislich gelöst werden, welche bestehen bleiben und ob das Produkt vorhandene Bedienweisen unterstützt. Die Produktkategorie allein ersetzt keine Prüfung.

Reicht ein fehlerfreier automatisierter Scan?

Nein. Er belegt nur, dass das eingesetzte Werkzeug unter den jeweiligen Bedingungen keine von ihm erkennbaren Fehler gefunden hat. Tastaturbedienung, verständliche Rückmeldungen und vollständige Nutzerwege benötigen zusätzliche Prüfung.

Darf eine Übergangslösung Teil des Angebots sein?

Ja, sofern Umfang, Grenzen, Wartung und Ausstieg geregelt sind. Sie sollte nicht als dauerhafte Behebung ausgegeben werden, wenn die zugrunde liegende Barriere nach dem Abschalten unverändert zurückkehrt.

Was sollte zuerst beauftragt werden?

Wenn eine belastbare Bestandsaufnahme fehlt, beginnen Sie mit einem klar abgegrenzten Audit Ihrer wichtigsten Abläufe. Auf dieser Grundlage lassen sich Behebung, ergänzende Werkzeuge und Retests sachlich ausschreiben.

Ihr nächster Schritt mit Zensations

Zensations ist ein 2010 in Wien gegründetes Digitalstudio. Wenn Sie Angebote vergleichen oder bestehende Maßnahmen überprüfen möchten, bietet ein Barrierefreiheit-Audit einen sinnvollen Ausgangspunkt für nachvollziehbare Prioritäten und Abnahmekriterien. Für die anschließende Arbeit an Gestaltung, Technik und Prozessen finden Sie weitere Informationen unter Accessibility. Ziel ist eine überprüfbare Verbesserung Ihrer konkreten Nutzerwege, keine pauschale Konformitäts- oder Rankinggarantie.

Quellen

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 – normativer technischer Prüfmaßstab.
• W3C WAI: Selecting Web Accessibility Evaluation Tools – Möglichkeiten und Grenzen von Prüfwerkzeugen.
• W3C WAI: Forms Tutorial – zugängliche Formulare und Rückmeldungen.
• W3C WAI: Dialog (Modal) Pattern – Tastatur- und Fokusverhalten modaler Dialoge.
• W3C WAI: Sustaining Accessibility – Barrierefreiheit im laufenden Betrieb.