Websiteentwicklung: Barrierefreiheit und Benutzbarkeit

Dieses Buch steht im Regal EDV.

Websiteentwicklung Barrierefreiheit und Benutzbarkeit

Projektdefinition[Bearbeiten]

Zielgruppe: Alle Autoren von Netz-Projekten, die kompetent Inhalte veröffentlichen möchten
Lernziele: Der Leser soll für Zugänglichkeitsprobleme bei digitalen Formaten und Veröffentlichungen im Netz sensibilisiert werden. Prinzipielle Kenntnisse über auftretende Probleme und Lösungsstrategien werden vermittelt.
Buchpatenschaft/Ansprechperson: Doktorchen
Sind Co-Autoren gegenwärtig erwünscht? Ideen, Ergänzungswünsche, Konzepte und weitere Ansätze sollten primär erst einmal auf der Diskussionsseite angesprochen werden und sind dort sehr willkommen.
Richtlinien für Co-Autoren: Da sich dieses knappe Büchlein bereits in einem komplett lesbaren Zustand befindet, sollte sich am Fertigstellungsgrad auch nichts mehr durch unvollständige Bearbeitungen verschlechtern. Änderungen jenseits von trivialen Korrekturen sollten also abgesprochen werden, Diskussion von Erweiterungen ist aber sehr erwünscht.
Projektumfang und Abgrenzung zu anderen Wikibooks: Formatspezifische Methoden, Merkmale und technische Details, um Inhalte zugänglich anzubieten, sind bei den Büchern zu den Einzelformaten verfügbar. Es ist also nicht die Idee, die einzelnen Techniken hier erneut zu erläutern. Die technische Umsetzung und die Details der technischen Spezifikation von Merkmalen ist also Gegenstand der anderen Bücher der Buchreihe.

Einleitung[Bearbeiten]

Die Begriffe Barrierefreiheit und Zugänglichkeit stammen ursprünglich aus der Architektur und bezeichnen dort den Anspruch, insbesondere öffentlich zugängliche Gebäude auch wirklich allen Bürgern zugänglich zu machen, insbesondere also auch solchen mit Behinderungen oder Beinträchtigung der Bewegungsmöglichkeiten.

Die Begriffe wurden dann auf digitale Dokumente, insbesondere solche ausgedehnt, die öffentlich im Netz angeboten werden. Neben besonderen persönlichen Eigenschaften kommen hier allerdings auch technische Einschränkungen als relevante Kriterien zum Tragen, weil es immer notwendig ist, mit geeigneten Programmen digitale Inhalte zur Darstellung zu bringen. Dieser Zugang zur Information bietet Menschen mit persönlichen Einschränkungen einerseits bessere Möglichkeiten, sich selbständig und ohne Hilfe anderer Menschen Information zu verschaffen. Andererseits hängt es aber stark von der Verfügbarkeit der Programme, der Dekodierbarkeit der Formate und der optimalen Darstellbarkeit für den jeweiligen Menschen ab, ob die Information dann auch wirklich verfügbar gemacht werden kann.

In einer Zeit, in der zunehmend mit recht unterschiedlichen Geräten wie persönlichen digitalen Assistenten, Mobiltelephonen oder Fernsehern Dokumente im Netz aufgerufen werden und in der auch seh-, hör- oder motorisch behinderte Menschen das Netz erfahren und erforschen möchten, ist die Barrierefreiheit von Informationen im Netz also ein zentrales Thema. Barrierefreiheit ist der Ansatz, Projekte so zu gestalten, dass keine Barrieren aufgebaut werden, sprich, kein Nutzer grundsätzlich ausgeschlossen wird. Das Angebot soll niemanden wegen besonderer technischer Möglichkeiten oder persönlicher Eigenschaften ausschließen. Gegebenenfalls kann das Angebot aber so angeboten werden, dass es für Nutzer mit eingeschränkten Möglichkeiten keine besonderen Probleme mit dem selbständigen Zugang zur Information gibt oder besondere Zugangshilfen und -erleichterungen und alternative Darstellungen desselben Inhaltes verfügbar sind.

Einschränkungen sind schon durch persönliche digitale Assistenten oder eine leichte Sehschwäche vorhanden. Barrierefreiheit bedeutet also, Angebote für jeden zugänglich umzusetzen. Durch Wahl ungeeigneter Mittel, Methoden oder Formate kann es schwer sein, ein Projekt komplett barrierefrei zu gestalten, daher kommt einer sorgfältigen Auswahl der Methoden und Formate und der guten Strukturierung der Projekte eine besondere Bedeutung zu.

Da digitale Information also für jeden Menschen dekodiert und irgendwie dargestellt werden muß, sind diese Informationen im Grunde für keinen Menschen ohne Hilfsmittel, eben wortwörtlich unmittelbar zugänglich. Aus der aktuellen Situation des jeweiligen Nutzers heraus ergibt sich dann individuell, welche Programme verfügbar sind und genutzt werden können, um sich die Information zugänglich zu machen.

Von zentraler Bedeutung ist folglich, dass die Art des digitalen Informationsangebotes so einfach, allgemein und standardisiert angeboten werden muß, dass für jeden interessierten Nutzer Programme verfügbar sind, um die Information geeignet zu präsentieren. Die Verwendung von freien Standards ermöglicht es hier, viele verschiedene Programme von verschiedenen Menschen zu realisieren, die dann jeweils für bestimmte Nutzergruppen einen optimalen Zugang zur Information gewährleisten. Je einfacher und verbreiteter natürlich die verwendete Kodierung ist, je klarer strukturiert und einfacher interpretierbar ein digitales Format ist, desto besser eignet es sich, um diesen Ansprüchen zur allgemeinen Zugänglichkeit gerecht zu werden. Als primäre Aufbereitung der Information eignet etwa einfacher Text in der Auszeichnungssprache XHTML mit einer Kodierung UTF-8 (oder im deutschsprachigen Raum alternativ auch ISO-8859-1) sehr gut. XHTML gehört zur XML-Sprachfamilie, für welche es viele verschiedene Programme und Bibliotheken gibt, die dessen Struktur interpretieren können, die Kodierungen sind häufig verwendete Standards. XHTML ist zudem weit verbreitet. Da es sich letztlich bei XHTML lediglich um Textdokumente handelt, die sowohl Struktur, Funktion und Bedeutung als auch den Inhalt selbst enthalten, sind solche Dokumente notfalls sogar mit sehr einfachen Programmen zugänglich zu machen, die XHTML oder XML selbst gar nicht interpretieren können brauchen, lediglich eine Dekodierung und Präsentation des digitalen Textes vornehmen müssen - dies erfordert allerdings in der Praxis genauere Kenntnisse des Formates durch den Leser und eine gute Struktur des Dokumentes (seines 'Quelltextes') selbst.

Viele Barrieren entstehen erst bei der visuellen Präsentation solcher Dokumente, die ebenfalls vom Autor beeinflußt werden kann, weil viele Nutzer selbst keine detaillierten Kenntnisse über die verwendeten Formate oder das zur Präsentation verwendete Programm haben müssen, gegebenenfalls also kaum in der Lage sind, vorhandene Barrieren aufgrund eigenen Wissens selbständig zu umgehen oder zu überwinden.

Unterscheidung verschiedener Barrieren[Bearbeiten]

Barrieren in Projekten können in verschiedene Bereiche gegliedert werden:

technische Barrieren

hierunter werden Barrieren verstanden, die durch die Verwendung oder Nichtverwendung einer bestimmten Technologie entstehen. Teils kann der Nutzer diese bei hinreichender Kenntnis der von ihm verwendeten Programme durch Deaktivierung dekorativer Funktionen allerdings selbst abbauen und Inhalte selbst zugänglich machen. Beispiele für technische Barrieren:

Kodierung oder Verschlüsselung der Information in unbekannter Weise oder ohne Verfügbarkeit einer Dekodierung
Verwendung ungeeigneter, proprietärer Dateiformate (die somit nicht mit allgemein verfügbaren Programmen dekodierbar oder darstellbar sind)
falsche Verwendung der Semantik der zugrundeliegenden Auszeichnungssprache
Fehlende Textalternativen zu Graphiken und Multimediaformaten
Inhalte erst mit Skriptsprachen erzeugen
feste Schriftgrößen
Verwendung ungeigneter Einheiten für Schriftgrößen und Breiten von Texten
geringe Kontraste bei Farben für Text und in Graphiken

soziale Barrieren

diese Barrieren lassen sich auch durch den geschickten Einsatz von Technik nicht vermeiden, sondern hängen unmittelbar vom jeweiligen Autor ab, zum Beispiel:

