Overlays und Widgets

Overlay-Widgets: was sie können und was nicht

Ein Skript einbauen, ein Symbol am Bildschirmrand, und die Barrierefreiheit ist erledigt – so lautet das Angebot. Dieser Artikel trennt sachlich, was ein Overlay tatsächlich leistet, wo seine technische Grenze verläuft und wie Sie den Unterschied an Ihrer eigenen Seite nachmessen können.

Aktualisiert am 27.08.2026

Lesezeit ca. 9 Minuten

Von Manuel Reichel, Geschäftsführer der MAP Handelsgesellschaft mbH

Das Wichtigste in Kürze

Ein Overlay ist ein Skript, das im Browser Ihrer Besucherin läuft und die Seite dort zur Laufzeit verändert. Das Dokument, das Ihr Server ausliefert, bleibt unangetastet.
Was es kann: Einstellmöglichkeiten anbieten – Schrift vergrößern, Kontrastmodus, Animationen anhalten. Für einen Teil Ihrer Kundschaft ist das ein echter Komfortgewinn.
Was es nicht kann: erfinden, was nirgends steht. Kein Skript weiß, was auf einem Produktfoto zu sehen ist, wofür ein unbeschriftetes Eingabefeld gedacht ist oder wie eine Gliederung gemeint war.
Für Menschen mit eigener Hilfstechnik ändert sich wenig: Deren Software liest den Original-Quelltext – und dort fehlt weiterhin, was fehlt.
Entscheidend ist, was im Quelltext steht. Die messbaren Verstöße bleiben dort stehen, gleichgültig, was im Browser darübergelegt wird – auch dann, wenn eine Prüfung bei aktivem Widget einzelne davon zunächst nicht anzeigt.
Sinnvoll sein kann ein Widget als Komfort-Angebot neben einer im Code umgesetzten Grundlage – nicht als Ersatz und nicht als Zwischenschritt.
Nachmessen statt glauben: dieselbe Seite einmal mit und einmal ohne aktives Widget prüfen und die Befundlisten vergleichen.

Was ein Overlay technisch ist

Ein Overlay – je nach Anbieter auch Widget, Accessibility-Toolbar oder Barrierefreiheits-Assistent genannt – ist ein kleines Programm, das im Browser Ihrer Besucherin läuft. Eingebaut wird es mit einer einzigen Zeile im Seitengerüst. Diese Zeile lädt ein Skript vom Anbieter, und das Skript legt sich über die bestehende Seite: sichtbar meist als Symbol am Bildschirmrand, das eine Leiste mit Einstellungen aufklappt.

Technisch entscheidend ist, wo dieses Skript arbeitet. Es verändert nicht das Dokument, das Ihr Server ausliefert, sondern die Fassung, die der Browser daraus im Speicher aufgebaut hat – Fachleute nennen sie das DOM. Alles, was ein Overlay tut, geschieht also zur Laufzeit: im Moment des Betrachtens, im Gerät der Besucherin, bei jedem Aufruf neu. Nehmen Sie die eine Zeile wieder heraus, ist die Seite exakt die, die sie vorher war. Es wurde nie eine Zeile Ihres Quelltextes geändert.

Typische Funktionen: Schrift vergrößern, Farben umkehren, Animationen anhalten, Text vorlesen. Manche Widgets schreiben darüber hinaus Attribute in das DOM – etwa eine Beschriftung für eine namenlose Schaltfläche oder einen per Bilderkennung erzeugten Alternativtext.

Der Reiz liegt auf der Hand: Einbau in einer Viertelstunde, ein überschaubarer Monatsbeitrag, keine Entwicklungsarbeit. Neben dem, was eine Umsetzung im Code kostet – die Größenordnungen stehen in Was kostet die BFSG-Umsetzung wirklich? –, sieht das nach einer günstigen Abkürzung aus. Ob sie ans Ziel führt, hängt daran, was ein Skript an dieser Stelle leisten kann.

Was Overlays tatsächlich leisten

Fangen wir mit dem an, was funktioniert – sonst wird die Bewertung unfair.

Ein Overlay bietet Einstellmöglichkeiten, die viele Menschen sonst nicht finden. Wer schlechter sieht, vergrößert die Schrift, ohne die Zoom-Tastenkombination des Browsers zu kennen. Wer starke Kontraste braucht, schaltet einen Kontrastmodus ein, ohne im Betriebssystem etwas umzustellen. All das können Browser und Betriebssysteme seit Jahren auch – nur weiß das ein großer Teil der Kundschaft nicht. Für ältere Kundinnen und Kunden und für alle, die die Bordmittel ihres Geräts nie eingerichtet haben, ist der Gewinn real. Das ist nicht nichts.

