Hinweis: Am 9. April beteiligen wir uns auf webkrauts.de am Naked CSS Day. Die Stylesheets sind an diesem Tag absichtlich abgeschaltet.

Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Accessibility im Sinn

Kleine Änderungen, große Wirkung

Accessibility im Sinn

Barrierefreiheit wird oft als zusätzliche Arbeit und schwer zu lernen beschrieben. Und überhaupt sei nur eine kleine Anzahl von Menschen betroffen. Diese Mythen haben keine logische Grundlage und sind das Ergebnis von veralteten Informationen oder Missverständnissen.

Tatsächlich geht es um zusätzliches Wissen, das sich Webworker aneignen müssen, ganz ähnlich wie das Lernen neuer JavaScript-Frameworks, CSS-Layout-Techniken oder neuer HTML-Elemente. Aber Barrierefreiheitstechniken sind nicht schwerer zu erlernen als diese anderen Fähigkeiten.

Im Bericht der Weltgesundheitsorganisation (WHO) bezüglich Behinderungen, heißt es:

Inklusive Kinder leben geschätzt über eine Milliarde Menschen (oder rund 15% der Weltbevölkerung) mit einer Behinderung.

Behinderung ist also nicht so ungewöhnlich, wie es empfunden wird. Angesichts chronischer Erkrankungen und dem erhöhten Risiko für ältere Menschen, eine Behinderung zu erwerben, bauen Webentwickler jetzt das Internet, das sie in der Zukunft selbst verwenden wollen.

Accessibility hat eine sehr enge Beziehung zu Usability und Fortschritte bei der Zugänglichkeit verbessern oft die Benutzerfreundlichkeit eines Webprojekts. Nutzer können auf zugängliche Art und Weise aufgebaute Websites auch an die eigenen Bedürfnisse anpassen.

Jenseits des bloßen Minimums

In den Zeiten von Tabellen-Layouts konnten Webentwickler Code schreiben, der die Validierungsregeln passierte, der aber nicht auf das semantische Modell von HTML aufsetzte. Erst später wurden Best Practices entwickelt, wie die Verwendung von Listen für die Navigation, und mit HTML5 wurden diese Listen in nav-Elemente eingeschachtelt. Das Arbeiten mit Accessibility-Standards ist ähnlich: Die Web Content Accessibility Guidelines (WCAG) 2.0 können helfen, Websites barrierefrei umzusetzen. Und sie erlauben uns, eine Aussage darüber zu treffen, ob eine Website zugänglich ist oder nicht, indem die Erfolgskriterien erfüllt werden. Mit WCAG 2.0 kann jedoch nicht gemessen werden, wie gut die Erfolgskriterien erfüllt werden. Das Projekt-Team muss sich bereits in der Konzeptionsphase für die besten Techniken entscheiden.

Das W3C entwickelt (und aktualisiert) eine lange Liste von Techniken, die zur Erfüllung der Erfolgskriterien verwendet werden können, aber es gibt Situationen, in der diese Techniken an die eigenen Bedürfnisse im Projekt angepasst werden müssen.

Checkbox-Beispiel

Das Kontrollkästchen im folgenden Video ist generell in zugänglicher Weise umgesetzt: Das input-Element hat eine ID, und dem Kontrollkästchen ist ein label zugeordnet. Es bezieht sich auf das input-Element über das for-Attribut. Der Hover-Bereich wird im Folgenden mit einem gelben Hintergrund und einem schwarzen gepunkteten Rahmen dargestellt:

Das Label ist klickbar, das Kontrollkästchen hat eine zugängliche Beschreibung. Fertig, nicht wahr?! Nicht wirklich. Der Raum zwischen dem Label und dem Kontrollkästchen kann nicht angeklickt werden:

Der Zwischenraum zwischen Kontrollkästchen und Label entsteht durch einen margin, der das Label nach rechts schiebt. Anwender erwarten jedoch sicherlich, dass auch dieser Zwischenraum anklickbar ist. Die einfache Lösung ist, mit dem Label das Kontrollkästchen und den Text zu umschließen:

Dann kann der anklickbare Bereich auch gleich durch die Verwendung von display: block; vergrößert werden:

