Usability im Schatten der Accessibility

Vor fast 15 Jahren habe ich auf dem Portal Barrierekompass den Artikel „Accessibility im Schatten der Usabiltiy“ verfasst. 2004 stand das Thema Accessibility noch sehr im Schatten von Usability – weit gehend bedeutungslos. Schon damals ist der Artikel der Frage nachgegangen, ob Barrierefreiheit auch grundsätzlich die Benutzbarkeit verbessert. Heute würden die meisten Accessibility- und Usabiltiy-Experten die Frage vermutlich reflexartig mit Ja beantworten. Aber ist das wirklich so? Zahlt Barrierefreiheit auf die Usabiltiy-Kasse ein?

Accessibility, Barrierefreiheit, BITV, WCAG oder Universal Design?

Wenn es um das Thema Barrierefreiheit geht, werden viele Begriffe in einen Topf geworfen. Aber ist tatsächlich immer das Gleiche gemeint, wenn von Accessibility, Barrierefreiheit, Barrierearmut, Zugänglichkeit, Inclusive Design, Design für alle, Universal Design oder WCAG- und BITV-Konformität die Rede ist? Und was ist mit der EU-Richtlinie 2102 und der EN 301 549?

Wir versuchen mal Licht ins Dunkel zu bringen. Ehrlicherweise muss man sagen, dass Barrierefreiheit nicht nur in Deutschland nach verordneten Richtlinien umgesetzt wird. In Deutschland war und ist das die BITV (Barrierefreie Informationstechnologie Verordnung). Im internationalen Kontext sind das die WCAG (Web Content Accessibility Guidelines), die von Landesgesetzen durchgesetzt werden. Zum Beispiel durch den Americans with Disabilities Act (ADA), der Section 508 (www.section508.gov), dem Canadians with Disabilities Act (CDA) oder dem Australian Disability Discrimination Act, um nur einige zu nennen. Gerade in den USA kommt es regelmäßig zu juristischen Klagen aufgrund von Verstößen gegen die gesetzlichen Vorgaben.

Auch die BITV liegt den internationalen WCAG zugrunde. Ab Ende 2018 rückt die BITV mit der Umsetzung der EU-Richtlinie 2102 dann noch mal deutlich näher an die WCAG. Wenn von Barrierefreiheit oder Accessibility die Rede ist, dann gelten nur diese Richtlinien – zumindest als Mindestmaß für Barrierefreiheit. Alles was über die Richtlinie hinausgeht, darf sich selbstverständlich auch barrierefrei nennen. Barrierearmut, Zugänglichkeit, Inclusive Design, Design für alle oder auch Universal Design sind de facto Etiketten ohne verbindlichen Rahmen.

Usability und Accessibility – zwei Seiten der gleichen Medaille?

Long story short: Accessibility und Usability haben auf dieser Basis relativ wenig miteinander gemein. Zumindest wenn man es aus dem Blickwinkel der richtlinienkonformen Barrierefreiheit betrachtet. Das hat ganz einfache Gründe: die WCAG-Richtlinien enthalten explizit nur Kriterien für Menschen mit Behinderung. Darüber hinaus berücksichtigen die WCAG-Richtlinien für Barrierefreiheit nicht alle Kriterien sämtlicher Behinderungsformen in gleicher Verteilung. Es ist ein offenes Geheimnis, dass die WCAG-Richtlinien manche Behinderungsarten mehr bedienen, als andere. Allgemeine Barrieren, die alle Menschen gleich betreffen, sind in den offiziellen Richtlinien gar nicht enthalten.
In ihrer Einleitung zur Erläuterung der Techniken liefert das W3C (World Wide Web Consortium) auch die entsprechende Erklärung dazu:

„Es gibt viele grundsätzliche Usability-Richtlinien die Content für alle Menschen besser nutzbar machen, inklusive Menschen mit Behinderung. Wie dem auch sei, in den WCAG 2.0 werden nur solche Richtlinien aufgenommen, die explizit Probleme von Menschen mit Behinderung adressieren“.

Das zeigt ganz deutlich, Usability und Accessibility sind nicht zwei Seiten der gleichen Medaille. Accessibility hat mit Usability aus Sicht der Richtlinien-Konformität wenig, bis nichts zu tun.

Usability-Fail und dennoch WCAG-Konform

Es gibt viele Beispiele für die Diskrepanz zwischen Barrierefreiheit und Usability. Wenn eine Internetseite eine Downloadgröße von 100 Megabyte hat, dann ist das keine Barriere oder besser gesagt kein Verstoß gegen die Richtlinien im Sinne der WCAG (und BITV). Und das obwohl lange Ladezeiten gerade für Screenreader-Nutzer extrem problematisch sein können, weil Screenreader Inhalte erst dann vorlesen, wenn eine Seite vollständig gerendert ist.

