BARRIEREFREIHEIT IM FOKUS

ein Dutzend Beispiele für a11y

Insidrrr Day 3 / 27.04.2013📅

Jan Eric Hellbusch und Nicolai Schwarz👥

NOTIZEN

Dies ist die kommentierte Fassung der Session »Barrierefreiheit im Fokus«,

die ich zusammen mit Jan Eric Hellbusch beim Insidrrr Day 3 am 27. April 2013

gehalten habe. Diese Folien enthalten nur meinen Part: zwölf Beispiele aus der täglichen Arbeit, bei denen wir die Barrierefreiheit verbessern können.

Notizen-Seiten wie diese beziehen sich jeweils auf die folgenden Seiten.

Ein paar Abkürzungen:

WCAG = Web Content Accessibility Guidelines, 🔗 Wikpedia

ARIA = Accessible Rich Internet Applications, 🔗 Wikpedia

BITV = Barrierefreie-Informationstechnik-Verordnung, 🔗 Wikpedia

a11y = Kurzform für Accessibility (Barrierefreiheit), weil man 11 Zeichen auslässt

Wer alles genauer wissen will, kann sich das Buch » Barrierefreiheit verstehen und umsetzen« von Kerstin Probiesch und Jan Eric Hellbusch besorgen (🔗 dpunkt.verlag).

✒

»Barrierefreies Webdesign ist die Kunst, Webseiten so zu gestalten,dass jeder sie nutzen und lesen kann.« Jan Eric Hellbusch

Barrierefreiheit geht sehr häufig Hand in Handmit Usability oder Suchmaschinenoptimierung.

Barrierefreiheit und gutes Design widersprechen sich nicht!

Allerdings gibt es durchaus ein paar kleine Details,die Designer und/oder Frontendentwickler nerven können.

BARRIEREFREIHEIT IM FOKUS

ein Dutzend Beispiele für a11y

BILDER01

NOTIZEN

Alle Bilder benötigen ein alt-Attribut. Der Text wird Blinden durch den Screenreader vorgelesen; er erscheint, wenn das Bild nicht geladen werden kann; und er ist sinnvoll für die Suchmaschinenoptimierung. Bilder, die zum Inhalt gehören, erfordern einen alt-Text, der das Bild so gut wie möglich beschreibt. Bilder, die nur zum Design und nicht zum Inhalt beitragen, sollten einen leeren alt-Text bekommen.

Das weiß mittlerweile jeder – sollte man meinen. Trotzdem gibt es immer wieder Websites, auf denen kein alt-Text vergeben ist. Nutzer eines Screenreaders bekommen davon also nichts mit. Hier zum Beispiel vier Bilder in einem Buch-Shop.

✒

NOTIZEN

Neben dem alt- gibt es noch das title-Attribut. Während der alt-Text das Bild so gut wie möglich beschreiben soll, ist der title-Text für zusätzliche Informationen gedacht. Eine gute Aufteilung ist:

alt = Beschreibung des Bildes

title = Angaben zur Quelle / Fotograf / URL

Wichtig ist, nicht denselben Text doppelt zu vergeben. Er würde im Screenreader auch zweimal vorgelesen werden.

Einige (ältere) CMS füllen den title-Text automatisch mit dem Namen der Bilddatei. WordPress macht das heute noch. Das ist ebenso nicht hilfreich.

✒

BILDER01

alt="Angela Merkel"title="Foto:Armin Linnartz,Quelle: wikipedia.de"

BILDER01

NOTIZEN

Einen passenden alt-Text zu finden, ist eine Kunst für sich. Im Beispiel der vorherigen Seite reicht vielleicht tatsächlich »Angela Merkel«. In vielen Fällen lässt sich das Bild aber besser beschreiben. Ein reines »Angela Merkel« wäre für die folgenden Bilder zu wenig.

✒

NOTIZEN

