7.1.1/7.2.1/7.3 Anwendbarkeit bei browsereigener Umsetzung?

[johannesFischer84]

In den drei Prüfschritten, die ich im Titel genannt habe, geht es um Zuschaltung von Untertiteln, Audiodeskriptionen mit Bedienelementen. Neben der Einbindung eines Video-Players könnte ein Seiten-Betreiber auch auf eigene Video-Player verzichten und stattdessen nur ein HTML-Dokument mit video-Element inklusive track-Element zum Beispiel für Untertitel bereitstellen. In diesem Fall wird das Video durch den jeweiligen Player des Browser-Herstellers wiedergegeben. Die Umsetzung ist hier in Firefox und Chrome beispielsweise unterschiedlich, vergleiche folgende Beispielseite mit so einem Video: https://html5-beispiele.pronix.de/Kapitel006/6_7/index2_subtitel.html

Wären die Prüfschritte in diesem Fall dennoch anwendbar? Ich würde dazu tendieren, dass die Prüfungen nicht anwendbar wären. Der Entwickler hat hier kaum Einfluss auf die Umsetzung, sofern er nicht die Nutzung auf einen bestimmten Browser begrenzen kann (bei öffentlich zugänglichen Seiten unmöglich). Aus meiner Sicht wären die Prüfschritte nur relevant, wenn man die Browser-Software selbst auf Barrierefreiheit prüfen würde, aber nicht beim Test einer Webseite, die nur durch den Browser wiedergegeben wird.

Wie sehen das andere?

[sweckenmann]

Johannes der erste Absatz wird nicht vollständig dargestellt. Daher bin mir nicht sicher, ob ich verstehe was du meinst. Aber muss man nicht sagen, der Autor muss einen player einbinden (egal ob nativ oder nicht), der accessibiltiy supported ist?

[johannesFischer84]

Johannes der erste Absatz wird nicht vollständig dargestellt.

Danke für den Hinweis, Sonja. Das kommt davon, wenn man HTML-Elemente mit spitzen Klammern hier rein setzt. Beim Editieren war der Text noch da, ich hab es korrigiert, nun wird alles angezeigt.

Aber muss man nicht sagen, der Autor muss einen player einbinden (egal ob nativ oder nicht), der accessibiltiy supported ist?

Mein jetzt sichtbares Beispiel ist, dass der Autor nichts einbindet und die Aufgabe, das Video abzuspielen, an den Browser abgegeben wird.

[sweckenmann]