Zweitens können Overlays einzelne technische Lücken zur Laufzeit überdecken. Findet das Skript eine Schaltfläche ohne Namen, kann es einen aus dem umgebenden Text ableiten. Findet es ein Bild ohne Alternativtext, kann es eine Bilderkennung darüberlaufen lassen. In einfachen Fällen kommt dabei etwas Brauchbares heraus.

Und es wirkt sofort: Wer heute etwas verbessern möchte und niemanden hat, der Code anfasst, sieht mit einem Widget schneller eine sichtbare Veränderung als mit jedem Umsetzungsprojekt.

Zwischen „wirkt sofort“ und „ist behoben“ liegt trotzdem ein großer Unterschied, und er hat einen technischen Grund: Ein Skript kann umrechnen, umfärben, vergrößern und umsortieren. Erfinden kann es nichts.

Wo die Grenze verläuft – und warum

Jede Overlay-Funktion setzt voraus, dass die nötige Information in der Seite schon vorhanden ist. Fehlt sie, endet die Reichweite des Skripts – ausgerechnet bei den Befunden, die wir in unseren Prüfläufen am häufigsten messen.

Es weiß nicht, was auf dem Bild zu sehen ist

Ein fehlender Alternativtext lässt sich nicht aus der Seite ableiten, weil die Information dort nirgends steht. Bilderkennung liefert eine Beschreibung dessen, was abgebildet ist – nicht dessen, was zählt. Aus dem Foto eines Strickpullovers wird „Person in grünem Oberteil“ statt „Strickpullover Marius in Dunkelgrün, Rückansicht mit Zopfmuster“. Warum dieser Unterschied über den Kauf entscheidet, steht in Alt-Texte für Produktbilder richtig schreiben. Bei Gütesiegeln, Größentabellen und Rabattstörern mit Text im Bild scheitert die Automatik ganz.

Es kann eine Formularbeschriftung nicht aus dem Nichts ableiten

Ein Eingabefeld, dem im Quelltext die Verknüpfung mit seiner Beschriftung fehlt – technisch das label-Element –, ist für Vorlesesoftware ein Feld ohne Namen. Ein Overlay kann raten: vielleicht passt der Text links daneben, vielleicht der graue Platzhalter im Feld. Rät es falsch, ist das Ergebnis schlechter als vorher, denn eine falsche Beschriftung wird mit derselben Bestimmtheit vorgelesen wie eine richtige. Im Checkout, wo Lieferadresse, Zahlungsart und Widerrufshinweis auseinandergehalten werden müssen, ist das kein akademisches Problem.

Es macht aus einer unlogischen Struktur keine logische

Überschriften sind für Vorlesesoftware das Inhaltsverzeichnis der Seite: Viele Nutzerinnen springen von Überschrift zu Überschrift, statt alles anzuhören. Ob eine Zwischenüberschrift zur zweiten oder zur dritten Ebene gehört, ist eine inhaltliche Entscheidung – ein Skript sieht davon nur Schriftgrößen. Dasselbe gilt für Tabellen ohne Kopfzellen und für eine Reihenfolge im Quelltext, die von der optischen abweicht: Neu ordnen kann ein Overlay sie nicht, weil ihm der Sinn fehlt.

Es ändert nichts für Menschen mit eigener Hilfstechnik

Wer blind ist, arbeitet mit einer seit Jahren eingeübten Vorlesesoftware, oft zusammen mit einer Braillezeile. Diese Werkzeuge lesen die Seite selbst und richten sich nach den Standards, nicht nach der Bedienlogik eines einzelnen Anbieters. Für diese Gruppe ändert ein Widget an der Substanz nichts: Ihr Werkzeug liest den Original-Quelltext, und dort fehlt weiterhin, was fehlt. Bringt das Widget zusätzlich eine eigene Vorlesefunktion mit, tritt es sogar in Konkurrenz zu der Software, die die Person bereits benutzt.

Und ein praktischer Punkt: Das Skript muss ankommen

Ein Overlay hängt an einer Datei von einem fremden Server. Wird sie durch einen Inhaltsblocker abgewiesen, im Firmennetz gesperrt oder lädt sie nur langsam, sieht die Besucherin die Seite in ihrem Ausgangszustand. Alles, was ausschließlich im Widget existiert, existiert dann nicht.