Zusätzlich kommen auch noch Bildunterzeilen ins Spiel. In einigen Artikeln ist zu lesen, dass auf den alt-Text verzichtet werden kann, wenn eine Bildunterzeile vergeben ist. Das Problem dabei ist das HTML-Konstrukt für die Bildunterzeile. Kann ein Screen-reader Bild und Text tatsächlich einander zuordnen? Das alt-Attribut steht immerhin direkt beim Bild-Element. Außerdem kann es passieren, dass ein alt-Text sich deutlich von der Bildunterzeile unterscheidet – siehe das Beispiel von taz.de.

Nebenbei: Wie effektiv ist es, Bild und Bildunterzeile in HTML5 mit <figure> und <figcaption> auszuzeichnen? Für eine moderne Website ist das sicher passend, aber Screenreader können mit HTML5 noch nicht viel anfangen. Dort wird der Zusammenhang aktuell also nicht hergestellt.

✒

NOTIZEN

alt-Texte sollten kurz gehalten werden. Was aber machen wir z.B. mit Infografiken, die sich nicht in ein paar Wörtern erklären lassen? Für solche Fälle steht uns das Attribut longdesc zur Verfügung, das auf eine URL mit einer längeren Erläuterung verlinken kann. Je nach CMS und Einstellungen haben normale Autoren/Redakteure darauf vielleicht keinen Zugriff; hilfreich ist diese Option aber allemal.

Zur Verfügung stehen uns also:

· alt = Beschreibung des Bildes

· title = Angaben zur Quelle / Fotograf / URL

· Unterzeile = Redaktioneller Text, der sich deutlich vom alt-Text unterscheiden kann

· longdesc = URI zu einem längeren Text, um komplexe Grafiken zu erklären

✒

alttitle

caption/figcaption

longdesc (URI)

BILDER01

ÜBERSCHRIFTEN02

NOTIZEN

Überschriften sind eine ideale Möglichkeit, sich mit dem Screenreader einen schnellen Überblick über eine Website zu verschaffen. Dabei sollten die Überschriften aber deut-lich formuliert sein. Was verbirgt sich auf der folgenden Seite etwa hinter »Uruk« oder »Schiff«? Für Sehende sind die Inhalte leichter zu verstehen, weil im Slider neben der Überschrift noch weitere Informationen schnell erfasst werden können.

In manchen Fällen kann es hilfreich sein, zusätzliche Texte in einer Überschrift für Screenreader hinzuzufügen, aber optisch zu verstecken, etwa

<h2>Uruk <span class="visuallyhidden">(Ausstellung)</span></h2>

🔗 http://davidwalsh.name/html5-boilerplate

✒

NOTIZEN

In HTML5 ist es außerdem möglich, verschiedene <section> oder andere Bereiche einzusetzen, die jeweils neu mit einer <h1> beginnen. Browser können diese Überschrif-ten-Ordnung intern gut verarbeiten; dadurch kommen auch Screenreader damit klar.

Persönliche Meinung: Bei den meisten Sites sehe ich kein Hindernis, eine »ordentliche« hx-Struktur aufzubauen, die wir seit Jahren gewohnt sind. Oft reichen ja die Ordnungen h1 bis h4 für die gesamte Site aus.

Der einzige Grund jeweils bei h1 zu beginnen, wären recht große Websites oder aber kompliziert gebaute CMS, bei denen es schwieriger ist, die Überschriften-Struktur anzupassen.

✒

LINKS03

NOTIZEN

Links sollten nicht nur durch Farbe dargestellt werden. Wer eine Sehschwäche hat wird die Farbe allein evtl. nicht wahrnehmen. Deshalb sollten alle Links (im Fließtext) unter-strichen sein. Es wären auch andere Auszeichnungen (fett, kursiv, Icons) möglich, aber Unterstreichungen haben sich etabliert.

