accessBlog

Aktuelles zum Thema Barrierefreies Webdesign.

12 Sep 2011

Textlastige Seiten gelten allgemein als barrierefrei. Doch es gibt einige Möglichkeiten, Texte für Menschen mit unterschiedlichen Behinderungen zugänglicher zu machen. Im folgenden möchten wir uns vor allem mit der technischen Strukturierung von Texten beschäftigen. Verständlichkeit und Textgestaltung (Typographie) sind ebenfalls wichtige Themen, sollen hier aber nicht behandelt werden.

Blinde benötigen Zwischenüberschriften und Absätze, um Textabschnitte wenn nötig überspringen zu können. Außerdem gibt es im Screenreader verschiedene Möglichkeiten, Texte zu überfliegen: Blinde können sich zum Beispiel alle Überschriften oder Links einer Seite anzeigen lassen.

Alle aktuellen Browser bieten die Möglichkeit, eigene Stylesheets anzulegen, um etwa die Lesbarkeit von Texten zu verbessern. Stylesheets erlauben es, die Größe von Text, den Textfluss und andere Faktoren der Lesbarkeit anzupassen. Das kann zum Beispiel Sehbehinderten helfen, aber auch Menschen mit Leseschwäche, die Probleme mit dem Blocksatz oder mit bestimmten Schriftfamilien haben können.

Sie funktionieren am besten, wenn für die Struktur der Seite semantisch korrektes HTML eingesetzt wird. HTML hat einen ganzen Satz von Tags, die ihren Inhalt beschreiben: zum Beispiel h1 bis h6 für Überschriften, ul für nichtnummerierte Listen oder blockquote für Zitate. Diese Tags werden von Screenreadern ausgewertet, um Blinden Informationen über das aktuelle Element weiterzugeben.

Weiterlesen …

Auszeichnungssprachen versus WYSIWYG

Jedes aktuelle Redaktionssystem hat zumindest rudimentäre Möglichkeiten zur Textformatierung. Puristen arbeiten mit einfachem HTML, was einige Vorteile mit sich bringt. Beliebter sind jedoch die What-You-See-is-what-you-get oder kurz WYSIWYG-Editoren. In WordPress ist zum Beispiel der TinyMCE integriert, der an gängige Textverarbeitungen erinnert.


Abb.: TinyMCE in der erweiterten Ansicht

Weniger stark verbreitet sind Mischformen von WYSIWYG und Auszeichnungssprachen. Eine der bekannteren Formen der Textformatierung ist die Wiki-Syntax, wie sie in MediaWiki eingesetzt wird. Wiki- oder Rich-Text-Editoren bieten an, die Formatierung über Schaltflächen vorzunehmen, blenden jedoch die Formatierungsanweisungen im Text ein. Puristen können die Anweisungen direkt über die Tastatur eingeben, visuell orientierte Menschen können die Formatierung über die Schaltflächen vornehmen.

Viele Autoren stören sich daran, wenn die Formatierungsanweisungen im Text sichtbar sind. Es bringt jedoch auch einige Vorteile mit sich:

  • Zum einen können so auch Blinde den Text formatieren. TinyMCE ist zwar prinzipiell mit Tastatur bedienbar, die Bedienung ist aber nicht sehr komfortabel.
  • Zum anderen hat man mehr Kontrolle über die Formatierung. Bei WordPress kommt es recht häufig zu seltsamen Umbrüchen, Formatierungs- und Darstellungsproblemen, die man mühsam nachbearbeiten muss. Das passiert vor allem, wenn Texte aus der Textverarbeitung in den WYSIWYG-Editor hineinkopiert werden.

Die Redakteure lernen durch die Formatierungsanweisungen, dass die Textstrukturierung im Web anders als in der Textverarbeitung funktioniert. Ein Nachteil besteht darin, dass die verwendete Auszeichnungssprache gelernt werden muss.

Strukturierung statt Aufhübschung

Ein sehr häufiger Fehler bei der Formatierung von Texten ist der Einsatz von nichtsemantischem HTML oder CSS. Man kann zum Beispiel eine Überschrift mit HTML als Überschrift kenntlich machen. Man kann aber auch ein DIV-Element verwenden und das ein wenig fetter und größer gestalten.

Das ist übrigens die Regel, nicht die Ausnahme. Die meisten Tageszeitungen verfahren so. Fast immer ist die eigentliche Artikelüberschrift als Überschrift gekennzeichnet, die Zwischenüberschriften hingegen nicht. Auch TinyMCE bietet in der WordPress-Standardkonfiguration keine Formatierungen für Zwischenüberschriften an. Hinzu kommt, dass Redakteure keinen Einfluss darauf haben, wie ihre Formatierungen im Redaktionssystem verarbeitet werden, schließlich soll das Layout einheitlich sein. Die Verarbeitungsregeln müssen im Redaktionssystem festgelegt werden.