Ein Beispiel einer schlecht lesbaren Schrift und Denglisch.

Wenn Sie Sütterlinschrift verwenden, dann ist das im Sinne der WCAG ebenfalls kein Problem. In den WCAG ist eine gut lesbare Schrift lediglich eine Empfehlung. Trotz der ganz offensichtlichen Usability-Probleme und Barrieren, die eine nicht lesbare Schrift verursachen. Sie sehen, ein Internetauftritt kann richtlinienkonform sein und trotzdem massive (Usabiltiy-)Barrieren aufweisen. Das zeigt auch das folgende Beispiel: Wenn Sie im Design ein grafisches Funktionselemente ohne sichtbaren Text verwenden, dann ist es nach den WCAG-Richtlinien egal, ob die Bedeutung der Grafik in Bezug auf die Funktion der Allgemeinheit bekannt ist oder nicht. Sie könnten sogar eine Toilettenschüssel als Mobilmenü-Button verwenden, weil es einfach keine WCAG-Richtlinie gibt, die das verbieten würde – solange das HTML inklusive erweiterter ARIA-Attribute korrekt ist. Die Toilettenschüssel als Mobilmenü-Button wird jeden Konformitätstest (egal ob BITV-Test oder WCAG-Test) bestehen (müssen). Auch für einen Minimum-Schriftgröße gibt es keine Richtlinien, weil das eben nicht nur behinderte Menschen tangieren würde, sondern alle Menschen. Eine gerenderte 2 Pixel kleine Schrift würde in Bezug auf Accessibility nach BITV und WCAG keinerlei Abzüge bekommen – eben weil die WCAG solche Failures fälschlicherweise in den Bereich Usability verorten.