Ebenso sollte Linktext den Link so gut wie möglich beschreiben. Bei cdu.de zum Beispiel an »Lesen Sie die aktuelle Ausgabe des UNION Magazin!« zu sehen.

Bei der Gelegenheit gibt es immer wieder Diskussionen um den »mehr«- oder »Weiterlesen«-Link z.B. am Ende von Teasern. Wer hier mit dem Screenreader von Link zu Link durchtabbt kann mit den »mehr«-Linktexten nicht viel anfangen. Auch hier wären optisch versteckte Texte möglich. Allerdings erlaubt WCAG 2.0 auch Linktexte, die durch einen »programmatisch ermittelbaren Kontext« aussagekräftig werden.

🔗 http://www.bitvtest.de/infothek/artikel/lesen/aussagekraeftige-linktexte.html

✒

SCHRIFTGRÖSSEN04

NOTIZEN

Links auf der Website, die dazu dienen, die Schriftgröße zu verändern, sind heutzutage eigentlich nicht mehr nötig. Schließlich habe alle Browser seit längerem einen einge-bauten Seitenzoom.

Dieser Seitenzoom funktioniert aber nicht in allen Browsern gleich. Firefox berück-sichtigt aktuell z.B. responsive Elemente (Seite 30), Chrome vergrößert einfach nur (Seite 31).

Für die Barrierefreiheit reicht der Seitenzoom für die Stufe AA aus. Bei AAA hingegen ist kein waagerechter Scrollbalken mehr erlaubt. Wenn AAA angepeilt wird, dann sind Zoom-Layouts meist nicht mehr ausreichend. Es kommt also auf das konkrete Projekt an und nach welchem Maßstab die Barrierefreiheit geprüft wird. Beim BITV-Test etwa muss auch die reine Textvergrößerung bei 150% – bzw. »Schriftgrad am größten« im IE – erfüllt sein (entgegen WCAG 2.0, die von 200% spricht).

Für höhere Weihen in der Barrierefreiheit bilden Schriften auf Basis vom em weiterhin die beste Grundlage. Bei responsiven Websites kann es außerdem schwierig werden, in den flexiblen Übergängen zusätzlich den Text-Zoom zu berücksichtigen.

✒

FOCUS05

NOTIZEN

Tastaturnutzer sollten in der Lage sein, mit der Tab-Taste bequem durch eine Website zu tabben. Dabei springen sie von Link zu Link bzw. in einem Formular weiter. Die Website sollte optisch hervorheben, auf welchem Element gerade der Fokus liegt.

Tabbt man auf der aktuellen Website von insidrrr.de wird zunächst ein Sprunglink zum Inhalt eingeblendet (gut). Danach wandert der Fokus ins Menü, wovon ein Tasta-turnutzer aber nichts mitbekommt, weil der Menüpunkt optisch nicht hervorgehoben wird (schlecht). Erst ein paar Tabs später, erscheint aus dem Nichts plötzlich ein Unter-menüpunkt.

✒

NOTIZEN

Landet der Tastatur-Nutzer auf einem Link, wird dieser in der Regel von einer dünnen gepunkteten (dotted) Linie umrahmt. Das ist gut, weil hier wieder ein optisches Signal gegeben wird, wo sich der Fokus gerade befindet. Designer mögen diese Linie nicht un-bedingt und unterdrücken den Rahmen oft. In älteren CSS-Resets wird die Linie ebenso ausgeblendet.

Statt den Rahmen aber für alle Fälle zu unterdrücken, ist es geschickter, sich auf die Zustände :hover und :active zu beschränken.

🔗 http://webkrauts.de/artikel/2009/verliere-nicht-den-focus

✒

FOCUS05

Ältere CSS-Reset-Anweisungen enthalten noch:

/* remember to define focus styles! */:focus { outline: 0; }

FOCUS05

Prüfen, ob die Reset-Anweisungen sinnvoll sind

