etablierte Bezeichnung?

[Cyx23]

Hallo,

gibt es übliche verständliche Kennzeichnungen für barrierefreie Seiten oder unterstützende Funktionen?

Ich möchte (nur/erstmal nur) Teile eines Projektes barrierefreier gestalten.

Wie kann z.B. eher dezent und doch verständlich auf Accesskeys hingewiesen werden?

Wäre z.B. neben dem Begriff "barrierefrei" etwas kürzeres wie "WAI" verständlich, gibt es bereits eine entsprechende Bezeichnungskultur?

Grüsse

Cyx23

[Sven Rautenberg]

Moin!

gibt es übliche verständliche Kennzeichnungen für barrierefreie Seiten oder unterstützende Funktionen?

Ich möchte (nur/erstmal nur) Teile eines Projektes barrierefreier gestalten.

Nicht lange fragen, einfach machen.

Wie kann z.B. eher dezent und doch verständlich auf Accesskeys hingewiesen werden?

Accesskeys haben in meinen Browsern irgendwie noch nie funktioniert. Eine Seite wird auch nicht dadurch barrierefreier, dass nun jeder Link einen von 26 möglichen Buchstaben erhält, damit man ihn schneller aufrufen kann. Ich sehe daher das Problem dieses Details eher als irrelevant an.

Wäre z.B. neben dem Begriff "barrierefrei" etwas kürzeres wie "WAI" verständlich, gibt es bereits eine entsprechende Bezeichnungskultur?

Du willst das eigentlich Selbstverständliche einbauen und suchst nach einem "Toll"-Sticker, damit man dich loben kann? Meinst du nicht, dass es primäres Ziel sein sollte, erstmal mit den Umbauten fertig zu werden. Dass man sich dann auf den Seiten leichter, barrierefreier bewegen kann, werden die Besucher schon von alleine merken - oder auch nicht (das ist ja gerade das Schöne an Barrierefreiheit: Man merkt ihre Anwesenheit nicht, man ärgert sich nur, wenn sie fehlt).

Sie werden keinerlei Vorteil haben, wenn du ihnen es explizit nochmal sagst, dass sie jetzt barrierefrei surfen. Allenfalls ein Eintrag in den News oder im Update-Log wäre angemessen, um zu verkünden, dass gewisse Dinge geändert wurden.

Eine sprachliche Bezeichnung ist mir jedenfalls nicht bekannt. "WAI" kennt jedenfalls niemand.

- Sven Rautenberg

[Cyx23]

Hallo,

Ich möchte (nur/erstmal nur) Teile eines Projektes barrierefreier gestalten.

[...]

Nicht lange fragen, einfach machen.

Wie kann z.B. eher dezent und doch verständlich auf Accesskeys hingewiesen werden?

Accesskeys haben in meinen Browsern irgendwie noch nie funktioniert. Eine Seite wird auch nicht dadurch barrierefreier, dass nun jeder Link einen von 26 möglichen Buchstaben erhält, damit man ihn schneller aufrufen kann. Ich sehe daher das Problem dieses Details eher als irrelevant an.

Das (die Irrelevanz) kann ich nicht beurteilen, klar ist aber dass kaum jemand ohne Hinweis diese Funktion vermutet. Ausserdem eigent es sich als Ersatzlösung für Netscape 4 (wäre aber da besonders unerwartet), bei dem schon einfache Formatierungen das Anspringen per tab stören können.

Wäre z.B. neben dem Begriff "barrierefrei" etwas kürzeres wie "WAI" verständlich, gibt es bereits eine entsprechende Bezeichnungskultur?

Du willst das eigentlich Selbstverständliche einbauen

Eben nur bedingt, (und m.E. übrigens gar nicht selbstverständlich) und ggf. durch zusätzliche Schalter und CSS-Switches unterstützbar usw..

[...]

Nochmals: "eher dezent und doch verständlich." Priorität hat ggf. das Layout, das weder durch Buttons noch durch die Eigenschaft Barrierefreiheit selbst zu sehr leiden soll.

Eine sprachliche Bezeichnung ist mir jedenfalls nicht bekannt. "WAI" kennt jedenfalls niemand.

Genau das wollte ich nochmal abklären, danke.

Grüsse

Cyx23

[Orlando]

Hi Sven, hi Cyx23,

gibt es übliche verständliche Kennzeichnungen für barrierefreie Seiten oder unterstützende Funktionen?

