6.2.2.4 Echtzeitanzeige von Sprech-Aktivität

[detlevhfischer]

Ist es zwingend erforderlich, die Ausgabe der Sprechaktivität auf der Braillezeile zu prüfen, oder reicht die Screenreader-Ausgabe? Falls die Zeile notwendig ist, würde das bedeuten, dass Prüfer ohne Braillezeile, falls der PS anwendbar ist, auf Braillezeilen-Nutzer angewiesen sind oder sich dieses Ding selbst besorgen und es verstehen mässen...

[cstrobbe]

Meinst du Folgendes?

Ist es zwingend erforderlich, die Ausgabe des Screenreders auf der Braillezeile zu prüfen, oder reicht die Sprachausgabe (d.h. Sprachsynthese)? (...) müssen.

[detlevhfischer]

Hmm.. Ich kenne mich mit der Braillezeile nicht gut genug aus, um zu wissen, ob alles, was auf der Zeile ankommt, auch in der Sprachausgabe ankommt. Falls das der Fall ist, wäre die Frage gelöst und die Überprüfung auch ohne Zeile möglich. Das muss besser ein kundiger Braillezeilen-Benutzer beantworten..,

[MarcHaunschild]

Haben wir hier einen oder soll ich mal einen fragen?

[johannesFischer84]

Hinweis: Ich hatte dazu mit #44 auch ein Issue eröffnet und dort meine Gedanken geäußert.

[mayerhh]

Die Sprach- und Braille-Ausgabe ist nicht identisch. Ein Weg für die Prüfung wäre vielleicht ein Braille-Betrachter. Bei Jaws und NVDA wird das mitgeliefert. Jaws gibt darüber auch Aktualisierungen von Live-Regions aus. Bei NVDA klappt das anscheinend nicht.

[johannesFischer84]

Die Sprach- und Braille-Ausgabe ist nicht identisch. Ein Weg für die Prüfung wäre vielleicht ein Braille-Betrachter. Bei Jaws und NVDA wird das mitgeliefert. Jaws gibt darüber auch Aktualisierungen von Live-Regions aus. Bei NVDA klappt das anscheinend nicht.

Interessant. Den Braille-Betrachter von NVDA habe ich gerade gefunden und ausprobiert. Ich frage mich allerdings, welche Gründe es gibt, wann die Braille-Zeile andere Ausgaben liefert als die Sprachausgabe. Und inwieweit ein Entwickler darauf Einfluss nehmen kann. Werden z. B. Attributwerte von aria-label ausgegeben, aber eine Textalternative in einem HTML-Knoten als einfacher Text nicht (reine Spekulation)? Gibt es da Erfahrungen?

[mayerhh]

