search

BIK-BITV / BIK-Web-Test

Testverfahren zur Prüfung der Barrierefeiheit von Webanwendungen anhand der Kriterien der WCAG 2.1, EN 301 549 und BITV 2.0
67 stars 21 forks source link

9.2.4.4 Wenn Dateiformat des Links für alle Nutzenden unklar, dann kein Mangel? #368

Closed CarstenKaul closed 10 months ago

CarstenKaul commented 10 months ago

Frage zur Prüfpraxis.

Zitat aus Ziffer 2.2 , Aufzählung #4:

Falls weder über den Linktext noch über ein entsprechend eindeutiges Icon Auskunft über das Dateiformat gegeben wird, ist das Dateiformat des Links möglicherweise für alle Nutzenden unklar. Dies ist nicht als Mangel im Sinne dieses Prüfschritts zu bewerten (sollte jedoch ggf. als allgemeines Usability-Problem angemerkt werden).

Habe ich das richtig verstanden, dass wenn gar kein Dateityp visuell oder programmatisch vorhanden ist, das nicht (mehr) bemängelt werden soll? Das macht aus meiner Sicht keinen Sinn. War dieser Text schon immer in dieser Anforderung drin?

Ich habe noch gelernt, dass das Öffnen HTML-externer-Dateien dazu führen kann, dass sich ggf. neue Apps-öffnen, z. B. Word oder Adobe-Reader und Nutzer dadurch irritiert sind, wenn sie die Browserumgebung plötzlich und unerwartet verlassen. Das ist ist eine besondere Erschwernis für Menschen die ohnehin schon auf eine beständige und erwartungskonforme Bedienung angewiesen sind. Die im Zitat genannte Begründung scheint die fehlende "Benachteiligung" dafür anzuführen, dass diese Anforderung nicht (mehr) bemängelt werden darf.

Oder verstehe ich da was falsch?

MarcHaunschild commented 10 months ago

Alles richtig.

Es sind zwei Dinge:

Erstens Barrierefreiheit bedeutet im Sinne der WCAG (und hier liegt ein WCAG SC zugrunde), dass alle Informationen jedem Menschen zugänglich sein sollen. Ist eine Information nicht vorhanden (gibt es also keinen Hinweis auf das Dateiformat) müssen Nutzer mit Hilfsmitteln (z.B. Screenreader) darüber nicht exklusiv unterrichtet werden.

Zweitens Medienbrüche sind sowieso immer schlecht für Nutzer - egal ob jemand behindert ist oder nicht - und sollten möglichst vermieden werden. Wenn es nicht anders geht, sollte über den Format-Wechsel zumindest hingewiesen werden. Aber das ist kein WCAG-Kriterium und als Prüfer kann man nicht verlangen, was die WCAG nicht hergeben (bzw. die EN 301 549, die hier aber nur auf das WCAG SC verweist).

Konformität ist leichter zu erreichen, als mancher denkt. Manchmal ist das gut, weil es praxisnah ist, manchmal ist es eine nur sehr rudimentäre Unterstützung die gefordert wird und oft kommt man mit der schlechteren Lösung davon. Siehe open captions vs closed captions...

CarstenKaul commented 10 months ago

OK. danke für die Ausführungen.

Ich kann der Argumentation aber nicht zustimmen, weil ich aus der langjährigen Schulungspraxis andere Erfahrungen gemacht habe. Als Sehender kann ich die URL in der Browserstatusleiste leicht beobachten und so erkennen auf was für eine Datei verlinkt wird. Sogar der Blinde kann sich notfalls die komplette URL vorlesen lassen. Menschen (ohne Screenreader-Funktionalität) wie z.B. die auf Vergrößerungssoftware angewiesen sind, bekommen das aber nicht hin. Auch das war für mich immer ein Argument, warum der externe Dateityp zumindest visuell angegeben werden muss.

Wenn die WCAG nicht mehr her gibt, mag das so sein. Praxisnah ist nach meiner Einschätzung aber nicht, weil die Folgen des unangekündigten Medienbruchs eine erhebliche Benachteiligung sein kann. Das ist für mich auch weiterhin das Hauptargument in Beratungsgesprächen für diese Anforderung bei unangekündigten Medienbrüchen.

Es war mir wichtig das zu erwähnen und kann dann geschlossen werden. Würde mich nur noch Interessieren wann dieser Zusatz ergänzt wurde. Ich bin mir sicher, das stand nicht immer so in der BIK-Prüfschrittbeschreibung und ich bin bereits seit 2007 dabei.

sweckenmann commented 10 months ago

@CarstenKaul Hier der PR der zur Änderung führte (Hintergrund waren Diskussionen in der WCAG Working Group, sind im PR verlinkt). https://github.com/BIK-BITV/BIK-Web-Test/pull/230

Siehe auch normativer Text des Erfolgskriteriums:

... except where the purpose of the link would be ambiguous to users in general...

Es ist natürlich trotzdem zu empfehlen, dass man über das Dateiformat informiert. Und wir schreiben das "als Empfehlung" auch in den Prüfreport, aber nach WCAG können wir es nicht als FAIL bewerten.

Wir machen übrigens seit ca. 1 Jahr zum Ende des Quartals Prüfschritt-Releases mit Änderungsprotokollen. Bei Interesse kannst du dich über github benachrichtigen lassen, wenn ein neues Release (mit Änderungsprotokoll) veröffentlicht wird.

CarstenKaul commented 10 months ago

Danke fürs raussuchen.

Ich habe die Benachrichtigungen über Git-Hub-Änderungen bereits seit ca. 12 Monaten aktiv und werde dann manchmal von der Masse an Änderungsbenachrichtigungen erschlagen um den Überblick zu behalten.

Für mich schwer nachzuvollziehen, dass das im Sinne der WCAG sein soll: https://github.com/w3c/wcag/issues/1149#issuecomment-640477191

Kann geschlossen werden.

johannesFischer84 commented 10 months ago

@CarstenKaul Carsten, die WCAG fordern das nicht, dass der Dateityp angegeben wird, siehe Technik H30, Example 6. Dort steht:

Many users prefer to know the file type when opening a file that results in opening a new application to view the file, so it is often regarded as useful to include this additional information. However, this is not required for compliance with this Success Criterion.

In der Beratungspraxis ist es aber natürlich sinnvoll, die Angabe des Dateityps zu empfehlen. Deine persönlichen Schulungserfahrungen kannst du da gleich mitgeben.