Und wo wir gerade dabei sind, könnten Nutzer erwarten, dass der ganze grau hinterlegte Bereich angeklickt werden kann. Das ist relativ einfach zu erreichen, indem die Styles statt auf ein umgebendes div direkt auf das Label angewendet werden:

Das Endergebnis verbessert die Benutzerfreundlichkeit des Formularelements enorm für Menschen mit motorischen Einschränkungen, mit einer Stimmeingabe, bei Mausbenutzung und bei Verwendung von Touchscreens. Für diese Verbesserung wird kein JavaScript und keine zusätzliche Zeile CSS benötigt. Und ein Container-Div wird auch noch eingespart.

  1. <form action="#">
  2.   <label for="uniquecheckboxid">
  3.     <input type="checkbox" name="checkbox" id="uniquecheckboxid" />
  4.     Checkbox
  5.   </label>
  6. </form>

Button-Beispiel

Die unten stehende Schaltfläche sieht aus wie ein typischer Bearbeiten-Button: Ein Stiftsymbol auf einem echten button-Element. Aber wenn ein Screenreader oder eine Braille-Tastatur zum Einsatz kommt, dann wird einfach nur »Button« ausgegeben, ohne Angabe, wozu er gut ist.

Das Code-Snippet zeigt, warum der Button nicht richtig ausgegeben werden kann:

  1. <button>
  2.   <span class="icon icon-pencil"></span>
  3. </button>

Das Symbol wird mittels Icon-Font angezeigt und es gibt keine Textalternative. Eine mögliche Lösung für dieses Problem wäre die Verwendung des title- oder des aria-label-Attributes, wodurch der Titel z.B. für Screenreader-Nutzer zugänglich ist:

Allerdings ist sind Screenreader nicht die einzige Art, wie Menschen mit Behinderung mit Websites interagieren. Das Einstellen eigener Schriftarten und -größen hilft vielen Nutzern, Webseiten leichter zu verstehen, beispielsweise Menschen mit Legasthenie, Menschen mit Sehbehinderung sowie älteren Nutzern. Der Icon-Font könnte also durch eine andere Schrift ersetzt werden; mit der Auswirkung, dass statt der gewünschten Icons andere oder sogar keine Zeichen zu sehen sind. Zusätzlich wird der Icon-Font möglicherweise nicht geladen, z.B. bei einer langsame Verbindung. Oder Nutzer entscheiden, externe Schriftarten ganz zu blockieren, um Ladezeit und Datenvolumen zu sparen. Die folgenden Screenshots zeigen die mobile GitHub-Seite mit und ohne externen Schriftarten:

Auf der Version ohne externe Schriftarten sind keine Icons zu sehen, auch das Menü-Icon fehlt gänzlich.
Auf der Version ohne externe Schriftarten sind keine Icons zu sehen, auch das Menü-Icon fehlt gänzlich.

Selbst wenn der title/aria-label-Ansatz verwendet worden wäre, bedeutet der Mangel an sichtbaren Buttons eine Barriere für die meisten Menschen. Eine Möglichkeit, dies zu umgehen, ist das »altmodische« img-Element mit einem geeigneten alt-Attribut zu verwenden. Überraschenderweise zeigt jedoch nicht jeder Browser den alternativen Text an, wenn das Bild nicht geladen werden kann.

  1. <button>
  2.   <img src="icon-pencil.svg" alt="Edit">
  3. </button>

Die Benutzung von ständig sichtbarem Text auf dem Button stellt sicher, dass Nutzer eine nützliche Textalternative erhalten, auch wenn das Bild nicht geladen werden kann. Es bietet sich aber natürlich nur dann an, wenn genug Raum für die Beschreibungen verfügbar ist.

  1. <button>
  2.   <span class="icon icon-pencil"></span> Edit
  3. </button>

Auch das Vorlesen des Buttons in Screenreadern funktioniert damit:

Clevere Verbesserungen der Benutzerfreundlichkeit sind aber nicht nur technische Aspekte: Wenn ein Nutzer auf den Seiten der BBC durch die Mediathek navigiert und die Kategorien »Untertitelte Videos« oder »Audiodeskription« auswählt, dann werden beim Abspielen von Videos, Untertitel oder Audio-Beschreibungen automatisch eingeschaltet. Kleine Dinge wie diese erhöhen die Benutzerfreundlichkeit, sind aber in der Umsetzung vergleichsweise wenig aufwändig. Es geht vielmehr darum, die Zusammenhänge zwischen der Website und der Benutzung durch Menschen mit Behinderungen zu erkennen. Mehr zur BBC-iPlayer-Accessibility-Fallstudie.