schwerverständliche Texte
Nutzung von Jargon, Abkürzungen, Fachsprache
verwendete Sprache an sich (wer kein deutsch kann, hat auch nicht viel von einem deutschsprachigen Dokument. Ein besonderes Problem kann etwa bei Gehörlosen auftreten, welche typisch primär die Gebärdensprache verinnerlicht haben, nicht jedoch die Schriftsprache, die gewöhnlich als Basis für barrierefreie und zugängliche Information gesehen wird. Kann ein Autor also etwa nur deutsch verbal und schriftlich, der Rezipient aber lediglich deutsche Gebärdensprache, tritt eine fundamentale Kommunikationsbarriere auf, welche weder vom Autor noch vom Rezipienten einfach überwindbar ist, weil es keine Programme gibt, geschweige denn frei zugängliche Programme, welche in der Lage wären, etwa digitale deutsche Schriftsprache in Gebärdensprache automatisch zu transformieren. Organisationen, die Gehörlose vertreten, empfehlen hier ausdrücklich, Textinhalte mit reichlich graphischen Alternativen anzureichern, also Graphiken und Bildern, um wenigstens das Verständnis des Textes zu erleichtern. Eine Animation oder ein Video mit Gebärdensprache als Alternative zum Text ist natürlich sehr wünschenswert, wird vom technischen Aufwand her aber heute von den wenigsten Autoren umzusetzen sein, ist aber etwa für Bundesbehörden in Deutschland inzwischen vorgeschrieben, für welche der große Aufwand dann auch wirklich finanzierbar ist.)

logische Barrieren

durchbrechen bestehender Konventionen
Inkonsistenz

Beteiligte Personengruppen[Bearbeiten]

Um das Basisziel des Netzes zu erreichen, dass Information von allen für alle bereitgestellt werden kann, können verschiedene Hauptgruppen von Personen unterschieden werden, die verschiedene Aufgaben, Bedürfnisse, Motivationen haben. Dabei kann eine reale Person verschiedenen dieser Gruppen angehören. Je nachdem, was diese Person gerade tut, entspricht sie dann zeitweise mehr dem einen oder dem anderen Gruppenprofil.

Die von der Zahl her stärkste Gruppe ist die der Leser, Rezipienten oder Nutzer von Inhalten. Diese Personen haben oft keine detaillierten Kenntnisse über technische Zusammenhänge, haben aber durchgehend das Bedürfnis, jeglichen sie interessierenden Inhalt zugänglich, barrierefrei und gut verständlich angeboten zu bekommen.

Die zweitstärkste Gruppe ist die der Autoren oder Anbieter von Inhalten. Der Kenntnisstand hinsichtlich technischer Details kann hier sehr unterschiedlich ausfallen. Das Hauptziel dieser Gruppe sollte darin liegen, Inhalte gemäß eigenen Interessen allen Interessierten möglichst zugänglich und barrierefrei anzubieten. Die Hauptaufgabe ist es also, eigene Information zu vermitteln, möglichst unabhängig davon, welche persönlichen Eigenschaften oder technischen Möglichkeiten der interessierte Nutzer der Information hat.

Die drittstärkste Gruppe ist die der Implementierer oder Anbieter von Darstellungsprogrammen. Der Kenntnisstand hinsichtlich technischer Details sollte eigentlich hoch sein, leider ist das aber nicht immer gegeben. Die Ziele dieser Gruppe können recht unterschiedlich sein, je nachdem, warum sie ein Darstellungsprogramm programmieren oder anbieten. Jedenfalls ist es eines der Ziele, Information, welche in bestimmten Formaten oder Teilbereichen von Formaten vorliegt, den Personen der ersten Gruppe zugänglich zu interpretieren und darzustellen. Dazu kann es notwendig sein, genauer zu analysieren, welche Interessen und Bedürfnisse die Gruppe der Autoren hat oder aber diese so zu steuern, dass diese Information in Formaten anbieten, die auch interpretiert werden können. Von praktischer Relevanz für diese Gruppe ist oft auch das Bedürfnis, fehlerhafte Dokumente durch die Darstellungsprogramme zugänglich zu machen, um den Nutzern auch Zugang zu so mangelhaft aufgearbeiteten Information zu ermöglichen. Dies ist besonders relevant für Informationen, die im Umfeld von HTML angeboten werden, denn es hat sich herausgestellt, dass der überwiegende Teil von veröffentlichten HTML-Dokumenten technisch fehlerhaft und mangelhaft ist - in der Hinsicht nimmt HTML eine Sonderstellung ein. Der Zusammenhang zwischen Ursache und Wirkung ist hier strittig - sind die Dokumente fehlerhaft, weil die Programme stillschweigend technisch grob fehlerhafte Dokumente trotzdem anzeigen oder müssen die Programme fehlerhafte Dokumente zugänglich machen, weil es so viel davon gibt? Ähnlich wie bei dem Problem mit Henne und Ei liegt die Erklärung hier in den Anfängen - hier also von HTML und den damaligen ersten Darstellungsprgrammen.

Die vierte Gruppe ist recht klein, aber sehr wichtig. Dabei handelt es sich um jene Personen, die Spezifikationen zu Dokumentformaten entwickeln. Die Ziele dabei sollten sein, dass Autoren mit den spezifizierten Formaten Information zugänglich anbieten können. Die Spezifikation ermöglicht es ferner den Implementierern, die Formate korrekt zu interpretieren und die Information eindeutig definiert darzustellen. Es kommt hier nun stark darauf an, dass die Spezifikation so umgesetzt ist, dass sie auch wirklich implementierbar ist. Zudem sollte sie einfach genug sein, damit interessierte Autoren auch mit angemessenem Lernaufwand korrekte Dokumente verwirklichen können. Zudem sollte das Format natürlich so gestaltet sein, dass Autoren überhaupt damit ihre Projekte verwirklichen können und schließlich auch wollen.

Hinsichtlich der Barrierefreiheit von Inhalten können nun diesen vier Hauptgruppen Pflichten und Möglichkeiten zugeordnet werden.

Natürlich ist bei der Spezifikation darauf zu achten, dass die spezifizierten Formate zugänglich sind und gegebenenfalls, sofern Konstruktionen und Inhalte vermittelt werden sollen, die in sich Zugänglichkeitesbarrieren beinhalten, sind dann Mechanismen vorzusehen, mit denen alternative Inhalte angeboten werden können, welche diese Barrieren nicht beeinhalten. Nach Möglichkeit sind die Spezifikationen natürlich auch so abzufassen, dass von den Autoren mit niedrigem Aufwand erzeugte einfache Dokumente auch von selbst zugänglich sind.

Bei den Anbietern von Darstellungsprogrammen ist zu fordern, dass Spezifikationen komplett und fehlerfrei umgesetzt werden. Es sind Mechanismen und Techniken bereitzustellen, mit denen Alternativen zu problematischeren Inhalten aufgerufen werden können. Besondere Aufmerksamkeit gilt hier auch Minderheiten, die aufgrund besonderer Merkmale oder Einschränkungen besondere Notwendigkeiten haben, Inhalte in besonderer Form präsentiert zu bekommen. Oft stellt sich dann allerdings heraus, dass die implementierten Hilfen auch für breitere Nutzergruppen sehr nützlich sind, die Rücksicht auf Minderheiten bietet also großes Potential, um die Nutzbarkeit von Darstellungsprogrammen allgemein zu verbessern.

Gegebenenfalls sollten Anbietern von Darstellungsprogrammen Fehler, Lücken und Mehrdeutigkeiten bei Formaten an die Spezifizierer melden, damit diese die Probleme beheben können. Zudem sollte es möglich sein, optionale, dekorative Techniken abzuschalten, um zu einer einfachen Darstellung des Inhaltes zu kommen, wenn durch die Dekoration technische Probleme entstehen, siehe dazu auch das im Folgenden erläuterte Schichtenmodell. Sofern sie Kenntnis davon haben, sollten sie auch auf Autoren einwirken, die fehlerhafte Dokumente veröffentlichen, damit diese die Fehler korrigieren können. Da die meisten Autoren ihre Inhalte mit den Darstellungsprogrammen testen, ist da eine automatische Fehleranzeige für Entwickler und Autoren eine Möglichkeit. Bei dem Darstellungsversuch von fehlerhaften Dokumenten sollte der Nutzer auf den Sachverhalt hingewiesen werden, dass letztlich geraten wird, was der Autor gemeint haben könnte. Ansonsten kann durch den Darstellungsversuch des Programmes leicht eine Fehlinterpretation durch den Nutzer impliziert werden.

Autoren und Anbieter von Information sollten natürlich gut strukturierte, fehlerfreie, zugängliche Dokumente veröffentlichen, Information barrierefrei anbieten. Zudem sollten sie auf bekannte Mängel und Fehler von Darstellungsprogrammen Rücksicht nehmen und gegebenenfalls auf Methoden verzichten, die von diesen Programmen falsch interpretiert werden. Ansätze können hier etwa sein, entweder auf das problematische HTML ganz zu verzichten und etwa XHTML zu verwenden und aber auf jeden Fall (X)HTML-Dokumente mit einem Validator vor einer Veröffentlichung zu prüfen und dann gegebenenfalls zu korrigieren. Dazu gehört aber natürlich auch, die Anbieter von Darstellungsprogrammen auf fehlerhafte Implementierungen hinzuweisen, damit diese in späteren Versionen des Programmes korrigiert werden können.

Der Leser oder Nutzer sollte mißtrauisch gegenüber den verwendeten Darstellungsprogrammen bleiben, aber auch gegenüber den Inhalten. Beides kann fehlerhaft sein, aber auch alternative Ansichten bieten, um Zugänglichkeitsprobleme zu umgehen. Es kann insbesondere sinnvoll sein, immer mal wieder oder bei Verdacht das Darstellungsprogramm zu wechseln, um Unterschiede erkennen zu können. Hinweise zu Fehlern in Dokumenten können natürlich den Autoren nützlich sein, ebenso wie Fehlermeldungen und Mängellisten zu den aktuellen Versionen von Darstellungsprogrammen an deren Anbieter oder zur allgemeinen Kenntnisnahme für Autoren. Der Leser ist also den Werken der Autoren und dem Verhalten der Darstellungsprogramme nicht gänzlich hilflos ausgeliefert. Durch Kenntnis der Bedienung und Nutzung verschiedener Programme hat dieser oft ganz gute Möglichkeiten, Information zugänglich zu machen, jedenfalls wenn der Autor der Information Grundregeln beim Erstellen der Inhalte eingehalten hat.

