Alex Kirsch
Independent Scientist
DE | EN

Blog

Einfacher, schöner und für alle: mein neuer Web-Auftritt

05.03.2021
Wie Usability, Barrierefreiheit und Technik in meinem neuen Web Experience Quick Check zusammenkommen.

Die Ausgangslage

alte Version des Blogs

Ein ständig nagendes schlechtes Gewissen. Sechs Jahre lang predigte ich Studierenden, dass Barrierefreiheit für Webseiten ein absolutes Muss ist. Aber kaum geht es an meine eigene Webseite, muss es ja schnell gehen und alle Maßnahmen, die ich nicht direkt auswendig wusste, waren plötzlich nicht so wichtig. Mir war auch klar, dass der "Checkbox-Trick" für mein mobiles Menü weder barrierefrei noch programmiertechnisch elegant war, aber der Wunsch nach Einfachheit durch reines CSS und HTML hat damals gesiegt.

Drei Jahre später nagt das schlechte Gewissen weiter und es hat Unterstützung bekommen von geänderten Anforderungen. Während in meiner ersten Webseite der erste einzelne Blogeintrag so groß wie möglich erscheinen musste, war die Liste der Einträge jetzt so weit gewachsen, dass der Blog nach einer Überarbeitung schrie. Die Sortierung der Blogserien war unintuitiv, der Klappmechanismus nicht durch Tastatur zu öffnen und die ganze Liste unübersichtlich. Obendrein war die Darstellung aller Blogartikel auf einer Seite unpraktisch, da ich keine einzelnen Artikel per URL referenzieren konnte.

Der Prozess

Der Blog als aktuellstes Problem war zuerst dran. Statt einer langen Seite mit Artikeln zum Aufklappen, gibt es jetzt ein Inhaltsverzeichnis mit Links zu Unterseiten. Der Klappmechanismus ist bei Blogserien weiterhin im Einsatz. Mit dem Thema Barrierefreiheit im Hinterkopf ist mir zum ersten Mal bewusst geworden, wie sehr meine Webseite eingeschränkt war. Ohne Maus oder Touch hatte man keine Chance, die Blogartikel zu lesen. Es lässt sich schwer beziffern, wie viele Menschen ich dadurch ausgesperrt habe, in jedem Fall habe ich sie von meiner meistbesuchten Seite fern gehalten. Die neue Lösung verwendet das recht neue HTML-Element details, das automatisch Tastaturbedienung unterstützt.

Dann zur Barrierefreiheit. Als erstes habe ich mir einen Screen Reader installiert (Orca auf Linux) und mir meine Webseite vorlesen lassen. Eine interessante Erkenntnis: meine Links zum Umschalten der Sprache ("DE | EN") wurden als "de-e e-en" vorgelesen, nicht gerade das was ich aussagen wollte. Allein diese Kleinigkeit hat mich dazu gebracht, diese Links zu überdenken und festzustellen, dass einer genügt. Ein alt-Attribut dazu und schon wusste auch der Screenreader, was "DE | EN" bedeutet.

Für weitere Checks zur Barrierefreiheit habe ich mir WAVE installiert. Dieser fing direkt an, meine Farben zu kritisieren. Erste Reaktion: "Das kann nicht sein!" Zweite Reaktion: "Wie soll ich das denn anders machen? Ich liebe mein Farb-Schema." Kurz durchgeatmet und zu dem Schluss gekommen, dass die Barrierefreiheit meiner Webseite nicht an Farben scheitern soll. Meine zwei Hauptfarben Blau und Grau hatten bei normaler Schriftgröße beide nicht genug Kontrast zu weiß (oder zu Schwarz). Hätte ich beide in einer dunkleren Variante gewählt, hätte man kaum einen Farbunterschied gesehen. Deshalb gibt es jetzt nur noch ein dunkles Blau als Hauptfarbe. Damit mussten aber die Zustände der Menüpunkte anders dargestellt werden und daraus ergab sich eine komplett neue Gestaltung des Menüs.

alte Version des Menüs neue Version des Menüs

Der Abschied von meinem Farbschema und dem gewohnten Menü war schwer, die Belohnung ist ein deutlich schickeres, moderneres Menü und sogar die Farbe gefällt mir besser.

alte Version der mobilen Version neue Version der mobilen Version

Zum Schluss noch das lange vor mir hergeschobene mobile Menü. Man kann sich fragen, warum ein mobiles Menü per Tastatur bedienbar sein sollte, die gibt es am Handy ja nicht. Die mobile Ansicht wird jedoch auch gern von Menschen mit eingeschränktem Sehvermögen auf dem Desktop genutzt bei großer Schrift und mit geringer Zeilenbreite. Außerdem war die technische Lösung recht unelegant.