Der Fachbereich Computer Science der University of York hat in einer Studie herausgefunden, dass fast 50 Prozent der Barrieren, auf die die blinden Studien-Teilnehmer gestoßen sind, von den WCAG-Richtlinien gar nicht erfasst werden (https://goo.gl/3cNFCR). So hatten die blinden Probanden beispielsweise große Probleme mit Inhalten auf Seiten, wo er nicht erwartet wurde sowie mit fehlendem Inhalt auf Seiten, wo er erwartet wurde. Die Probanden berichteten auch von Problemen durch zu langen Ladezeiten, komplexer Informationsarchitektur oder einfach nur durch kaputte Links. Alles Usability-Fails, die im Sinne der Barrierefreiheit nach den Richtlinien keine Abzüge bedeuten würden.

WCAG, BITV und besondere Schwerpunkte

Es gibt Experten, wie Joe Clark, die behaupten, dass die WCAG sich stark auf Aspekte konzentrieren, die durch technische Prüftools erfassbar und bewertbar sind. Wie dem auch sei, klar ist, wenn von Barrierefreiheit im Internet die Rede ist, geht es weitgehend um blinde und stark sehbehinderte Menschen. In den Erläuterungen der BITV 1.0 bezogen sich beispielsweise nur zwei der insgesamt 28 Anforderungen überhaupt auf Hörbehinderungen.

Hier ist die Tastatur schwer zu erkennen, sie ist aber richtlinienkonform.

Viele Prüfschritte gelten nach den Richtlinien als erfüllt, auch wenn sie einzelne Zielgruppen ignorieren – zum Beispiel sehende Tastaturnutzer. Nehmen Sie den Prüfschritt „2.4.1 – Bereiche überspringbar machen“: so genannte Skip-Links (Übersprung-Links direkt zur Suche, direkt zum Inhalt, direkt zum Footer, etc.) helfen allen Menschen, die auf Tastaturnutzung angewiesen sind, um Seiten-Bereiche zu überspringen. Der Prüfschritt gilt aber auch als erfüllt, wenn Sie mit unsichtbaren HTML5 Seitenstruktur-Elementen, ARIA-Landmark-Roles und strukturierenden Bereichsüberschriften arbeiten. Das sind alles Elemente, die für blinde Menschen, die einen Screenreader verwenden, extrem hilfreich sind. Ein normal sehender Tastaturnutzer hat davon aber nichts. Es sei denn der Tastaturnutzer weiß tatsächlich, was Landmarks sind und besorgt sich die Browser-Erweiterung für Google Chrome von Matthew Tylee Atkinson, mit der auch sehende Nutzer in den Genuss dieser Technik kommen. Ein sehr unwahrscheinliches Szenario.

Oder nehmen Sie beispielsweise das Title-Attribut. Das title-Attribut wurde vor 20 Jahren eingeführt und ist als „Tooltipp“ für Zusatzinformationen auf Links oder Buttons gut etabliert. Mit sinnvollen Tooltipps kann die Usability für Desktop-Nutzer deutlich verbessert werden. Und das sind auch heute noch vermutlich 50 Prozent aller Nutzer. Leider funktioniert die Tooltipp-Technik für einige Nutzergruppen nicht. So haben nur der Internet Explorer 10+ und Edge die Möglichkeit der Anzeige des Titelattributs für Tastaturnutzer implementiert. Auch Nutzer von Bildschirmlupen, Screenreadern oder Menschen mit motorischen und kongnitiven Einschränkungen können Probleme mit dem title-Attribut haben. Beim W3C wird deshalb mittlerweile davon abgeraten, sich auf das Title-Attribut zu verlassen (https://www.w3.org/TR/html/dom.html#the-title-attribute).

Soweit lassen sich die Argumente nachvollziehen. Aber was bedeutet das für den Prüfschritt „2.4.4 – Aussagekräftige Linktexte“ in den WCAG? Nach den Richtlinien dürfen Sie sich nicht alleine auf das Title-Attribut verlassen, um für einen aussagekräftigen Linktext zu sorgen. Mit dem Aria-label-Attribut hingegen ist der Prüfschritt erfüllt. Alle Desktop-Nutzer (ohne Screenreader) haben das Nachsehen. Menschen mit motorischen und kongnitiven Einschränkungen bekommen auch keinen Ersatz, genauso wenig, wie Nutzer von Touch-Devices (Smartphones und Tablets). Im Sinne der Usability würde man vermutlich nach einer Lösung suchen, die einen Tooltipp für alle Menschen gleichermaßen ermöglicht. Die Richtlinien für Barrierefreiheit legen ihren Fokus auch für diesen Prüfschritt ganz klar auf Screenreader-Nutzer.

Eine echte Barriere: Link- und Funktionswüste im Footer.

Usability verbessert die Accessibility – aber nicht umgekehrt.

Ob es sich nun um eine ausreichend große Basisschrift, erhöhte Zeilenabstände, gut lesbare Schriftarten, optimierte Ladezeiten, eine einfache und verständliche Sprache oder einfach ein klares User Interface Design handelt – Usability verbessert damit die Zugänglichkeit.

Usability-Regeln für Internetauftritte und webbasierte Applikation beziehen alle Menschen mit ein. Sie wenden sich nicht explizit an Menschen mit Behinderung und berücksichtigen in der Regel keine spezifischen Bedürfnisse, die sich durch verschiedene Behinderungsarten ergeben können. Trotzdem verbessern grundsätzliche Usability-Regeln die Zugänglichkeit – gerade weil Sie in den offiziellen Prüfschritten der WCAG-Richtlinien (und auch in der BITV) ausgeklammert werden. Ob es sich nun um eine ausreichend große Basisschrift, erhöhte Zeilenabstände, gut lesbare Schriftarten, optimierte Ladezeiten, eine einfache und verständliche Sprache oder einfach ein klares User Interface Design handelt – Usability verbessert damit die Zugänglichkeit.

Auch Optimierungen, beispielsweise durch Niehaus-Wireframing oder Heatmaps, zahlen auf die Kasse der verbesserten Zugänglichkeit ein. Denn durch die Gewichtung von Inhalten und der deutlichen Unterscheidung von „wichtig und unwichtig“ wird vielen Nutzern die Orientierung erleichtert. Das sind allerdings keine Aspekte, die mit Accessibility-Richtlinien zu tun haben.

Usability, Geräteunabhängigkeit und Responsivität

Die BITV und die WCAG treffen auch keine konkreten Aussagen darüber, wie robust eine Internetseite in Bezug auf Unterstützung älterer Technologien und Geräte-Betriebssystem-Kombinationen sein muss. Ob eine Seite nur die neuesten Browser Versionen unterstützt und für Touch-Endgeräte optimiert ist, spielt für Barrierefreiheit de facto keine Rolle. Responsive Design ist für Barrierefreiheit kein Muss.

Fazit

Es gibt viele Empfehlungen in den WCAG-Richtlinien, die sich im Grenzbereich Usability bewegen. Eine allgemeine Usability findet in den offiziellen Richtlinien keine Berücksichtigung. Wenn es um Barrierefreiheit nach offiziellen Richtlinien geht, spielen Anforderungen der Usability keine Rolle. Letztendlich stellt sich dadurch aber eher die Frage, ob dies nicht eine konzeptionelle Lücke der WCAG-Richtlinien ist. Denn es gibt in der Tat sehr viele Aspekte der Usability, die Barrierefreiheit deutlich verbessern. Nur verbindlich geprüft werden sie im Rahmen von Richtlinien-Tests nicht.

Ein Kommentar

  • Spannender und sehr ausführlicher Artikel.
    Am Ende habe ich mich gefragt, ob Accessibility-Experten auch Usability-Experten sind oder eher nicht. Das Fazit und die Beispiele zeigen, dass eher (und leider) der 2. Fall vorliegt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.