Neben diesen vier Gruppen ist übrigens in letzter Zeit eine fünfte kleine Gruppe mehr in den Vordergrund gerückt. Dies sind die Betreiber der Netze selbst. Die zentrale Forderung an diese ist natürlich, die Netze für den Informationsaustausch verfügbar zu machen, diesen aber nicht zu manipulieren oder aber ohne Einverständnis der Autoren und Nutzer Informationen für andere Zwecke abzuzweigen. Diese Gruppe sollte sich also eigentlich neutral gegenüber der Information und dem Informationsaustausch verhalten, was auch die zentrale Forderung an diese Gruppe ist. In der Praxis kommt es in neuerer Zeit aber bei dieser Gruppe häufiger zu einem nicht neutralen Verhalten - abhören des Informationsaustausches, Manipulation oder Sperrung von Inhalten, die auch Zensur oder Urheberrechtsverletzungen implizieren können. Barrierefrei und zugänglich ist das Netz natürlich nur, wenn diese Gruppe ihre Neutralität bewahrt und nicht selbst inhaltliche Interessen verfolgt.

Der weitere Teil dieses Buches beschäftigt sich schwerpunktmäßig mit den Maßnahmen des Autors. Der kurze Überblick macht aber bereits deutlich, dass dieser nicht allein verantwortlich für Zugänglichkeitsprobleme ist. Die Abhängigkeiten der einzelnen Gruppen voneinander sind komplex und durch Interaktion der Gruppen lassen sich einige Probleme erst über einen längeren Zeitraum lösen. Allerdings kann jeder Autor so oder so durch barrierefreie Dokumente gute Voraussetzungen schaffen, dass auch bei vorhandenen Mängeln in Darstellungsprogrammen und Spezifikationen seine Informationen allgemein zugänglich sind oder recht einfach zugänglich gemacht werden können.

Es zeigt sich bereits am Sprachproblem, dass einzelne Autoren, Darstellungsprogramme und Nutzer eine gemeinsame Grundlage haben müssen, auf welcher Kommunikation stattfinden kann. Etwa kann man einzelnen Autoren schlecht vorschreiben, in welchen Sprachen sie veröffentlichen. Die Fähigkeiten der Nutzer bestimmen hier dann letztlich darüber, wer Zugang zu solch sprachabhängigen Informationen hat. Bei größeren Organisationen oder Behörden kann man indessen deutlich mehr fordern als bei einzelnen Autoren. Ist es der Auftrag oder das Ziel einer solchen Behörde, etwa Information für alle Bürger eines Landes verfügbar zu machen, ist es offenbar notwendig, die Information auch in allen Sprachen verfügbar zu machen, die als Amtsprachen akzeptiert sind oder die praktisch relevant sind. Das Beispiel der Gehörlosen zeigt hier gut das Problem. Beherrschen diese primär die Gebärdensprache ihres Landes, nicht aber die Schriftform, so hilft es diesen wenig bis gar nicht, wenn insbesondere in Hinblick auf Sehbehinderte Mitmenschen nur schwer textlastige Information angeboten wird. Zusätzliche Graphiken und Bilder helfen vielen Menschen, die Inhalte besser zu verstehen, nicht nur Gehörlosen. Richtet sich der Inhalt der Behörde aber eben an alle Bürger, so ergibt sich damit dann auch die Notwendigkeit, den Inhalt zustätzlich in Gebärdensprache anzubieten, nicht nur in Schriftform und mit Bildern und Graphiken angereichert.

Methoden[Bearbeiten]

Trennung von Inhalt und Dekoration oder Layout[Bearbeiten]

Um Barrieren abzubauen und die Gestaltung für verschiedene Endgeräte zu ermöglichen (zum Beispiel Vorleseprogramme, mobile Telephone mit kleinen, eventuell aber hochauflösenden Bildschirmen), sollten Elemente einer Auszeichnungssprache wie (X)HTML niemals dem Layout dienen. Das gesamte Aussehen sollte über eine externe Stilvorlage geregelt werden – und auch nur dort. Erst die konsequente Trennung von Inhalt und Layout ermöglicht es, dem Inhaltsanbieter beziehungsweise dem Nutzer, die Darstellung auf seine Bedürfnisse hin zu optimieren.

Allerdings ist eine Trennung von Inhalt und Dekoration bei anderen Formaten als (X)HTML nicht immer ganz einfach. Bei SVG etwa kann eine Farbinformation für ein graphisches Element inhaltlich wichtig sein, ist daher nicht als dekorativ einzustufen, wenn ohne diese Information die Interpretation des Bildes erschwert wird oder unmöglich gemacht wird. SVG bietet dafür explizit neben den Stilvorlagen auch Präsentationsattribute an - Bilder im Format SVG sind demnach also so zu gestalten, dass bei der Deaktivierung der Interpretation von Stilvorlagen oder Skriptsprachen wie java-script oder ecmascript keine Änderung der inhaltlichen Aussage des Bildes eintritt. Hier ist zwischen Konzept und Praxis zu unterscheiden. Ist etwas etwa als 'rot' per Präsentationsattribut gekennzeichnet, so ist dies eine inhaltlich relevante Information, welche dem Nutzer prinzipiell auch unabhängig von der Fähigkeit zugänglich ist, unterschiedliche Farben unterscheiden zu können, weil es so als Attribut im Dokument steht. Praktisch ist die Präsentation durch übliche Darstellungsprogramme allerdings einfach 'rot' und eine Relation zur XML-Struktur im Dokument ist für die Mehrheit der Nutzer nicht einfach nachzuvollziehen. Aufgrund der Forderung, dass Information nicht nur durch Farbinformation unterscheidbar sein soll, ist es hier also praktisch notwendig, Sinn und Zweck des SVG-Dokumentes mit den dafür vorgesehenen Strukturen zu erläutern. Dabei ist es problemabhängig, ob bei solch einer Erklärung für das gesamte Dokument inhaltlich noch relevant ist, ob ein bestimmter Teil davon rot ist, oder ob dies nur der Differenzierung von anderen Strukturen bei einer visuellen Präsentation dient. Ist das Rot an sich relevant, darf es sicher als Information in der Dokumentbeschreibung nicht fehlen, dienen Farben hingegen nur der visuellen Differenzierung, sind sie in der Textalternative praktisch belanglos und brauchen nicht erwähnt zu werden. Wichtig ist in diesem Zusammenhang auch ein möglicher inhaltlicher Zusammenhang mit einer Funktion. Wird etwa in einem interaktiven Dokument angeregt einen 'roten Knopf' zu drücken, um eine Aktion oder Animation zu bewirken, so ist es wichtig, den 'roten Knopf' als solchen durch Titel und Beschreibung zu identifizieren, also nicht nur durch Farbgebung per Präsentationsattribut. Es kann natürlich meistens viel besser sein, den Knopf durch seine Funktion zu identifizieren, ihn also zum Beispiel in Bezeichnung und Beschreibung als Stopknopf oder 'Not-Aus' zu benennen.

Ganz allgemein verwendet wird ein sogenanntes Schichtenmodell, besonders geeignet für (X)HTML, aber auch für SVG, wenn die Anmerkungen aus dem vorherigen Absatz beachtet werden. Notwendig ist nur die erste Schicht mit dem Inhalt. Die zweite des Layouts dient mehr der Gefälligkeit, ähnlich wie die dritte, die durch Verwendung von Skriptsprachen ins Spiel kommt.

Die erste Schicht ist die des Inhaltes.

Dieser liegt als Text vor, bevorzugt in einer XML-Auszeichnungssprachen wie XHTML. Diese Schicht bietet also den kompletten Inhalt des Projektes an, der damit ohne weitere Schichten und Technologien zugänglich wird. Dabei ist darauf zu achten, dass die Wahl der Elemente und Attribute, mit denen der Text ausgezeichnet wird, auch zum Inhalt paßt. Damit hat die Auszeichungssprache also semantische Relevanz und kann dabei helfen, die inhaltlichen Aussagen und Strukturen zu verstehen. Ein Darstellungsprogramm, welches die verwendete Auszeichnungssprache interpretieren kann, kann diese erste Schicht ohne weitere Angaben des Autors für eine Präsentation nutzen, die dem Nutzer die komplette Information der Seite zugänglich macht. Bei XHTML ist dies zum Beispiel Text, bei dem Überschriften, Absätze, Listen, Tabellen, Bilder etc als solche erkennbar und vom Nutzer im Sinne des Autors interpretierbar sind.

