| 5.2 Aktivierung von Barrierefreiheitsfunktionen |
Prüft, ob Nutzer angebotene zusätzliche Barrierefreiheits-Funktionen (z. B. Kontrastmodus, Vorlesefunktion, Inhalte in Leichter Sprache) leicht erkennen und einschalten könnenbitvtest.debitvtest.de. Schalter für solche Funktionen müssen selbst barrierefrei (z. B. kontrastreich und per Screenreader auslesbar) gestaltet seinbitvtest.de. |
EN 301 549, 5.2 (Aktivierung von Barrierefreiheitsfunktionen) |
Entspricht der EN-Forderung. Der BITV-Prüfschritt konkretisiert, dass Bedienelemente zum Aktivieren der zus. Funktionen selbst zugänglich sein müssenbitvtest.de. |
| 5.3 Biometrie |
Prüft, ob bei Nutzung biometrischer Verfahren (Fingerabdruck, Gesichtserkennung etc.) stets eine alternative Login-Möglichkeit angeboten wird. Wenn z. B. eine biometrische Identifizierung verlangt wird, muss alternativ eine nicht-biometrische Methode (z. B. Passwort) oder eine zweite biometrische Methode nutzbar seinbitvtest.de. |
EN 301 549, 5.3 (Biometrie) |
Entspricht der EN-Forderung. Die Norm verlangt, dass Web-Angebote biometrische Authentifizierung nicht exklusiv nutzen, sondern immer eine Alternative für Personen anbieten, die die primäre Methode nicht verwenden könnenbitvtest.de. |
| 5.4 Erhaltung von Barrierefreiheitsinformationen bei Konvertierung |
Prüft, ob semantische Informationsstrukturen (Überschriften, Listen usw.) bei einer Konvertierung oder Speicherung von Web-Inhalten in andere Formate erhalten bleibenbitvtest.de. Beispielsweise sollen beim Export einer HTML-Seite als PDF die Auszeichnungen (z. B. Überschriften) nicht verloren gehenbitvtest.de. |
EN 301 549, 5.4 (Erhaltung von Barrierefreiheits-Informationen bei Konvertierung) |
Entspricht der EN-Forderung. In der Praxis bieten Web-Angebote solche Konvertierungsfunktionen bislang selten anbitvtest.de. (Falls die Konvertierung durch den Browser erfolgt, fällt dies nicht in den Prüfumfangbitvtest.de.) |
| 6.1 Audiobandbreite für Sprache |
Prüft, ob bei Web-Angeboten mit Sprachkommunikation die Audioqualität mindestens einem festgelegten Standard entspricht (Orientierung am Standard der internetbasierten Telefonie)bitvtest.de. Eine ausreichende Bandbreite stellt sicher, dass Sprache für Nutzer mit Hörbehinderung klar verständlich ist. |
EN 301 549, 6.1 (Audiobandbreite für Sprache) |
Entspricht der EN-Forderung. Die Norm setzt einen verbindlichen Mindeststandard für die Audioqualität festbitvtest.de. (Eine Verschlechterung durch schlechte Internetverbindung führt nicht zur Fehlbewertung, da vom Web-Anbieter nicht zu beeinflussenbitvtest.de.) |
| 6.2.1.1 Textkommunikation in Echtzeit |
Prüft, ob Systeme mit Echtzeit-Sprachkommunikation zusätzlich eine Echtzeit-Textkommunikation (RTT – Real-Time Text) unterstützenbitvtest.de. D. h. Teilnehmer sollen während der Eingabe eines Textes diesen nahezu verzögerungsfrei live an andere übertragen können, ohne erst einen Chat-Nachricht abzuschickenbitvtest.de. |
EN 301 549, 6.2.1.1 (Textkommunikation in Echtzeit) |
Entspricht der EN-Forderung. Die Norm verlangt diese parallele Textkommunikation unmissverständlich, obwohl dies von aktuellen Webkonferenz-Systemen noch kaum unterstützt wirdbitvtest.de. |
| 6.2.1.2 Gleichzeitige Sprache und Text |
Prüft, ob Teilnehmer, die Echtzeit-Text statt Sprache nutzen, in Konferenzfunktionen gleichberechtigt behandelt werdenbitvtest.de. Funktionen wie Handheben oder Warteschlangen müssen für Text-Nutzer in gleicher Weise verfügbar sein; Text-Teilnehmende dürfen nicht in separaten Nischen behandelt werdenbitvtest.de. |
EN 301 549, 6.2.1.2 (Gleichzeitige Sprache und Text) |
Entspricht der EN-Forderung. Diese Anforderung stellt klar, dass Echtzeit-Textnutzer bei allen Funktionen (Wortmeldungen etc.) gleichrangig berücksichtigt werden müssenbitvtest.de. |
| 6.2.2.1 Visuell unterscheidbare Anzeige von Textnachrichten |
Prüft, ob empfangene und gesendete Nachrichten in einer Echtzeit-Text-Kommunikation visuell klar unterscheidbar dargestellt werdenbitvtest.de. Beispielsweise sollten eigene Beiträge und die Beiträge anderer optisch unterschiedlich angezeigt oder in separaten Textbereichen aufgelistet werden können. |
EN 301 549, 6.2.2.1 (Visuell unterscheidbare Anzeige von Textnachrichten) |
Entspricht der EN-Forderung. Die Norm verlangt, dass Nutzer bereits gesendete vs. empfangene Echtzeit-Textbeiträge leicht auseinanderhalten könnenbitvtest.de. |
| 6.2.2.2 Programmatisch unterscheidbare Anzeige von Textnachrichten |
Prüft, ob eigene und fremde Beiträge in einer Echtzeit-Textunterhaltung auch für assistive Technologien (z. B. Screenreader) unterscheidbar sindbitvtest.de. Beispielsweise können eigene Nachrichten mit einem entsprechenden Attribut oder vorangestellten Namenskürzeln versehen werden, damit sie programmatisch als solche erkennbar sindbitvtest.de. |
EN 301 549, 6.2.2.2 (Programmatisch unterscheidbare Anzeige von Textnachrichten) |
Entspricht der EN-Forderung. Die Norm fordert eine technische Kennzeichnung, damit Hilfsmittel wie Screenreader eigene vs. fremde Nachrichten identifizieren könnenbitvtest.de. |
| 6.2.2.3 Sprecheridentifizierung |
Prüft, ob bei Echtzeit-Textkommunikation eine Sprecher-Identifizierung analog zur Sprachkommunikation erfolgtbitvtest.de. Wenn in einer Konferenzanwendung z. B. aktive Sprecher durch ein Icon markiert werden, soll auch kenntlich gemacht werden, wer gerade einen Echtzeit-Textbeitrag sendet (z. B. durch Symbol oder Namensanzeige neben dem Teilnehmer)bitvtest.de. |
EN 301 549, 6.2.2.3 (Sprecheridentifizierung) |
Entspricht der EN-Forderung. Die Norm stellt sicher, dass Text-Teilnehmende nicht “unsichtbar” bleiben, sondern als aktiv Beitragende kenntlich gemacht werden – analog zur Sprecheranzeige bei Audiobitvtest.de. |
| 6.2.2.4 Echtzeitindikation von Sprachkommunikation |
Prüft, ob bei einer Web-Anwendung mit kombinierter Sprach- und Textkommunikation die Aktivität von Sprechenden in Echtzeit visuell angezeigt und programmatisch verfügbar istbitvtest.de. D. h. es muss z. B. ein visuelles Signal geben, wer gerade spricht, und diese Information muss auch vom Screenreader auslesbar seinbitvtest.de. |
EN 301 549, 6.2.2.4 (Synchronität bei Sprach-/Text-Kommunikation) |
Entspricht der EN-Forderung. Die Norm verlangt eine Echtzeit-Anzeige der Sprachaktivität inkl. maschinenlesbarer Information, sofern Sprach- und Textkommunikation kombiniert werdenbitvtest.de. |
| 6.2.3 Interoperabilität von Echtzeit-Textkommunikation |
Prüft, ob eine Web-Anwendung mit Echtzeit-Text (RTT) auch mit anderen Anwendungen interoperabel ist, also Echtzeit-Textnachrichten zwischen verschiedenen Systemen austauschen kannbitvtest.de. Dazu muss sie die einschlägigen Standard-Protokolle für RTT unterstützen (ggf. laut technischer Doku)bitvtest.de. |
EN 301 549, 6.2.3 (Interoperabilität von Echtzeit-Textkommunikation) |
Entspricht der EN-Forderung. Die Norm verlangt die Unterstützung standardisierter Protokolle, sodass Echtzeit-Text systemübergreifend funktioniertbitvtest.de. (Im Test wird dies i. d. R. anhand der Dokumentation oder Einstellungen überprüft.) |
| 6.2.4 Reaktionsgeschwindigkeit der Echtzeit-Textkommunikation |
Prüft, ob die Übertragung von Echtzeit-Texteingaben ohne merkliche Verzögerung erfolgt. Konkret dürfen eingegebene Zeichen mit höchstens ca. 500 ms Verzögerung an die Empfänger übermittelt werdenbitvtest.de, um einen flüssigen Dialog zu gewährleisten. |
EN 301 549, 6.2.4 (Reaktionsgeschwindigkeit der Echtzeit-Textkommunikation) |
Entspricht der EN-Forderung. Die Norm gibt ~500 ms als maximal zulässige Verzögerung für die Übertragung von RTT-Zeichen vorbitvtest.de. |
| 6.3 Anrufer-Identifizierung |
Prüft, ob in Web-Anwendungen mit Telefonie-Funktion der Anrufer auch für Nutzer von Hilfstechnologien erkennbar istbitvtest.de. D. h. der Name/die Nummer des Anrufers darf nicht nur visuell angezeigt, sondern muss z. B. dem Screenreader direkt als Meldung ausgegeben werden, sobald ein Anruf eingehtbitvtest.de. |
EN 301 549, 6.3 (Anrufer-Identifizierung) |
Entspricht der EN-Forderung. Die Norm stellt sicher, dass die Identität des Anrufers programmatisch bereitgestellt wird und nicht nur visuell – wichtig für Screenreader-Nutzerbitvtest.de. |
| 6.4 Alternativen zu sprachbasierten Diensten |
Prüft, ob für sprachbasierte Kommunikationsdienste (z. B. Sprachnachrichten, Telefonmenüs/IVR) auch eine textbasierte Zugangsoption angeboten wird. Beispielsweise muss bei einem webbasierten Anrufbeantworter oder Sprachmenü eine Möglichkeit bestehen, dieselben Funktionen über Text (Chat, E-Mail o. Ä.) zu nutzen, falls der Nutzer nicht sprechen/hören kannetsi.org. |
EN 301 549, 6.4 (Alternativen zu sprachbasierten Diensten) |
Entspricht der EN-Forderung. Die Norm verlangt etwa, dass bei Angeboten mit Voicemail, Auto-Attendant oder IVR auch textbasierte Schnittstellen bereitstehenetsi.org. |
| 6.5.2 Auflösung bei Videotelefonie |
Prüft, ob Web-Anwendungen mit Videoanruf-Funktion mindestens eine gewisse Mindestbildauflösung unterstützenbitvtest.de. Konkret wird mindestens QVGA (320×240 Pixel) als Auflösung gefordert, damit z. B. Gebärdensprache oder Mundbild im Video erkennbar istbitvtest.de. |
EN 301 549, 6.5.2 (Auflösung bei Videotelefonie) |
Entspricht der EN-Forderung. Die Norm fordert QVGA als Mindestmaßbitvtest.de – in der Praxis bieten heutige Systeme meist höhere Auflösungen, sodass diese Anforderung i. d. R. erfüllt istbitvtest.de. |
| 6.5.3 Bildwiederholfrequenz bei Videotelefonie |
Prüft, ob die Videotelefonie eine Bildrate von mind. 20 Bildern pro Sekunde unterstütztbitvtest.de. Eine ausreichende Bildwiederholfrequenz ist wichtig, damit z. B. Gebärden und Mimik flüssig wahrgenommen werden könnenbitvtest.de. |
EN 301 549, 6.5.3 (Bildwiederholfrequenz bei Videotelefonie) |
Entspricht der EN-Forderung. Die Norm verlangt mindestens 20 FPS für Videokommunikationbitvtest.de. (Kurzzeitige Einbrüche durch Netzprobleme führen nicht zur Bewertung „nicht erfüllt“.) |
| 6.5.4 Synchronität bei Videotelefonie |
Prüft, ob bei Videotelefonie Bild und Ton synchron wiedergegeben werden. Laut Norm darf die maximale Abweichung zwischen gesprochenem Ton und zugehörigem Video höchstens ca. 100 ms betragenetsi.org, damit Lippenbewegungen und Audio übereinstimmen. |
EN 301 549, 6.5.4 (Synchronität zwischen Audio und Video) |
Entspricht der EN-Forderung. Die Norm setzt einen Grenzwert (~0,1 Sekunden) für die Asynchronität zwischen Audio und Video in Echtzeit-Kommunikation festetsi.org. |
| 6.5.5 Visuelle Anzeige von Audio-Aktivität |
Prüft, ob bei Videotelefonie ein visuelles Echtzeit-Signal vorhanden ist, das anzeigt, wenn Audio übertragen wirdetsi.org. Beispielsweise ein Pegelanzeiger oder ein blinkendes Icon signalisiert einem Nutzer mit Hörbehinderung, dass der Gesprächspartner spricht, selbst wenn der Ton nicht gehört wird. |
EN 301 549, 6.5.5 (Visueller Indikator für Audioaktivität) |
Entspricht der EN-Forderung. Die Norm verlangt einen sichtbaren Indikator für aktive Sprachübertragung in Echtzeit-Videogesprächenetsi.org. Dies hilft insbesondere hörbehinderten Nutzern. |
| 6.5.6 Sprecher-Anzeige für Gebärdensprachen-Kommunikation |
Prüft, ob in einer Videokonferenz mit Gebärdensprach-Nutzung eine visuelle Kennzeichnung erfolgt, wer gerade gebärdet. Wenn also für hörende Nutzer eine Sprecherkennung existiert, muss analog auch angezeigt werden, welcher Teilnehmer aktuell in Gebärdensprache kommuniziertetsi.org (etwa durch Hervorhebung des Videofeeds). |
EN 301 549, 6.5.6 (Sprecher-Identifizierung bei Gebärdensprache) |
Entspricht der EN-Forderung. Die Norm verlangt eine gleichwertige Sprecheridentifikation für Echtzeit-Gebärdenkommunikation, sofern für Sprechende eine Kennzeichnung angeboten wirdetsi.org. |
| 7.1.1 Wiedergabe von Untertiteln |
Prüft, ob ein eingebundener Video-Player Untertitel ein- und ausschaltbar zur Verfügung stelltbitvtest.de. Dynamisch zuschaltbare (nicht fest eingebrannte) Untertitel müssen über entsprechende Bedienelemente im Player aktivierbar seinbitvtest.de. |
EN 301 549, 7.1.1 (Wiedergabe von Untertiteln) |
Entspricht der EN-Forderung. Der BITV-Test überprüft hier das Vorhandensein von Steuerelementen zum An- und Abschalten von Untertiteln im Videoplayerbitvtest.de. |
| 7.1.2 Synchrone Untertitel |
Prüft, ob der Videoplayer Untertitel synchron zur gesprochenen Tonspur anzeigen kannbitvtest.de. Es darf keine dauerhafte Asynchronität zwischen Untertiteltext und Audio bestehen (abgesehen von unvermeidbaren kurzen Verzögerungen)bitvtest.de. |
EN 301 549, 7.1.2 (Synchronität von Untertiteln) |
Entspricht der EN-Forderung. Die Norm verlangt, dass Untertitel zeitgleich mit dem Gesprochenen erscheinen; Abweichungen durch falsches Timing im Player oder Untertitel-Datei werden als Fehler gewertetbitvtest.de. |
| 7.1.3 Erhaltung von Untertiteln |
Prüft, ob bei Web-Anwendungen, die Videos übertragen, konvertieren oder aufzeichnen, alle vorhandenen Untertitel-Daten erhalten bleibenbitvtest.de. Eine Konvertierung (z. B. Video-Transcoding) darf nicht dazu führen, dass Untertitel verlorengehen. |
EN 301 549, 7.1.3 (Erhaltung von Untertiteln) |
Entspricht der EN-Forderung. Die Norm fordert die vollständige Übernahme vorhandener Untertitel bei Übertragung oder Umwandlung von Videosbitvtest.de. |
| 7.1.4 Untertitel-Anpassungen |
Prüft, ob der Videoplayer ermöglicht, die Darstellung von Untertiteln an die Bedürfnisse des Nutzers anzupassenetsi.org. Dies umfasst z. B. Einstellungen für Schriftgröße, Schriftart, Untertitel-Farben und Hintergrundetsi.org – außer die Untertitel sind technisch nicht veränderbar (z. B. als eingebrannte Bilddatei). |
EN 301 549, 7.1.4 (Anpassung der Untertitel-Eigenschaften) |
Entspricht der EN-Forderung. Die Norm verlangt, dass Untertitel als modifizierbarer Text vorliegen und Nutzer die Anzeigeeigenschaften anpassen könnenetsi.org. (Untertitel, die nur als Grafik eingebettet sind, gelten als nicht anpassbaretsi.org.) |
| 7.1.5 Gesprochene Untertitel |
Prüft, ob der Videoplayer einen Modus bietet, der vorhandene Untertitel als Audio ausgibt (vorliest)etsi.org. Das heißt, wenn ein Nutzer den Inhalt nicht lesen kann, sollte eine Audioversion der Untertitel (z. B. als separater Audiokanal mit vorgelesenen Untertiteln) verfügbar seinetsi.org. |
EN 301 549, 7.1.5 (Gesprochene Untertitel) |
Entspricht der EN-Forderung. Die Norm verlangt eine Funktion zur Sprachwiedergabe von Untertitelnetsi.org, um z. B. blinden Nutzern den untertitelten Inhalt zugänglich zu machen. Idealerweise erfolgt dies über eine separate Audiospuretsi.org. |
| 7.2.1 Wiedergabe von Audiodeskription |
Prüft, ob bei Vorhandensein einer Audiodeskriptionsspur im Video diese über den Player abgespielt werden kannbitvtest.de. Der Player muss also ein Bedienelement zum Aktivieren der Audiodeskription bereitstellen, falls eine solche Tonspur existiertbitvtest.de. |
EN 301 549, 7.2.1 (Wiedergabe von Audiodeskription) |
Entspricht der EN-Forderung. Die Norm verlangt, dass vorhandene Audiodeskriptionen dem Nutzer zugänglich gemacht werden – z. B. durch einen „AD“-Knopf im Playerbitvtest.de. |
| 7.2.2 Synchrone Audiodeskription |
Prüft, ob der Videoplayer eine ausgewählte Audiodeskriptions-Tonspur synchron zum Video wiedergeben kannbitvtest.de. Es wird also kontrolliert, dass Bild, Haupt-Tonspur und die Audiodeskription zeitlich aufeinander abgestimmt laufen. |
EN 301 549, 7.2.2 (Synchronität der Audiodeskription) |
Entspricht der EN-Forderung. Analog zu 7.1.2 fordert die Norm hier Synchronität, jetzt bezogen auf ggf. zugeschaltete Audiodeskriptionenbitvtest.de. |
| 7.2.3 Erhaltung von Audiodeskription |
Prüft, ob bei Übertragung, Konvertierung oder Aufnahme von Videos eine vorhandene Audiodeskriptionsspur vollständig erhalten bleibtbitvtest.de. Eine Web-Anwendung darf beim Umgang mit Video nicht die im Original vorhandene AD-Tonspur verlieren oder beschädigen. |
EN 301 549, 7.2.3 (Erhaltung von Audiodeskription) |
Entspricht der EN-Forderung. Analog zu 7.1.3 verlangt die Norm, dass beim Konvertieren/Aufzeichnen eines Videos die Audiodeskription erhalten bleibtbitvtest.de (soweit das Zielformat dies unterstützt). |
| 7.3 Bedienelemente für Untertitel und Audiodeskription |
Prüft, ob die Schalter zum Aktivieren von Untertiteln und Audiodeskription im Videoplayer auf gleicher Ebene und ebenso leicht zugänglich angeordnet sind wie die übrigen Video-Steuerelementebitvtest.de. Sie dürfen insbesondere nicht in Untermenüs „versteckt” sein, die erst über ein zusätzliches Icon (z. B. Zahnrad) geöffnet werden müssenbitvtest.de. |
EN 301 549, 7.3 (Bedienelemente für UT/AD) |
Entspricht der EN-Forderung. Die Norm stellt hier eine neue Anforderung: Die Kontrollknöpfe für Untertitel und Audiodeskription müssen genauso direkt verfügbar sein wie Play/Pause, Lautstärke etc.bitvtest.de, damit Nutzer sie problemlos finden können. |
| 9.1.1.1a Alternativtexte für Bedienelemente |
Prüft, ob alle grafischen Bedienelemente (verlinkte oder interaktive Grafiken, z. B. Icons, Logos, Schaltflächen) mit einem geeigneten Alternativtext versehen sindbitvtest.de. Der Alt-Text soll das Ziel oder die Aktion des Elements eindeutig benennen (z. B. Funktion des Buttons oder Ziel des Link-Icons)bitvtest.de. |
EN 301 549, 9.1.1.1 (Nicht-Text-Inhalt – WCAG 2.1 SC 1.1.1) |
Entspricht einem Teil der EN-Anforderung 9.1.1.1. Die Norm fordert für alle Nicht-Text-Inhalte eine Textalternativeetsi.org. BITV unterteilt dies in mehrere Prüfschritte: 9.1.1.1a konzentriert sich auf verlinkte/aktive Grafiken. |
| 9.1.1.1b Alternativtexte für Grafiken und Objekte |
Prüft, ob nicht-interaktive Grafiken/Bilder mit informativem Inhalt sowie eingebettete Objekte (z. B. <object>, <embed>) aussagekräftige Alternativtexte haben. Jede inhaltstragende Grafik muss durch einen Text beschrieben werden, der ihre Bedeutung wiedergibtbitvtest.de. |
EN 301 549, 9.1.1.1 (Nicht-Text-Inhalt – WCAG 2.1 SC 1.1.1) |
Entspricht ebenfalls der EN-Anforderung 9.1.1.1. Hier wird der allgemeine Fall statischer, informativer Grafiken geprüftbitvtest.de. Die Norm macht keinen expliziten Unterschied zwischen aktiven und passiven Grafiken – beide Prüfschritte (a & b) zusammen erfüllen SC 1.1.1. |
| 9.1.1.1c Leere alt-Attribute für Layoutgrafiken |
Prüft, ob reine Layout- und Ziergrafiken (ohne inhaltliche Bedeutung) ein leeres alt-Attribut (alt="") tragensozialstation-marktoberdorf.de. Ein leeres alt sorgt dafür, dass Screenreader diese rein dekorativen Bilder überspringen und keine irrelevanten Ansagen machen. |
EN 301 549, 9.1.1.1 (Nicht-Text-Inhalt – WCAG 2.1 SC 1.1.1) |
Entspricht der EN-Anforderung, allerdings ist dies in der Norm nur implizit enthalten. BITV definiert dafür einen eigenen Prüfschritt: Rein dekorative Grafiken müssen durch alt="" für Hilfsmittel ignorierbar seinsozialstation-marktoberdorf.de. |
| 9.1.1.1d Alternativen für CAPTCHAs |
Prüft, ob für CAPTCHAs geeignete alternative Lösungen vorhanden sind. Bei bildbasierten CAPTCHAs muss der Alternativtext zumindest den Zweck des Tests beschreiben und auf eine nicht-visuelle Lösung hinweisen (z. B. „Geben Sie das Wort ein – Audio-Version unten verfügbar“)bitvtest.de. Optimal ist eine vollständig alternative CAPTCHA-Methode (z. B. Audio-CAPTCHA oder andersartiges Rätsel). |
EN 301 549, 9.1.1.1 (Nicht-Text-Inhalt – WCAG 2.1 SC 1.1.1) |
Entspricht der EN-Anforderung. Die WCAG/EN fordern explizit zugängliche Alternativen für CAPTCHAs (z. B. ein Audio- oder textbasiertes CAPTCHA)bitvtest.de. BITV hebt dies als eigenen Prüfschritt hervor, da CAPTCHAs oft Probleme für bestimmte Nutzergruppen darstellen. |
| 9.1.2.1 Alternativen für Audiodateien und stumme Videos |
Prüft, ob für rein auditiven Inhalt (Audio-only) sowie rein visuelle, stumme Videos jeweils textliche Alternativen bereitgestellt werden. Konkret braucht ein Audio ohne Bild eine transkribierte Text-Alternative, und ein stummes Video eine schriftliche Beschreibung des Geschehens, damit die Information auch ohne Hören/Sehen vermittelt wird. |
EN 301 549, 9.1.2.1 (Alternative für Audio/Video allein – WCAG 2.1 SC 1.2.1) |
Entspricht der EN-Anforderung (SC 1.2.1)etsi.org. Die Norm verlangt Transkripte für nur-Audio-Inhalte und Text-Beschreibungen für nur-Video-Inhalte. (BITV fasst beide Fälle in einem Prüfschritt zusammen.) |
| 9.1.2.2 Aufgezeichnete Videos mit Untertiteln |
Prüft, ob für vorab aufgezeichnete Videos mit Ton Untertitel in derselben Sprache bereitstehen. Jeder zeitbasierte Medieninhalt (Video+Audio) muss also Untertitel für hörbehinderte Nutzer anbieten. |
EN 301 549, 9.1.2.2 (Untertitel für aufgezeichnete Videos – WCAG 2.1 SC 1.2.2) |
Entspricht der EN-Anforderung (SC 1.2.2)etsi.org. Die Bereitstellung von Untertiteln für alle vorproduzierten Videos ist eine Kernforderung der WCAG/EN. |
| 9.1.2.3 Audiodeskription oder Volltext-Alternative für Videos |
Prüft, ob für vorab aufgezeichnete Videos mit Ton entweder eine Audiodeskription vorhanden ist oder alternativ eine vollständige Textbeschreibung des Video-Inhalts geboten wird. Falls komplexe visuelle Informationen im Video enthalten sind, müssen sie für Sehbehinderte entweder durch eine AD-Spur oder durch ein Skript/Transcript vermittelt werden. |
EN 301 549, 9.1.2.3 (Audiodeskription oder Medienalternative – WCAG 2.1 SC 1.2.3) |
Entspricht der EN-Anforderung (SC 1.2.3)etsi.org. Die Norm lässt Wahlfreiheit zwischen Audiodeskription und gleichwertiger Textalternative, sofern damit alle visuellen Inhalte zugänglich gemacht werden. |
| 9.1.2.4 Videos (live) mit Untertiteln |
Prüft, ob Live-Videoinhalte (Live-Streaming mit Ton) mit Untertiteln in Echtzeit versehen sind. Beispielsweise muss bei einem Live-Video-Event für Zuschauer eine Echtzeit-Untertitelung (z. B. durch Schriftdolmetscher) angeboten werden. |
EN 301 549, 9.1.2.4 (Untertitel für Live-Videos – WCAG 2.1 SC 1.2.4) |
Entspricht der EN-Anforderung (SC 1.2.4). Live-Untertitelung ist gefordert, um Live-Sendungen für Hörbehinderte zugänglich zu machen. (In der Praxis ist dies aufwendig und wird oft durch Echtzeit-Dolmetscher oder Automatik realisiert.) |
| 9.1.2.5 Audiodeskription für Videos |
Prüft, ob vorab aufgezeichnete Videos mit Ton eine Audiodeskription besitzen, sofern wichtige visuelle Inhalte sonst nicht zugänglich wären. D. h. bei Filmen, Tutorials etc. muss eine zusätzliche Audio-Erzählspur vorhanden sein, die relevante visuelle Informationen beschreibt. |
EN 301 549, 9.1.2.5 (Audiodeskription für Videos – WCAG 2.1 SC 1.2.5) |
Entspricht der EN-Anforderung (SC 1.2.5). Die Norm verlangt für aufgezeichnete Videos eine Audiodeskription, sofern nötig. (Wenn das Video nur Dialog enthält und keine eigenständigen visuellen Infos, kann diese Anforderung entfallen.) |
| 9.1.3.1a HTML-Strukturelemente für Überschriften |
Prüft, ob Überschriften inhaltlich korrekt als HTML-Überschriften (<h1>–<h6>) ausgezeichnet sind und nicht nur z. B. via Fettschrift oder großer Schrift simuliert werden. Die hierarchische Gliederung der Seite muss sich in der Überschriften-Struktur widerspiegeln. |
EN 301 549, 9.1.3.1 (Info und Beziehungen – WCAG 2.1 SC 1.3.1) |
Entspricht einem Aspekt der EN-Anforderung 9.1.3.1. Die Norm fordert generell, die logische Struktur von Inhalten im Markup abzubilden. BITV prüft dies u. a. getrennt für Überschriften. |
| 9.1.3.1b HTML-Strukturelemente für Listen |
Prüft, ob Aufzählungen und Listen korrekt mit HTML-Listen (<ul>, <ol>, <li>) ausgezeichnet sind und nicht durch manuelle Nummerierung oder andere Workarounds dargestellt werden. |
EN 301 549, 9.1.3.1 (Info und Beziehungen – WCAG 2.1 SC 1.3.1) |
Entspricht einem Aspekt von 9.1.3.1. Die Norm verlangt auch für Listen eine semantisch korrekte Auszeichnung. BITV zieht dafür einen eigenen Prüfschritt heran. |
| 9.1.3.1c HTML-Strukturelemente für Zitate |
Prüft, ob Zitate im Inhalt mit geeigneten HTML-Elementen (z. B. <q> für Inline-Zitate, <blockquote> für Blockzitate) gekennzeichnet sind. Dadurch können assistive Technologien Zitate als solche erkennen (und z. B. anders intonieren). |
EN 301 549, 9.1.3.1 (Info und Beziehungen – WCAG 2.1 SC 1.3.1) |
Entspricht einem Aspekt von 9.1.3.1. Die Norm deckt diese semantische Anforderung ab, erwähnt Zitate aber nicht explizit – BITV operationalisiert es als eigenen Prüfschritt. |
| 9.1.3.1d Inhalt gegliedert |
Prüft, ob der Inhalt insgesamt logisch gegliedert ist und Gruppierungen korrekt wiedergegeben werden. Dazu gehört z. B., dass Abschnitte durch Überschriften getrennt sind und inhaltlich zusammengehörige Elemente (z. B. Formulareingabefelder mit ihrem Label) strukturell zusammen stehen. |
EN 301 549, 9.1.3.1 (Info und Beziehungen – WCAG 2.1 SC 1.3.1) |
Entspricht der allgemeinen Anforderung 9.1.3.1. Hier wird breit geprüft, ob die visuelle/logische Struktur im Code nachvollziehbar ist. (Dies fasst mehrere WCAG-Aspekte zusammen.) |
| 9.1.3.1e Datentabellen richtig aufgebaut |
Prüft, ob Datentabellen mit Überschriftenzellen (<th>) und ggf. Tabellenzusammenfassungen/Caption korrekt strukturiert sind. Überschriftenzeilen und -spalten müssen als solche deklariert sein, damit Screenreader Zellen den passenden Header zuordnen können. |
EN 301 549, 9.1.3.1 (Info und Beziehungen – WCAG 2.1 SC 1.3.1) |
Entspricht einem Aspekt von 9.1.3.1. Die Norm verlangt semantisch korrekte Tabellen. BITV unterteilt dies in e) und f) für Prüfung im Detail. |
| 9.1.3.1f Zuordnung von Tabellenzellen |
Prüft, ob bei komplexeren HTML-Tabellen mit mehrfachen Kopfzellen die Bezüge (scope, headers-Attribut oder <table> <caption>) korrekt hergestellt sind. Jeder Datenzelle muss eine eindeutige zugehörige Kopfzelle zugeordnet sein, damit die Relation für Screenreader klar ist. |
EN 301 549, 9.1.3.1 (Info und Beziehungen – WCAG 2.1 SC 1.3.1) |
Siehe 9.1.3.1e – auch dies ist Teil der EN-Forderung nach korrekten Beziehungen in Tabellen. BITV-Prüfschritt f) geht speziell auf die technische Verknüpfung von Zellen und Headers ein, was in der Norm implizit gefordert ist. |
| 9.1.3.1g Kein Strukturmarkup für Layouttabellen |
Prüft, ob Tabellen, die rein zum Layout/Zweck der Gestaltung verwendet werden, nicht als Datentabellen ausgezeichnet sind. Eine Layouttabelle darf keine <th> oder Summary erhalten und sollte nach Möglichkeit vermieden werden. |
EN 301 549, 9.1.3.1 (Info und Beziehungen – WCAG 2.1 SC 1.3.1) |
Entspricht der EN-Forderung, jedoch nicht explizit erwähnt in der Norm. Die WCAG empfiehlt dringend, Layouttabellen zu vermeiden; BITV fordert hier klar, dass kein Tabellenmarkup fälschlich für Layout verwendet wird. |
| 9.1.3.1h Beschriftung von Formularelementen programmatisch ermittelbar |
Prüft, ob alle Formularelemente (Eingabefelder, Auswahlfelder, Checkboxen etc.) mit einer für Software erkennbaren Beschriftung versehen sind. Konkret muss jedes Feld ein zugeordnetes <label> oder ein ARIA-Label haben, sodass z. B. Screenreader den Zweck des Feldes ausgeben können. |
EN 301 549, 9.1.3.1 (Info und Beziehungen – WCAG 2.1 SC 1.3.1) |
Entspricht einem wichtigen Teil von SC 1.3.1. Die Norm verlangt, dass Beziehungen wie Label–Formularfeld im Code vorhanden sind. BITV isoliert dies als Prüfschritt, um sicherzustellen, dass kein Formularfeld unbeschriftet bleibt. |
| 9.1.3.2 Sinnvolle Reihenfolge |
Prüft, ob die Inhalte auf der Seite in einer sinnvollen und der Bedeutung entsprechenden Reihenfolge im Quellcode stehen (und via Tastatur in dieser Reihenfolge fokussierbar sind)etsi.orgetsi.org. Beispielsweise muss eine logisch lesbare Reihenfolge auch dann gegeben sein, wenn per CSS Spalten umsortiert wurden. |
EN 301 549, 9.1.3.2 (Sinnvolle Abfolge – WCAG 2.1 SC 1.3.2) |
Entspricht der EN-Forderung (SC 1.3.2). Die Norm verlangt, dass die Reihenfolge im Code die inhaltliche Bedeutung bewahrt. BITV prüft dies z. B. durch lineares Lesen ohne CSS. |
| 9.1.3.3 Ohne Bezug auf sensorische Merkmale nutzbar |
Prüft, ob Anleitungen oder Bedienhinweise nicht ausschließlich auf sensorische Merkmale verweisen. D. h. eine Anleitung darf sich nicht nur auf Aussehen, Farbe, Position etc. beziehen (z. B. „Klicken Sie auf das rote Feld rechts“), sondern muss anderweitig identifizierbar sein (z. B. durch Text oder Form). |
EN 301 549, 9.1.3.3 (Keine alleinige Bezugnahme auf sensorische Merkmale – WCAG 2.1 SC 1.3.3) |
Entspricht der EN-Forderung (SC 1.3.3). Die Norm verlangt, dass Beschreibungen unabhängig von Farbe/Form verständlich sind. BITV übernimmt dies direkt als Prüfschritt. |
| 9.1.3.4 Keine Beschränkung der Bildschirmausrichtung |
Prüft, ob Inhalte nicht auf eine bestimmte Bildschirm-Ausrichtung festgelegt sind. Nutzer dürfen z. B. eine Seite im Hoch- oder Querformat verwenden, ohne dass Inhalte unzugänglich oder gesperrt sind. (Ausnahme: spezifische Anwendungen, die z. B. aus physikalischen Gründen nur in einer Ausrichtung funktionieren.) |
EN 301 549, 9.1.3.4 (Keine Ausrichtungsbeschränkung – WCAG 2.1 SC 1.3.4) |
Entspricht der EN-Forderung (SC 1.3.4). Die Norm verlangt, dass Web-Inhalte sowohl im Portrait- als auch Landscape-Modus nutzbar sind, sofern keine essentielle Einschränkung vorliegt. |
| 9.1.3.5 Eingabefelder zu Nutzerdaten vermitteln den Zweck |
Prüft, ob bei Formularfeldern, die persönliche Nutzerdaten abfragen (Name, E-Mail, Adresse etc.), mittels autocomplete-Attributen oder ähnlichem der jeweilige Zweck maschinenlesbar angegeben ist. So können Browser oder AT z. B. passende Autovervollständigung anbieten. |
EN 301 549, 9.1.3.5 (Eingabezweck erkennen – WCAG 2.1 SC 1.3.5) |
Entspricht der EN-Forderung (SC 1.3.5). Die Norm verlangt, dass für bestimmte gängige Datentypen (Name, E-Mail, Adresse usw.) der Input-Zweck im Markup codiert wird. |
| 9.1.4.1 Ohne Farben nutzbar |
Prüft, ob keinerlei Information ausschließlich durch Farbe vermittelt wird. Beispielsweise dürfen Links nicht nur durch farbliche Hervorhebung erkennbar sein (es muss z. B. zusätzlich eine Unterstreichung geben) und Diagramme müssen neben Farbmarkierungen auch Beschriftungen oder Muster besitzen. |
EN 301 549, 9.1.4.1 (Nutzung ohne Farbsehen – WCAG 2.1 SC 1.4.1) |
Entspricht der EN-Forderung (SC 1.4.1). Die Norm verlangt, dass Inhalte auch bei fehlender Farbwahrnehmung verständlich bleiben. BITV deckt dies voll ab. |
| 9.1.4.2 Ton abschaltbar |
Prüft, ob Audioinhalte, die automatisch länger als 3 Sekunden spielen, vom Nutzer angehalten oder stummgeschaltet werden können. Hintergrundmusik oder Auto-Play Audio dürfen also nicht ohne Stop/Pause-Kontrolle ununterbrochen laufen, da dies z. B. Screenreader-Nutzer stark beeinträchtigt. |
EN 301 549, 9.1.4.2 (Audio abschaltbar – WCAG 2.1 SC 1.4.2) |
Entspricht der EN-Forderung (SC 1.4.2). Automatisch gestartes Audio >3 Sek. muss pausier- oder abschaltbar sein. BITV übernimmt dies 1:1. |
| 9.1.4.3 Kontraste von Texten ausreichend |
Prüft, ob Fließtext und wichtige textuelle Inhalte einen ausreichenden Kontrast zum Hintergrund aufweisen. Nach WCAG müssen reguläre Texte mindestens Kontrastverhältnis 4.5:1 (bzw. große Schrift 3:1) zum Hintergrund habenilias.nrw. |
EN 301 549, 9.1.4.3 (Kontrast (Minimum) – WCAG 2.1 SC 1.4.3) |
Entspricht der EN-Forderung (SC 1.4.3). BITV setzt die gleichen Kontrastschwellen an. (Logos oder unwichtige Texte sind ausgenommen, analog WCAG.) |
| 9.1.4.4 Text auf 200% vergrößerbar |
Prüft, ob der Inhalt durch Zoom (bis 200%) vergrößert werden kann, ohne dass Information oder Funktionalität verloren geht und ohne dass der Nutzer horizontale Scrollbalken für Fließtext benötigt. |
EN 301 549, 9.1.4.4 (Textgröße anpassbar – WCAG 2.1 SC 1.4.4) |
Entspricht der EN-Forderung (SC 1.4.4). Die Norm verlangt, dass Zoom bis 200% unterstützt wird, was BITV hier testet (typisch via Browser-Zoom-Funktion). |
| 9.1.4.5 Schriftgrafiken |
Prüft, ob Text grundsätzlich als echter Text und nicht als eingebettetes Bild dargestellt wird. WCAG erlaubt Schrift als Grafik nur, wenn es notwendig ist (z. B. Logo) oder der Nutzer selbst das Aussehen anpassen kann. |
EN 301 549, 9.1.4.5 (Text in Bildform – WCAG 2.1 SC 1.4.5) |
Entspricht der EN-Forderung (SC 1.4.5). BITV überprüft insbesondere, ob keine unnötigen Text-in-Grafik Vorkommen existieren (z. B. Buttons mit Text als Bild statt echter Text). |
| 9.1.4.10 Inhalte brechen um |
Prüft, ob Inhalte bei kleineren viewport-Größen (z. B. auf dem Handy) automatisch umgebrochen werden und kein horizontales Scrollen notwendig ist. Insbesondere darf kein fester Layout-Viewport die mobile Ansicht sabotieren. |
EN 301 549, 9.1.4.10 (Responsive Umbruch – WCAG 2.1 SC 1.4.10) |
Entspricht der EN-Forderung (SC 1.4.10). BITV testet mit auf 320 CSS-Pixel Breite verkleinertem Fenster, ob der Inhalt ohne horizontales Scrollen nutzbar bleibt. |
| 9.1.4.11 Kontraste von Grafiken und grafischen Bedienelementen ausreichend |
Prüft, ob bedeutungstragende Grafiken und aktive grafische UI-Elemente genügend Kontrast zum Hintergrund aufweisen. Z. B. Icons, die Information vermitteln, oder Buttons (auch Umriss von Formularfeldern) müssen einen Kontrast von min. 3:1 zum Hintergrund haben. |
EN 301 549, 9.1.4.11 (Nicht-Text-Kontrast – WCAG 2.1 SC 1.4.11) |
Entspricht der EN-Forderung (SC 1.4.11). BITV dehnt die Kontrastprüfung auf alle visuell relevanten Nicht-Text-Elemente aus (Symbole, Controls), gemäß der Norm. |
| 9.1.4.12 Textabstände anpassbar |
Prüft, ob der Inhalt robust gegenüber Benutzeranpassungen der Textabstände ist. Wird per CSS der Zeilenabstand, Absatzabstand, Wort- und Buchstabenabstand vergrößert (nach WCAG-Vorgaben), darf nichts unleserlich oder abgeschnitten werden. |
EN 301 549, 9.1.4.12 (Textabstände – WCAG 2.1 SC 1.4.12) |
Entspricht der EN-Forderung (SC 1.4.12). BITV prüft konkret die vier im WCAG-Techniques definierten Abstands-Parameter. |
| 9.1.4.13 Eingeblendete Inhalte bedienbar |
Prüft, ob Inhalte, die bei Hover oder Fokus eingeblendet werden (Tooltip, Dropdown-Menü etc.), vom Nutzer leicht wegklick- und fokussierbar sind. Insbesondere: Hover-Popups dürfen nicht sofort verschwinden, wenn man den Mauszeiger bewegt, und Fokus-Popups müssen per Escape schließbar sein. |
EN 301 549, 9.1.4.13 (Inhalte bei Hover oder Fokus – WCAG 2.1 SC 1.4.13) |
Entspricht der EN-Forderung (SC 1.4.13). BITV testet hier die drei Kriterien: Inhalt bleibt bestehen, ist fokussierbar und kann vom Nutzer geschlossen werden. |
| 9.2.1.1 Ohne Maus nutzbar |
Prüft, ob sämtliche Funktionen der Website mit der Tastatur allein erreichbar sind. Es darf keine Aktion geben, die zwingend Maus- oder Touchbedienung voraussetzt. Der Fokus muss mittels Tab/Arrow in sinnvoller Reihenfolge durch alle Bedienelemente bewegt werden können. |
EN 301 549, 9.2.1.1 (Tastaturbedienbarkeit – WCAG 2.1 SC 2.1.1) |
Entspricht der EN-Forderung (SC 2.1.1). BITV stellt sicher, dass kein „Maus-Zwang“ besteht. Alle interaktiven Elemente müssen per Tab erreichbar und auslösbar sein. |
| 9.2.1.2 Keine Tastaturfalle |
Prüft, ob es keine „Tastaturfalle“ gibt, d. h. der Tastaturfokus darf nie in einem Element oder Fenster feststecken. Der Nutzer muss immer weiter navigieren oder zurück wechseln können (z. B. darf ein modales Dialogfenster per ESC oder Aktion geschlossen werden können). |
EN 301 549, 9.2.1.2 (Kein Keyboard-Trap – WCAG 2.1 SC 2.1.2) |
Entspricht der EN-Forderung (SC 2.1.2). Die Norm verlangt, dass der Fokus nicht irreversibel „eingesperrt“ wird. BITV prüft dies insbesondere bei Dialogen, Frames, eingebetteten Elementen etc. |
| 9.2.1.4 Tastatur-Kurzbefehle abschaltbar oder anpassbar |
Prüft, ob eventuell vorhandene Single-Key-Tastaturkurzbefehle (z. B. Buchstabentasten als Shortcut in Web-Apps) deaktiviert oder umkonfiguriert werden können, um Konflikte mit Screenreader-Tastenbefehlen oder unabsichtlicher Auslösung vorzubeugen. |
EN 301 549, 9.2.1.4 (Kurzbefehle anpassbar – WCAG 2.1 SC 2.1.4) |
Entspricht der EN-Forderung (SC 2.1.4). BITV übernimmt die WCAG 2.1-Anforderung, dass Einzeltasten-Befehle (falls genutzt) immer abschalt- oder neu belegbar sein müssen. |
| 9.2.2.1 Zeitbegrenzungen anpassbar |
Prüft, ob zeitgesteuerte Inhalte oder Session-Timeouts dem Nutzer genügend Anpassungsmöglichkeiten bieten. Konkret: Läuft ein zeitlicher Ablauf (z. B. Formulareingabezeit), muss der Nutzer ihn verlängern, anhalten oder deaktivieren können – außer die Zeit ist essenziell (z. B. Live-Auktion). |
EN 301 549, 9.2.2.1 (Einstellbare Zeitlimits – WCAG 2.1 SC 2.2.1) |
Entspricht der EN-Forderung (SC 2.2.1). BITV prüft z. B., ob Warnungen vor automatischem Logout erscheinen und eine Verlängerung möglich ist. |
| 9.2.2.2 Bewegte Inhalte abschaltbar |
Prüft, ob sich bewegende, blinkende oder automatisch wechselnde Inhalte vom Nutzer angehalten oder ausgeblendet werden können, wenn sie länger als 5 Sekunden laufen. Z. B. muss ein automatisch rotierendes Banner stoppbar sein. |
EN 301 549, 9.2.2.2 (Unterbrechbare Animation – WCAG 2.1 SC 2.2.2) |
Entspricht der EN-Forderung (SC 2.2.2). BITV achtet darauf, dass kein Nutzer durch ablenkende Bewegungen überfordert wird, indem er sie nicht stoppen kann. |
| 9.2.3.1 Verzicht auf Flackern |
Prüft, ob keinerlei Inhalt mit schneller Blink- oder Flackerfrequenz (größer ~3 mal pro Sekunde) vorkommt, der potenziell epileptische Anfälle auslösen könnte. Inhalte dürfen also nicht in gefährlicher Weise flimmern. |
EN 301 549, 9.2.3.1 (Keine gefährlichen Blitzfrequenzen – WCAG 2.1 SC 2.3.1) |
Entspricht der EN-Forderung (SC 2.3.1)etsi.org. BITV verlangt faktisch, dass die „3 Blitze oder weniger“-Regel eingehalten wird. (Falls doch blinkende Inhalte nötig sind, müssten sie unterhalb der Schwellenwerte bleiben.) |
| 9.2.4.1 Bereiche überspringbar |
Prüft, ob es Mechanismen gibt, um wiederkehrende Seitenelemente zu überspringen – typischerweise ein „Skip to content“-Link, mit dem man per Tastatur das Menü überspringen kannetsi.org. So können Nutzer direkt zum Hauptinhalt springen. |
EN 301 549, 9.2.4.1 (Blöcke überspringen – WCAG 2.1 SC 2.4.1) |
Entspricht der EN-Forderung (SC 2.4.1). BITV erwartet mindestens einen Sprunglink oder ARIA Landmarks, um z. B. Navigationsblöcke zu umgehen. |
| 9.2.4.2 Sinnvolle Dokumenttitel |
Prüft, ob jede Seite einen aussagekräftigen <title> hat, der den Inhalt oder Zweck der Seite knapp beschreibtetsi.org. Der Title erscheint z. B. im Browser-Tab und als Überschrift bei Suchergebnissen, daher wichtig für Orientierung. |
EN 301 549, 9.2.4.2 (Seitentitel – WCAG 2.1 SC 2.4.2) |
Entspricht der EN-Forderung (SC 2.4.2). BITV verlangt, dass der Seitentitel nicht generisch („Home“) oder leer ist, sondern Kontext bietet. |
| 9.2.4.3 Schlüssige Reihenfolge bei der Tastaturbedienung |
Prüft, ob die Fokus-Reihenfolge beim Tabben durch die Seite logisch und intuitiv istetsi.org. Der Fokus soll in einer sinnvollen Abfolge durch die Bedienelemente springen (z. B. von links oben nach rechts unten). Eine unsinnige Reihenfolge (etwa Sprünge) kann Nutzer verwirren. |
EN 301 549, 9.2.4.3 (Fokus-Reihenfolge – WCAG 2.1 SC 2.4.3) |
Entspricht der EN-Forderung (SC 2.4.3). BITV testet dies praktisch mit der Tab-Taste und erwartet, dass die Reihenfolge der Bedeutung/GUI-Anordnung entspricht. |
| 9.2.4.4 Aussagekräftige Linktexte |
Prüft, ob Links so benannt sind, dass ihr Ziel aus dem Linktext erkennbar ist. Links wie „Hier klicken“ oder „mehr…“ ohne Kontext gelten als nicht aussagekräftig. Idealerweise beschreibt der Linktext eindeutig, was beim Anklicken passiert oder welche Seite kommt. |
EN 301 549, 9.2.4.4 (Linkzweck im Kontext – WCAG 2.1 SC 2.4.4) |
Entspricht der EN-Forderung (SC 2.4.4). BITV bewertet isolierte Linktexte und ihren Kontext, damit Nutzer – insbesondere Screenreader-Nutzer, die sich Links vorlesen lassen – das Ziel verstehen können. |
| 9.2.4.5 Alternative Zugangswege |
Prüft, ob alternative Navigationsmechanismen vorhanden sind, z. B. eine Sitemap, ein Suchfeld oder ein Inhaltsverzeichnis, zusätzlich zur normalen Menü-Navigation. Dies erleichtert Benutzern die Orientierung, v.a. bei umfangreichen Websites. |
EN 301 549, 9.2.4.5 (Mehrere Navigationswege – WCAG 2.1 SC 2.4.5) |
Entspricht der EN-Forderung (SC 2.4.5). BITV erwartet mind. zwei verschiedene Zugangswege zum Inhalt (z. B. Menü und Suche), wie es auch die WCAG empfiehlt. |
| 9.2.4.6 Aussagekräftige Überschriften und Beschriftungen |
Prüft, ob Überschriften von Inhalten und Beschriftungen von Formularfeldern aussagekräftig und verständlich sind. Jede Überschrift soll den folgenden Abschnitt treffend zusammenfassen; jedes Formular-Label soll klar machen, welche Eingabe erwartet wird. |
EN 301 549, 9.2.4.6 (Überschriften und Labels – WCAG 2.1 SC 2.4.6) |
Entspricht der EN-Forderung (SC 2.4.6). BITV legt Wert darauf, dass Überschriften nicht kryptisch oder leer sind und Labels nicht nur aus Sternchen o. Ä. bestehen, sondern sinnvolle Texte tragen. |
| 9.2.4.7 Aktuelle Position des Fokus deutlich |
Prüft, ob der Tastaturfokus jederzeit visuell hervorgehoben ist, sodass ein Tastaturnutzer sieht, welches Element aktuell fokussiert ist. Das Standard-Fokusrechteck darf nicht durch fehlende CSS-Styling unsichtbar gemacht sein; im Gegenteil sollte es gut sichtbar sein. |
EN 301 549, 9.2.4.7 (Fokus sichtbar – WCAG 2.1 SC 2.4.7) |
Entspricht der EN-Forderung (SC 2.4.7). BITV achtet darauf, dass kein Element einen zu schwachen oder gar keinen sichtbaren Fokusindikator hat. |
| 9.2.5.1 Alternativen für komplexe Zeiger-Gesten |
Prüft, ob für Funktionen, die eine komplexe Zeiger-Geste (z. B. Drag-and-drop, Multi-Finger-Gesten) erfordern, auch ein einfacher alternativer Eingabemodus existiert. Z. B. muss man ein Drag&Drop-Element auch per Tastatur oder Klicks bewegen können. |
EN 301 549, 9.2.5.1 (Zeigergesten – WCAG 2.1 SC 2.5.1) |
Entspricht der EN-Forderung (SC 2.5.1). BITV stellt sicher, dass komplexe Maus/Touch-Gesten (wenn vorhanden) nicht die einzige Bedienmöglichkeit sind. |
| 9.2.5.2 Zeigergesten-Eingaben können abgebrochen oder widerrufen werden |
Prüft, ob zeigerbasierte Aktionen, die durch Down-Event ausgelöst werden (d. h. sofort beim MouseDown/TouchStart), rückgängig gemacht werden können oder eine Bestätigung erfordern. So sollen versehentliche Klicks (z. B. Touch-Bedienung) nicht unweigerlich Aktionen auslösen, ohne Chance zum Abbrechen. |
EN 301 549, 9.2.5.2 (Zeiger-Abbruch – WCAG 2.1 SC 2.5.2) |
Entspricht der EN-Forderung (SC 2.5.2). BITV überprüft z. B., ob Buttons Aktionen erst beim Loslassen (MouseUp) ausführen oder einen zweiten Klick zur Bestätigung erfordern, um Fehlbedienungen vorzubeugen. |
| 9.2.5.3 Sichtbare Beschriftung Teil des zugänglichen Namens |
Prüft, ob der visuell dargestellte Text eines Bedienelements (z. B. die Aufschrift auf einem Button) auch im zugänglichen Namen (Accessible Name) des Elements enthalten ist. Dies ist relevant, wenn z. B. mittels ARIA ein abweichender Accessible Name gesetzt wurde – er sollte den sichtbaren Text mit enthalten, um Verwirrung zu vermeiden. |
EN 301 549, 9.2.5.3 (Beschriftung im Namen – WCAG 2.1 SC 2.5.3) |
Entspricht der EN-Forderung (SC 2.5.3). BITV richtet sich nach der sogenannten „Accessible Name and Description Computation“: Sichtbarer Label-Text muss Teil des programmatischen Namens sein, damit Sprachassistenten konsistent funktionieren. |
| 9.2.5.4 Alternativen für Bewegungsaktivierung |
Prüft, ob Funktionen, die durch Geräteschütteln, Neigen oder andere Bewegungen ausgelöst werden könnten, auch anderweitig (ohne Bewegung des Geräts) ausführbar sind – außer die Bewegung ist die Kernfunktion (z. B. Schrittzähler). Zudem muss sich eine Bewegungserkennung abschalten lassen, um versehentliche Auslösungen zu verhindern. |
EN 301 549, 9.2.5.4 (Bewegungsgeste-Alternativen – WCAG 2.1 SC 2.5.4) |
Entspricht der EN-Forderung (SC 2.5.4). BITV übernimmt diese WCAG 2.1-Anforderung. Bewegungssteuerungen (z. B. Schütteln zum Aktualisieren) dürfen nicht ohne Alternative sein und sollten deaktivierbar sein. |
| 9.3.1.1 Hauptsprache angegeben |
Prüft, ob die Hauptsprache der Webseite korrekt im HTML deklariert ist (z. B. <html lang="de"> für eine deutschsprachige Seite). Dies ermöglicht Sprachtools, Screenreader etc. die richtige Aussprache und Silbentrennung zu wählen. |
EN 301 549, 9.3.1.1 (Sprache der Seite – WCAG 2.1 SC 3.1.1) |
Entspricht der EN-Forderung (SC 3.1.1). BITV verlangt, dass jede Seite ein gültiges lang-Attribut für die Hauptinhalts-Sprache besitzt. |
| 9.3.1.2 Anderssprachige Wörter und Abschnitte ausgezeichnet |
Prüft, ob Wörter oder Passagen, die in einer anderen Sprache als der Hauptseite verfasst sind, mit dem korrekten lang-Attribut markiert sind (z. B. lang="en" für ein englisches Zitat auf einer deutschen Seite). Damit können Screenreader die Aussprache umstellen. |
EN 301 549, 9.3.1.2 (Sprache von Teilinhalten – WCAG 2.1 SC 3.1.2) |
Entspricht der EN-Forderung (SC 3.1.2). BITV achtet darauf, dass z. B. fremdsprachige Fachbegriffe, Zitate oder Namen als solche ausgezeichnet sind, damit AT die Sprache wechseln. |
| 9.3.2.1 Keine unerwartete Kontextänderung bei Fokus |
Prüft, ob kein Interface-Element beim Fokuserhalt automatisch eine unerwartete Änderung verursacht. Z. B. darf ein Drop-down nicht sofort bei Fokus springen oder ein Link nicht schon beim Fokussieren laden, ohne dass der Nutzer eine Bestätigung (Klick) gegeben hat. |
EN 301 549, 9.3.2.1 (Kein Ereignis bei Fokus – WCAG 2.1 SC 3.2.1) |
Entspricht der EN-Forderung (SC 3.2.1). BITV bestätigt, dass Fokusieren allein keine Aktionen auslöst, wie es die WCAG fordert, um Nutzern Kontrolle zu geben. |
| 9.3.2.2 Keine unerwartete Kontextänderung bei Eingabe |
Prüft, ob keine plötzliche Änderung passiert, wenn ein Eingabefeld verändert wird (ohne dass der Nutzer fertig ist). Z. B. soll das Auswählen einer Option in einem Select-Menü nicht sofort die Seite neu laden, solange der Nutzer nicht explizit abschickt. |
EN 301 549, 9.3.2.2 (Kein Ereignis bei Eingabe – WCAG 2.1 SC 3.2.2) |
Entspricht der EN-Forderung (SC 3.2.2). BITV stellt sicher, dass Änderungen an Steuerelementen nicht sofort unerwartete Navigation oder Kontextwechsel verursachen. |
| 9.3.2.3 Konsistente Navigation |
Prüft, ob wiederkehrende Navigationselemente (Menüs, Footer-Links) auf allen Seiten in derselben Reihenfolge und mit denselben Inhalten auftauchen. Beispielsweise darf die Hauptmenü-Reihenfolge nicht willkürlich variieren, damit Benutzer sich einprägen können, wo etwas steht. |
EN 301 549, 9.3.2.3 (Konsistente Navigation – WCAG 2.1 SC 3.2.3) |
Entspricht der EN-Forderung (SC 3.2.3). BITV verlangt konsequente Wiederholung von Navigationsmustern, was die Norm zur Verbesserung der Vorhersehbarkeit fordert. |
| 9.3.2.4 Konsistente Bezeichnung |
Prüft, ob gleiche Funktionen auf verschiedenen Seiten gleich benannt sind. Z. B. sollte ein „Suche“-Feld auf allen Seiten dasselbe Label tragen und nicht mal „Suche“, mal „Finden“ heißen. Einheitliche Bezeichnungen helfen insbesondere kognitiv beeinträchtigten Nutzern. |
EN 301 549, 9.3.2.4 (Konsistente Bezeichnung – WCAG 2.1 SC 3.2.4) |
Entspricht der EN-Forderung (SC 3.2.4). BITV achtet darauf, dass z. B. Buttons, Links und Menüpunkte konsistente Texte haben, wie es die Norm der Vorhersehbarkeit halber fordert. |
| 9.3.3.1 Fehlererkennung |
Prüft, ob bei Formularen auftretende Fehler vom System erkannt und dem Nutzer mitgeteilt werden. Wenn der Nutzer z. B. ein Pflichtfeld leer lässt oder eine falsche Eingabe tätigt, muss eine Fehlermeldung erscheinen, die das fehlerhafte Feld identifiziert. |
EN 301 549, 9.3.3.1 (Fehlererkennung – WCAG 2.1 SC 3.3.1) |
Entspricht der EN-Forderung (SC 3.3.1). BITV verlangt klare Fehlermeldungen und Markierungen im Formular (z. B. „Bitte Feld X ausfüllen“), wie es die Norm vorsieht. |
| 9.3.3.2 Beschriftungen von Formularelementen vorhanden |
Prüft, ob alle Formulareingabefelder eine textliche Beschriftung und/oder Erläuterung haben, die dem Nutzer den Zweck der Eingabe mitteilt. Insbesondere müssen Pflichtfelder gekennzeichnet sein und z. B. Dropdowns eine beschreibende Überschrift haben. |
EN 301 549, 9.3.3.2 (Beschriftungen bzw. Anleitungen – WCAG 2.1 SC 3.3.2) |
Entspricht der EN-Forderung (SC 3.3.2). BITV kontrolliert, dass nichts unbezeichnet bleibt und ggf. Hilfetexte (Platzhalter, Legenden) vorhanden sind, analog zur Norm. |
| 9.3.3.3 Hilfe bei Fehlern |
Prüft, ob bei Formularen, die rechtliche, finanzielle oder Daten-ändernde Vorgänge auslösen (z. B. Online-Anträge), den Nutzern bei fehlerhaften Eingaben Hilfestellungen angeboten werden. Z. B. könnten Formulareingabefehler konkrete Korrekturvorschläge oder Beispiele zur richtigen Eingabe anzeigen. |
EN 301 549, 9.3.3.3 (Fehlervermeidung bei wichtigen Vorgängen – WCAG 2.1 SC 3.3.3) |
Entspricht der EN-Forderung (SC 3.3.3). BITV setzt dies für alle Formulare ein, die kritische Transaktionen betreffen, entsprechend der Normvorgabe, dem Nutzer möglichst Hilfe zu geben, Fehler zu vermeiden oder zu korrigieren. |
| 9.3.3.4 Fehlervermeidung wird unterstützt |
Prüft, ob bei sehr wichtigen Eingaben (z. B. Abschluss von Verträgen, Versenden von Daten) Maßnahmen zur Fehlervermeidung umgesetzt sind. Dies kann z. B. eine Zusammenfassungsseite zur Bestätigung vor dem endgültigen Absenden sein oder eine leicht zugängliche Möglichkeit, eine bereits abgeschickte Eingabe zu korrigieren/stornieren. |
EN 301 549, 9.3.3.4 (Fehlervermeidung – WCAG 2.1 SC 3.3.4) |
Entspricht der EN-Forderung (SC 3.3.4). BITV prüft z. B. Checkout-Prozesse und Formulare mit rechtlicher Wirkung, ob eine Bestätigungs- und Korrekturmöglichkeit gegeben ist – dies verlangt auch die Norm. |
| 9.4.1.1 Korrekte Syntax |
Prüft, ob der zugrundeliegende HTML-Code der Seiten syntaktisch valide (wenigstens in allen wesentlichen Punkten) ist. Fehler im Markup, die die Parsbarkeit beeinträchtigen (z. B. nicht geschlossene Tags, Duplikat-IDs), können zu Zugänglichkeitsproblemen führen und sollten vermieden sein. |
EN 301 549, 9.4.1.1 (Kompatibilität – WCAG 2.1 SC 4.1.1) |
Entspricht der EN-Forderung (SC 4.1.1). BITV nutzt Validatoren, um erhebliche HTML-Fehler aufzuspürenilias.nrw. Kleinere Formalfehler führen nicht automatisch zu „nicht erfüllt“, sofern keine Auswirkung. |
| 9.4.1.2 Name, Rolle, Wert verfügbar |
Prüft, ob für jedes interaktive Element der Name, die Rolle und der aktuelle Wert/Zustand im Code ermittelbar sindetsi.org. Das betrifft v. a. benutzerdefinierte Controls oder Skript-Widgets: Sie müssen mit ARIA so versehen sein, dass AT den Element-Typ (Rolle), dessen Namen/Label und z. B. den Auswahlstatus erkennen können. |
EN 301 549, 9.4.1.2 (Name, Rolle, Wert – WCAG 2.1 SC 4.1.2) |
Entspricht der EN-Forderung (SC 4.1.2). BITV testet insbesondere Self-made-Widgets (Dropdowns, Slider etc.) auf korrekte ARIA-Beschreibung. Die Norm fordert diese vollständige Semantik, damit z. B. Screenreader korrekt informieren können. |
| 9.4.1.3 Statusmeldungen programmatisch verfügbar |
Prüft, ob dynamische Statusmeldungen auf der Seite (z. B. „Formular erfolgreich gesendet“ oder Live-Validierungsfehlermeldungen) so implementiert sind, dass sie von assistiver Technologie automatisch erkannt und vorgelesen werden, ohne den Fokus zu verschieben. Typischerweise erfordert dies ARIA-Attributes wie role="status" oder aria-live. |
EN 301 549, 9.4.1.3 (Statusmeldungen – WCAG 2.1 SC 4.1.3) |
Entspricht der EN-Forderung (SC 4.1.3). BITV überprüft, ob z. B. AJAX-Feedback oder Inline-Fehlermeldungen mit ARIA-Live-Bereichen versehen sind. Die Norm verlangt, dass solche Änderungen dem Nutzer mitgeteilt werden, ohne Kontextverlust. |
| 11.7 Benutzerdefinierte Einstellungen |
Prüft, ob das Web-Angebot die benutzerdefinierten Einstellungen des Browsers bzw. Betriebssystems bezüglich Darstellung übernimmtbitvtest.debitvtest.de. Insbesondere Veränderungen bei Standard-Schriftart, -schriftgröße, Vorder-/Hintergrundfarben und Fokus-Cursor müssen respektiert werdenbitvtest.debitvtest.de. Der Prüfschritt testet z. B. im Firefox, ob eine Seite bei vom Nutzer gewählten Farben und Schriften entsprechend angepasst gerendert wird (und keine Inhalte verschwinden)bitvtest.debitvtest.de. |
EN 301 549, 11.7 (Benutzerpräferenzen) |
Entspricht der EN-Forderung. Die Norm verlangt, dass Web-Anwendungen die Plattform-Voreinstellungen der Nutzer für Maßeinheiten, Farben, Schriftart/-größe und Cursorform berücksichtigenbitvtest.debitvtest.de. Dieser Prüfschritt wurde in BITV 2.0 neu eingeführtbitvtest.de (ähnliches gab es früher informell als „bei user-definierten Farben erkennbar“bitvtest.de). Keine Abweichung – BITV konkretisiert nur die Prüfung im Browser. (EN-Abschnitt 11.7 gilt eigentlich für Software; nach Tabelle A.1 ist er aber auch auf Web-Inhalte anzuwendenbitvtest.de.) |
| 11.8.2 Barrierefreie Erstellung von Inhalten |
Prüft, ob in Web-basierten Autorenwerkzeugen (z. B. CMS-Editoren, Blog-Kommentarformularen) die erzeugten Inhalte standardkonform und barrierefrei angelegt werden könnenbitvtest.debitvtest.de. Beispielsweise muss ein CMS die Auszeichnung von Überschriften, Listen, Alternativtexten etc. ermöglichen und diese Auszeichnungen in den ausgegebenen HTML-Code übernehmenbitvtest.debitvtest.de. |
EN 301 549, 11.8.2 (Barrierefreie Inhaltserstellung) |
Entspricht der EN-Forderung. Die Norm verlangt von Autoren-Tools, dass sie Autoren unterstützen, barrierefreie Inhalte zu erzeugenbitvtest.de. BITV prüft dies praktisch, z. B. ob ein Redakteur im CMS Überschriften als solche deklarieren kann und diese im Frontend-HTML auftauchenbitvtest.de. (EN 11.8.1 „Content technology“ ist eine übergeordnete Anforderung und wird im BITV-Test nicht als eigener Schritt geprüft, da sie durch die Erfüllung von 11.8.2–11.8.5 abgedeckt wirdetsi.org.) |
| 11.8.3 Erhaltung von Barrierefreiheitsinformationen bei Transformation |
Prüft, ob Web-Anwendungen, die Dateien umwandeln (z. B. Dateikonverter oder Import/Export-Funktionen in Web-Apps), die Barrierefreiheits-Infos erhaltenbitvtest.debitvtest.de. Wenn z. B. ein langes HTML-Dokument vom System in mehrere HTML-Seiten aufgeteilt wird oder als PDF exportiert wird, müssen Überschriften, Listen etc. im Ergebnis erhalten bleibenbitvtest.de. BITV testet dies insbesondere für HTML↔HTML-Transformationen im gleichen Format; bei anderen Formaten ggf. manuell. |
EN 301 549, 11.8.3 (Erhaltung von Accessibility-Infos bei Transformation) |
Entspricht der EN-Forderung. Die Norm verlangt, dass beim Konvertieren von Inhalten in andere Formate alle semantischen Zugänglichkeitsinformationen soweit möglich mitübernommen werdenbitvtest.de. BITV weist darauf hin, dass bei Formaten außerhalb von HTML zusätzliche Prüfverfahren nötig sein könnenbitvtest.de. |
| 11.8.4 Reparaturassistenz |
Prüft, ob ein webbasiertes Autorensystem mit eingebauter Accessibility-Prüfung im Fehlerfall dem Autor Hilfestellung zur Korrektur bietetbitvtest.de. Ist z. B. im CMS ein Bild ohne Alt-Text eingefügt und der integrierte Prüfer schlägt Alarm, sollte er einen verständlichen Hinweis geben („Bitte Alternativtext eingeben“)bitvtest.de. (Eine Pflicht zur Existenz eines Prüf-Tools selbst besteht aber nicht.) |
EN 301 549, 11.8.4 (Assistenz bei Reparatur – WCAG2ICT) |
Entspricht der EN-Forderung. Die Norm verlangt wenn ein Autorentool über eine Barrierefreiheits-Prüfung verfügt, muss diese beim Korrigieren von gefundenen Barrieren helfenbitvtest.de. BITV betont, dass kein Tool vorgeschrieben ist, aber falls vorhanden, sinnvolle Korrekturhinweise liefern mussbitvtest.de. |
| 11.8.5 Vorlagen |
Prüft, ob ein Autorentool, das Dokument-Vorlagen anbietet, mindestens eine Vorlage klar als barrierefrei geeignet kennzeichnetbitvtest.de. D. h. Redakteure sollen eine Template auswählen können, die z. B. bereits korrekte Überschriftenstrukturen, Kontraste etc. erfüllt, um barrierefreie Inhalte zu erstellenbitvtest.de. Getestet wird das Ergebnis: Eine damit erstellte Seite muss barrierefrei sein. |
EN 301 549, 11.8.5 (Barrierefreie Vorlagen) |
Entspricht der EN-Forderung. Die Norm verlangt mindestens eine barrierefreie Vorlage in Autorensystemenbitvtest.de. BITV prüft dabei nicht die Vorlage selbst, sondern ob mit ihr tatsächlich barrierefreie Inhalte erzeugt werden könnenbitvtest.de. |
| 12.1.1 Dokumentation von Kompatibilität und Barrierefreiheit |
Prüft, ob die vom Anbieter bereitgestellte Dokumentation des Web-Angebots Informationen über die Barrierefreiheits-Funktionen und -Einschränkungen enthältbitvtest.de. Z. B. sollten vorhandene Zusatzfunktionen (Vorlesemodus, Tastaturkürzel) erklärt und eventuelle Inkompatibilitäten mit bestimmten Hilfsmitteln angegeben seinbitvtest.de. |
EN 301 549, 12.1.1 (Doku zu Kompatibilität/Accessibility) |
Entspricht der EN-Forderung. Die Norm verlangt, dass in der Nutzer-Dokumentation alle speziellen Barrierefreiheitsfunktionen beschrieben werdenbitvtest.de. BITV prüft dies, indem die Hilfeseiten oder Nutzerhandbücher (sofern web-basiert) in die Seitenauswahl einbezogen werdenbitvtest.de. |
| 12.1.2 Barrierefreie Dokumentation |
Prüft, ob die dem Nutzer bereitgestellte Dokumentation selbst barrierefrei ist. Das heißt, Handbücher oder Hilfeseiten müssen wiederum die Anforderungen an zugängliche Web-Inhalte (Kap. 9) oder an barrierefreie Dokumente (Kap. 10) erfüllenbitvtest.de. Liegt die Doku z. B. als Webseite vor, muss sie denselben BITV-Kriterien genügen wie das Produkt selbst. |
EN 301 549, 12.1.2 (Zugängliche Dokumentation) |
Entspricht der EN-Forderung. Die Norm schreibt vor, dass alle dem Endnutzer zur Verfügung gestellten Dokumentationen selbst barrierefrei sein müssenbitvtest.de. BITV prüft dies ggf. mit, indem die Dokumentations-Seiten als Teil der Bewertung betrachtet werdenbitvtest.de. |
| 12.2.2 Technischer Support |
Prüft, ob der technische Support des Anbieters in der Lage ist, auf Anfragen zur Barrierefreiheit bzw. Kompatibilität des Angebots einzugehenbitvtest.de. Beispielsweise sollte der Helpdesk auf Nachfrage erklären können, wie man die Barrierefreiheitsfunktionen nutzt, oder bekannte Probleme mit bestimmten Screenreadern kennen. (Dies ist schwierig testbar; BITV berücksichtigt z. B. vorhandene Support-Dokumente oder testet stichprobenartig eine Anfrage.) |
EN 301 549, 12.2.2 (Informationen im Support – EN ICT Support) |
Entspricht der EN-Forderung. Die Norm verlangt, dass der Support Hilfestellung zu den besonderen Zugänglichkeits- und Kompatibilitätseigenschaften des Produkts bieten kannbitvtest.de. BITV merkt an, dass dies schwer objektiv prüfbar ist und vom jeweiligen Support-Mitarbeiter abhängen kannbitvtest.de. |
| 12.2.3 Effektive Kommunikation |
Prüft, ob der Anbieter bei der Kommunikation mit Menschen mit Behinderungen geeignete Kanäle bereitstelltbitvtest.de. Das heißt z. B., ob es neben Telefon auch E-Mail oder Text-Chat gibt, damit z. B. gehörlose Nutzer Support erhalten können. Gegebenenfalls kann auch auf Vermittlungsdienste (Relay) zurückgegriffen werden. |
EN 301 549, 12.2.3 (Effektive Kommunikation) |
Entspricht der EN-Forderung. Die Norm verlangt vom Anbieter, bei Kontaktaufnahmen seitens behinderter Nutzer barrierefreie Kommunikationswege anzubietenbitvtest.de. BITV fordert praktisch mindestens zwei unterschiedliche Kontaktmöglichkeiten (analog zu 2.4.5 „Alternative Zugangswege“)bitvtest.de. |
| 12.2.4 Vom Support bereitgestellte Dokumentation |
Prüft, ob zusätzliche Dokumente, die nur auf Anfrage vom Support ausgegeben werden (z. B. ausführlichere Handbücher, FAQs per E-Mail), ebenfalls barrierefrei sindbitvtest.de. Wenn der Anbieter also auf Nachfrage Dokumentation verschickt oder online zugänglich macht, muss diese die Kriterien für barrierefreie Web-Dokumente (Kap. 9 bzw. 10) erfüllen. |
EN 301 549, 12.2.4 (Vom Support gelieferte Doku) |
Entspricht der EN-Forderung. Die Norm verlangt analog zu 12.1.2, dass auch ad-hoc vom Support bereitgestellte Unterlagen barrierefrei sein müssenbitvtest.de. BITV prüft dies, falls anwendbar, durch Einbeziehen solcher Dokumente in die Auswahl. |