Mir ist keine Weg bekannt als Entwickler gezielt eine Braille-Zeile anzusprechen. Die ARIA Docs sagen zu dem Thema auch kaum etwas. Bei role=status steht "Assistive technologies MAY reserve some cells of a Braille display to render the status." (https://www.w3.org/TR/wai-aria-1.1/)

[MarcHaunschild]

Ich möchte mal etwas ganz grundsätzliches sagen, über eine bedenkliche Entwicklung, die ich auch in Diskussionen außerhalb der BIK-Gemeinde (z.B. in der IAAP) zu bemerken meine. Die WCAG sind bewusst technikunabhängig formuliert. Werden Aria-Attribute, Textalternativen usw standardkonform eingesetzt, ist es vollkommen egal, ob Braille-Nutzern dies ausgegeben wird oder nicht. Der Prüfschritt ist bestanden. Punkt. Man kann eine korrekt erstellte Website nicht abwerten, wenn das Problem in der AT liegt. Was wäre denn die Alternative? Auf den Marktführer optimieren und so Monopolbildung fördern? - Bei den Browsern erleben wir das gerade zugunsten von Chrome. Wir wissen wo das endet: diese Seite wurde optimiert für IE6 mit einer Auflösung von 800 mal 600 Pixeln! Standards sind das A und O bei der Umsetzung von Barrierefreiheit und man kann In einem Test auf Konformität von niemandem mehr verlangen, als diese einzuhalten. Zumindest nicht bei einer Konformitätsprüfung zur Einhaltung von Mindeststandards. Natürlich sind Entwickler darüber hinaus aufgefordert sich mit best-practice um noch mehr Zugänglichkeit zu bemühen - aber das hat dann schon nichts mehr mit dem Test zu tun. Natürlich verwende ich schon jetzt Screenreader, als Hilfsmittel um Fehler zu finden. Das führt aber auch oft in die Irre. So gibt VoiceOver bisweilen erstaunlich aussagekräftige Text-Alternativen aus, wo vom Seitenbetreiber keine angegeben wurden: Toll für die Nutzer, für einen Tester kontraproduktiv. Eine AT ist also gerade nicht objektiv und schon gar nicht der Maßstab dafür, ob ein Prüfschritt als bestanden zu werten ist. Und neben der Tatsache, dass etwas in einer bestimmten AT nicht funktioniert, gibt es ja auch das andere Extrem: Ein Nutzer der JAWS weit überdurchschnittlich gut bedienen kann, kommt auch mit sehr schlechten Webseiten zurecht. Da sagen wir ja auch nicht, wenn der das schafft, bekommt die Seite trotz aller Verstöße gegen die Spec und best practices das Siegel "barrierefrei", weil es ja irgendwie doch möglich wäre, alle relevanten aus der Seite rauszukitzeln. Langer Rede kurzer Sinn: der ganze Test sollte meiner Meinung nach ohne jede AT durchführbar sein. Nur Standard-Konformität ist objektiv bewertbar. Ob etwas in einer bestimmten AT ankommt, sollte in diesem Test keine Rolle spielen. Hinweis am Rande: Das ITZ Bund fordert für alle im Rahmen der Dienstekonsolidierung bereit gestellten Informationen zusätzlich zu einem bestandenen Test positive Ergebnisse von Tests mit authentischen Nutzern (also Menschen mit Behinderungen, die AT einsetzen). Ich bin ausdrücklich dafür, dass das gemacht wird, denn wir wissen, wie es enden kann, wenn nur Checklisten abgehakt werden. Aber man muss ganz klar trennen zwischen einerseits Konformität zu einem Standard wie der EN und anderseits Nutzertests, in denen dann eben doch wieder Subjektivität (Auswahl der Teilnehmer, Anteile der unterschiedlichen Arten von Behinderungen usw) eine große Rolle spielt. Das sind QS-Maßnahmen wie wir sie auch aus der Usability und Marktforschung kennen, die überprüfen, wie eine Mehrheit mit den von uns bereit gestellten Dingen klar kommt. Aber dieser Test hier sollte eine Grundlage bilden für alle, nicht nur für die Mehrheit. Sorry wenn ich als Außenstehender hier solche Grundsatz-Debatten anstoße, aber ich verwende den Test ja nun seit vielen Jahren und bin ein großer Fan, sehr wohlwollend und derzeit ein wenig besorgt von der aktuellen Entwicklung...

[sweckenmann]

Ich stimme @MarcHaunschild zu. Zusätzlich muss man noch berücksichtigen, ob eine Technik "accessibiltiy supported" ist, aber grundsätzlich denke ich auch, dass wir das so im BITV-Test handhaben.

Ich habe mich mit diesem Prüfschritt noch nicht so intensiv beschäftigt, was ich aber noch nicht verstehe, es geht um den "visuellen Indikator", der vorhanden sein muss?

Where ICT provides two-way voice communication, and has RTT capabilities, the ICT shall provide a real-time visual indicator of audio activity on the display.

Im zweiten Absatz steht:

NOTE 1: The visual indicator may be a simple character position on the display that flickers on and off to reflect audio activity, or presentation of the information in another way that can be both visible to sighted users and passed on to deaf-blind users who are using a braille display.

Also entweder ein visueller Indikator der aufflackert oder etwas das von Sehenden und taub-blinden Menschen (über eine Braille-Zeile) angezeigt wird? Da steht nicht "und"? Lasse mich aber auch gerne belehren ;).

In der jetzigen Prüfschritt-Version (PR) wird beides geprüft? Wenn wir tatsächlich auch die programmatische Ermittelbarkeit prüfen, dann denke ich auch, dass wir das ohne Hilfsmittel prüfen müssen.

[johannesFischer84]

Also entweder ein visueller Indikator der aufflackert oder etwas das von Sehenden und taub-blinden Menschen (über eine Braille-Zeile) angezeigt wird? Da steht nicht "und"? Lasse mich aber auch gerne belehren ;).

Sonja, hast du eventuell das "both ... and" im letzten Halbsatz überlesen? Der lautet: "that can be both visible to sighted users and passed on to deaf-blind users who are using a braille display".

[sweckenmann]

@johannesFischer84 Oh, ja. Stimmt. Vielen Dank.

[detlevhfischer]

ich habe da gerade in #44 noch was dazu geschrieben - ich verstehe die verschiedenen Nutzerszenarien noch nicht ganz, vor allem nicht, wie das für taubblinde Nutzer funktionieren kann, gleichzeitig zuzuhören und zu ermitteln wer spricht - wenn das nicht Teil des gleichen Textflusses ist. Wenn role=status theoretisch auf einer reservierten Stelle der Braillezeile ausgegeben wird, wie @mayerhh sagt, könnte es gehen? Kennt jemand ähnliche Beispiele?