Skip to content

Report

Jump to bottom Edit New page
cyBerta edited this page Sep 8, 2013 · 18 revisions

Gliederung

1. Formen von Handycaps und assestierender Technik (AT)

2. Überblick über Standarts

3. Beispiele aus WCAG 2.0

4. Beispiele aus ARIA

Formen von Handycaps

Bei der Herstellung barrierefreier User-Interfaces müssen die Verschiedenartigkeiten menschlicher Einschränkungen, beachtet werden. Sie verlangen unterschiedliche konzeptuelle und technische Lösungen bei der Gestaltung barrierefreier Webseiten. Im folgenden werden kurz einige Handycaps zusammengefasst:

Blindheit

Als blind gelten Menschen, die unter 1/50 des Durchschnittlichen Sehvermögens besitzen. Sie sind auf assenstierende Technik, die Webseiten lesen und in einer ihnen verständlichen Form ausgeben angewiesen. Webseiten einlesende Software werden Screenreader genannt, ein bekanntes Beispiel hierfür ist jaws. Ausgegeben werden Webseiten über ein Refreshable Braille Display, auch als Braille Terminal bekannt, oder über Text-to-Speech-Software. Fehlende Metainformationen in einer Webseite, sowie Webseiten, die nur auf Tastaturnavigation ausgelegt sind, sind für blinde Menschen nur eingeschränkt oder unnutzbar.

Sehbehinderung

Es gibt eine Reihe verschiedener Seheinschänkungen wie Farbblindheit, Blendempfindlichkeit, Schwierigkeiten bei der Hell-Dunkel-Anpassung oder ein eingeschränktes Gesichtsfeld. Zu beachten sind u.a. skalierbare Schriften und Layouts, die richtige Kombination von Vorder- und Hintergrundfarbe sowie ein Webseitenaufbau, der auch mit individuell angepasstem (=überschriebenen) Layout erkenn- und navigierbar bleibt. Typische assistierende Techniken sind Vergrößerungssoftwares/Bildschirmlupen.

Schwerhörigkeit und Gehörlosigkeit

Viele von Geburt an hochgradig schwerhörige sowie Gehörlose Personen nutzen Gebärdensprache als erste Muttersprache. Die Deutsche Gebärdensprache unterscheidet sich syntaktisch deutlich von der deutschen Schriftsprache, welche viele von Geburt an Gehörlose eher als 2.erlernte Sprache beherrschen. Dies kann zu Verständnisschwierigkeiten bei komplizierten oder längeren, schlecht strukturierten Texten führen. Darüber hinaus muss die erschwerte oder fehlende Wahrnehmung gesprochener Inhalte und akustischer Signale schwerhöriger bzw. gehörloser Menschen beachtet werden und für alternative Darstellungen zeitbasierter Medien wie Audio oder Video gesorgt werden. Typische assistierende Techniken sind Hörgeräte.

motorische Einschränkungen