Okay, vielleicht habe ich mich falsch ausgedrückt. Mit dieser nativen Umsetzung scheint es ja noch mehr Probleme zu geben, auch was Tastaturbedienbarkeit anbelangt (ich bin hier aber nicht so tief drin, aber siehe https://developer.mozilla.org/en-US/docs/Learn/Accessibility/Multimedia). Hier wird z.T. auch beschrieben, dass man anpassen muss. Das heißt diese Technik ist noch nicht ausreichen unterstützt? Es gibt das ja in anderen Techniken auch, dass Browser-abhängig etwas funktioniert oder auch nicht und wir uns überlegen, was ist da akzeptabel. Oder bin ich auf dem falschen Dampfer? In der Theorie verstehe ich schon, was du meinst.

[johannesFischer84]

Hm, stimmt, ich habe im Firefox zum Beispiel keine Möglichkeit gefunden, mit der Tastatur Untertitel zu aktivieren. Für die übrigen Bedienelemente kann man sich im Firefox mit den Pfeiltasten für Videoposition und Lautstärke behelfen, mit Leertaste Wiedergabe/Pause betätigen bzw. alles auch über das Kontextmenü machen. Die Untertitel-Aktivierung ist aber auch im Kontextmenü nicht enthalten. In Chrome kann ich zwar mit Tabulator alles fokussieren, die Untertitel sind da aber in einem Untermenü versteckt.

Du hast Recht, perfekte Barrierefreiheit ist das nicht. Bei der Fehlerbehandlung von Pflichtfeldern eines Formulars haben wir ja auch gesagt, die Meldungen im Browser sind nicht barrierefrei, also muss der Entwickler selbst für etwas sorgen. Daher wäre also die Video-Umsetzung durch die Browser auch nicht barrierefrei und Entwickler müssten zwingend einen Video-Player oder zumindest Steuerungselemente dafür bereitstellen. Paul J. Adam hat in einer Demo zwar auch den Browser-Player genutzt, aber unter dem Video eigene Bedienelemente eingefügt: https://pauljadam.com/demos/html5-video-a11y.html

[detlevhfischer]

Ich denke, die Probleme der nativen Umsetzung müsste man hier eigentlich nicht erfassen, weil die Barrieren ja in anderen Prüfschritten erfasst werden.

[pp-ernst]

Auf der Beispielseite https://html5-beispiele.pronix.de/Kapitel006/6_7/index2_subtitel.html habe ich im Firefox die Untertitel mit Tastatur einblenden können. Eingabereihenfolge: TAB: play-Button ist fokussiert Leertaste: Video startet TAB: Untertitel-Button ist fokussiert Leertaste: Untertitelmenu ist eingeblendet 3xTAB: Deutsch ist fokussiert Leertaste: Deutsche Untertitel sind aktiviert

[MarcHaunschild]

Ich kann es im Safari auch vollständig bedienen (Desktop mit Tastatur, iOS mit eingeschaltetem VoiceOver und Streichgeste nach links/rechts) - in Chrome ging es auch? Ab wann gilt es denn als zugänglich? - Der IE wurde rausgenommen, aber wie wird das begründet? - Ich nehme an, weil "wir" den als irrelevant ansehen, aber was ist der objektive Maßstab? Wenn wir den Marktanteil zugrunde legen, fallen praktische alle ATs raus. Sagt man Marktanteil gemessen an den darauf angewiesenen Nutzern, bekommt man das Problem, das man bei der kleinen Gruppe keine verlässlichen Zahlen hat. Oder weiß jemand wie oft in Deutschland die Kombination IE/Jaws eingesetzt wird oder andere? Ist der IE wirklich schon irrelevant? In anderen Ländern auch (es ist ja das word wide web - nicht das Web von Deutschland). Nicht falsch verstehen - ich bin dafür uralte Browser rausfallen zu lassen (die von Adams unten genannten unterstützen Browser haben ja schon einige Jährchen auf dem Buckel). Wenn eine Technik bereits von mehreren Browsern unterstützt wird, würde ich diese Technik eher als bestanden bewerten wollen. Weil ich eher die Unterstützung zukünftiger Browser "loben" möchte, als den Aufwand, der in Browser gesteckt wird, die schon anfangen moderig zu riechen. Gerade wenn es im FF und Safari funktioniert, weil die Kombination FF und NVDA und Safari/VoiceOver gefühlt einer sehr großen Menge von Benutzern nicht nur zur Verfügung stehen, sondern von denen auch präferiert werden. Grundsätzlich bin ich dazu auch noch ein Freund von nativen Elementen, weil bei denen die Wahrscheinlichkeit auf eine nachhaltige barrierefreie Umsetzung am wahrscheinlichsten ist. Und noch ein Punkt: selbst die hakelige Bedienung in Chrome ist eine Bedienung, die man mit der Zeit als Nutzer erlernt. Selbst eine unschöne bekannte Bedienung ist meist besser, als eine eigentlich bessere, aber unbekannte, die erst erlernt werden muss. Das ist generell der Nachteil von individuellen Lösungen: sie müssen auf jeder Website neu erlernt werden. Ich bin hier vielleicht nicht objektiv, weil mich persönlich das am meisten nervt: rausfinden, welche (womöglich nur unsichtbar beschrifteten) Bedienelemente wofür zu nutzen sind und wie ich verborgene Elemente öffne (zum Beispiel die Sprachversionen der Untertitel) und wo ich die finde. Nervt mich und ich freue mich immer, wenn native Elemente genutzt werden, bei denen ich weiß, wo sich etwas befindet und wie ich das bedienen kann. Am elegantesten finde ich die Kombination von nativ und eigenen Elementen (die ich allerdings vermutlich nicht nutzen würde).

Paul Adams schreibt übrigens, dass native captions von folgenden Browser unterstützt werden:

Chrome (OS X, Windows 7, Android 4.3) Safari (iOS 7, OS X) Firefox (OS X, Android, Windows 7)

Die Versionen scheinen auf eine Unterstützung seit langer Zeit hinzudeuten (iOS 7 ist 8 Jahre alt).

Sollte das nicht genügen?

[johannesFischer84]

@pp-ernst

Leertaste: Untertitelmenu ist eingeblendet 3xTAB: Deutsch ist fokussiert

Danke für den Hinweis. Auf die Idee, dreimal die Tabulatortaste zu drücken, bin ich nicht gekommen. Die Elemente zur Untertitelaktivierung wären damit sogar auf gleicher Ebene wie Play/Pause. Schön ist das nicht, denn wie viele anderen Leute werden ebenfalls nicht darauf kommen, dreimal TAB zu drücken. Ob man im Einzelfall hier ein Auge zudrücken, wenn jemand das video-Element nutzt, ist nicht so ganz klar, denn bei Fehlermeldungen lassen wir auch nicht die Browserbehandlung zu. Generell schwieriges Thema. Aber immerhin gut, dass die Untertitel per Tastatur aktivierbar sind.