Es kommt auch sehr häufig vor, dass Listen nicht korrekt formatiert werden. Die meisten Leute verfahren wie in der Textverarbeitung, schreiben einen Bindestrich, ihren Text und drücken dann auf Return. Die Textverarbeitung bietet in der Standardeinstellung per AutoFormat eine Auflistung an. Im Web klappt das aber nicht. Eine Einrückung wird dann über Leerzeichen, Tabulator oder ein Zitateelement umgesetzt, was sehr unprofessionell aussieht.

Ein häufiger Fehler, der nur bei WYSIWYG-Editoren auftreten kann ist die falsche Formatierung von Listen. Eine Liste mit drei Listenpunkten wird zu drei Listen mit jeweils einem Listenpunkt. Das geschieht, wenn jeder Punkt einzeln als Liste formatiert wird, anstatt die gesamte Liste einmal zu formatieren. Rein optisch fällt dieser Fehler allerdings in der Regel nicht auf, stört aber den blinden Screenreadernutzer.

Grenzen der Formatierung

Wesentlich mehr Formatierungsoptionen bieten die meisten Redaktionssysteme nicht an. Abkürzungen und Kennzeichnung von Sprachwechseln gehören nicht zum Standardumfang von WYSIWYG-Editoren. Einfache Tabellen lassen sich vielleicht noch einfügen, aber schon bei komplexeren Formatierungen dürfte Schluss sein, weil sie von den Redaktionssystemen nicht unterstützt werden. Ob HTML oder Wiki-Syntax, fast alle Redaktionssysteme filtern aus Sicherheitsgründen Formatierungsanweisungen heraus, die sie nicht kennen. Den Texteditor um solche Funktionen zu ergänzen ist allerdings keine technisch aufwendige Aufgabe.

Mehr Verständnis

Es gibt also kurz zusammengefasst zwei Kernprobleme bei der Strukturierung von Texten:

  1. Die Programmierer von Redaktionssystemen setzen nur Standardanforderungen um oder arbeiten gar mit Layout statt Struktur, setzen also CSS statt HTML ein. Sie setzen nur die grafischen Anforderungen um, weil sie sich selbst nicht um die Formatierung von Texten kümmern müssen.
  2. Die Redakteure ihrerseits sind mit den Grundlagen der Strukturierung von Texten im Web nicht vertraut. Entweder kommen sie aus dem Printbereich, wo andere für das Layout zuständig sind. Oder sie sind gelernte Online-Redakteure, in deren Kursen HTML und CSS stiefmütterlich behandelt wird. In der Regel wissen sie auch nicht, was unter semantischem HTML zu verstehen ist und können entsprechend auch ihre Anforderungen an das Redaktionssystem nicht sauber formulieren.

Die Anforderungen an strukturierte Texte müssen also schon im Redaktionssystem umgesetzt werden. Die Redakteure ihrerseits müssen dazu angehalten und geschult werden, Texte korrekt zu strukturieren.

Kommentare zu dieser Meldung: 2

Permalink Andy Pillip meinte am 12.09.2011:

Schöner Artikel!

Meiner Meinung nach funktioniert die Textstrukturierung im Web keinesfalls anders als in der Textverarbeitung.

Auch dort ist es wichtig, Überschriften, Tabellen und so weiter semantisch aus zu zeichnen. Sonst gäbe es auch dort keine automatisch generierten Inhalts-, Bilder- oder Tabellenverzeichnisse.

Kurz gesagt ist es wichtig, die Formatvorlagen zu benutzen, was einer semantischen Auszeichnung gleich kommt.

Viel zu häufig wird in Textverarbeitung aber nur „klicke hier, dann da” gelehrt, statt die Konzepte zu erklären — genau so wie in CMS Schulungen.

Der Grundkurs unserer CMS Schulungen beinhalten im ersten Teil immer anschauliche Beispiele für semantische Auszeichnungen, und was passiert wenn man sie nicht nutzt.

Beispiele für behinderte Benutzer werden dabei leider sehr oft als zu weitgehend abgetan.

Übrigens bietet der tinyMCE sehr wohl in der Standardkonfiguration (nicht in der für WordPress) einen Button für Abkürzungen und auch einen „Attribute” an, über den die Sprache gekennzeichnet werden kann.

Permalink Monika T-S meinte am 15.09.2011:

Ich gebe zu, dass ich bereits wahnsinnig glücklich bin, wenn ich die Verwendung von Überschriften überhaupt soweit erklären konnte, dass sie genutzt werden.
Die meisten Editoren geben h1-h6 an, das verstehen aber sehr viele meiner Kunden nicht. p Tags zb geben diese Editoren aber als "Absatz" an. Das kennen fast alle.
Würde statt h1 Hauptthema stehen und zumindest Unterthema könnt ichs eher weitergeben. Die Semantik von h1-h6 ist für irr viele Leute, auch wirklich gebildete schwer verständlich. Hier ist html an sich nicht barrierefrei ;).

h1-h6 wird in html5 auch anders gesehen, hier kommt ne andere Semantik ins Spiel.

Oder denn doch nicht?