Menschen mit motorischen Einschränkungen sind auf assistierende Techniken angewiesen, die ihnen die Tastatur- und/oder Mausnavigation erleichtern. Je nach Behinderungsgrad helfen Großfeldtastaturen (http://www.barrierefreies-webdesign.de/beispiele/barrierefreies-webdesign/abschnitt-1-2/abbildung-einer-grossfeldtastatur.html), Spezialsensoren, Taster, Spezialmäuse(http://www.barrierefreies-webdesign.de/beispiele/barrierefreies-webdesign/abschnitt-1-2/verwendung-der-integra-mouse.html), die mit dem Kinn oder den Lippen bedienbar sind, Kopfsteuerungen, "Eyetracking"-Technologien und Spracherkennungssoftware (z.B. http://www.nuance.de/for-business/by-product/dragon/dragon-for-the-pc/dragon-professional/index.htm). Fehlende Metainformationen macht können Webseite für motorisch eingeschränkte Menschen schlecht nutzbar oder unbenutzbar machen. Eine konzeptuell nur auf Mausnavigation ausgerichtete Webseite erschwert außerdem die Nutzbarkeit.

Lese- und Sprachschwierigkeiten

Leseschwierigkeiten kann verschiedene Ursachen haben, beispielsweise wenn es sich bei der angebotenen Sprache nicht um die eigene Muttersprache handelt oder bei einer Lese-Rechtschreib-Schwäche. Als Webdeveloper ist darauf zu achten, dass die Webseite nicht zu textlastig, bzw. ohne auditive/visuelle Alternative angeboten wird. Auch Implementierung von Mehrsprachigkeit hilft dabei, Barrieren abzubauen.

Lernbehinderungen/Lernschwierigkeiten

Menschen mit Lernbehinderung haben oft Schwierigkeiten, komplexe Texte zu verstehen. Entsprechend muss auf eine leicht verständliche Sprache oder Textalternative geachtet werden. Auch die Navigation muss möglichst intuitiv und klar strukturiert sein.

Standards

Für die Umsetzung technischer Standards zur barrierefreien Webseitengestaltung gibt es in Deutschland die auf dem Bundesgleichstellungsgesetz aufbauende „Barrierefreie Informations-Technik-Verordnung“ (BITV 2.0). Diese Verordnung gilt nur auf Bundesebene – auf Länder- und kommunaler Ebene greifen Landesgleichstellungsgesetze (für Berlin bspw. LGBG §17 http://www.berlin.de/lb/behi/auftrag/gleichberechtigungsgesetz.html), privatwirtschaftliche Webseiten sind von der BITV 2.0 rechtlich ebenfalls nicht betroffen. Dennoch halten sich einige Firmen an sie, um den Nutzer_innen-Kreis zu erhöhen.

Die technische Umsetzung der BITV 2.0 ist in den Web Content Accessibility Guidelines 2.0 (WCAG 2.0) des W3C geregelt. Die WCAG 2.0 besteht aus 3 Ebenen: 4 Grundzielen für die Erstellung barrierefreier Webseiten, 12 Richtlinien, die die 4 Prinzipien konkretisieren, aber technikneutral formuliert sind und 61 Erfolgskriterien, die konkrete Handlungsanweisungen für eine barrierefreie Umsetzung von Webseiten unter Berücksichtigung aktueller Techniken vorgibt.

Eine weitere Empfehlung heißt Accessible Rich Internet Applications (ARIA). Als technische Spezifikation befindet sich ARIA noch im Entwurfsstadium. Sie wird von der Web Accessibility Initiative, die dem W3C angehört entwickelt und stellt eine semantische Erweiterung für HTML zur Steigerung der Barrierefreiheit von Web 2.0 Anwendungen dar. ARIA definiert Rollen, Beziehungen, Zustände und Eigenschaften von Objekten und erhöht damit die Interpretierbarkeit selbiger durch assistierende Technik wie Screenreader.

Beispiele aus WCAG 2.0

Im Folgenden werden einige praktische Beispiele zur Erstellung barrierefreier Webseiten mit Bezug auf die vier Grundprinzipien sowie einer Auswahl der 12 Richtlinien der WCAG 2.0 erläutert.

Prinzip Wahrnehmbarkeit:

Informationen und Bestandteile der Benutzerschnittstelle müssen den Benutzern so präsentiert werden, dass diese sie wahrnehmen können.

Richtlinie 1.1 Textalternativen: stellen Sie Textalternativen für alle Nicht-Text-Inhalte zur Verfügung, so dass diese in andere vom Benutzer benötigte Formen geändert werden können, wie zum Beispiel Großschrift, Braille, Symbole oder einfachere Sprache.

Beispiel Textalternativen:

  • Jedes Nicht-Text-Element mit inhaltlicher Funktion soll mit einer Beschreibung versehen versehen werden, NICHT NUR BILDER; dies geschieht im Code über alt=""; steht bei alt nichts, dann wird eine Seite mit mehreren Grafiken hintereinander so vorglesen: "Grafik Grafik Grafik..."!
  • Die Beschreibung sollte folgende Punkte beinhalten: Was ist die Funktion der Grafik? Was ist der Inhalt der Grafik? Dass es sich um eine Grafik handelt, braucht nicht erwähnt zu werden, es wird automatisch vermittelt
  • Grafische Navigationselemente sollten knapp den Zweck wiedergeben, bei Schriftgrafiken reicht das, was auf dem Element steht.
  • Schmuckgrafiken ohne inhaltliche Funktion sollten einen leeren alt-Text beinhalten, dann werden sie von Screenreadern ignoriert: alt="" ohne Leerzeichen
  • wichtig: keine informativen Hintergrundbilder verwenden, diese sind für Screenreader in jedem Fall unsichtbar!
  • wenn längere Beschreibungen einer Grafik notwendig sind, sollte zusätzlich ein Link verwendet werden, der direkt unter dem Bild sichtbar ist und auf eine andere Datei mit der Beschreibung verweist.

Praxisbeispiel 1: go to inbox

analoges Codebeispiel dazu: <a href="inbox.html"><img src="icon/email.gif" alt="go to inbox" /></a>

Praxisbeispiel 2:

Verschiedene Handycaps

Bilderklärung

<img src="/img/handycap.gif" alt="Verschiedene Handycaps" height="180" width="250" longdesc="BilderklaerungHandycap.html"> <a href = "https://github.com/cyBerta/WebAccessibility/wiki/handycapExplanation">Bilderklärung</a>

Richtlinie 1.2 Zeitbasierte Medien: Stellen Sie Alternativen für zeitbasierte Medien zur Verfügung.

  • Bei zeitbasierten Medien wird zwischen reinen Audioinhalten, reinen Videoinhalten und synchronisierten Medien (mit Audio- und Videospur) unterschieden.
  • Für reine Audioinhalte gilt: Textabschrift für aufgezeichnete Audioinhalte, z.B. Link für Transkript direkt neben dem eingebetteten Player. Videoclips lassen sich mit Untertiteln (für gehörlose Menschen) oder mit einer Audiodeskription (für blinde Menschen) versehen
  • Das HTML5 <video>-Element kann text-Tracks, die im WebVTT-Format, was dem üblichen SRT-Format für Untertitel ähnelt, synchron zum Video abspielen. Noch ist WebVTT nicht in in allen Browsern implementiert aber in Chrome und im Internet Explorer.

Codebeispiel:

<video src="foo.ogv">

  <track kind="subtitles" label="English subtitles" src="subtitles_en.vtt"srclang="en" default></track>
  <track kind="subtitles" label="Deutsche Untertitel" src="subtitles_de.vtt" srclang="de"></track>

</video>

  • Da WebVTT noch nicht in allen Browsern implementiert ist, gibt es auch JavaScript Bibliotheken, die eine mehrsprachige Einbindung von Untertiteln ermöglicht. Ein Beispiel hierfür ist Bubble JS (Link zur Seite: hier).
  • Eine weitere Technik zur alternativen Darstellung von Medieninhalten ist SMIL (Synchronized Multimedia Integration Language)

Richtlinie 1.4 Unterscheidbar: Machen Sie es Benutzern leichter, Inhalt zu sehen und zu hören einschließlich der Trennung von Vorder- und Hintergrund.

Farbe und Kontraste

  • Hintergrundbilder verschlechtern deutlich die Lesbarkeit von Text, daher sollte möglichst auf Hintergrundbilder verzichtet o. verblasst werden.
  • Darüber verbessert ist ein hoher Kontrast die Unterscheidbarkeit von Vorder- und Hintergrund.
  • Unterscheidungsmerkmale sollten nicht nur auf Farbunterschieden beruhen: z.B. bei Kurvendiagrammen sollten Unterscheidungsmerkmale nicht nur die Farbe sondern beispielsweise die Strichstärke oder Linienstil darstellen. Farbenblinde erkennen rein farbliche Unterscheidungen u.U. nicht oder schlecht.
  • Hervorhebungen von Text sollte nicht nur farblich gestaltet werden, sondern auch die Tags <em> oder <strong> genutzt werden. Diese Tags können von Screenreadern interpretiert werden. Hervorhebungen mithilfe von CSS-Templates werden von Screenreadern nicht erkannt (wodurch blinde Menschen diese nicht wahrnehmen können).
  • Besonders wichtig für Navigation ist Hervorhebung von Links. Es sollten im CSS alle Zustände der Links (link, visited, hover, active, focus) mit Vorder- und Hintergrundfarbe definiert werden. Besonders wichtig ist das Definieren von hover für Menschen, mit Sehbehinderungen, die die Maus bedienen können und focus u.a. für motorisch eingeschränkte Menschen, die mit der Tabulator-Taste navigieren. Das gleiche gilt bei JavaScript für die Events onmouseover und onfocus. Zusätzlich sollten Links durch eine Unterstreichung oder ein voranstehendes Symbol gekennzeichnet werden.
  • Ein Styleswitcher bietet Möglichkeit zwischen verschieden Darstellungsvariaten für Schrift und Layout zu wählen, die mit unterschiedlichen Stylesheets bereitgestellt werden. Inhalt und Struktur bleiben dabei erhalten.

Folgende Kontraste sollten vermieden werden:

  • ROT-GRÜN (und andere Komplementär-Kontraste) - kann auf Monitoren zu Flimmer-Effekt führen.
  • ROT-SCHWARZ - Menschen mit Rotschwäche sehen Rot als dunkles Grau und Dunkelrot als Schwarz!
  • Beige/Gelb/Orange mit Rot und Grün - die meisten Farbfehlsichtigen ersetzen Rot und Grün durch Beige/Gelb/Orange.
  • große weiße Flächen - kann Menschen mit erhöhter Lichtempfindlichkeit blenden. Abhilfe schafft das Abtönen größerer weißer Flächen.

Empfohlene Farbkombinationen sind:

  • Schwarz auf weiß, Weiß auf Rot, Weiß auf schwarz, Blau auf Weiß, Gelb auf Blau

Prinzip Bedienbarkeit

Bestandteile der Benutzerschnittstelle und Navigation müssen bedienbar sein.

Richtlinie 2.1 Per Tastatur zugänglich: Sorgen Sie dafür, dass alle Funktionalitäten per Tastatur zugänglich sind.

Es gibt einige Eingabehilfen für Webseitenelemente wie Formulare, <input>,<textarea>,<label>,<legend>,<button> oder Links, die die Navigation unterstützen:

accesskey

  • Ermöglicht die Navigation eines Elements durch einen definierten Tastenkürzel.

Praxisbeispiel:

zurück zu WebAccessibility: Zum klicken dieses Links [Alt]+[Shift]+[l] drücken

analoges Codebeispiel: <a href="http://www.myhomepage.org/description" accesskey="d">DESCRIPTION</a> [Alt]+[Shift]+[d]<br>

tabindex

  • Jeder Tag bekommt einen unterschiedlichen Wert für Tabindex, vom untersten nach oben gezählt beim Tab-Drücken. Der Tabindex muss dann durchgehend auf der Seite per Hand definiert werden, sonst kann Tastatur-Bedienung eher noch umständlicher werden.

placeholder

  • Hilft der Orienierung, indem beispielhaft vorgegeben wird, was in welcher Formatierung in ein Feld hereingeschrieben werden soll.

autofocus

  • Wurde neu mit HTML5 eingeführt. Mit Autofocus lässt sich der Fokus auf ein Eingabefeld oder ein besonders wichtiges Element der Webseite setzen, damit nicht umständlich dorthin navigiert werden muss.
**Beispiel für tabindex, placeholder, autofocus**

<p>

<label for="nameinput" tabindex="1">Name:</label>
<input type="text" name="textinput" tabindex="2" id="nameinput" placeholder="Max Mustermann" autofocus>
<br>

</p>

Download this example and run on localhost

Richtlinie 2.4 Navigierbar Stellen Sie Mittel zur Verfügung, um Benutzer dabei zu unterstützen zu navigieren, Inhalte zu finden und zu bestimmen, wo sie sich befinden.

Blöcke überspringen/Blöcke direkt annavigieren

  • Eine Möglichkeit, die Tastaturnavigation zu erleichtern ist es, am Anfang der Webseite einen direkten Link zum Inhalt anzubieten, der beispielsweise die Navigationsleiste überspringt. Ein praktisches Beispiel hierfür ist unter http://www.biene-award.de zu finden.

Linearisierung in Datentabellen

  • Blinde Menschen müssen sich auch in größeren Tabellen orientieren können. Die Braille-Zeile zeigt nur eine Zeile der Tabelle an, ein zurück navigieren zum Tabellenkopf ist umständlich. Daher ist es wichtig, dass von jeder Zelle aus die Meta-Information, zu welcher Spalte und welcher Zeile sie gehört, verfügbar ist.

Beispiel:

<caption>Eintrittspreise fürs Kino</caption>

<tr>

	<td class=“keineDaten“></td>

	<th id=“spar“>Emäßigt</th>

	<th id=“normal“>Normaltarif</th>

</tr>

<tr>

	<th id =“Kinotag“>Kinotag</th>

	<td headers =  „Kinotag spar“>4,00€</td>

	<td headers =  „Kinotag normal“>6,00€</td>

</tr>

<tr>

	<th id =“Sonntag“>Sonntag</th>

	<td headers =  „Sonntag spar“>5,50€</td>

	<td headers =  „Sonntag normal“>7,50€</td>

</tr>

<table>

<caption>Eintrittspreise fürs Kino</caption>
<tr>
	<td class=“keineDaten“></td>
	<th id=“spar“>Emäßigt</th>
	<th id=“normal“>Normaltarif</th>
</tr>
<tr>
	<th id =“Kinotag“>Kinotag</th>
	<td headers =  „Kinotag spar“>4,00€</td>
	<td headers =  „Kinotag normal“>6,00€</td>
</tr>`
<tr>
	<th id =“Sonntag“>Sonntag</th>
	<td headers =  „Sonntag spar“>5,50€</td>
	<td headers =  „Sonntag normal“>7,50€</td>
     </tr>

</table>

Prinzip Verständlichkeit

Informationen und Bedienung der Benutzerschnittstelle müssen verständlich sein

Richtlinie 3.1 Lesbar: Machen Sie Inhalt lesbar und verständlich.

Abkürzungen und Akronyme

  • Abkürzungen und Akronyme sollten mithilfe des <acronym>-Elements erklärt werden

Codebeispiel:

<p>

 Webseiten, die der <acronym title="Web Content Accessibility Guidelines" lang="en">
 <span lang="de">WCAG</span></acronym> 2.0 entsprechen sind barrierefrei</span>.

</p>

analoges Praxisbeispiel:

Webseiten, die der WCAG 2.0 entsprechen sind barrierefrei.

leichte Sprache

  • Es sollte eine Version mit sogenannter leichter Sprache angeboten werden, auf die sich die Webseite umstellen lässt (ähnlich wie bei i8n von Webseiten). Dabei sollte auf eine klare textliche Strukturierung, eine minimierung der Zeichen pro Zeile, ausreichend Zeilenabstand und die Wahl eines möglichst einfachen Wortschatzes geachtet werden. Auch die Navigation sollte ggf. in ihrer Komplexität reduziert und Navigationselemente umbeschriftet werden, sodass mit einem Klick alle wichtigen Seiten, die in einfacher Sprache angeboten werden, erreichbar sind. Darüber hinaus können erklärende Bilder die Verständlichkeit von Inhalten steigern.
  • Ein gutes Beispiel für leichte Sprache findet sich auf der Seite des Bundestages.

Prinzip Robustheit

Inhalte müssen robust genug sein, damit sie zuverlässig von einer großen Auswahl an Benutzeragenten einschließlich assistierender Techniken interpretiert werden können.

Screenreader-Interpretation

  • es sollte immer der Doctype und die Codierung angegeben werden, damit Screenreader Webseiten besser interpretieren können

Codebeispiele:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

  • es sollte immer die Sprache der Seiten angeben werden, damit Screenreader die richtige Aussprache benutzen können!
  • Bei englischsprachigen Worten / Anglizismen innerhalb eines deutschen Textes, sollte dieser entsprechend in einem SPAN gekennzeichnet werden.

Codebeispiele:

<html lang="de"> ... </html>

<span lang="en">Web Accessibility Initiative</span>.

BEISPIELE AUS ARIA

Im folgenden werden einige Aspekte zur barrierefreien Gestaltung von Webanwendungen genannt, die auf der technischen Spezifikation ARIA (Accessible Rich Internet Applications) basieren. Das Verhalten einer Webanwendung wird maßgeblich mit Hilfe von JavaScript definiert. Auch komplexe Navigationselemente, wie mehrere von einander abhängige Slider, Input-Felder mit Autovervollständigung oder integriereten Checkboxen, die die Navigation vereinfachen, werden durch JavaScript modelliert. Diese Elemente bringen für die Navigation mit Hilfe von Screenreadern einige Hürden mit sich. Widgets dieser Art sind selten per Tastatur nutzbar. Die Aufgabe des Widgets kann der Screenreader nicht interpretieren. Darüber hinaus sind Status und Eigenschaften des Widgets Nutzern assistiver Technologien nicht zugänglich. Und schließlich werden Aktualisierungen der JS-basierten Elemente den assistiven Technologien nicht mitgeteilt. Um die Interaktion mit den Widgets zu ermöglichen müssen diese mit Rollen versehen werden.

1. Landmark Roles

  • Durch ARIA können Bereiche definiert werden, die mithilfe von Assestiver Technik direkt annavigiert werden können. Diese Bereiche werden Landmark Roles genannt.Beispiele für Landmark Roles sind "application" (die gesamte Region, die als Webapp deklariert wird), "contentinfo" (Copyright, Datenschutzerklärung, z.B. im Footer), "banner" (Banner/Header), "form" (Eingabemaske), "navigation" (Navigation) oder "search" (Suchfeld), die Screenreader direkt ansteuern können.

Codebeispiele:

<header id="banner" role="banner"> ... </header>

<nav role="navigation"> ... </nav>

<article id="post" role="main"> ... </article>

<footer role="contentinfo"> ... </footer>

  • Weitere wichtige Rollen neben Landmark Roles sind Widget Roles. Diese können Navigationselementen, wie Slidern, Textboxen oder Scrollbars eine semantische Bedeutung zuordnen. Dadurch können Nutzer der assestiven Technik die Funktion der Widgets verstehen.

2. Einfache ARIA Attribute

  • Einfache ARIA Attribute werden genutzt, um Eigentschaften eines Elementes zu definieren, die assestive Technik interpretieren kann. Sö kann beispielsweise einem Eingabefeld das Attribut aria-required zugeordnet werden, das den Screenreader auf die Feldvalidierung hinweist.

3. Aria-Live Attribut

  • Wenn sich Inhalte auf dem Bildschirm aktualisieren, bekommt das der Screenreader meist nicht mit, beispielsweise, wenn die DOM-Manipulation im bereits vorgelesenen Bereich des Bildschirms stattfand. Änderungen in Regionen, die mit dem aria-live-Attribut gekennzeichnet werden, können bei implementiertem ARIA von Screenreadern automatisch erkannt und gesprochen werden. Dies gilt auch, wenn User gerade an anderer Stelle der Webseite ist.
  • Das Aria-Live-Attribut kann 3 verschiedene Zustände einnehmen: aria-live=[off/polite/assertive]
  • Meist wird die Eigenschaft "polite" genutzt, da hier Änderungen erst angesagt werden, wenn der User inaktiv ist.

4. Aria-Controls Attribut

  • Das Aria-Controls--Attribut verbindet ein Kontrollelement mit einer Region, die von ihm gesteuert wird: aria-controls=[IDLIST]
Add a custom footer
Add a custom sidebar

Clone this wiki locally