Mehr Informationen

Beim W3C gibt es mehrere Dokumente, die einen Überblick zum Thema Barrierefreiheit geben und beschreiben, wie Accessibility allen zugute kommt.

  • How People with Disabilities Use the Web enthält eine Übersicht über verschiedene Arten von Behinderungen und mit welchen Hilfsmitteln das Internet benutzt werden kann.
  • Tips for Getting Started with Web Accessibility bietet kurze einfache Tipps für Entwickler, Designer und Content-Autoren.
  • Und für den erfahreneren Entwickler gibt es eine Reihe von Tutorials über Barrierefreiheit im Web, einschließlich Informationen über das Erstellen von zugänglichen Formularen und der Information, wie Webworker Bilder zugänglich in Websites einbindet. Auch ein Beispiel für ein barrierefreies Karussell findet sich dort.

Fazit

Webprojekte mit langfristiger Barrierefreiheit können nur gelingen, wenn Accessibility kein Nachgedanke ist. Für Organisationen, Abteilungen und Teams muss Accessibility eines der Fundamente eines erfolgreichen Webprojekts werden und in der gleichen Liga spielen wie Performance, Code-Qualität und Design. Nutzer bemerken es oft nicht, wenn diese grundlegenden Aspekte guter Website-Designs und -Entwicklung richtig berücksichtigt wurden. Aber sie werden immer merken, wenn sie schlecht umgesetzt sind.

Wenn Accessibility selbstverständlich dazugehört, dann können neue Lösungen auf der Grundlage verfügbarer Daten geschaffen werden. Davon profitieren auch Menschen, die gar nicht wussten, dass sie Accessibility brauchen:

In diesem Video von der letzten Apple-Keynote wird Apple TV durch Spracheingabe über eine Fernbedienung gesteuert. Wenn der Nutzer fragt, was die Person im Film gesagt hat (»What did she say?«), wird das Video 15 Sekunden zurückgespult und Untertitel werden für eine kurze Zeit eingeschaltet. Alle drei Technologien, die Fernbedienung, die Spracheingabe und Untertitel haben ihre Wurzeln in der Unterstützung von Menschen mit Behinderungen. Jetzt profitieren alle davon.

Anmerkung der Redaktion

Dieser Artikel ist die deutsche Version von Erics Beitrag für die Seite 24ways. Der Adventskalender dort bietet noch viele weitere interessante Beiträge, alle in englischer Sprache.

Kommentare

Enrico Reinsdorf
am 17.12.2015 - 08:43

Hallo zusammen,

meiner Erfahrung nach ist es oft der Kunde der bei knappen Budget die Zugänglichkeit vernachlässigen möchte und nicht unbedingt der Webworker.

Mir ist schon klar, dass der Mehraufwand der Zugänglichkeit einfach in die Kalkulation mit eingerechnet werden sollte, allerdings wäre zu berücksichtigen, dass man manchmal vielleicht aus Budgetgründen nur ein fertiges Template nutzt und dann die Zugänglichkeit oben drauf setzen müsste.

Oder um bei den Icon-Fonts vs. Bild-Icons zu bleiben -- hier muss dann aus der Schrift erst wieder Bilder erzeugt werden, die dann wiederum jedes einzeln für sich ein Server-Request erzeugt. Dies kann man als Gegenargument für die Performance gebracht werden. Denn die Bild-Icons in einem Bild zusammenzufassen bringt ja in dem Fall nichts, wenn sie im IMG-Tag benutzt werden sollen.

Ich persönlich bin auch ein Befürworter von Usability und Accessibility und würde mich freuen wenn alle Projektbeteiligten diese Aspekte mehr in den Vordergrund stellen würden :-D

Permanenter Link

Gunnar Bittersmann
am 17.12.2015 - 22:34

meiner Erfahrung nach ist es oft der Kunde der bei knappen Budget die Zugänglichkeit vernachlässigen möchte und nicht unbedingt der Webworker.