Auch bei der ersten Schicht ist zu bedenken, dass Menschen unterschiedliche Präferenzen haben, in welcher Form Inhalt als gut verständlich angesehen wird. Viele Menschen haben etwa eine stark visuelle Präferenz. Sie profitieren davon, wenn zusätzlich zu Text und Formeln Inhalte auch graphisch aufbereitet angeboten werden, so kann es diesen Menschen erleichtert werden, Zusammenhänge durch die graphische Repräsentation in wenigen Sekunden zu erfassen, während sie vielleicht am Verständnis eines Textinhaltes alleine gescheitert wären. Natürlich ist es, sofern der Inhalt dies sinnvoll erscheinen läßt, auch hier sinnvoll, allgemein zugängliche Formate einzusetzen, also für Computergraphiken, Animationen etc ein Format wie SVG statt einer Pixelgraphik. Andere Menschen lassen sich Inhalte eventuell nur vorlesen oder die Präsentation beschränkt sich auf eine Braille-Zeile. Dies kann eine besondere Herausforderung bei der Verwendung von Graphik für den Autor sein, der folglich immer eine Alternative als Text bereitstellt, welcher die gleiche Funktion erfüllt wie die Graphik. Bei Formaten wie XHTML oder SVG sind solche Textalternativen bereits im Format vorgesehen, technisch vom Autor also einfach umzusetzen.

Die zweite Schicht ist das Layout oder die Dekoration mit Stilvorlagen, bevorzugt mit CSS umgesetzt. Mit dieser Schicht können Alternativen zur reinen Darstellung des XHTML oder SVG angeboten werden, also eine andere Anordnung des Inhaltes, farbliche Dekoration, besondere interaktive Effekte. Dies kann insbesondere Menschen mit stark visuellen Präferenzen und starkem Erlebnisdrang helfen, den Inhalt zu verstehen oder sich lang genug mit dem Projekt zu beschäftigen, um den Inhalt durchzulesen. Unabhängig davon, ob die Stilvorlage interpretiert wird oder welche der alternativen Stilvorlagen verwendet wird, bleibt der eigentlich zu vermittelnde Inhalt derselbe, es werden nur unterschiedliche Zugänge zum Inhalt angeboten.

Durch das Angebot alternativer Ansichten kann der Zugang für diverse Nutzergruppen erleichtert werden - nicht nur die Geschmäcker sind verschieden, sondern auch die Sehgewohnheiten und -fähigkeiten. Empfehlenswert sind etwa je nach Nutzer alternative Stilvorlagen einmal mit dunkler Schrift auf hellem Grund und einmal mit heller Schrift auf dunklem Grund. Da auch die Farbwahrnehmung beeinträchtigt sein kann, empfehlen sich auch immer Stilvorlagen, die auf Kontrasten und nicht primär auf verschiedenen Farben basieren.

Zudem kann mit Stilvorlagen die Ergonomie der Navigation in Projekten gegenüber der einfachen Darstellung ohne Stilvorlage verbessert werden, davon können viele Nutzer profitieren. Das gilt allerdings nur, wenn die Nutzung intuitiv möglich ist, also keine Barrieren dadurch entstehen, dass der Nutzer erst länger lernen muß, wie ein Projekt ergonomisch verwendet werden kann. Dies sollte sich von selbst ergeben oder der Lerneffekt kann auch während der Nutzung entstehen, ohne dass die Stilvorlage das Auffinden der Inhalte behindert, bevor ein Lerneffekt einsetzt.

Gerade beim Einsatz neuer CSS3-Module für Dynamik und Interaktivität und intensiveres Erlebnis eines Projektes ist daran zu denken, dass Darstellungsprogramme, die etwas älter sind, also nur CSS2 interpretieren, diese Effekte nicht anzeigen werden. Von daher ist eine Stilvorlage immer so aufzubauen, dass der Inhalt auch bei aktivierter CSS-Interpretation mit einem etwas älteren Programm noch zugänglich bleibt, denn nicht jeder Nutzer weiß, wo er notfalls die Interpretation von CSS komplett deaktivieren kann oder nicht jeder benutzt ein Programm, wo diese Deaktivierung überhaupt möglich ist.

Die dritte Schicht besteht in der Verwendung von Skriptsprachen. Gemeint sind hier Skripte, die auf dem Rechner des Nutzers laufen (typisch: ecmascript, java-script), also anwenderseitige Skript, nicht Skripte, die auf einem Rechner per Dienstprogramm Ausgaben in Formaten wie (X)HTML oder SVG erzeugen (typisch PHP, perl), die dann an die Darstellungsprogramme ausgeliefert werden. Mit anwenderseitigen Skripten ist es möglich, Inhalte stark dynamisch und interaktiv anzubieten, also besonders auf Nutzerreaktionen einzugehen. Es ist damit auch möglich, bei stark interaktiven Anwendungen die Menge der zwischen Darstellungsprogramm und Dienstprogramm ausgestauschten Daten auf nicht redundante Teilmengen zu reduzieren. Der Inhalt wird nicht mehr nur als einfacher Text angeboten, sondern als Erlebnis, als eine Anwendung. Mit solchen Skripten kann sowohl die zweite als auch die erste Schicht manipuliert werden. Daher bietet die Verwendung von Skripten ein besonders gefährliches Potential, Barrieren zu schaffen, Inhalte unzugänglich zu machen. Daher gilt auch hier wieder, dass auch diese dritte Schicht die eigentliche inhaltliche Aussage der ersten Schicht nicht verändert. Es wird damit lediglich ein alternativer Zugang zum ohnehin bereits mit der ersten Schicht vorhandenen Inhalt angeboten. Hilfreich kann solch eine Schicht besonders für solche Nutzer sein, die Probleme haben, ihre Aufmerksamkeit länger auf einen statischen Text zu konzentrieren. Durch ein interaktives, dynamisches Erlebnis des Inhaltes können solche Personen dennoch dazu befähigt werden, sich auch mit komplizierteren Inhalten länger zu beschäftigen und sie auch inhaltlich zu erfassen.

Ähnlich wie bei den Stilvorlagen gilt es hier wieder zwischen Verbesserung der Ergonomie gegenüber einer möglichst niedrig einzustellenden Lernstufe abzuwägen und ein Optimum zu finden. Der Zugang zum Inhalt darf also durch die Optimierung für eine Nutzergruppe nicht für eine andere pessimiert werden. Widersprechen sich die Anforderungen für verschiedene Personen, sollten mehrere Alternativen angeboten werden, die auf die jeweiligen Probleme der jeweiligen Gruppen optimal eingehen.

Die Trennung der drei Schichten ist nicht bei jedem Format so einfach wie bei (X)HTML. Oder aber die Trennlinien liegen nicht unbedingt immer im gleichen Bereich. Wie bereits angedeutet, schon bei einem Graphikformat wie SVG etwa sind Farben oft nicht mehr rein dekorativ, sondern beinhalten Information. Daher gibt es in SVG für die rein dekorativen Aspekte ebenfalls Eigenschaften im Format CSS, aber auch Präsentationsattribute, die es erleichtern, den Inhalt zu verstehen. Bei anderen, insbesondere nicht XML-Formaten kann leicht das Problem auftreten, dass die Schichten nicht voneinander trennbar sind, auf solche Formate ist dann folglich zu verzichten.

Generell haben Formate wie (X)HTML und SVG viele eingebaute Hilfen, die es Autoren eigentlich sehr leicht machen, Inhalte zugänglich anzubieten. Entsprechend fällt es bei diesen Formaten auch recht leicht, die drei Schichten konsequent zu trennen, so dass man recht gut damit Dokumente anbieten kann, bei denen der Zugang zum Inhalt ganz unabhängig davon ist, ob Skripte oder Stilvorlagen interpretiert werden oder nicht.

Auf Fragen der Barrierefreiheit wird sowohl im Wiki-Buch über SVG ausführlich eingegangen als auch im Buch über XHTML dieser Buchreihe. Die in den Formaten eingebauten Hilfen sind jeweils erläutert.

Semantik[Bearbeiten]

Semantik bezeichnet im Zusammenhang mit elektronischen Dokumenten die Auszeichnung von Inhalten gemäß ihrer Bedeutung. So sollten beispielsweise (X)HTML-Elemente immer nach ihrem (in den entsprechenden Empfehlungen) vorgesehenen Verwendungszweck eingesetzt werden, niemals entgegen diesem. Tabellen etwa sollten nur dazu dienen, tabellarische Daten zu strukturieren und nicht, um ein Layout zu gestalten. Überschriften sollten entsprechend als diese verwendet werden, niemals um lediglich Text hervorzuheben. Umgedreht können Überschriften auch dekoriert werden, es sollten aber nicht beliebige Elemente so dekoriert werden, dass sie wie Überschriften aussehen.

Nur wenn Inhalte der Bedeutung entsprechend ausgezeichnet sind, können sie auch ohne die Nutzung eines bestimmten Layouts mit Bedeutung versehen werden. Die ist insbesondere bei der Verwendung von Programmen nützlich, welche die Inhalte vorlesen (englisch: screen-reader), aber auch Suchmaschinen greifen auf diese Formatierungen zurück. Jeder Nutzer hat im Zweifelsfalle durch das Studium der ausgezeichneten Semantik eines Dokumentes eine Hilfe zur Interpretation des Inhaltes.

Erreichbarkeit von Inhalten[Bearbeiten]

Sämtliche Inhalte eines Projektes sollten unabhängig vom jeweiligen Eingabegerät angesteuert und ausgewählt werden können. Nicht alle Nutzer können oder wollen eine Maus oder ein ähnliches Zeigergerät verwenden (zum Beispiel bei eingeschränkter Motorik oder der Verwendung von Sensorbildschirmen – wie sie in modernen Mobilgeräten üblich sind). Zusätzlich sollten zu audiovisuellen Medien Text-Alternativen vorhanden sein. Dies ist hilfreich, wenn der Nutzer diese Medien nicht laden kann (oder will) oder sie schlicht aufgrund körperlicher Einschränkungen nicht erfassen kann.