Aufgabe für Aufgabe: was geht, was nicht

Die folgende Übersicht sortiert die typischen Aufgaben danach, ob ein Overlay sie zur Laufzeit erledigen kann. „Teilweise“ steht dort, wo es eine sichtbare Wirkung gibt, die aber an Bedingungen hängt.

Was ein Overlay zur Laufzeit erledigen kann – und was nicht
Aufgabe	Kann ein Overlay das?	Warum bzw. warum nicht
Schrift vergrößern, Zeilenabstand erhöhen	Ja	Reine Darstellungsfrage; die Werte werden im Browser überschrieben. Browser und Betriebssystem können das ebenfalls – das Widget macht es leicht auffindbar.
Kontrastmodus zum Umschalten anbieten	Ja	Die Farben werden zur Laufzeit ersetzt. Die im Stylesheet hinterlegten Ausgangsfarben bleiben unverändert – und an ihnen wird gemessen.
Animationen anhalten, Ablenkung reduzieren	Ja	Auch das ist Darstellung. Für Menschen, die auf Bewegung empfindlich reagieren, eine spürbare Erleichterung.
Fehlenden Alternativtext ergänzen	Nein – Bilderkennung ist ein Notbehelf	Die Information steht nirgends in der Seite. Eine Bilderkennung beschreibt das Motiv, nicht den Zweck: Artikelname, Variante und Text im Bild fehlen weiterhin.
Fehlende Formularbeschriftung ergänzen	Teilweise, und mit Risiko	Das Skript kann nur aus dem Umfeld raten. Eine falsch geratene Beschriftung klingt für die Nutzerin genauso verbindlich wie eine richtige und führt im Checkout in die Irre.
Überschriften in eine logische Gliederung bringen	Nein	Die Gliederung ist eine inhaltliche Entscheidung. Sichtbar ist für ein Skript nur die Schriftgröße, und die sagt nichts über die Ebene aus.
Tastaturbedienung herstellen (Menü, Filter, Dialoge)	Nein	Fokusreihenfolge und Fokusfallen entstehen im Aufbau der Seite. Wer keine Maus benutzt, braucht sie dort behoben – überlagern hilft nicht.
Kontrastwerte im Ausgangszustand korrigieren	Nein	Das Widget bietet einen alternativen Modus an, den man erst einschalten muss. Der Zustand, den alle anderen sehen, bleibt, wie er ist.
Nutzung mit vorhandener Hilfstechnik verbessern	Kaum	Vorlesesoftware und Braillezeile lesen den Original-Quelltext. Eigene Vorlesefunktionen treten neben eine Software, die die Person schon eingerichtet hat.
Die messbaren Verstöße aus dem Dokument entfernen	Nein	Das ausgelieferte Dokument wird nicht angefasst. Eine Prüfung findet dieselben Befunde wie vor dem Einbau.

Die Zeilen mit „Ja“ haben etwas gemeinsam: Es geht um Darstellung – Größe, Farbe, Bewegung. Die Zeilen mit „Nein“ ebenfalls: Dort geht es um Information und Struktur, also um das, was eine Redaktion oder eine Entwicklerin beisteuern muss. Entlang dieser Linie verläuft die Grenze.

Der Punkt, der zählt: geprüft wird der Quelltext

Für die Praxis ist eine Frage wichtiger als jedes technische Detail: Was sieht jemand, der Ihre Seite prüft?

Geprüft wird das Dokument, das Ihr Server ausliefert, und das Verhalten der Seite bei der Bedienung. Ein Prüfwerkzeug öffnet die Seite und protokolliert, welches Element gegen welches Erfolgskriterium verstößt: Bild ohne Alternativtext, Eingabefeld ohne Beschriftung, Schaltfläche ohne Namen, Kontrastwert unter dem Schwellenwert. Welche Befunde das in der Praxis sind, steht in Die häufigsten Barrierefreiheits-Fehler.

Ein Overlay entfernt keinen einzigen dieser Befunde aus dem Dokument. Es legt eine zweite Ebene darüber, die im Browser wirkt, solange das Skript läuft. Das Bild ohne Alternativtext ist im Quelltext weiterhin ein Bild ohne Alternativtext. Läuft das Widget während einer automatischen Prüfung mit, können einzelne seiner Laufzeit-Änderungen mitgezählt werden; am ausgelieferten Dokument ändert das nichts – deshalb sagt der Vergleich zweier Durchläufe mehr als ein einzelner.