:focus { outline: none; }unterdrückt die Outline für alle User; sowohl beim Draufklicken mit der Maus als auch bei Nutzung der Tastatur

a:hover, a:active { outline: none; }unterdrückt die Outline beim Draufklicken mit der MausNutzer mit Tastatur sehen nun aber den fokussierten Link mit Outline

🔗 http://webkrauts.de/2009/12/11/verliere-nicht-den-focus

KLICKFLÄCHEN06

NOTIZEN

Für Klickflächen gibt es innerhalb der WCAG keine konkrete Forderung. Allerdings sollten diese Flächen allein schon aus Gründen der Usability groß genug sein. Das betrifft insbesondere Pager und kleine Icons. Wenn schon jemand mit normaler Beweglichkeit Probleme hat, die Klickflächen zu treffen, wie ergeht es dann erst jemandem mit einer motorischen Störung?

✒

FORMULARE07

NOTIZEN

Über Formulare könnte man sicher eine eigene Session halten. Wichtig ist erst ein-mal alle Felder mit einem entsprechenden <label> zu versehen. Das sollte ein CMS von sich aus liefern. Außerdem sollten Pflichtfelder gekennzeichnet werden. Die Frage ist, reicht ein Stern * dafür aus? Liefert das CMS nur diesen Stern, ist ein Text vor dem Formular sinnvoll, der erklärt, dass Sterne Pflichfelder kennzeichnen. Sinnfrei ist eine Angabe wie title="Diese Angabe wird benötigt." – denn diese liest ein Screenreader gar nicht vor.

Direkt »Pflichtfeld« zu notieren, ist die beste Lösung. Zusätzlich kann

aria-required="true"

angegeben werden.

✒

<label for="edit-email">E-Mail<span class="form-required" title="Diese Angabe wird benötigt.">*</span></label><input type="text" id="edit-email" name="email" value="" size="60"maxlength="60" class="form-text required" />

<label for="edit-email">E-Mail<span class="form-required">(Pflichtfeld)</span></label><input type="text" id="edit-email" name="email" value="" size="60"maxlength="60" class="form-text required" />

<label for="edit-email">E-Mail<span class="form-required">(Pflichtfeld)</span></label><input type="text" id="edit-email" name="email" value="" size="60"maxlength="60" class="form-text required" aria-required="true" />

NOTIZEN

Manche CMS/Plugins liefern immer noch ein Bild-Captcha, um Spam zu vermeiden. Diese Dinger sind sinnfrei. Entweder sie sind so einfach, dass auch Spambots sie lösen können. Oder sie sind so schwer, dass alle Nutzer damit Probleme haben. Und natürlich haben Sehbehinderte keine Chance, solch ein Captcha zu lösen.

Die richtige Lösung wäre entweder ein Honeypot oder aber ein Frage-Captcha.

· Ein Honeypot fügt ein Formularfeld hinzu, das sowohl vor sehenden Nutzern als auch vor Screenreadern verborgen wird. Spambots aber füllen dieses Feld aus, so dass Spam darüber ausgefiltert werden kann.

· Ein Frage-Captcha besteht aus einer simplen Frage plus Antwort. Etwa: »Welcher Tag folgt auf Montag?« Die Frage darf nicht zu schwer sein, denn Nutzer sollen ja nicht an der letzten Hürde beim Absenden scheitern (»An wieviele Länder grenzen Deutsch-land?«, »Wie hieß der erste Außenminister der BRD?«).

✒

KONTRASTMODUS08

NOTIZEN

Der Kontrastmodus nutzt alternative Farben, Schriftarten, Symbolgrößen, Abstände und Rahmen. Je nach Sehbehinderung kann das eine große Hilfe sein. Wichtig ist zu wissen, dass Hintergrundbilder und -farben im Kontrastmodus nicht dargestellt werden.