eher als die diversen Logos (WAI, Bobby) halte ich einen kurzen Absatz der so oder so ähnlich lauten könnte, für sinnvoll: Diese Site ist barrierefrei im Sinne der BITV ("Barrierefreie Informationstechnik-Verordnung"), der WAI ("Web Acessibility Initiative", Web-Zugänglichkeits-Initiative) usw. Über Links sollte weiterführende Information erreichbar sein.

Wie kann z.B. eher dezent und doch verständlich auf Accesskeys hingewiesen werden?

Mit einem Link [Accesskeys], der zu einer ausführlichen Erklärung führt?

Accesskeys haben in meinen Browsern irgendwie noch nie funktioniert.

Opera: [Shift][Esc], Accesskey - das funktioniert tadellos.

Wäre z.B. neben dem Begriff "barrierefrei" etwas kürzeres wie "WAI" verständlich, gibt es bereits eine entsprechende Bezeichnungskultur?

Bekannter dürfte mittlerweile die "BITV" sein, das ist aber relativ... Auf Abkürzungen sollte man sich nicht verlassen.

Grüße,
 Roland

[molily]

Hallo Cyx,

gibt es übliche verständliche Kennzeichnungen für barrierefreie Seiten oder unterstützende Funktionen?

Nun, üblich ist vermutlich »Zur Text-Version«. ;)

Ich möchte (nur/erstmal nur) Teile eines Projektes barrierefreier gestalten.

Wie kann z.B. eher dezent und doch verständlich auf Accesskeys hingewiesen werden?

Wenn du eine Art generelle Hilfe zur Seitenbedienung bieten möchtest und in diesem Kontext auf die Accesskeys hinweisen möchtest, würde ich den entsprechenden Abschnitt dort etwa »Bedienung über Tastenkombinationen« nennen und die Kurztasten beschreiben (am besten auch, was der Anwender drücken muss - viel Spaß beim Beschreiben der dutzenden Varianten für die verschiedenen Browser und Betriebssysteme...).

Übrigens gibt es viele Argumente gegen Accesskeys und deren Wirksamkeit, beispielsweise sind viele Tastaturkombinationen bereits belegt, besonders wenn Zusatztechniken verwendet werden. Ab einer Handvoll wird es auch meiner Meinung nach zuviel, vielleicht wäre es angesichts dessen vorteilhafter, die »Tools« wie Home, Suche, Hilfe, Übersicht, Kontakt usw. anstatt die Rubriken der Primärnavigation mit Accesskeys zu versehen.

Wäre z.B. neben dem Begriff "barrierefrei" etwas kürzeres wie "WAI" verständlich, gibt es bereits eine entsprechende Bezeichnungskultur?