Sowohl bei (X)HTML als auch bei SVG sind bei Elementen, bei denen Medien wie Audio- oder Videodateien eingebunden werden können, entsprechende Mechanismen bereitgestellt, um alternative Inhalte und Texte anzubieten. Leider gilt dies bei HTML 5 nur noch eingeschränkt, welches zunehmend davon ausgeht, dass die Text-Alternativen in der Audio- oder Video-Datei enthalten sind. Enthalten diese Dateien keine Textalternativen, sind die in HTML 5 eingeführten neuen Elemente audio und video folglich ungeeignet. Entweder ist also das Format zu wechseln, die Textalternative für alle zusätzlich anzubieten oder einfach auf das audiovisuelle Medium und die Textalternativen nebeneinander zu verweisen. Eine praxisnahe Idee für HTML 5 ist demzufolgen, gleichwertigen Text nicht alternativ, sondern zusätzlich zu audio, video und ähnlichen Elementen ohne Möglichkeiten für Alternativtexte anzubieten. Ob dieser Text vor oder nach dem Element notiert wird oder auf einer eigenen Seite, bleibt dem Autor überlassen, auch die Kennzeichnung der Korrelation zwischen verschiedenen Varianten von Inhalt bleibt weitgehend dem Autor überlassen. In vielen Fällen kann ein Autor in HTML 5 allerdings seine Medien in ein Element figure setzen und darin mittels figcaption eine Beschriftung angeben, die primär aus korrespondierendem Text besteht, der aber natürlich auch etwa per Verweis auf korrelierte Dokumente oder Fragmente verweisen kann.

Ferner soll Information unabhängig von den Möglichkeiten des jeweiligen Nutzers zugänglich sein. Dabei kann davon ausgegangen werden, dass einmal abgesehen von unwahrscheinlichen, kurzfristigen Problemen mit der Kodierung der binären Informationen (in der Praxis UTF-8 verwenden oder im europäischen Raum auch die übliche ISO-Kodierung), Information als einfacher Text zugänglich ist. Ferner helfen Auszeichnungssprachen wie (X)HTML und SVG mit Strukturen, die die Semantik repräsentieren, die Information leichter verständlich zu machen. Solch ein (XML)-Format, welches auf einfachem Text basiert, ist also immer die Primärquelle für zugängliche Information. Da es nun wiederum vielen Menschen leichter fällt, graphisch aufbereitete oder dekorierte Repräsentationen von Information nachzuvollziehen, kann dies als alternativer oder ergänzender Inhalt ebenfalls verfügbar gemacht werden. Dabei ist generell daran zu denken, dass etwa Pixelgraphik keine Information enthält, die direkt als Text zugänglich wäre, von daher ist dies immer nur als Alternative zu vorhandenem Text sinnvoll verwendbar. Ähnliche Probleme können sich ergeben, wenn ganz allgemein ein Formatwechsel vorliegt. Flash-Dateien, Java-Applets, Video- und Audio-Formate etwa werden aus verschiedenen Gründen nicht für jeden dekodierbar sein, daher stellen diese auch immer nur eine Alternative zu einer Textrepräsentation dar.

Bindet man etwa SVG in XHTML ein oder umgedreht, so handelt es sich zwar in beiden Fällen um prinzipiell zugängliche Textformate, es kann aber nicht davon ausgegangen werden, dass jedes Programm, welches das eine Format interpretiert, auch das andere interpretiert, insbesondere nicht in gleicher Qualität Textalternativen zugänglich macht, daher empfiehlt sich auch hier jeweils die Angabe einer kurzen Textalternative im Ausgangsformat. Solch eine Kurzinformation erspart allerdings nicht, etwa bei einer eingebundenen SVG-Datei, diese selbst mit Textalternativen zur Graphik zugänglich zu machen, wie es in SVG vorgesehen ist.

Einige spezifische Methoden für (X)HTML oder SVG:

Tab-Index[Bearbeiten]

Mit dem Attribut Tab-Index kann bei (X)HTML die Reihenfolge der zu fokussierenden Verweise festgelegt werden, was mit der Tabulator-Taste möglich ist. So können zum Beispiel unwichtige Verweise wie zum Beispiel zu Werbezwecken und Ähnliches übersprungen werden. In der Praxis hat sich erwiesen, dass die Zugänglichkeit von Dokumenten sich durch Verwendung dieses Attributes eher verschlechtert. Sofern das Bedürfnis aufkommt, dieses Attribut verwenden zu wollen, ist fast immer eine schlechte Dokumentstruktur zu vermuten. Autoren sollten dies also als Hinweis werten, die Struktur des Dokumentes zu verbessern. Nach einer solchen Verbesserung sollte das Attribut in den allermeisten Fällen redundant sein.

Sprungmenü (englisch Skiplinks)[Bearbeiten]

Ein sogenannter Skiplink (Sprungverweis) ist ein Verweis auf ein Fragment im selben Dokument. So können zum Beispiel unwichtige Elemente wie Kopfzeile oder Navigation übersprungen werden, wenn ein Vorleseprogramm verwendet wird oder das Layout nicht geladen wird. Natürlich ist es geschickter, wenn man die Reihenfolge der Inhalte von vorne herein so festlegt, dass die relevanten Inhalte vorne stehen, also etwa der Seiteninhalt vor der Projektnavigation angeordnet ist. Das Sprungmenü mit Verweisen zu Abschnitten oder Kapiteln im selben Dokument hingegen sollte also sehr weit vorne stehen und wiederum auch nicht zu lang sein.

Tastenkürzel (englisch Accesskeys)[Bearbeiten]

Mit Tastenkürzeln (auch Tastaturkürzel) können ähnlich dem Sprungmenü Dokumentfragmente angesprungen werden, hier durch drücken einer Taste. Die Funktion ist allerdings bei (X)HTML nur für bestimmte Elemente verfügbar. Zudem ist dem Nutzer eines Projektes natürlich zur Kenntnis zu bringen, welche Taste welchen Zweck hat. Da Darstellungsprogramme meist eine eigene Steuerung per Tastatur haben, gibt es dort zumeist eine spezielle Taste, die gedrückt werden muß, bevor die Tastenkürzel eines Dokumentes aktiv sind. So kann um Beispiel der Navigation die Taste '1' zugewiesen werden:

<h2><a accesskey="1">Menü</a></h2>
<ul>
    <li>Startseite</li>
    <li>Dokumente</li>
</ul>

Interaktive Inhalte[Bearbeiten]

Interaktive Inhalte (zum Beispiel durch Skripte realisiert, aber bei SVG auch bereits deklarativ ohne Skript verfügbar) sollten immer nur ein Zusatz, niemals Voraussetzung zum Zugang zum Inhalt sein. Man sollte sie, wenn gewünscht, nutzen können. Da man Nutzer aussperren würde, wenn man sie zur Voraussetzung erklärt, untergräbt dies die in Formaten wie (X)HTML und SVG integrierten Mechanismen der Barrierefreiheit. Dem Nutzer muß zudem natürlich auch immer klar sein, wie interaktive Inhalte zu bedienen sind - da der Autor meist anders denkt als der Nutzer, kann ein intuitives Verständnis meist nicht vorausgesetzt werden.

Häufig zu beobachtende negative Beispiele[Bearbeiten]

