etablierte Bezeichnung?

[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