Wieso willst du es überhaupt offen thematisieren? »Accessiblity Statements« beziehungsweise Konformitätserklärungen haben höchstens formal-rechtlichen Wert, da sind die Bezeichnungen an die jeweiligen Richtlinien gebunden, wie du das letztlich nach außen hin benennst, ist davon unabhängig, »barrierefrei« ist durchaus üblich. Im Gegensatz zur WCAG (insbesondere Version 2, siehe http://www.w3.org/TR/WCAG20/#conformance) verlangt die BITV übrigens meines Wissens keine vorgeschriebene Konformitäts-Klausel, für den normalen Besucher sind diese in der Form sowieso uninteressant. Prinzipiell sehe ich auch nicht viel Sinn darin, einen informalen Hinweis anzubringen à la »wir sind in und schreiben auch barrierefrei«, dann eher einen speziellen Fokus auf die Dokumentation der Features legen (im Stil einer »Hilfe«, wie gesagt)

Ich rätsel auch darüber, wie man die angesprochenen Personalisierungs-Funktionen verständlich benennen könnte. Beim Style-Switcher vielleicht etwas wie »Erscheinungsbild anpassen«? Das hängt natürlich von den angebotenen Stylesheets ab; wenn es dabei ausschließlich um Farbumkehrung und eventuell Stylesheet-Deaktivierung oder Deaktivierung des die Skalierbarkeit erschwerenden Spaltenlayouts geht, wäre »Erscheinungsbild«/»Aussehen« nicht unbedingt passend (don't make me think...). Bei Funktionen wie dem Anpassen der Schriftgröße usw. ist das Finden von angemessenen Bezeichnungen schon einfacher. Zusätzliche Symbole eigenen sich unter Umständen auch zur Illustration. Wenn du diese Personalisierungs-Funktionen auf einer zentralen Seite in einem gemeinsamen Formular zusammenträgst, ist die Benennung nicht in gleicher Weise kritisch, weil ein erklärender Satz sowieso von Nöten ist.

Mathias

[MudGuard]

Hi,

gibt es übliche verständliche Kennzeichnungen für barrierefreie Seiten oder unterstützende Funktionen?

Das führt doch höchstens dazu, daß der User bei Mängeln an der Barrierefreiheit sagt: die lügen mich also auch noch an...

Ich möchte (nur/erstmal nur) Teile eines Projektes barrierefreier gestalten.

Tu das.

Wie kann z.B. eher dezent und doch verständlich auf Accesskeys hingewiesen werden?

Wenn, dann per Link auf eine Beschreibungsseite. Ich halte Accesskeys aber nicht unbedingt für sinnvoll.
Wer auf die Tastatur angewiesen ist, dürfte bereits viele Tastenkombinationen belegt haben...

Wäre z.B. neben dem Begriff "barrierefrei" etwas kürzeres wie "WAI" verständlich, gibt es bereits eine entsprechende Bezeichnungskultur?

Gar nicht erwähnen, einfach machen (s.o.)

cu,
Andreas

[Cyx23]

Hallo nochmal,

gibt es übliche verständliche Kennzeichnungen für barrierefreie Seiten oder unterstützende Funktionen?

da die Barrierefreiheit erstmal keine Priorität haben soll, bleibt nur die Skalierbarkeit der Schrift als mögliches Feature ohne Erklärungsbedarf.
Bei Schaltern müsste mangels etablierter Sprache oder Symbolik womöglich indirekt durch -gut auffindbare!- Begriffe und Erklärungen stark in das Layout eingegriffen werden. Damit kommt wieder die Frage nach zwei Seiten oder einer Vorschaltseite, es gibt also erstmal keine vernünftige Strategie eine "normale" Seite _auch_ barrierefrei zu machen.

Wie kann z.B. eher dezent und doch verständlich auf Accesskeys hingewiesen werden?

Für Accesskeys scheint sich zumindest hier im Thread keiner zu begeistern, und beim NC4 ist das Problem dass der Erklärungsbedarf besonders hoch wäre.

Fazit erstmal keine Lösung, ggf. "barrierefrei" als Bez., und sonst eher "BITV" als WAI.

Grüsse

Cyx23

[molily]

Hallo, Cyx,

da die Barrierefreiheit erstmal keine Priorität haben soll, bleibt nur die Skalierbarkeit der Schrift als mögliches Feature ohne Erklärungsbedarf.
Bei Schaltern müsste mangels etablierter Sprache oder Symbolik womöglich indirekt durch -gut auffindbare!- Begriffe und Erklärungen stark in das Layout eingegriffen werden.

Ich weiß wirklich nicht, warum man für zwei Links namens »Schrift vergrößern« und »Schrift verkleinern« das Layout umkrempeln muss und was an diesen Bezeichnungen uneindeutig ist. Das ist alles praktisch umsetzbar. Querlinks innerhalb des Dokuments erlauben es durchaus, sie beispielsweise in der rechten Spalte bzw. am Dokumentende unterzubringen, ohne dass sie schlecht auffindbar werden. Für ausschließliche Screenreader-Benutzer sind sie ja sowieso uninteressant und müssen nicht schnell erreichbar sein, das Auge wandert hingegen schnell nach rechts.

Damit kommt wieder die Frage nach zwei Seiten oder einer Vorschaltseite, es gibt also erstmal keine vernünftige Strategie eine "normale" Seite _auch_ barrierefrei zu machen.

Ich sehe da keinen logischen Zusammenhang. Dieses simple Feature bedarf keiner Extraversion und es ist durchaus möglich, eine »normale« Seite barrierefrei zu machen, ohne das Konzept zu verwerfen. Mir kommt es so vor, als legest du dir die Tatsachen so zurecht, wie du sie haben willst. Was du äußerst, sind aber nur Behauptungen.

Wie kann z.B. eher dezent und doch verständlich auf Accesskeys hingewiesen werden?

Für Accesskeys scheint sich zumindest hier im Thread keiner zu begeistern, und beim NC4 ist das Problem dass der Erklärungsbedarf besonders hoch wäre.

Das verstehe ich nicht, meines Wissens kann Netscape 4 keine accesskeys, insofern sehe ich keinen großartigen Erklärungsbedarf für diesen und diesbezüglich ähnlich verfahrende Browser, nur eben, dass es nicht funktioniert.

Fazit erstmal keine Lösung, ggf. "barrierefrei" als Bez., und sonst eher "BITV" als WAI.

Ohne bindende Zielvereinbarungen gemäß dem Bundesgleichstellungsgesetz ist die BITV momentan sowieso fern und nur eine Zweitquelle, wie gesagt. Das wird die Zeit zeigen. Die Orientierung an den WCAG, speziell im Hinblick auf Version 2.0, und dem Barriereabbau darüber hinaus ist m.E. ratsamer und bietet auch Ansätze zur Zukunftssicherheit, die das starre Befolgen des BITV-Regelkatalogs (der auf dem technischen Niveau von 1999 dümpelt) alleine nicht bietet.

Grüße,
Mathias

[Cyx23]

Hallo Mathias,

Ich weiß wirklich nicht, warum man für zwei Links namens »Schrift vergrößern« und »Schrift verkleinern« das Layout umkrempeln muss und was an diesen Bezeichnungen uneindeutig ist. Das ist alles praktisch umsetzbar. Querlinks innerhalb des Dokuments erlauben es durchaus, sie beispielsweise in der rechten Spalte bzw. am Dokumentende unterzubringen, ohne dass sie schlecht auffindbar werden. Für ausschließliche Screenreader-Benutzer sind sie ja sowieso uninteressant und müssen nicht schnell erreichbar sein, das Auge wandert hingegen schnell nach rechts.

ein interessanter Aspekt, das Dokumentende kann allerdings bei textorientierten Seiten mit Scrolleiste hinsichtlich Layout ein unkritischerer Bereich sein, ich hatte bislang an Platzierungen oben rechts oder oben mittig gedacht.

Wenn die Schrift sowieso skalierbar ist sind Links wie »Schrift vergrößern« und »Schrift verkleinern« doch wohl eher überflüssig, möglich wäre ein Schalter für die Hintergrundfarbe oder ggf. "invers". Die Problematik liegt aber noch woanders....

Damit kommt wieder die Frage nach zwei Seiten oder einer Vorschaltseite, es gibt also erstmal keine vernünftige Strategie eine "normale" Seite _auch_ barrierefrei zu machen.

Ich sehe da keinen logischen Zusammenhang. Dieses simple Feature bedarf keiner Extraversion und es ist durchaus möglich, eine »normale« Seite barrierefrei zu machen, ohne das Konzept zu verwerfen. Mir kommt es so vor, als legest du dir die Tatsachen so zurecht, wie du sie haben willst. Was du äußerst, sind aber nur Behauptungen.

....nämlich da wo diese Hinweise selbst eben bereits barrierefrei sein müssen, um gefunden zu werden. Z.B. auch bei einem "normalen" Layout, schwarz auf weiss  mit 10 oder weniger px, dazu einige Links die im "Normalfall" eher weniger Aufmerksamkeit erlangen sollen und z.B. 10px light oder silver auf white dargetellt sind. Es geht also um verschiedene z.Teil gegensätzliche Anforderungen, und nicht darum alles vorrangig barrierefrei zu machen. Und Auftritte nach gesetzlichen Vorgaben oder öffentliche Websites sind wieder ein anderes Thema.

Für Accesskeys scheint sich zumindest hier im Thread keiner zu begeistern, und beim NC4 ist das Problem dass der Erklärungsbedarf besonders hoch wäre.

Das verstehe ich nicht, meines Wissens kann Netscape 4 keine accesskeys, insofern sehe ich keinen großartigen Erklärungsbedarf für diesen und diesbezüglich ähnlich verfahrende Browser, nur eben, dass es nicht funktioniert.

Netscape 4 unterstützt die Tab-taste nicht richtig, und Accesskeys als möglichen Ersatz kann ich gut nachrüsten, aber dann eben mit Erklärungsbedarf. Wenn Accesskeys ansonsten wenig Sinn machen kann ich natürlich den Aufwand für die anderen Browser oder gleich vollständig einsparen.

Grüsse,

Cyx23