Websiteentwicklung: Barrierefreiheit und Benutzbarkeit
Inhaltsverzeichnis |
Einleitung [Bearbeiten]
In einer Zeit, in der zunehmend mit recht unterschiedlichen Geräten wie persönlichen digitalen Assistenten, Mobiltelephonen oder Fernsehern Dokumente im Internet aufgerufen werden und in der auch seh-, hör- oder motorisch behinderte Menschen das Internet erfahren und erforschen möchten, ist die Barrierefreiheit von Informationen im Internet 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 zugeschnitten werden, dass es für Nutzer mit eingeschränkten Möglichkeiten besondere Zugangshilfen und -erleichterungen bietet. 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.
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:
- feste Schriftgrößen
- Verwendung ungeigneter Einheiten für Schriftgrößen und Breiten von Texten
- geringe Kontraste bei Farben für Text und in Graphiken
- falsche Verwendung der Semantik der zugrundeliegenden Auszeichnungssprache
- Verwendung ungeeigneter, proprietärer Dateiformate
- Fehlende Textalternativen zu Graphiken und Multimediaformaten
- Inhalte erst mit Skriptsprachen erzeugen
- 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)
- logische Barrieren
-
- durchbrechen bestehender Konventionen
- Inkonsistenz
Beteiligte Personengruppen [Bearbeiten]
Um das Basisziel des Internets 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 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 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. Gegebenenfalls sollten sie Fehler, Lücken und Mehrdeutigkeiten 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 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.
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 ist 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.
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 Screenreader, Smartphones), 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.
Verwendet wird ein sogenanntes Schichtenmodell, besonders geeignet für (X)HTML. 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 biete 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, 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.
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 des 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.
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 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. 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. 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.
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 Standards) 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 Bedeuung versehen werden. Die ist insbesondere bei der Verwendung von Programmen nützlich, welche die Inhalte vorlesen (Screenreader), 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.
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
- 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.
- Sprungmenü (englisch
- Skiplinks)
- 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 Screenreader 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 sollte also sehr weit vorne stehen und wiederum auch nicht zu lang sein.
- Tastenkürzel (englisch
- Accesskeys)
- 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
- Interaktive Inhalte (zum Beispiel durch Skripte realisiert) 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.
- Negative Beispiele:
- 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
- Tabellen
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
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 Testes 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 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 Screen-Readern 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.
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. Desweiteren 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]
Mit Aria ist derzeit eine Erweiterung von (X)HTML in Vorbereitung, 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. Aktuell (2012) gibt es noch keine Version von (X)HTML, in der Aria integriert wäre, 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.