Der Kern in zwei Sätzen: Ein Overlay verändert nicht die Website, sondern ihre Darstellung im Browser. Die Verstöße bleiben im Quelltext stehen und sind dort weiterhin messbar – von jedem, der prüft.

Dazu kommt die Barrierefreiheitserklärung, die § 14 BFSG für betroffene Dienstleistungen verlangt: Darin ist zu beschreiben, wie es um die Barrierefreiheit des Angebots steht und welche Teile noch nicht barrierefrei sind. Wer dort Anbieterversprechen übernimmt, macht damit eine Aussage über die eigene Seite – und belegen lässt sie sich nur an der eigenen Seite, nicht am Leistungsumfang eines fremden Skripts. Wie eine solche Erklärung aufgebaut ist, steht in Barrierefreiheitserklärung: Muster und Anleitung.

Ob und wie eine Marktüberwachungsbehörde im Einzelfall prüft und was ein Verstoß nach § 37 BFSG bedeutet – dort ist ein Bußgeld von bis zu 100.000 € vorgesehen –, beurteilt eine Anwältin oder ein Anwalt. Unser Punkt ist ein rein technischer: Der Befund bleibt messbar, gleichgültig, was im Browser darübergelegt wird.

Wann ein Overlay trotzdem Sinn ergeben kann

Nach all dem eine faire Antwort auf die Ausgangsfrage: Ja, ein Overlay kann sinnvoll sein – als zusätzliches Komfort-Angebot neben einer im Code umgesetzten Grundlage. Nicht als Ersatz für sie und auch nicht als Zwischenschritt auf dem Weg dorthin.

Der Unterschied ist keine Haarspalterei, sondern der ganze Punkt. Auf einer Seite, deren Bilder beschriftet und deren Formulare mit der Tastatur bedienbar sind, ist ein Widget ein Zusatzangebot für Menschen, die Einstellungen brauchen, aber ihr Gerät nicht umbauen möchten. Auf einer Seite mit vierhundert unbeschrifteten Bildern verdeckt dasselbe Widget nur die Tür, die verschlossen bleibt.

Wenn Sie ein Widget zusätzlich einsetzen, sehen Sie sich drei Dinge an:

Was verspricht der Anbieter?

Wer Komfortfunktionen anbietet und sie auch so nennt, ist ein Werkzeuganbieter – das ist redlich. Wer verspricht, eine Website automatisch in Übereinstimmung mit den WCAG zu bringen, sagt etwas zu, das ein Skript nicht messen kann. Lassen Sie sich zeigen, welche Erfolgskriterien nach Angabe des Anbieters abgedeckt sind und welche ausdrücklich nicht.
Ist das Widget selbst bedienbar?

Die Leiste muss mit der Tastatur erreichbar sein, einen sichtbaren Fokus haben, sich schließen lassen und darf keine Inhalte verdecken – auch nicht auf dem Smartphone. Ein Bedienelement für Barrierefreiheit, das selbst eine Barriere ist, kommt häufiger vor, als man denkt.
Kollidiert es mit vorhandener Hilfstechnik?

Funktionen mit eigener Vorlesefunktion oder eigener Tastatursteuerung greifen in etwas ein, das Ihre Besucherin längst eingerichtet hat. Lassen sich genau diese Funktionen einzeln abschalten, ist das ein gutes Zeichen.

Und eine Offenlegung in eigener Sache: Wir bieten kein Overlay an – auch nicht als schnelle Zwischenlösung und auch nicht auf ausdrücklichen Wunsch. Nicht, weil Widgets grundsätzlich schlecht wären, sondern weil das Geld dafür jeden Monat abfließt, während der Befund im Quelltext unverändert stehen bleibt. Welche Punkte stattdessen zuerst an die Reihe kommen, steht in BFSG-Checkliste für Onlineshops.

Anbieterversprechen selbst prüfen: zwei Scans genügen

Sie müssen niemandem glauben – uns eingeschlossen. Der Unterschied zwischen „überdeckt“ und „behoben“ lässt sich an Ihrer eigenen Seite nachmessen. Sie brauchen dafür nur die Möglichkeit, das Widget kurz zu deaktivieren.

Zwei Scans: mit aktivem Widget und ohne

