Am 16. Mai 2008 nahm ich am 10. Accessible Media Stammtisch teil. Dabei wagte ich das Experiment mittels meines eeePC (mit Internetverbindung) und Twitter den Votrag von Wolfram Huber (Web-Tech Coaching) live ins Netz zu bringen.
Wie es mit mit dem twittern erging werde ich in einem eigenen Beitrag „[[Votragstwittern]]“ berichten.
Nachfolgendes ist eine Mischung aus meiner Twitter“mitschrift“, Erinnerungsstücken und Kommentaren, die über Twitter und E-Mail während und nach der Veranstaltung bei mir einlangten. Danke hiermit an alle, die sich einbrachten. Schon jetzt ersuche ich euch um Kommentare, Ergänzungen, Anmerkungen oder auch Korrekturen, sollte ich etwas inkorrekt wiedergegeben haben. Also:
Wolfram Huber referierte über das Thema „Redaktionelle Barrierefreiheit“. Das beinhaltet die Frage wie ReakteurInnen, die eher mit einem CMS (Content Management System) arbeiten, zur Barrierefreiheit ihrer Website beitragen können bzw. auch müssen.
Die Redaktion beginnt
Die redaktionelle Barrierefreiheit beginnt dabei bei der Übergabe der Website durch den Webdesigner. An diesen wäre die Anforderung zu richten, dass das CMS die RedakteurInnen bei ihrer Arbeit so gut wie möglich unterstützt. Dies kann der „Zwang“ zur Eingabe eines Alternativtextes für ein Bild sein oder die einfache Möglichkeit der Auszeichnung von fremdsprachigen Satzteilen.
Huber arbeitete sich durch eine Präsentation, die an sich für ein Tagesseminar gedacht ist. Wir sahen daher nur Ausschnitte. Die angekündigte halbe Stunde hielt er nicht durch – was ich positiv meine -, da es etliche Zwischenfragen und teilweise angeregte Kurzdiskussionen gab.
Thema Bilder
Bezüglich eines Alternativtextes sollte man sich die Fragen stellen „Was ist der Inhalt?“, „Was ist die Aussage des Bildes“ und „Was ist die Funktion des Bildes“. Alternativtexte sollten eine Länge von 80 Zeichen nicht überschreiten, da einige Browser längere „Tooltips“ nicht anzeigen würden. Es ist auch unnötig mit einer Einleitung wie „Bild:“ zu beginnen, da dies einem Screenreader Benutzer sowieso klar wäre. (Zum Thema Screenreader siehe auch meine persönlichen Anmerkungen am Schluss.)
Bei Schmuckgrafiken ist ein leeres alt-Attribut zu verwenden, da ansonsten Screenreader den Dateinamen des Bildes vorlesen.
Schwierig sind Bilder mit mit vielen Informationen, wie z.B. Diagramme. Hier kann ein Alternativtext nur eine rudimentäre Information wiedergeben. Die Verwendung des longdesc-Attributs wäre eine Möglichkeit, jedoch unterstützen das etliche CMSe nicht.
Alternative wäre in den Alternativtext eine Kurzbeschreibung einzufügen und den Rest in den „normalen“ Text nach der Grafik zu packen (ev. in einer Unterseite).
Eric Eggert hat per Twitter kommentiert, dass Diagramme über eine (versteckte) Tabelle für Screenreader sichtbar gemacht werden können.
Strukturierung
Streiften wir nur kurz und wurden auf das Beispiel www.wai-austria.at verwiesen.
Überschriften
(sind auch ein Teil der Struktur) sollten auch nicht mehr als 60 Zeichen beinhalten und einer festen Struktur folgen (eine h1, der dann h2 und der h3 folgt).
Plaintext
Auch dies ist manchmal erforderlich. Regeln wären hierzu u.a. dass man für Listen keine o’s als Aufzählungspunkte verwendet sondern ein 1., 2.,.. Versalschrift ist zu vermeiden und Abkürzungen wären bei der ersten Erwähnung im Text auszuschreiben.
Abkürzungen und Acronyme
Das Tag acrynom steht für Abkürzungen, das Tag abbr für eine abgekürzte Schreibweise. Diese Unterscheidung wird aber nicht einheitlich verwendet, was viele WebredakteurInnen verunsichert.
acronym wäre daher für Begriffe wie EDV, TÜV oder PC zu verwenden, abbr für Abk., lt., betr. Manche Screenreader BenutzerInnen schalten diese Funktion aber ab bzw. lassen sich nur Akronyme vorlesen, da sie sich nicht dauernd etwas erklären lassen möchten, was sie sowieso wissen. Frage aus dem Plenum, was man machen soll, wenn das CMS nur acronym unterstützt. Huber meint, dann möge man einfach dies für alle verwenden. Besser so als gar nicht.
Fremdwörter
soll man soweit es geht vermeiden. Die Frage war, wie man mit Wörtern wie „Checkpunkt“ umgehen soll. Es gab dazu in der Runde ganz unterschiedliche Meinungen, mache zeichnen nur „Check“ als englischsprachig aus. Meinung war aber, dass man solche Kompositas (wie der Fachbegriff heißt) überhaupt vermeiden sollte, da sie oft auch unverständlich sind und es bessere Begriffe gäbe. Es kam auch der Hinweis, dass die WCAG 2.0 dies anders regeln würde.
Links
Noch immer finden sich Websites in deren Newsbereich zig Artikel mit Links aufgeführt sind, die alle „mehr“ heissen. Das wäre zu vermeiden. Aus dem Publikum wurde erwidert, dass „mehr“ oft bei Teasern verwendet würde, die nicht mehr als die Überschrift beinhalten. Hier nach der Überschrift nochmals als Linktext diesen Text zu nehmen wäre etwas seltsam. Wenn man schon „mehr“ verwendet, dann solle man den Link im title-Attribut näher und eindeutig bezeichnen. Eine Anregung wäre die Links so zu bezeichnen, wie die h1 der Seite auf die man verlinkt.
Externe Links die sich in einem neuen Fenster öffnen sind auf alle Fälle auch so zu kennzeichnen. Eine gute Idee ist bei externen Links automatisch ein Zusatzicon anzuzeigen, in dessen Alternativtext darauf verwiesen wird, dass ein externe Link folgt. Dieses Icon ist vor dem Link anzubringen. Danach angebracht würde auch der Alternativtext vorgelesen nachdem der/die BesucherIn schon auf den Link geklickt hat.
Tabellen
Gefragt war, ob s bei einfachen Tabellen reicht die Überschriften auszuzeichnen, da ein CMS oft nicht mehr anbietet. Huber verwies zuerst auf die Website von Einfach für Alle, auf der etliche barrierefreie Tabellenbeispiele zu finden sind.
Bei kleinen Tabellen, wie z.B. 3 Spalten mit 7 Zeilen reichen auch th’s. Insbesondere neue Screenreader Versionen können damit gut umgehen. Laut Eva Papst sei aber die Update Freudigkeit bei Screenreader BenutzerInnen auch endend wollend und daher die neueste Version oft nicht installiert.
Huber präsentierte als Beispiel vom anderen Ende der Komplexität eine 30seitige Budgettabelle mit mehrere Verschachtelungen. Hier ende auch die Möglichkeit von barrierefreien Tabellen. Die Lösung die er wählte, war die Tabelle und damit die Verschachtelungen aufzulösen und sie somit lesbarer zu gestalten.
Wording/Textgestaltung
Das richtige und verständliche Wording wäre ein ganz eigenes Thema, dass während des Vortrags daher nur angestreift werden konnte. Huber plädierte für die Verwendung von mehr Bildern zur Auflockerung etc. Man müsse den RedakteurInnen die Angst nehmen (Thema: Schulung), dass sie dann wieder etwas bezüglich Alternativtexten etc. falsch machen könnten.
In der Diskussion wurde eingeworfen, dass man verständliche Sprache nicht mit „easy to read“ (leichter lesen) verwechseln dürfe. Huber verwies auf www.gleichundgleich.at auf der „leichter lesen“ Versionen zu finden wären und auch Gebärdensprachvideos. Ein weiteres Beispiel sei www.ojm.at mit einem Umschaltbutton für leichte Sprache.
Aus dem Publikum wurde die Frage gestellt, ob man fremdsprachige Namen in Alternativtexten aufnehmen solle. Die Antwort war, dass Screenreader nicht intelligenter als Menschen seien. Auch viele von uns wissen nicht wie man das „Sean“ von Sean Connery ausspricht. Daher könnte man ruhig die Namen aufnehmen.
Abteilung von Wörtern
Auf einer der Websites entdeckten wir in einer kleinen Textbox ein relativ langes Wort, dass somit breiter als die Textbox war. Je nach Browser wurde daher ein Stück vom Text abgeschnitten oder dieser ragte über die Box hinaus. Beides ist natürlich nicht „ansehlich“. Erste Meinung war, dass sich hier auch der Designer etwas vorab überlegen solle um die Redaktion bei der Eingabe zu unterstützen.
Die einzige Möglichkeit für RedakteurInnen sei dann ein Wort mit Bindestrich zu trennen. Das würde in einem Screenreader nicht so schön klingen, aber laut Eva Papst sei dies nicht so ein Problem. Viel schlimmer wären breaks.
Es kam dann zu einer technischen Diskussion, der ich nicht so folgen konnte. Eric Eggert hat mir dazu aber einen Kommentar geschrieben, den ich dankend und gerne hier übernehme:
Um Silbentrennung zu ermöglichen kann man in HTML, also im Text selbst, die ­-Entität benutzen. steht dabei für Soft-Hyphen, also bedingter Trennstrich.
So habe ich in meinem Blog das Wort Medieninformatik als Medien­in­forma­tik direkt ins HTML geschrieben. Das ­ dient dann als Sollbruchstelle für das Wort, dort wird dann praktisch ein „- “ eingesetzt, wenn das Ende der Zeile erreicht ist.
Siehe auch hier: http://de.selfhtml.org/html/text/zeilenumbruch.htm#erlauben
Das funktioniert mit IE ab Version 5, Safari ab Version 2 sowie Opera ab Version 7.1 – Einzig Firefox unterstützt dieses Zeichen bisher nicht, dort ist es erst in Version 3 so weit (Die Wörter werden dann eben weiterhin nicht getrennt).
In wieweit es sinnvoll ist so etwas manuell einzusetzen kann man streiten, mit PHP oder so ist eine Automatisierung aber sicherlich möglich. (Ein kleines Problem stellt noch die Durchsuchbarkeit von Seiten dar, da Wörter mit Shy in einigen Browsern manchmal nicht als ein Wort erkannt werden.)
Nachdem aus der halben Stunde fast eineinhalb Stunden wurden, wurde der erste Teil des Stammtisches hiermit beendet.
Martin Ladstätter dankte im Namen des Vereins Accessible Media für den Vortrag und die rege Diskussion sowie MAIN_Mediearbeit Integrativ für die Bereitstellung der Räumlichkeiten und die Gastfreundschaft.
Danach wurde noch in kleineren Gruppen heftigst weiter diskutiert, Ideen gewälzt und die Chance genutzt etliche ExpertInnen in einem Raum zu haben bzw. auch gegenseitig Erfahrungen auszutauschen.
Fazit
Ein Satz von Herrn Huber blieb mir im Ohr:
„Eine Website ist nur so gut wie der/die schlechtest geschulte MitarbeiterIn!“
Anmerkung vom 19. Mai:Herr Huber meinte in einer Mail, dass das so geschrieben wohl ein wenig radikal sei (ev. habe ich es auch ein wenig im Gedächtnis verküzrt) und er daher es so gedruckt eher mit
„Durch fehlende Schulungen der Redaktion kann eine prinzipiell gut barrierefreie Seite schnell wieder Barrieren aufbauen“
ausdrücken würde.
Daher ist Schulung von immenser Bedeutung und sollte bei der Planung einer Website und auch im laufenden Betrieb mit bedacht werden.
Persönliche Anmerkung
Im Text taucht oft der Begriff Screenreader auf. D.h. aber nicht, dass man beim erstellen einer Website nur an sehbehinderte oder blinde Menschen denken soll. Alternativtexte nutzen auch allen, die – aus welchen Gründen auch immer – das Laden von Bildern abgeschalten haben. Sinnvolle Linkbezeichnungen gehe weit über Barrierefreiheit hinaus. Die Erklärung von Acronymen hilft Menschen mit Lernschwäche – aber oft auch allen, die z.B. mit WCAG (Erklärung bei Wikipedia) nicht anfangen.
Eine gute Struktur ist vielen hilfreich, u.a. auch Menschen die nur mit der Tastatur steuern und somit leichter auf der Seite navigieren können.
Was der Abend wieder einmal zeigte, dass es oft mehrere Lösungsansätze gibt – und keine perfekte Lösung. Manches klingt in der Theorie gut, was AnwenderInnen dann ganz anders sehen. Das mag vielleicht einen „einfachen“ Webredakteur verwirren, der nach einer strikten Anleitung sucht. Auch hier hilft nur immer wieder nachfragen, neu dazu lernen und nicht glauben, dass man schon absoluteR ExpertIn sei.
Noch ein Satz von Wolfram Huber. Man möge sich bewusst sein, dass eine barrierefreie Textgestaltung auch etwas mehr Zeit seitens der WebredakteurInnen benötigt und man dies auch im Prozess einer Seitengestaltung mit einplanen müsse.
Auch ich bin froh, diesen doch recht langen Artikel fertig geschrieben zu haben und würde gerne einfach auf „veröffentlichen“ klicken. Oft fällt mir erst im nach hinein ein, Sprachauszeichnungen durchzuführen. All das muss ich einüben, automatisieren und mir die Zeit dafür geben/nehmen.
Daher war auch der gestrige Abend wieder eine gute Gelegenheit Neues zu hören, Bekanntes zu reflektieren, Fragen zu stellen und insbesondere den Diskussionen mit Interesse zu folgen.