Durch den technischen Umbau sind auch gestalterische Aspekte zu Tage getreten. Die absolute Positionierung über dem eigentlichen Inhalt sah in der alten Version schief aus und es gab das technische Problem, den Fokus beim Aufklappen des Menüs auf den ersten Menüpunkt zu setzen. Meine neue Variante war einfacher zu programmieren als die alte, fügt sich besser ins Gesamtbild ein, sieht ansprechender aus und lässt sich durch größere Schaltflächen angenehmer bedienen.

Ein Ziel des Umbaus war mehr Menschen Zugang zu meiner Webseite zu ermöglichen. Das habe ich erreicht indem ich auf Maßnahmen zur Barrierefreiheit geachtet habe. Andererseits schließt die neue Lösung auch Nutzende aus, nämlich diejenigen, die immer noch den Internet Explorer nutzen. Während ich bei der alten Version dafür gesorgt habe, dass sie auch im Internet Explorer ordentlich angezeigt wird, habe ich jetzt an dieser Stelle gespart. Zu viele meiner verwendeten Mechanismen werden im Internet Explorer nicht unterstützt und ich habe weder die Motivation noch die Kapazitäten die komplette Webseite für Internet Explorer von Grund auf neu zu erstellen. Es ist also immer eine Abwägung, wen man reinlässt und wer draußen bleibt.

Die Einsicht

Auch wenn ich es jahrelang behauptet habe, so richtig glaubt man es doch erst, wenn man es selbst sieht: barrierefreie Webseiten ermöglichen nicht nur mehr Menschen Zugriff, sie sind insgesamt besser bedienbar und in meinem Fall sogar schöner.

Wieso habe ich das also nicht schon früher getan? Die grundlegenden Mechanismen und die Motivation kannte ich und doch schien es mir ein zu großer Aufwand. Das Problem besteht meiner Meinung nach in der Fülle der Informationen und ihrer üblichen Präsentation entlang von körperlichen und geistigen Einschränkungen (wie bei den Web Content Accessibility Guidelines (WCAG) oder der Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (BITV)).

Wenn man eine Webseite (um-)gestaltet, braucht man Richtlinien geordnet nach Maßnahmen zur technischen und visuellen Gestaltung. Viele Maßnahmen wirken sich sowieso auf mehrere Einschränkungen aus. Beispielsweise sind sprechende Link-Benennungen nicht nur wichtig für Screen Reader (also für blinde Menschen, aber nicht nur für diese) und Spracheingabe-Systeme (für Menschen mit motorischen Einschränkungen), sondern erleichtern auch das visuelle Scannen einer Seite für alle BesucherInnen. Barrierefreiheit ist kein Anhängsel von Usability, sondern ein integraler Bestandteil, der sich mit vielen "normalen" Regeln guter User Interface Gestaltung überlappt.

Mir ist auch bewusst geworden, dass ein großer Teil einer Webseite unsichtbar ist. Eine gute Webseite hat eine gegliederte Seitenstruktur, nicht nur visuell, sondern auch im Code. Das ermöglicht die Nutzung durch Assistenzsoftware genauso wie durch Suchmaschinen. Nebenbei hilft es bei der Gestaltung der Webseite, wenn man nicht nur Elemente nebeneinander setzt, sondern sich genau Gedanken macht, was deren Rolle ist. Das schärft das mentale Modell, das man Nutzenden bietet.

Aus den Erfahrungen dieser Webseitenumgestaltung, zusammen mit dem Wissen aus meiner Juniorprofessur für Mensch-Computer-Interaktion habe ich ein eigenes Modell für meinen Web Experience Quick Check entwickelt als Rundum-Betrachtung aller Aspekte von Usability, Barrierefreiheit und technischer Umsetzung.

Ein wenig Eitelkeit

Ich bin kein Fan von Metriken und die Gestaltung einer Webseite ist keine Optimierungsaufgabe. Trotzdem hat es mich gefreut, dass meine Webseite von dem Google Tool Lighthouse in jeder Kategorie mit 100 von 100 Punkten bewertet wurde: Ergebnis Lighthouse Check für www.alexkirsch.de: 100 Punkte in jeder Kategorie

Das hat nicht einmal die Webseite des W3C geschafft (die zugegebenermaßen etwas umfangreicher ist als meine): Ergebnis Lighthouse Check für www.w3.org: sehr gute Werte mit Verbesserungspotential

← Zurück zur Blog-Übersicht