Lassen Sie dieselbe Seite zweimal automatisch prüfen – einmal mit eingebundenem Widget, einmal ohne – und vergleichen Sie Anzahl und Art der Befunde. Bleibt die Liste gleich, hat das Skript an Ihrem Dokument nichts geändert. Ob und wie viel sich ändert, sehen Sie in wenigen Minuten – an Ihrer eigenen Seite statt in einer Produktbroschüre.
Verschwundene Befunde einzeln ansehen

Fällt tatsächlich etwas weg, sehen Sie sich genau diese Stellen an: Welcher Alternativtext oder welche Beschriftung steht jetzt dort, und stimmt sie inhaltlich? Ein Befund, der durch einen falsch geratenen Text verschwindet, ist kein behobener Befund – er ist nur nicht mehr zählbar.
Die Seite ohne das fremde Skript aufrufen

Blockieren Sie das Widget-Skript im Browser oder rufen Sie die Seite in einer Umgebung auf, in der Fremdskripte nicht geladen werden. Was Sie dann vor sich haben, ist der Ausgangszustand Ihrer Seite – und der Zustand, den ein Teil Ihrer Besucherinnen ohnehin sieht.
Der Tastatur-Test

Legen Sie die Maus beiseite und gehen Sie mit der Tabulatortaste durch Menü, Filter und Bestellstrecke – erst mit, dann ohne Widget. Wo Sie hängen bleiben oder nicht erkennen, wo Sie gerade sind, liegt ein Problem, das kein Overlay löst.

Dazu drei Fragen an den Anbieter: Welche Erfolgskriterien der WCAG 2.1 AA deckt das Produkt nach eigener Angabe ab – und welche ausdrücklich nicht? Was geschieht mit der Barrierefreiheit unserer Seite, wenn wir das Abo kündigen? Wer trägt das Risiko, wenn eine Behörde oder ein Wettbewerber die Seite beanstandet? Die Antworten sagen mehr als jede Produktseite.

Was auch unsere Prüfung nicht leistet

Zum Schluss der Teil, der uns selbst betrifft – sonst wäre der ganze Artikel ein bequemes Argument.

Automatisierte Prüfung deckt nur die maschinell prüfbaren Kriterien ab. Eine vollständige Konformitätsbewertung erfordert zusätzlich manuelle Prüfung. Das gilt für jedes Werkzeug am Markt und für unseres genauso.

Ein Scan sieht, ob ein Alt-Attribut vorhanden ist – nicht, ob der Text etwas taugt. Er misst Kontrastwerte – nicht, ob eine Fehlermeldung im Bestellformular weiterhilft. Er erkennt eine fehlende Beschriftung – nicht, ob die Reihenfolge im Checkout für jemanden nachvollziehbar ist, der die Seite nur hört. Diese Fragen beantwortet ein Mensch.

Der Unterschied zum Versprechen einer automatischen Lösung liegt also nicht darin, dass wir alles messen könnten. Er liegt darin, was mit dem Gemessenen geschieht: Wir beheben die messbaren technischen Verstöße nach WCAG 2.1 AA / EN 301 549 im Quelltext, und wir benennen, was danach offen bleibt. Ein so behobener Befund ist nicht überdeckt, sondern nicht mehr vorhanden – nachweisbar mit einem zweiten Scan.

Barrierefreiheit ist damit kein einmaliges Ergebnis, sondern ein Zustand, den man hält: Jedes neue Produktbild und jedes Theme-Update kann neue Befunde bringen. Auch deshalb liegt die Arbeit im Code und nicht in einer Ebene darüber – nur was im Quelltext steht, ist nach dem nächsten Update noch da.

Häufige Fragen

Macht ein Overlay meine Website barrierefrei?

Nein. Es fügt Einstellmöglichkeiten hinzu und kann einzelne Lücken im Browser überdecken. Die Ursachen – fehlende Alternativtexte, unbeschriftete Formularfelder, eine unlogische Gliederung, nicht bedienbare Menüs – bleiben im Quelltext bestehen und sind dort weiterhin messbar. Für Menschen, die mit eigener Vorlesesoftware arbeiten, ändert sich dadurch wenig, weil ihr Werkzeug den Original-Quelltext liest.

Reicht ein Overlay als Übergangslösung, bis der Umbau fertig ist?

Als Komfortangebot kann es parallel laufen. Als Übergang im Sinne von „damit ist die Sache vorerst erledigt“ trägt es nicht: Die Befunde sind währenddessen unverändert messbar. Wer ohnehin umbauen will, spart mit dem Widget keinen einzigen Arbeitsschritt – er verschiebt ihn und zahlt in der Zwischenzeit ein Abo.