Das Beispiel zeigt meine Website textformer.de, die ich offensichtlich nie auf den Kontrastmodus getestet habe. Das Newsbild, das zum Start erscheint, sollte besser nicht als Hintergrundbild eingebaut werden (Screenreader bekommen an dieser Stelle echten Text vorgesetzt). Und bei der Navigation rächt es sich, wenn man sich irgendwann mal Image-Replacement-Techniken angeeignet (und nicht weiter darüber nachgedacht) hat.

✒

NOTIZEN

Im Gegensatz dazu ist pro-retina.de auf den Kontrastmodus vorbereitet. In der Naviga-tion kommt außerdem eine border-Technik zum Zuge, die den aktuellen Menüpunkt bzw. den :hover-Zustand mit einem zusätzlichen Rand hervorhebt.

🔗 http://webkrauts.de/artikel/2008/sonnenseiten-barrierefreiheit

✒

FEHLERMELDUNG09

NOTIZEN

Noch einmal ein Beispiel von pro-retina.de: Füllt jemand ein Formular nicht richtig aus, wird die Fehlermeldung auf der Seite ausgegeben. Das ist Standard. Auf der Web-site wird eine Fehlermeldung aber zusätzlich in den <title> der Seite geschrieben. Das hat den Vorteil, dass Screenreader-Nutzer nicht erst zum Inhalt springen müssen; der <title> wird Ihnen sofort vorgelesen, und sie bekommen den Fehler schneller mit.

✒

ARIA ROLES10

NOTIZEN

Mit den ARIA roles ist es möglich, Widgets und Inhalte einer Website inhaltlich genauer zu beschreiben. So kann ein Schieberegler etwa die Rolle role="slider" bekommen, was es assistiven Technologien ermöglicht, die Funktion zu verstehen.

🔗 http://www.hessendscher.de/wai-aria/

Dabei überschreibt die Rolle die ursprüngliche Funktion des Elements. Mit <p role="heading"> würde ein Absatz also als Überschrift fungieren, was nicht sinn-voll ist, schließlich gibt es bereits die hx-Elemente.

Beim aktuellen Stand können Screenreader mit HTML5-Elementen nichts anfangen, ARIA roles werden aber interpretiert. Daher ist die Angabe <nav role="navigation"> zwar inhaltlich doppelt, aber nötig.

Diese Rollen sollten nicht im Überfluss verteilt werden, sondern überlegt.

✒

ARIA ROLES10

<div id="header"><div id="footer"><ul id="nav">

ARIA ROLES10

<div id="header"><div id="footer"><ul id="nav">

<header><footer><nav>

ARIA ROLES10

<div id="header"><div id="footer"><ul id="nav">

<header><footer><nav>

<header role="banner"><footer role="contentinfo"><footer role="complementary"><nav role="navigation">

ARIA ROLES10

Abstract Roles – Abstract roles are used for the ontology. Authors MUST NOT not use abstract roles in content.

Widget Roles – These roles act as standalone user interface widgets or as part of larger, composite widgets. dialog / progressbar / slider / status

Document Structure – These roles describe structures that organize content in a page. Document structures are not usually interactive.article / columnheader / definition / directory / document

Landmark Roles – These roles are regions of the page intended asnavigational landmarks. contentinfo / form / main / navigation / search

FARBKONTRASTE11

NOTIZEN

Als Designer muss ich feststellen: Farbkontraste (im Sinne der Barrierefreiheit) nerven. Natürlich lege ich an den wichtigen Stellen Wert auf einen deutlichen Kontrast. In manchen Fällen finde ich einen geringen Kontrast allerdings hübscher/passender/ausreichend. In meinem Fall sind meine Augen und meine Monitore aber auch ganz gut. Ich kann schließlich alles erkennen, was ich mir zusammenbaue.

Für die Barrierefreiheit muss ich manchmal einen höheren Kontrast wählen als ich es gerne hätte. So wird aus einem helleren vielleicht ein dunkleres Grau. Das stört mich als Designer, aber natürlich kommt es allen Nutzern zugute, wenn der Kontrast höher ist.