Zum einen finde ich Webseitenentwicklung nach dem Motto „Ey, du bist behindert, du kommst hier net rein“ ganz einfach menschenverachtend. Geld sollte kein Grund sein, jemanden von der Nutzung des Webs auszuschließen. “When we work on making our devices accessible by the blind I don’t consider the bloody ROI” —Tim Cook, CEO Apple

Zum anderen ist es nicht so, dass Barrierefreiheit zwangsläufig enorme Ressourcen verschlingt. Das Web ist von Natur aus barrierefrei – solange man dem nicht mit schlechtem HTML, CSS oder JavaScript entgegenwirkt. Es geht darum, die Barrierefreiheit zu erhalten; und das liegt doch in den Händen des Webentwicklers. Es sollte zum Grundlagenwissen eines jeden Webentwicklers gehören, was man tun und was man lassen muss. Wann immer man bspw. im Stylesheet :hover schreibt auch an :focus zu denken, sollte selbstverständlich sein und kostet auch nichts extra.

dass man manchmal vielleicht aus Budgetgründen nur ein fertiges Template nutzt und dann die Zugänglichkeit oben drauf setzen müsste.

Barrierefreiheit oben drauf zu setzen ist wohl wirklich mit enormem Aufwand verbunden. Besser, man nimmt sie gar nicht erst weg. Wenn ein fertiges Template <div onclick="…"> statt <button> verwendet, sollte man dieses vielleicht gar nicht erst einsetzen, sondern sich gleich nach einem besseren umsehen.

Oder um bei den Icon-Fonts vs. Bild-Icons zu bleiben -- hier muss dann aus der Schrift erst wieder Bilder erzeugt werden, die dann wiederum jedes einzeln für sich ein Server-Request erzeugt. Dies kann man als Gegenargument für die Performance gebracht werden.

Nicht wirklich. Icons sollten i.a.R. keine Pixelgrafiken sein, sondern Vektorgrafiken. Und wenn man alle Icons als <symbol>s in einer SVG-Datei hat, braucht man dafür auch nur einen Request.

Permanenter Link

Christoph Freyer
am 17.12.2015 - 11:38

Ein guter Artikel, der anregt seine Arbeitsweise zu überdenken. Oft sind es ja nur ein paar Kleinigkeiten die es braucht um eine Website zugänglicher zu machen. Leider ist, wie Enrico es bereits angemerkt hat, oft nicht das Budget vorhanden um eine vernünftige Zugänglichkeit zu realisieren. Ich glaube trotzdem, dass unsere Seiten in dieser Beziehung laufend besser werden. Seit dem semantischen Einsatz von HTML5 ist ein Mindestmaß garantiert. Ebenso hat gerade durch die Anpassung an mobiles auch ein Umdenkprozess begonnen: was brauch ich wirklich? wie ist es zu bedienen? Mit Hinweisen wie in diesem Artikel werden Stolperfallen aufgedeckt. Lasst uns doch unsere Arbeitsweise so überdenken ob man nicht bereits durch die Struktur den Großteil der Usability und Accessibility erreichen kann.

Permanenter Link

Gunnar Bittersmann
am 18.12.2015 - 20:54

Die einfache Lösung ist, mit dem Label das Kontrollkästchen und den Text zu umschließen

Ich finde es merkwürdig, input in label zu schachteln. Schließlich ist ein Eingabefeld ja kein Bestandteil seiner Beschriftung.

Auch dann wird man die Beschriftung (nicht zuletzt zu Zwecke des Stylens) in ein eigenes Element tun wollen:

  1. <label>
  2.   <input type="checkbox" name="myCheckbox"/>
  3.   <span>pick me!</span>
  4. </label>

Gegenüber

  1. <span>
  2.   <input type="checkbox" name="myCheckbox" id="myCheckbox"/>
  3.   <label for="myCheckbox">pick me!</label>
  4. </span>

dieselbe Anzahl von Elementen.

(Im ersten Fall bräuchte man keine ID fürs Eingabefeld – jedenfalls nicht für die Zuornung der Beschriftung. Aber womöglich braucht man doch eine für andere Zwecke. ;-))

Ein Beschriftung und Eingabefeld gruppierendes Element ist durchaus vernünftig. Aber sollte dieses das label-Element sein?

Permanenter Link

Die Kommentare sind geschlossen.