nicht angemeldet
Versuch eines barrierefreien Applikations-Menüs
JürgenB
Versuch eines barrierefreien Applikations-Menüs
JürgenB
marctrix
Gunnar BittersmannHallo,
ich bin gerade dabei, bei meinem GPX-Viewer die Kartenlegende, über die die Kartenelemente ein- und ausgeblendet werden können, zu überarbeiten. Siehe z.B. diese Seite. Da die Legende komplett per Javascript aus den geladenen Daten erstellt wird, habe ich eine Testseite mit statischem html erstellt, s. problematische Seite.
Da die Kartenlegende sich wie ein Pulldown-Menü verhält, aber keine Links enthält, habe ich mich an die „Regeln“ für Application Menus gehalten. Die Auswahl der Pulldowns erfolgt neben der Maus über die Tab-Taste, in den Pulldowns wird mit den Pfeiltasten navigiert.
Jetzt meine Fragen
-
Ist es wirklich intuitiv, wenn die aktiven Elemente im Pulldown nur mit den Pfeiltasten angesprungen werden können? Oder sollte man das Anspringen mit dem Tabulator zusätzlich aktiviert lassen?
-
Wie sigmalisiere ich Benutzern von Vorlesesoftware, wie das Menü zu bedienen ist?
-
Durch role-Attribute?
-
Durch Aria-Label?
-
Durch visuell versteckte Hinweistexte?
-
Ich habe z.Zt. Mail-Kontakt mir einem Blinden. Mit einer Zwischenversion mit verstecktem Hinweis ist er zurechtgekommen. Daher tendiere ich momentan zu dieser Variante. Aber was meint ihr?
Gruß
Jürgen
-
Lieber JürgenB,
welchen Sinn hat eine Vorlesesoftware bei Karten? Inwiefern kann die Vorlesesoftware den visuellen Inhalt der Kacheln verständlich machen?
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix,
der Blinde, zu dem ich Kontakt habe, zeichnet seine Wege mit einer Navi-Software auf. Nun möchte er den Weg erfühlen. Dazu habe ich von meiner Seite zum Anzeigen von GPX-Daten eine Version erstellt, die als Defaulteinstellung den Weg (Track) in schwarz mit etwas dickerer Linie zeichnet und die Karte ausblendet. Zusätzlich werden unter dem Kartenbereich Informationen angezeigt. Wird die Seite dann gedruckt, werden die Texte in Braille dargestellt und alles auf einem Spezial-„Drucker“ in Papier gestanzt, und kann dann ertastet und Archviert werden. Falls es dich interessiert und du eine GPX-Datei hast (sonst nimm diese), kannst du es ja mal ausprobieren.
Gruß
Jürgen -
Hej Felix,
welchen Sinn hat eine Vorlesesoftware bei Karten? Inwiefern kann die Vorlesesoftware den visuellen Inhalt der Kacheln verständlich machen?
Gar nicht. Und dennoch gibt es für blinde Möglichkeiten Dinge zu nutzen, von denen wir es uns gar nicht vorstellen können, siehe Antwort von Jürgen.
Er könnte aber auch mit dem richtigen Ausschnitt ausgedrückt zu einem sehenden gehen, die App „be my eyes“ verwenden oder, oder, oder.
Es macht immer Sinn, so viele Barrieren wie möglich zu entfernen.
Gut wäre natürlich neben der visuellen kartendarstellung zusätzlich eine Liste anzubieten, wie sie von Routenplanern erstellt wird (wann man wo anbieten muss, wie viele Meter/ Kilometer es bis dahin sind und wie lange die Strecke insgesamt ist (km, Zeit zu Fuß und mit dem Auto…). Das ist auch für sehende ein Mehrwert, wenn so etwas mitgegeben wird und kann ein- und aufklappbar gemacht werden, so dass es sehenden nicht viel Platz nimmt - falls das ein Problem sein sollte.
Marc
--
Ceterum censeo Google esse delendam-
Hallo Marc,
Gut wäre natürlich neben der visuellen kartendarstellung zusätzlich eine Liste anzubieten, wie sie von Routenplanern erstellt wird (wann man wo anbieten muss, wie viele Meter/ Kilometer es bis dahin sind und wie lange die Strecke insgesamt ist (km, Zeit zu Fuß und mit dem Auto…). Das ist auch für sehende ein Mehrwert, wenn so etwas mitgegeben wird und kann ein- und aufklappbar gemacht werden, so dass es sehenden nicht viel Platz nimmt - falls das ein Problem sein sollte.
das ist aber dann nicht mehr Aufgabe des Kartenscripts. Das kann eine Erweiterung des Scripts erledigen, oder der Seitenautor schreibt einen informativen Text zur Karte. Bei den meisten Anwendern meines Scripts ist es anders herum. Die haben einen Reisebericht und garnieren ihn mit einer Kartenansicht.
Gruß
Jürgen-
Hej JürgenB,
das ist aber dann nicht mehr Aufgabe des Kartenscripts.
Viele Wege führen nach Rom! 😉
Selbstverständlich sollte man den für Entwickler und Redakteure bequemsten wählen.
Auch bei der Umsetzung von Barrierefreiheit sollte man möglichst niemandem mehr Arbeit als nötig aufhalsen.
Der neue BITV-Test wertet übrigens „überwiegend erfüllte“ Prüfschritte als bestanden.
Es geht nicht darum aus Prinzip oder Dogmen-Gläubigkeit etwas strikt durchzusetzen, sondern die meisten Menschen (insbesondere die die Regeln aufstellen), sind in erster Linie nur an einem interessiert: das Web soll zugänglicher für alle werden - dabei entstehen in der Regel deutlich bessere Webseiten, die allen ermöglichen eine Webseite per Maus, Tastatur, Spracheingabe zu bedienen (oder mal so, mal so, ganz nach Anwendungsfall, Aufenthaltsort oder Laune).
Streng und mitunter ein wenig dogmatisch sind meiner Meinung nach viele Berater. Für die gibt es oft nur richtig und falsch, was vielleicht auch daran liegen mag, dass sie sich absichern müssen/ möchten.
Ich gehe möglichst so an die Verbesserung einer bestehenden Website, dass ich erst mal die Seite prüfe, relativ grob hinsichtlich der schlimmsten Fehler. Dann merke ich sehr schnell, ob der Auftraggeber bereit ist, wenigstens die zu beheben. Ist das gelungen, versuche ich die restlichen Fehler in einem zweiten Durchgang zu finden.
Selbst wenn dem Auftraggeber das dann Zuviel wird, ist bis dahin schon viel gewonnen und alle haben davon mehr, als würde ich von Anfang an über jede „Kleinigkeit“ reden.
Wenn man die BITV erfüllen muss, bleibt einem natürlich nichts anderes übrige als alle Fehler zu beseitigen.
Aber auch dann ist eine priorisierung sinnvoll. Erst mal beheben, was schnell geht und viel bringt, dann hat man kurzfristig eine erhebliche Verbesserung. In den folgenden Schritten dann verfeinert man das Ergebnis immer mehr.
Wenn möglich versuche ich aber alle Fehler an einer Komponente auf einen Schlag zu beheben. Ist ja auch doof, wenn man zweimal an dieselbe Stelle muss.
Marc
--
Ceterum censeo Google esse delendam
-
-
-
-
Hej JürgenB,
Jetzt meine Fragen
-
Ist es wirklich intuitiv, wenn die aktiven Elemente im Pulldown nur mit den Pfeiltasten angesprungen werden können? Oder sollte man das Anspringen mit dem Tabulator zusätzlich aktiviert lassen?
-
Wie sigmalisiere ich Benutzern von Vorlesesoftware, wie das Menü zu bedienen ist?
- Durch role-Attribute?
Ja mit treeview
- Durch Aria-Label?
Aria-label ist nicht so gut, besser aria-described by, wenn es etwas zu beschreiben gibt, sind diese Infos meist für alle hilfreich, nicht nur für Blinde.
- Durch visuell versteckte Hinweistexte?
Nur wenn die Sehende stören würden.
Marc
--
Ceterum censeo Google esse delendam-
Tach!
[...] besser aria-described by, wenn es etwas zu beschreiben gibt, sind diese Infos meist für alle hilfreich, nicht nur für Blinde.
Wie wird dieses Attribut (von Browsern?) verwendet, dass es für alle hilfreich ist?
dedlfix.
-
Hej dedlfix,
[...] besser aria-described by, wenn es etwas zu beschreiben gibt, sind diese Infos meist für alle hilfreich, nicht nur für Blinde.
Wie wird dieses Attribut (von Browsern?) verwendet, dass es für alle hilfreich ist?
Das funktioniert so. Du gibst einem ohnehin sichtbaren Element (zum Beispiel einem div mit einer Bildbeschreibung oder einer Überschrift) eine
idund einem anderen Element (z.B. einem Bild) einaria-describedby. So ist der für alle sichtbare Text dem Bild logisch zugeordnet.Das macht beispielsweise Sinn, wenn du in einem Text voraussetzt, dass eine bestimmte Aussage bei allen Leuten ankommt, die du in dem Bild zu sehen meinst. Es kommt nämlich vp9, dass andere Menschen in ein und demselben Bild unterschiedliche Dinge wahrnehmen. So kannst du sicherstellen, dass Sehende und nicht Sehende verstehen, warum du dieses Bild verwendest und kannst dich in deiner weiteren Argumentation darauf stützen.
Marc
--
Ceterum censeo Google esse delendam-
Tach!
Das funktioniert so. Du gibst einem ohnehin sichtbaren Element (zum Beispiel einem div mit einer Bildbeschreibung oder einer Überschrift) eine
idund einem anderen Element (z.B. einem Bild) einaria-describedby. So ist der für alle sichtbare Text dem Bild logisch zugeordnet.Diese logische Verbindung muss sich ein Sehender aber aus der gerenderten Anzeige im Browser herleiten, ansonsten wird er nur von Vorlesesoftware hergestellt?
dedlfix.
-
Hej dedlfix,
Das funktioniert so. Du gibst einem ohnehin sichtbaren Element (zum Beispiel einem div mit einer Bildbeschreibung oder einer Überschrift) eine
idund einem anderen Element (z.B. einem Bild) einaria-describedby. So ist der für alle sichtbare Text dem Bild logisch zugeordnet.Diese logische Verbindung muss sich ein Sehender aber aus der gerenderten Anzeige im Browser herleiten, ansonsten wird er nur von Vorlesesoftware hergestellt?
Ja, das ist wichtig. Der text kann beispielsweise mit dem Bild zusammen in einem Kasten oder direkt neben dem Bild oder so sein.
Oft wird bei so etwas erst oder nur an Blinde gedacht - auch sonst passiert mitunter, dass Blinde „bevorzugt“ werden.
So kann man - entsprechende Software vorausgesetzt - sagen, dass ein bestimmter Link geöffnet werden soll - wenn der sichtbar anders beschriftet ist als im Quellcode (z.b. Mit einem vorangestellten Hinweis für Screenreader), kann man sich den Mund fusselig reden. Die Software wird den Link nicht so finden, wie er sichtbar beschriftet ist.
Wird selbstverständlich verlangt von der WCAG, aber manch einer denkt nicht dran…
Marc
--
Ceterum censeo Google esse delendam-
Hallo Marc,
So kann man - entsprechende Software vorausgesetzt - sagen, dass ein bestimmter Link geöffnet werden soll - wenn der sichtbar anders beschriftet ist als im Quellcode (z.b. Mit einem vorangestellten Hinweis für Screenreader), kann man sich den Mund fusselig reden. Die Software wird den Link nicht so finden, wie er sichtbar beschriftet ist.
Wird selbstverständlich verlangt von der WCAG, aber manch einer denkt nicht dran…
d.h. man soll auf verteckte Hinweise verzichten?
Gruß
Jürgen-
Hej JürgenB,
So kann man - entsprechende Software vorausgesetzt - sagen, dass ein bestimmter Link geöffnet werden soll - wenn der sichtbar anders beschriftet ist als im Quellcode (z.b. Mit einem vorangestellten Hinweis für Screenreader), kann man sich den Mund fusselig reden. Die Software wird den Link nicht so finden, wie er sichtbar beschriftet ist.
d.h. man soll auf verteckte Hinweise verzichten?
Nicht wenn man den Hinweis hinten dran hängt. Wenn der Anfang stimmt, scheint Software (ich habe die leider nie im Einsatz gesehen) die Links, Button usw zu finden.
Es schlägt sich auf deutsch im BITV-Prüfschritt 2.5.3a nieder und ist auch gut erklärt. Am problematischsten ist es, wenn der unsichtbare Text mitten im sichtbaren ist oder (logischerweise) wenn sich angezeigter und tatsächlich im Code hinterlegter Text komplett unterscheiden (beispielsweise, wenn man den Text im html per css versteckt und gar nicht anzeigt und dann was anderes anzeigen lässt - klingt bescheuert, wird aber mitunter gemacht, wenn es einfacher zu coden ist)…
Marc
--
Ceterum censeo Google esse delendam-
Hallo Marc
d.h. man soll auf verteckte Hinweise verzichten?
Nicht wenn man den Hinweis hinten dran hängt. Wenn der Anfang stimmt, scheint Software (ich habe die leider nie im Einsatz gesehen) die Links, Button usw zu finden.
puh. Dann habe ich wenigstens das richtig gemacht. Wobei „Wegpunkt anzeigen/verbergen“ ja noch geht, aber „Waypoint show/hide“ sprachlich eher „na ja“ ist.
Gruß
Jürgen-
Hej JürgenB,
d.h. man soll auf verteckte Hinweise verzichten?
Nicht wenn man den Hinweis hinten dran hängt. Wenn der Anfang stimmt, scheint Software (ich habe die leider nie im Einsatz gesehen) die Links, Button usw zu finden.
puh. Dann habe ich wenigstens das richtig gemacht. Wobei „Wegpunkt anzeigen/verbergen“ ja noch geht, aber „Waypoint show/hide“ sprachlich eher „na ja“ ist.
Wie wäre es mit „Toggle waypoint (show/ hide)“?
Marc
--
Ceterum censeo Google esse delendam-
Hallo Marc,
d.h. man soll auf verteckte Hinweise verzichten?
Nicht wenn man den Hinweis hinten dran hängt. Wenn der Anfang stimmt, scheint Software (ich habe die leider nie im Einsatz gesehen) die Links, Button usw zu finden.
puh. Dann habe ich wenigstens das richtig gemacht. Wobei „Wegpunkt anzeigen/verbergen“ ja noch geht, aber „Waypoint show/hide“ sprachlich eher „na ja“ ist.
Wie wäre es mit „Toggle waypoint (show/ hide)“?
schlecht. Der sichtbare Teil der Liste sieht eigentlich z.B. so aus:
Parkplatz
Gipfel
Restaurant
…Und der Hinweis soll ja nur hinten angehängt werden.
Gruß
Jürgen
-
-
-
-
-
-
-
-
-
Hallo Marc,
hast du mal mehr Infos zu treeview? Eine Suche nach diesem Begriff hat nichts geliefert, was mir hilfreich erschien.
Gruß
Jürgen-
@@JürgenB
hast du mal mehr Infos zu treeview? Eine Suche nach diesem Begriff hat nichts geliefert, was mir hilfreich erschien.
Navigation Treeview Example Using Computed Properties ist nicht hilfreich genug?
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann-
Hallo Gunnar,
die Seite kenne ich, die beantwortet aber die Frage nach dem Sinn vom Aria und role nicht richtig. Oder soll man beides nehmen und noch versteckte Hinweise?
Und warum Pfeiletasten intuitiver als der Tabulator sind, oder ob man doch beides nimmt, geht da auch nicht raus hervor. Da hätte ich gerne auch die Einschätzung von euch Experten.
Gruß
Jürgen-
Dem schließe ich mich mal an!
Gruß der misanthrop
-
-
Hallo Gunnar,
Navigation Treeview Example Using Computed Properties ist nicht hilfreich genug?
ich habe mir das jetzt noch mal angesehen, verstehe aber u.A das
role="group"im Beispiel nicht.Aber es wird doch von treeviews mit Pfeiltastenbedienung in Seitennavigationen (Linkliste) abgeraten. Pfeiltastenbedienung sei etwas für Anwendungsmenüs. Zu Anwendungsmenüs habe ich dieses Beispiel gefunden: https://www.w3.org/WAI/tutorials/menus/examples/appmenu/. Hier werden jetzt aber wieder andere Aria- und role-Attribute vergeben. Was soll ich denn jetzt nehmen?
Wie sagte einst Hans-Dieter Hüsch: „Je weniger ich von einer Sache verstehe, desto mehr beschäftige ich mich damit. Je mehr ich mich mit einer Sache beschäftige, desto weniger verstehe ich davon, so dass ich am Ende gar nichts mehr verstehe.“ (Aus dem Gedächtnis ziziert.)
Gruß
Jürgen
-
-
Hej JürgenB,
hast du mal mehr Infos zu treeview? Eine Suche nach diesem Begriff hat nichts geliefert, was mir hilfreich erschien.
Leider nein, außer die offiziellen Quellen. Ich hatte irgendwie gedacht, du hättest die kürzlich hier stattgefunden Diskussion über treeview mitbekommen.
Mir war das auch noch neu und ich komme im Moment nicht dazu, mich einzulesen und mich dazu auszutauschen, weil ich so viel um die Ohren habe.
Erst mal finde ich es auch befremdlich, dass man ausschließlich mit den Pfeiltasten navigieren kann.
Intuitiv wäre ich da nicht drauf gekommen, denke ich mal.
Meiner Meinung nach hat die Navigation mit Pfeiltasten den Vorteil, dass man nur benötigte Untermenüs öffnet und sich so nicht überall durch tabben muss. Daher ist das eigentlich gut, uneigentlich muss man halt erst mal drauf kommen.
Marc
--
Ceterum censeo Google esse delendam
-
-