Wir haben bereits ein Widget im Einsatz. Müssen wir es entfernen?

Aus technischer Sicht besteht dazu kein Anlass – nur nimmt Ihnen das Widget auch nichts ab. Sehen Sie sich zuerst an, ob es selbst mit der Tastatur bedienbar ist und ob es keine Inhalte verdeckt. Prüfen Sie außerdem, ob Sie Anbieterversprechen auf Ihrer Seite oder in Ihrer Barrierefreiheitserklärung wiederholen, die Sie selbst nicht belegen können. Parallel dazu gehen Sie die Grundlage im Code an. Ob eine Aussage auf Ihrer Website im Einzelfall angreifbar ist, beurteilt eine Anwältin oder ein Anwalt.

Warum lehnen viele Menschen mit Behinderung Overlays ab?

Weil das Werkzeug an ihrer Arbeitsweise vorbeigeht. Wer eine Vorlesesoftware oder eine Braillezeile benutzt, hat Stimme, Tempo und Tastenbefehle über Jahre eingerichtet. Ein Widget bringt eine zweite Bedienlogik ins Spiel, die auf jeder Website anders aussieht, und kann der vorhandenen Software ins Gehege kommen. Vor allem aber fehlt dem Widget dieselbe Information, die im Quelltext fehlt.

Sieht ein Prüfwerkzeug, ob ein Overlay aktiv ist?

Ein Scan protokolliert, was er in der Seite vorfindet. Läuft das Widget-Skript mit, können dessen Änderungen im Browser mitgemessen werden. Genau deshalb ist der Vergleich zweier Durchläufe – einmal mit, einmal ohne Widget – aussagekräftiger als ein einzelner Scan: Er zeigt, was aus dem ausgelieferten Dokument selbst stammt und was nur eine Ebene darüber ist.

Was kostet ein Overlay im Vergleich zur Umsetzung im Code?

Ein Widget wird als Abo bezahlt, also Monat für Monat, solange es eingebunden ist. Die Umsetzung im Code ist ein einmaliger Aufwand; das Ergebnis steht danach in Ihrem Quelltext und bleibt dort, auch wenn Sie den Dienstleister wechseln. Der ehrliche Vergleich lautet deshalb nicht „günstig gegen teuer“, sondern „laufende Miete für eine Ebene darüber“ gegen „einmalige Arbeit an der Sache selbst“.

Weiterlesen

Die häufigsten Barrierefreiheits-Fehler – die Befunde, die ein Overlay im Quelltext stehen lässt.
BFSG-Checkliste für Onlineshops – was stattdessen zuerst an die Reihe kommt – Punkt für Punkt.
Was kostet die BFSG-Umsetzung wirklich? – Größenordnungen für die Umsetzung im Code statt Abo für ein Widget.
Alt-Texte für Produktbilder richtig schreiben – warum kein Skript erfinden kann, was auf dem Bild zu sehen ist.
Zurück zur Ratgeber-Übersicht

Sehen Sie nach, was unter dem Widget liegt

Der kostenlose Erstscan prüft Ihre Seite so, wie ein Prüfwerkzeug sie vorfindet, und listet die messbaren Befunde auf – die Liste, an der ein Overlay nichts ändert. Wir beheben die messbaren technischen Verstöße nach WCAG 2.1 AA / EN 301 549 im Quellcode und belegen den Unterschied mit einem zweiten Scan.

Kostenlosen Erstscan anfordern

Dieser Artikel ist eine technische Einordnung und keine Rechtsberatung. Quellen: WCAG 2.1, Erfolgskriterien 1.1.1 Nicht-Text-Inhalte, 1.3.1 Info und Beziehungen, 2.1.1 Tastatur, 3.3.2 Beschriftungen oder Anweisungen und 4.1.2 Name, Rolle, Wert (Stufe A) sowie 1.4.3 Kontrast (Minimum) und 2.4.6 Überschriften und Beschriftungen (Stufe AA); EN 301 549, Abschnitte 9.1.1.1, 9.1.3.1, 9.1.4.3, 9.2.1.1, 9.2.4.6, 9.3.3.2 und 9.4.1.2; Gesetz zur Stärkung der Barrierefreiheit von Produkten und Dienstleistungen (BFSG), insbesondere §§ 3, 14 und 37; Barrierefreiheitsstärkungsgesetz-Verordnung (BFSGV). Die beschriebenen Funktionsweisen sind gattungstypisch; einzelne Anbieter werden bewusst nicht genannt.