Für Text auf Hintergrund gibt es feste Kontrastwerte, die erreicht werden müssen. Zum Testen gibt es verschiedene Tools, zum Beispiel den Colour Contrast Check unter 🔗 http://snook.ca/technical/colour_contrast/colour.html.

Deutliche Kontraste sollten auch für :hover- und :focus-Zustände gewählt werden.

✒

FARBKONTRASTE11

»Das W3C macht da mit der WCAG 2.0 (Web Content Accessibility Guidelines 2.0) klare Vorgaben. Der Kontrast zwischen Text im Vordergrund und seiner Hintergrundfarbe sollte bei einer Textgröße kleiner 18px (ohne Fettschrift) und kleiner 14px (fett geschrieben) ein Verhältnis 4,5:1 aufweisen, kleiner 18px (nicht fett geschrieben) und größer 18px (bei Fettschrift) noch 3:1, um die AA Spezifikationen zu erfüllen. Für die AAA-Spezifikation beträgt die Ratio sogar 7:1 bzw. 4,5:1 (A, AA und AAA sind die Stufen der Konformität, mit denen die Zu-gänglichkeit einer Internetseite vom W3C bewertet wird). Text über gemustertem Hintergrund oder Bildern sollte dementsprechend höher kontrastiert werden. Texte und Schriften als Teil eines Logos oder mit rein dekorativem Charakter hingegen sind von diesen Bestimmungen ausgenommen.«🔗 http://webkrauts.de/2009/08/05/kontrastreiche-farbwelten

EXTRAS12

NOTIZEN

Während viele Techniken zur Barrierefreiheit problemlos auf den meisten Websites umgesetzt werden können, gibt es einige Elemente, die eher selten umgesetzt werden.

Leichte Sprache ist zum Beispiel sinnvoll für Hörgeschädigte, Gehörlose, Menschen mit geistiger Behinderung, Analphabeten, Migranten und Touristen mit wenig Kompetenz in der deutschen Sprache. Die Texte werden nach bestimmten Grundsätzen geschrieben, etwa: Es werden kurze Sätze verwendet. Oder jeder Satz enthält nur eine Aussage. Auf Websites kommen solche Texte dennoch eher selten zum Einsatz.

🔗 http://de.wikipedia.org/wiki/Leichte_Sprache

Ebenso ist es oft nicht möglich, Videos zusätzlich mit Gebärdensprache zu versehen oder Videos und Audiodateien zu transkribieren.

✒

BARRIEREFREIHEIT IM FOKUS

ein Dutzend Beispiele für a11y

Soweit zu den Beispielen✓

Und nun: die Screenreader-Demonstration📣

KONTAKT

Jan Eric Hellbusch

@2bweb

🔗 barrierefreies-webdesign.de

· Sachbuchautor

· Delegierter des DVBS im Fach- ausschuss für Informations- und Telekommunikationssysteme der Blinden- und Sehbehindertenverbände Deutschlands

· Leiter des AK Homepage der Pro Retina

Nicolai Schwarz

@textformer

🔗 textformer.de

· freier Designer und Webentwickler aus Dortmund

· Autor für t3n

· Redakteur bei der Screenguide

· Redakteur bei webkrauts.de

· Dozent für Webdesign

CREDITS

Bildnachweise

· Titel und Kapitelbilder stammen von 🔗 http://sxc.hu.

· Das Merkel-Bild auf den Seiten 7 und 8 kommt von 🔗 Wikpedia.

· Die anderen Merkel-Bilder stammen von commons.wikimedia.org und flickr.com.

Genutzte Fonts

· Neuton – 🔗 http://www.dafont.com/neuton.font

· SciFly – 🔗 http://www.dafont.com/scifly.font

· Icons: Entypo – 🔗 http://www.entypo.com/