Flash-Inhalte und komplett mit Flash umgesetzte Projekte, die ohne Alternativtext per object eingebunden werden
JavaScript-Navigationen
Erzeugen neuer Inhalte mit JavaScript, besonders mit Ajax
Texte, Bilder, Videos und Musik, die dem Inhalt dienen und nur per Skript eingebunden oder ausgetauscht werden
Captchas (Bilderrätsel, welche angeblich der Abwehr von Spam dienen, tatsächlich aber primär Nutzer eines Projektes nerven oder gar vergraulen.
Sitzungen mit Keksen (englisch: cookies) fluten

Abhilfe für häufig zu beobachtende negative Beispiele[Bearbeiten]

Für Strukturen, die per Flash oder JavaScript präsentiert werden, wird folglich immer ein deklarativer Primärhinhalt benötigt, der mit solchen Techniken nur dekorativ ergänzt wird, der aber unabhängig davon funktioniert.

Deklarativ ist eine Methode, wenn die Interaktion Bestandteil der Basissprache ist, was etwa auf deklarative Animation und Interaktion in SVG zutrifft, die folglich einer ebenfalls möglichen Skript-Variante von Animation und Interaktion vorzuziehen ist, aufgrund der Einschränkungen der Möglichkeiten deklarativer Notationen aber für einige Anwendungen etwas sperriger umzusetzen sein kann, für einfache Anwendungen ist die deklarative Notation hingegen meist ohnehin viel einfacher. Für Menschen, die zeitabhängigen Aktionen wie Animationen nicht folgen können, wird natürlich unabhängig davon immer noch eine einfache Textalternative mit einer zusammenfassenden Beschreibung der Vorgänge benötigt. Siehe dazu auch den Abschnitt über zeitabhängige Inhalte.

Flash oder JavaScript haben meist nur eine wirklich notwendige Funktion bei massiv interaktiven Unterhaltungsspielen, die dann zwangsläufig nicht allen Menschen zugänglich sind. Eine zusammenfassende, zugängliche Textbeschreibung solcher Spiele ist natürlich immer möglich und auch notwendig, wenn die Spiele nicht stattdessen als nur dekorativ gekennzeichnet sind, also keine inhaltliche Relevanz aufweisen.

Ajax-Anwendungen sind meist ohnehin überflüssig und redundant, weil man den Primärinhalt ja ohnehin komplett zugänglich ohne Skriptanwendung anzubieten hat, von daher kommt ein Nachladen von Inhalten bei einer sinnvollen Strukturierung von Projekten gar nicht vor. Das Bedürfnis nach einer solchen Ajax-Anwendung weist also stark auf fundamentale Mängel im Konzept eines Projektes hin. Als effiziente Alternative zu einer zugänglichen, skriptfreien Basisversion eines Projektes können solche Anwendungen natürlich gleichwohl auftreten. Dann ist das Projekt so umzusetzen, dass die Umschaltung zwischen den Alternativen automatisch passiert, eine Belehrung des Nutzers oder gar eine Aufforderung, etwa die Interpretation von JavaScript zu aktivieren oder sich ein neueres Darstellungsprogramm zu besorgen, welches Ajax beherrscht, ist natürlich zu unterlassen.

Auf Captchas ist prinzipiell zu verzichten, es ist ihre Funktion, unzugänglich zu sein, widerspricht also dem primären Ziel, Information für alle zugänglich anzubieten. Eine Ausnahme bilden hier allenfalls Projekte, die sich die Unterhaltung mit Bilderrätseln (oder Audio-Rätseln etc) zum Ziel gemacht haben, wo das Rätsel also eigentliches Thema der Seite ist, nicht unzulängliches Mittel für einen anderen Zweck. Angeblich sollen Captchas dazu dienen, zwischen menschlichen Nutzern und Maschinen zu unterscheiden, was aber schon vom Ansatz her unsinnig ist, weil jeder Mensch immer einen Rechner und Programme braucht, um sich digitale Inhalte zugänglich zu machen. Programme und Maschinen sind also immer notwendig, um Inhalte zu lesen. Selbst wenn man vom naiven Ansatz der Erfinder von Captchas ausgeht, sind diese gescheitert, weil immer mehr spezielle Programme entwickelt werden, um Captchas ohne menschliche Hilfe oder mit unwissentlicher menschlicher Hilfe zu dekodieren, um eben jenen Spam in Foren und sonstigen Diensten unterzubringen, den man da automatisch mit Skripten unterbringen will. Zahlreiche Menschen, deren Interaktion man bei solchen Diensten gerne hätte, werden aber gerade frustriert und ausgesperrt, weil sie die Rätsel selbst nicht lösen können oder kein Interesse daran haben, in dem Zusammenhang Rätsel zu lösen, die rein gar nichts mit dem Thema zu tun haben und auch nicht mit ihrem aktuellen Anliegen. Viele Menschen verfügen auch nicht über leistungsfähigen Programme, um die Rätsel effektiv durch Maschinen lösen zu lassen. Im Fazit funktionieren Captchas also gerade falsch herum, sie sperren die aus, die man haben will und lassen die rein, die man draußen halten will, sie sind diskriminierend und erniedrigend für Menschen, die man nötigen will, sie zu verwenden. Das Paradox besteht bei den derzeit halbwegs erfolgreichen Captchas gerade darin, das Menschen leistungsfähige Programme benötigen, um die Captcha-Rätsel zu lösen. Die gleichen Programme können aber natürlich dann auch von Spambots verwendet werden, um dieselben Captcha-Rätsel zu lösen. Ein bösartiger Angreifer hat bei zu komplizierten Captcha-Rätseln zudem immer die Möglichkeit, ein eigens Projekt zu erstellen, wo seinerseits Belohnungen (Honigtöpfe) für Menschen aufgestellt werden, die dann ihre Kreativität nutzen sollen, um die Captcha-Rätsel zu lösen, wonach ein Angreifer dann diese Lösungen verwenden kann, um mit Spambots jene Seiten anzugreifen, wo die Captcha-Rätsel ursprünglich gestellt wurden.

Als Alternativen zu Captchas bieten sich etwa an:

Zwang zur Vorschau beim Absenden von Formularen, was Spambots meist nicht verstehen, sie sind meist nicht darauf eingerichtet, nach dem Absenden eines Formulars die wieder als Formular formulierte Antwort abermals zu verschicken.
Zusätzliche, eigentlich nicht auszufüllende Formulareingaben (Honigtöpfe), die von Spambots meist nicht erkannt werden und doch ausgefüllt werden, weil sie den für Menschen verstehbaren Hinweis im Label nicht beachten, dass dieses Formularfeld nicht von Menschen auszufüllen ist, die als Menschen ein Formular absenden wollen.
Einbau von Zeitmarken etwa mit PHP - damit kann man prüfen, wie lange es dauert, bis ein Formular ausgefüllt und abgesendet wird, je nach Umfang des Formulars werden Menschen dafür einige Sekunden bis Minuten brauchen, es aber nach einigen Stunden nicht mehr verschicken. Zusammen mit einem Hinweis, dass ein Formular etwa nur akzeptiert wird, wenn man mindestens 10 Sekunden und nicht mehr als 10 Stunden für das Ausfüllen braucht, der von Spambots nicht verstanden wird, von Menschen schon, kann man auch damit einen großen Teil von Spambots ausschließen.

Eine Kombination mit der Maßnahmen würde es für einen Angreifer notwendig machen, alle Maßnahmen im Detail zu analysieren und seine Skripte umfangreich anzupassen. Das ist ein relativ hoher Aufwand, um Spambots zu programmieren. Der Angreifer hat also einen ähnlich hohen Aufwand, wie gleich selbst das Formular auszufüllen, was er immer tun kann, wovon man ihn auch mit Captchas nicht abhalten kann, jedenfalls nicht mehr oder weniger als andere Menschen.

Kekse (englisch cookies) sind eine Methode, um in einer Sitzung Interaktionen eines Nutzers über mehrere Seitenaufrufe hinweg diesem zuzuordnen, wofür eine kleine Textinformation versendet wird, welche eine Identifikation der Sitzung enthält. Relevante Nutzungsdaten werden auch nicht im Keks abgelegt, sondern nur die Kennung der Sitzung.

Man sollte die Sitzung nicht davon abhängig machen, dass ein Nutzer solche Kekse annimmt oder beliebig viele davon für einen Seitenaufruf. Diese Methode wird oft mißbraucht, um die Spuren von Nutzern im Netz zu verfolgen und diesen damit zu identifizieren. Von daher muß man ohnehin damit rechnen, dass Nutzer solchen Techniken zunehmend mißtrauisch gegenüberstehen. Aufgrund einer Fehlkonzeption eines Projektes kann es auch passieren, dass bei einem einzigen Seitenaufruf mehrere Kekse statt nur eines Sitzungskekses angeboten werden, was für den Nutzer sehr nervig bis frustrierend sein kann, wenn er teils Duzende von aufklappenden Fenstern angezeigt bekommt und mit Fragen bombardiert wird, ob er den jeweiligen Keks annehmen will oder nicht, es gibt also für jeden Keks jeweils eine einzelne Anfrage. Bei einer Flut solcher Anfragen bei einem Seitenaufruf, hat der Nutzer also auch keine Chance, diese entweder alle pauschal anzunehmen oder abzulehnen, was extrem nervenaufreibend sein kann.

Es sollte also maximal ein Keks pro Seite versendet werden - und zwar erst nach der Anmeldung des Nutzers bei einem Dienst. Und dem Nutzer sollte somit durch die Anmeldung klar sein, dass der Keks für ihn einen Nutzen hat. Unabhängig davon sollte die jeweilige Seite dann vor dem Einsatz des Kekses natürlich darauf hinweisen, worin Funktion und Nutzen liegen, damit der Verwendung gegebenenfalls auch zugestimmt wird.

Kekse werden immer exakt von dem Dienstrechner verschickt, von welchem das aktuelle Dokument kommt, Kekse von anderen Dienstrechnern (etwa von eingebetteten Dateien wie Bildern oder auch von Skripten stammend) sind vom Nutzer ohnehin leicht als unsinnig einzustufen und eine leicht vermeidbare Barriere. Selbst der der Nutzer Kekse pauschal ablehnt, sind die Sitzungen natürlich so zu organisieren, dass sie trotzdem funktionieren, wozu es diverse Möglichkeiten gibt.

Tabellen[Bearbeiten]

In (X)HTML können Tabellen besonders schwierig zu verstehen sein, wenn es dem Nutzer nicht möglich ist, diese zu betrachten. Daher bietet (X)HTML spezielle Konstruktionen, die es auch bei komplexen Tabellen erlauben, Beschriftungen von Zeilen und Spalten der jeweiligen Tabellenzelle zuzuordnen. Diese Mechanismen sind bei komplexeren und größeren Tabellen unbedingt zu verwenden, um den Inhalt verständlich zu machen.

Zeitabhängige Inhalte[Bearbeiten]

Zeitabhängige Inhalte können ebenfalls problematisch sein, wenn der Nutzer der Geschwindigkeit der Änderung des Inhaltes nicht folgen kann. Wird zum Beispiel in einem SVG-Dokument die Darstellung eines Textes animiert, so soll der Text auch statisch verfügbar gemacht werden. Ob dies nun über die Möglichkeit des Pausierens der Animation erreicht wird oder interaktiv auf eine statische Darstellung umgeschaltet werden kann, kann vom jeweiligen Einzelfall abhängen. Ene weitere elegante Möglichkeit wäre, den Inhalt anfangs statisch darzustellen und es dem Nutzer zu überlassen, die Dynamik bei Bedarf zu starten und bei längeren Laufzeiten dann auch wieder abzuschalten. Ähnlich sind Situationen zu handhaben, wo es aufgrund anderer Konstruktionen zeitabhängigen Inhalt gibt - es sollte immer klar sein, wie der Nutzer auf eine Variante umschalten kann, wo er selbst die Geschwindigkeit der Rezeption des Inhaltes bestimmen kann.

Sprachattribute[Bearbeiten]

In Texten kommen oft auch Wörter in anderen Sprachen, zum Beispiel Englisch vor. Von Vorleseprogrammen werden diese dann in der eingestellten Sprache vorgelesen. Wenn nun etwa ein englisches Wort vorkommt, wird dieses dann mit deutschem Sprachlaut vorgelesen. Um dies zu vermeiden, sollte dieses Wort mit einem span-Element umschlossen werden und diesem die Sprache Englisch zugewiesen werden, so dass dieses auch englisch vorgelesen wird:

<p>Zurück zu <span xml:lang="en">Home</span>.</p>

Generell ist auch für das Wurzelelement eines Dokumentes, welches Text enthält, ein Sprachattribut anzugeben, welches sich dann auch auf alle Nachfahren bezieht. Damit ist dann für das gesamte Dokument eindeutig festgelegt, in welcher Sprache es verfaßt ist. Bei Bedarf und vorhandener Möglichkeit können natürlich auch Alternativen in anderen Sprachen verfügbar gemacht werden. Die Möglichkeiten dazu sind vom verwendeten Format abhängig - während es etwa in SVG recht einfach ist, Sprachalternativen im selben Dokument unterzubringen, ist es bei (X)HTML eher üblich und einfacher, je eine Alternative in einer Spache anzubieten und auf die Dokumente mit den alternativen Sprachen zu verweisen.

Die Fähigkeit von Autoren, die gleiche Information in verschiedenen Sprachen anzubieten, ist zumeist stark begrenzt. Die Fähigkeit von Nutzern, die Information in einer beliebigen, vom Autor gewählten Sprache zu verstehen, ist zumeist ebenfalls stark begrenzt. Zwar gibt es schon länger Programme, die sich an einer automatischen Übersetzung von Texten versuchen, die Ergebnisse sind allerdings eher als mäßig bis komisch einzustufen. Auch für solche Programme sind jedenfalls passende Sprachangaben sehr wichtig. Bereits an diesem Problem verschiedener Sprachen ist allerdings zu erkennen, dass hier recht schnell eine Grenze erreicht ist, ein Autor wird praktisch nicht allen die Information zugänglich machen können, allenfalls jenen, die eine der verwendeten Sprachen verstehen können.

Logische Struktur[Bearbeiten]

Das Dokument sollte eine logische Struktur verfolgen. So sollten Elemente und Inhalte an erwarteten Stellen platziert werden. Der Nutzer sollte alle Elemente leicht finden. Dies wird auch erleichtert, wenn die Anzahl gleichartiger, gleichzeitig zu überschauender Strukturen gering gehalten wird. Zwischen ihnen sollten Assoziationen erstellt werden, damit man der Struktur leichter folgen kann. Des Weiteren sollten Überschriften hierarchisch verwendet werden, um die Verzweigung eines Elementes verständlicher zu machen.

Ein gut verständliches Dokument hat also eine einfache Struktur, die vom Nutzer leicht nachvollziehbar ist. Es überfordert den Nutzer nicht durch zuviel Komplexität, es sollten also nicht zahlreiche Inhalte, die nichts miteinander zu tun haben, in einem Dokument miteinander konkurrieren. Dies erschwert dem Nutzer, die Bedeutung des gesamten Dokumentes zu erfassen und erfordert eine längere Analyse, welche Inhaltsfragmente überhaupt inhaltlich zusammengehören oder überhaupt relevant sind.

Verwendung von Aria und RDFa[Bearbeiten]

Aria ist eine Erweiterung von (X)HTML, die vor allem dazu dient, mit Skripten und anderen Methoden bereits unzugänglich gemachte Projekte wieder zugänglich zu machen. In vielen Fällen ist das der falsche Weg. Wer gleich von Anfang an ein Projekt gemäß dem Schichtenmodell barrierefrei umgesetzt hat, wird kaum Probleme haben, die mit Aria gelöst werden könnten.

Für XHTML 1.x gibt es bislang kein Aria-Modul, entsprechende Attribute sind dort nicht verfügbar, allerdings gibt es XHTML+RDFa, mit welchem man auf Attributebene die semantische Bedeutung von Inhalten genauer festlegen kann, siehe auch das Kapitel im Buch über XHTML dieser Buchreihe. Im Zweifelsfalle kann mittels RDFa auch auf eine Bedeutung verwiesen werden, die per Aria festgelegt ist. Zu beachten ist dabei jedenfalls, dass mit dem Notieren der Bedeutung oder der Semantik keinesfalls irgendeine Funktion sichergestellt wird. Der Autor hat den Inhalt also wie gehabt so zu gestalten, dass der Inhalt zugänglich ist, unabhängig davon, ob oder wie ein Darstellungsprogramm auf die Anwesenheit solcher Attribute reagiert oder welche Funktionalität damit oder anderen zusätzlichen Dekorationen oder Methoden privilegierten Nutzern zuteil werden mag.

Aria kann allerdings als Erweiterung von HTML 5 verwendet werden, um Zugänglichkeitsprobleme in Dokumenten zu kennzeichnen, welche dieser Sprachversion folgen. Dies ist formal bei beiden Sprachvarianten von HTML 5 kein Problem, weil sie keine Möglichkeit der Versionskennung aufweisen, in einem Dokument also auch nicht mit einem Konstrukt dieser Sprachvarianten angegeben kann, welche Sprachvariante verwendet wird, somit sind Erweiterungen durch Autoren immer möglich, implizieren aber natürlich nicht eine spezifische Behandlung solcher Erweiterungen durch Darstellungsprogramme. Entsprechendes gilt für den Einsatz von RDFa als Erweiterung von HTML 5.

Reaktionsfähige Gestaltung[Bearbeiten]

Mit dem englischen Begriff 'responsive design' ist in den letzten Jahren ein neues Schlagwort aufgekommen, um zu kennzeichnen, dass sich insbesondere bei einer graphischen Präsentation von digitalen Inhalten die Art der Darstellung den Möglichkeiten des zur Darstellung verwendeten Gerätes anpassen sollte. Das bezieht sich schwerpunktmäßig auf Stilvorlagen (CSS), kann aber auch eine Anpassung von Inhalten umfassen, etwa die Anpassung der verschiedenen Varianten einer Graphik an das verwendete Ausgabegerät.

Nun, die Grundidee ist keineswegs neu. (X)HTML allein macht dies bereits seit Anfang an automatisch. Oft haben allerdings Designer CSS mißbraucht, um diese automatisch verfügbare Funktionalität von (X)HTML-Darstellungsprogrammen zu deaktivieren, um ihr unflexibles, auf eine feste Größe des Darstellungsbereiches hin ausgelegtes Layout oder Design durchzusetzen, unabhängig davon, ob dies beim jeweiligen Betrachter irgendeinen Sinn ergibt oder nicht.

Im Laufe der Jahre gab es dann aber immer mehr Mobiltelephone, mit denen ebenfalls Inhalte aus dem Netz dargestellt werden konnten, allerdings zunächst auf kleinen, niedrig auflösenden Monitoren. Entweder wurde diese Nutzergruppe komplett ignoriert oder, nachdem die Anzahl dramatisch gestiegen war, es wurde für diese Gruppe der Inhalt unter eigener URI und mit eigenem Layout präsentiert. Mittlerweile gibt es allerdings die aktuellen Mobiltelephone mit der Funktionalität mit deutlich größeren, hochauflösenden Monitoren. Problematisch ist zudem, dass man entweder die Nutzer kleiner Geräte irgendwie dazu bringen muß, die URI anzusteuern, unter der eine für sein Gerät geeignete Darstellung ist, oder man versucht dies automatisch durch ein Dienstprogramm zu bestimmen, was aber eine sehr fehleranfällige Methode ist. Deswegen ist die Idee mit verschiedenen URIs nicht nur sehr wartungsaufwendig, sondern auch sehr fehleranfällig, woraus sich dann zusätzliche Barrieren und Zugänglichkeitsprobleme ergeben können, die nicht akzeptabel sind.

Zudem haben sich die Abmessungen typischer Monitore grob seit der Jahrtausendwende deutlich verändert. Ein relevanter Parameter ist hierbei das Aspektverhältnis von Breite zu Höhe des verfügbaren Darstellungsbereiches. Dieses hängt zum einen vom Aspektverhältnis des Monitors ab, zum anderen aber auch davon, dass graphische Oberflächen von Betriebssystemen per Voreinstellung ihr Menü meist horizontal anordnen, ebenso die Menüs von Programmfenstern.

Hatte man früher noch ein beinahe quadratisches Aspektverhältnis von 5:4, hat sich das im Laufe der Jahre über 4:3 nach 16:10, 16:9 oder gar 2:1 hin verschoben. Diese breiten Monitore führen dann oft zwangsläufig zu einem anderen Arbeiten. Programmfenster werden dabei dann oft insbesondere in der Breite, aber auch in der Höhe deutlich kleiner eingestellt als auf die Größe des Monitors. Mit Mobiltelephonen und Geräten zur Darstellung digitaler Bücher gibt es nun sogar auch Situationen, wo die Breite des Darstellungsbereiches nicht mehr deutlich größer ist als die Höhe. Das Aspektverhältnis kann sich gar umkehren, also etwa 9:16, was ganz neue Präsentationsbedingungen ergibt.

Letztlich ist den Designern damit ein Maß abhanden gekommen, wie groß der Darstellungsbereich beim jeweiligen Nutzer ist. Mit 'responsive design' kommt daher die Rückbesinnung darauf, dass Inhalt eigentlich für alle zugänglich sein soll, unter anderem eben auch unabhängig davon, wie groß der verfügbare Darstellungsbereich ist.

Insbesondere sehr breite Darstellungsbereiche sind aber auch für die 'normale' Präsentation von Fließtext in (X)HTML nicht unbedenklich, weil sehr breite Zeilen das Lesen, das Finden des nächsten Zeilenanfangs erschweren. So ist es oft wünschenswert für den Nutzer, den Darstellungsbereich für Fließtext auf vielleicht dreißig bis sechzig Zeichen Breite einzuschränken.

Auf diese Probleme hat man jedenfalls bei CSS 3 reagiert. Medienanfragen (englisch: media queries) sind bereits verfügbar, spezielle Einheiten, die sich auf die Größe des Darstellungsbereiches beziehen, sind in Vorbereitung (Modul von CSS 3 für Einheiten).

Daneben bietet auch bereits CSS 2 einige Möglichkeiten, etwa mit float Inhalte nebeneinander anzuordnen, wenn dafür ausreichend Platz vorhanden ist oder automatisch untereinander, wenn nicht genügend Platz vorhanden ist. Dies ist insbesondere nützlich, um den Platz bei breiten Darstellungsbereichen besser auszunutzen. Typisch wird etwa die Projektnavigation neben dem eigentlichen Inhalt positioniert, wenn dafür Platz ist. CSS 2 gibt es allerdings nicht her, den verfügbaren Platz wirklich zu prüfen, dies ist erst mit den Medienanfragen möglich.

Mit CSS 2 hat man meist vorausgesetzt, dass bei einem sinnvollen Darstellungsbereich mindestens dreißig bis vierzig Zeichen in eine Zeile passen und hat dann etwa der Navigation neben dem Inhalt eine Breite von zehn bis fünfzehn Zeichen gegönnt. Bei einer teils ebenfalls üblichen und sinnvollen absoluten Positionierung eines solchen Menüs neben dem Inhalt gab es dann natürlich Probleme etwa bei Mobiltelephonen, die eine so kleine Anzeige hatten, dass die angenommene Voraussetzung nicht mehr stimmte. Zunächst haben die Darstellungsprogramme für solche Mobiltelephone einfach etwa Angaben zur absoluten Positionierung ignoriert, so dass es kein Problem damit gab. Aufgrund steigender Größen bei neueren Mobiltelephonen war diese Lösung dann aber irgendwann nicht mehr akzeptabel, weswegen man sich heute nicht mehr darauf verlassen kann, dass etwa absolute Positionierung automatisch auf kleinen Geräten ignoriert wird, eben weil da heute ganz normale Darstellungsprogramme laufen und nicht mehr für diese kleinen Geräte speziell angepaßte Programme.

Eine Möglichkeit besteht nun darin, gezielt für kleine Darstellungsbereiche eine alternative Stilvorlage bereitzustellen, wie man ja allgemein für denselben Inhalt mehrere alternative Stilvorlagen anbieten kann. Der Haken dabei ist allerdings, dass einige Darstellungsprogramme, die nennenswert genutzt werden, hier Implementierungslücken oder -fehler haben und kein Menü anbieten, damit der Nutzer alternative Stilvorlagen auswählen kann. Bei einem Wechsel zu einer anderen Seite eines Projektes, welches die gleiche Auswahl an alternativen Stilvorlagen bietet, behalten die meiste Darstellungsprogramme den bei der vorherigen Seite ausgewählten Stil nicht bei, was das gesamte Konzept für den Nutzer unpraktisch werden läßt. Bei manchen anderen Nutzern mag zudem nicht bekannt sein, wie man eine alternative Stilvorlage auswählt, selbst wenn dies möglich ist, zumal die meisten Darstellungsprogramme nicht anzeigen, wenn Alternativen angeboten werden.

Ein Ausweg ist hier, als Autor selbst ein solches Auswahlmenü im Inhaltsbereich bereitzustellen und diese Auswahl dann selbst dynamisch zu realisieren, etwa über eine Verarbeitung auf dem Dienstrechner (zum Beispiel, indem die Ausgabe mit PHP erzeugt wird). Bei diesem Ansatz ist es natürlich besonders wichtig, dass eine solche Auswahlmöglichkeit vom Nutzer auch bemerkt wird und zugänglich ist, auch wenn das verwendete Gerät nicht gut zum anfänglichen Stil paßt.

Erst in den letzten Jahren hat es sich etabliert, dass skalierbare Graphiken (SVG) sinnvoll genutzt werden können. Wenn diese zusammen mit Fließtext in einem Dokument präsentiert werden, gibt es zumeist das Bedürfnis, dass sich einerseits die Größe der Zeichen im Fließtext (etwa als XHTML+CSS umgesetzt) durch die Einstellungen des Nutzers gegeben sein soll, die Graphik (SVG) aber so skaliert sein soll, dass sie einerseits möglichst groß präsentiert wird, aber nicht größer als der verfügbare Darstellungsbereich, damit man die Graphik auf einmal und komplett betrachten kann. Für XHTML+CSS allein ist die eine Forderung nach geeigneter Schriftgröße kein Problem. Für SVG allein ist die andere Forderung nach einer optimalen Skalierung kein Problem. Beides zusammen in einem Dokument erfordert hingegen, dass das Layout oder die Präsentation in nicht ganz trivialer Weise auf die Größe des Darstellungsbereiches reagieren muß.

Durch Medienanfragen kann nun ein Autor einfach angeben, was passieren soll, wenn eine bestimmte Breite unterschritten oder überschritten wird oder welches Layout bei welchen typischen Aspektverhältnissen zur Anwendung kommt. Oft reicht das aus, um effizient mit ein paar Anfragen eine gute und zugängliche Präsentation des Inhaltes für ganz verschiedene Darstellungsbereiche zu erzielen. Für den Fall mit Text und Graphik kann die Situation allerdings eskalieren, wenn der Autor sehr viele Medienanfrage stellen muß, um das Ziel näherungsweise zu erreichen. Hier kann in Zukunft etwa weiterhelfen, dass es mit dem Modul von CSS 3 für Einheiten möglich sein wird, das Bild einfach relativ zum verfügbaren Darstellungsbereich zu dimensionieren, ebenso bietet dieses Modul die Möglichkeit, Dimensionierungsangaben aus verschiedenen Sachverhalten berechnen zu lassen.

So wird es denn letztlich gut möglich, Dekoration mit CSS für ganz verschiedene Darstellungsbereiche anzubieten und zu vermeiden, dass die Präsentation mit einem starren Layout zu Zugänglichkeitsbarrieren führt, die früher vom Nutzer nur umgangen werden konnten, indem die Interpretation von CSS komplett deaktiviert wurde. Dieser Ausweg ist indessen nicht einmal bei allen gängigen Darstellungsprogrammen möglich, bei denen der jeweilige Nutzer dann sowohl der eventuell fehler- und mangelhaften Präsentation des Programmes ausgeliefert ist als auch dem eventuell problematischen Layout durch den Autor.

Reaktionsfähiges Layout wird damit auch zu einem guten Teil eine Möglichkeit für Autoren, Defizite von graphischen Darstellungsprogrammen so zu kompensieren, dass durch diese keine Zugänglichkeitsbarrieren für den Nutzer dieser mangelhaften Programme entstehen.

Ein verbleibendes Problem bei diesem Konzept ist zum Beispiel, dass es auf diesem Wege bislang keine Möglichkeit gibt, das Layout etwa den Sehgewohnheiten des Nutzers gut anzupassen. Es gibt etwa Sehschwächen, die es wünschenswert erscheinen lassen, helle Schrift auf dunklem Hintergrund zu haben oder umgedreht. Verschiedene Sehschwächen können also einander ausschließende Anforderungen an die Präsentation stellen. Ähnlich kann dies auch auf eine von der Umgebungsbeleuchtung abhängige bevorzugte Präsentation zutreffen. Immerhin gibt etwa beim Standardformat EPUB für digitale Bücher eine Möglichkeit für Autoren, unterschiedliche Stile für Tag und Nacht bereitzustellen, typisch tags also dunkle Schrift auf hellem Grund, nachts umgedreht, um auch diesen Bereich halbautomatisch abzudecken.

Weiterführende Literatur[Bearbeiten]