Zugänglichkeit im Webdesign – es bleibt schwierig!
13. Juni 2008
Machen wir uns nichts vor: Die Zeiten, in denen man dem erstaunten Grafiker mitteilen musste, dass sein hübscher Screenentwurf unter Umständen auf den Monitoren der Nutzer ein wenig anders aussehen könnte als im Photoshop, sind so langsam vorbei. Es hat sich langsam aber sicher eine gesunde Grundakzeptanz dafür gebildet, dass man im Hinblick auf die Zugänglichkeit (früher hieß das mal Barrierefreiheit) das visuelle Design von Websites nicht als vollständig kontrollierbar ansehen darf.
Die Gründe dafür sind ebenfalls hinlänglich bekannt. Als erstes werden dabei meist die Nutzer mit Sehbehinderungen genannt. Dabei stellt die unfassbare Vielfalt von Zugangsgeräten inzwischen fast das größere Problem dar: schlechte Browser auf winzigen Handydisplays, gute Browser auf kleinen Smartphonedisplays oder auf Vollbild gezogene Browser auf riesigen 30-Zoll-Monitoren. Außerdem sind langsame Netzverbindungen zu berücksichtigen (GPRS, EDGE), sowie restriktive Arbeitsplatzumgebungen, wo die paranoide IT-Abteilung verhindert, dass ein aktueller Browser installiert oder gar JavaScript aktiviert wird. Ein ganz schönes Dilemma! Aber an sich keine brandneue Erkenntnis.
(Am Rande: Vollblinde Nutzer tangiert das alles wenig – für Sie ist eigentlich nur der HTML-Quelltext interessant und irgendwann vielleicht mal das Audiostylesheet, falls sowas in diesem Leben noch von irgendeiner Screenreader-Software implementiert werden sollte.)
update: Wie Eric richtig anmerkt, bedienen sich Screenreader nicht direkt beim HTML, sondern bei der MSAA-Schnittstelle, die aber natürlich ihrerseits das HTML als Grundlage nimmt und nur wenige CSS-Parameter wie display: none;
einfließen lässt.
Alle Macht dem User also; soweit ist ein Konsenz unter den professionellen Webentwicklern vorhanden. Doch jetzt wird es schwierig: Die spannende Frage an dieser Stelle lautet nun nicht mehr, ob man dem Nutzer ermöglichen soll, das Design an individuelle Bedürfnisse anzupassen, sondern vielmehr an welcher Stelle man sich idealerweise einhängt, um optimale Zugänglichkeit zu erreichen. Dabei spielen verteufelt viele Faktoren eine Rolle, die dummerweise oftmals im Gegensatz zueinander stehen und in unterschiedlichen Nutzungsszenarien betrachtet werden müssen.
1. Onsite-Faktoren
Naturgemäß können wir als Webdesigner nur die so genannten Onsite-Faktoren unter Kontrolle haben, also wie die Website umgesetzt und ausgestattet wird. Was dann der Empfänger später beim Betrachten damit anstellt, liegt (glücklicherweise) nicht in unserer Macht. Aber wir können natürlich für eine gute Grundvoraussetzung sorgen. Dazu gehört ganz selbstverständlich valides und semantisch aufbereitetes HTML – aber das ist nicht alles!
1.1 Das reguläre Stylesheet
In den Blogs und Foren werden erbitterte Kämpfe darüber geführt, ob man bereits das reguläre Stylesheet der Website auf die besonderen Eigenschaften von Sehbehinderungen abstimmen muss. Man denkt dann im Wesentlichen an zwei Maßnahmen: Große Schriften und starke Kontraste. Dumm nur, dass es auch Sehbehinderungen gibt, die mit starken Kontrasten gar nicht klarkommen! Außerdem kann man nicht wissen, ob ein weißer oder dunkler Hintergrund im Einzelfall besser geeignet ist. Darüber hinaus: Große Schriften können auf mobilen Geräten zu schwieriger Handhabung führen, weil mehr gescrollt werden muss, was dann abhängig vom Gerät mal mehr und mal weniger fummelig sein kann.
Und so weiter und so fort. Was für den einen Nutzer eine echte Hilfe ist, kann für den anderen eine neu geschaffene Barriere darstellen. Der Mythos einer »korrekten grafischen Gestaltung« zur Erreichung von Barrierefreiheit ist lange genug propagiert worden. Es gibt da leider keine absoluten Regeln.
Doch was machen wir nun konkret? Es gibt zwei verschiedene Vorgehensweisen:
- Man stellt alle potenziellen Schwierigkeiten der individuellen Nutzer zusammen. Junge, das wird eine lange Liste! Dann ermittelt man, wo sich zwei Probleme konträr gegenüberstehen und versucht herauszubekommen, welche Zielgruppe mehr Mitglieder hat, um dann dahingehend zu optimieren. Somit schafft man einen Kompromiss. Leer ausgehen tun dabei freilich die Nutzer mit exotischeren Anforderungen. Und man hat eine Menge Arbeit vor sich.
- Man vertagt das Problem einfach und richtet sich ausschließlich nach dem schicken und Corporate-Design-gerechten Entwurf des Grafikers. Es gibt ja noch andere Orte als das Default-Stylesheet, an dem das Aussehen der Seite bestimmt werden kann.
1.2 Faktor: Styleswitcher und Textzoom-Buttons
Lange Zeit dachte man, eine richtig barrierefreie Seite muss möglichst viele zusätzliche Regler und Buttons besitzen, über die man das Design extrem flexibel an die eigenen Bedürfnisse anpassen kann: Mindestens drei verschiedene Stylesheets (default, hoher Kontrast, invers, linearisiert usw.) und natürlich auch Buttons zum Skalieren des Schriftgrades. Wer richtig protzen wollte, ließ die Schriftfamilie nach Belieben austauschen, weil manche Menschen lange Texte lieber in serifenlosen Fonts oder gar Comic Sans lesen möchten.
Alles prinzipiell kein Problem, doch irgendwann ist dann auch die Grenze erreicht, wo die Anzahl der Optionen schlicht selber zu einer massiven Barriere wird. Zudem bleibt natürlich die Hauptfrage im Raum stehen, wo man diese Navigation am besten platziert und wie diese aussieht. Ein sehbehinderter User nämlich, der sich die Schrift einer Seite sehr groß wünscht, muss logischerweise beim ersten Besuch des Angebots erst einmal den entsprechenden Button finden. Wenn dieser dann im Default-Zustand entsprechend winzig ist, kann man es auch gleich sein lassen. Und wie soll ein Nutzer, der von komplett weißen #ffffff-Flächen geblendet wird und gar nichts mehr erkennt, den Regler zur invers-Version finden, wenn die entsprechende Website nun mal einen weißen Hintergrund besitzt?
(Am Rande: Interessant sind natürlich automatische Sniffer-Routinen, die über Server-Request, JavaScript und/oder media queries zumindest die Größe von Bildschirm und Viewport herausfinden können, und ob es sich beispielsweise um ein iPhone handelt. Gerade bei Letzterem tut sich derzeit so einiges, und das ist durchaus nicht zum schlechtesten für die Zugänglichkeit – machen iPhone-Versionen von Websites sind auch auf dem Desktop schlicht besser als ihre vollwertigen Verwandten …)
1.3 Fazit Onsite-Faktoren
Natürlich ist dies etwas überspitzt ausgedrückt. Wir dürfen es uns als Webdesigner nicht ganz so leicht machen und einfach alle Onsite-Faktoren der visuellen Zugänglichkeit als ungeeignet und widersprüchlich abtun! Doch ich behaupte, dass man es in vielen Fällen auch übertreiben kann mit der Bemutterung des Users und den wilden Spekulationen darüber, was dieser wohl am dringendsten benötigt. Und das bringt uns schon zum nächsten Punkt.
2. Offsite-Faktoren
Völlig unabhängig von der Gestaltung und Umsetzung der jeweiligen Website gibt es eine Menge von Faktoren, die primär auf der Seite des Nutzers eine Rolle spielen. Voraussetzung dafür ist natürlich eine gewisse Erfahrung im Umgang mit der gerade verwendeten Hard- und Software. Eine Rentnerin, die vor einer Woche auf einer Kreuzfahrt ihren ersten Computerkurs gemacht hat, wird womöglich mehr Schwierigkeiten bei der Bedienung von Websites haben als ein 40-jähriger Geburtsblinder, der sich seit 12 Jahren immer die neueste Spezialhardware leisten kann und alle Tricks im Browser kennt. Denn auch hier gibt es einiges zu beachten!
2.2 Browseroptionen
Bei vielen Webdesignern ist eine gewisse arrogante Grundhaltung zu beobachten (und da nehme ich mich ausdrücklich nicht von aus): »Sollen die Leute doch lernen, ihren Browser korrekt zu bedienen!«, »Wir brauchen einen Internet-Führerschein!«, usw… Charmanter könnte man behaupten, seine User »nicht für ganz dumm zu halten«, oder die Unsinnigkeit zu betonen, eine Textskalierung aufwändig mit JavaScript und Cookies nachzubauen, wenn doch jeder Browser von Haus aus die Möglichkeit bietet, dies bequem global für alle Websites zu regeln.
Genau hier liegt einer der Knackpunkte: Man weiß eben leider nicht, wie gut die User ihre Browser kennen. Es gibt darüber zu wenig gesichertes Wissen. Ständig werden Umfragen gemacht, ob die Leute schon mal Blogs gelesen oder Podcasts gehört haben. Aber offenbar kommt niemand auf die Idee, im großen Stile zu erheben, ob Webnutzer den eingebauten Textzoom ihres Browsers kennen oder sich bewusst sind, dass sie Werbebanner über Plugins wegfiltern können. Das wären einmal interessante Zahlen!
Man lässt sich leicht verführen von der Tatsache, dass die Benutzer der eigenen Website sich auskennen und eventuelle Schwierigkeiten mit dem Layout selber beheben können. Aber meine Güte: Die Besucher einer Webdesigner-Website sind vieles, aber sicher nicht repräsentativ für die gesamte Netzbevölkerung.
2.3 User-Stylesheets und die Betriebssytem-Ebene
Bei den meisten Usern noch viel weniger bekannt als die regulären Browseroptionen dürfte die Verwendung von User-Stylesheets sein. Dies ist eine Technik, die im großen Stile nur von Menschen genutzt wird, die unter einer sehr starken und/oder sehr speziellen Sehbehinderung leiden. Userstylesheets ermöglichen die knallharte individuelle Anpassung sämtlicher per CSS anpassbaren Elemente auf die jeweiligen Bedürfnisse des Nutzers: Alle Websites mit schwarzem Hintergrund und hellgrünem Text? Kein Problem! Alle Schriftangaben ignorieren und grundsätzlich nur Comic Sans auf 22 Pixel anzeigen? Wird erledigt.
Natürlich erfordert so ein Stylesheet ein ganz schönes Stück an Fachwissen und Erfahrung. Doch man muss immer die Motivation dahinter sehen: Die gesamten Netzinhalte endlich nutzbar machen zu können und nicht auf fremde Hilfe angewiesen zu sein!
Ähnliches gilt für die Ebene des Betriebssystems; auch hier kann man sich, falls nötig, alle Farben und Schriften so konfigurieren, dass es passt. Das geht inzwischen ganz selbstverständlich in jedem modernen Betriebssystem und wirkt sich in der Regel natürlich auch auf die Webinhalte aus, obwohl man zugegebenermaßen mit gut aufbereiteten Userstyles eine noch individuellere Darstellung erreichen kann.
Die Erkenntnis
Was ziehen wir daraus für Schlüsse? Müssen wir überhaupt noch auf zugängliches Webdesign achten, wenn doch der User letztlich alles selber einstellen kann? Andererseits: Genügt die theoretische Möglichkeit der individuellen Anpassung, um sich als Webdesigner vor seiner Verantwortung zu drücken? Wieviele behinderte User können sich spezielle Hard- und Software finanziell leisten? Und und und.
Es gibt nur ganz wenige Aussagen, die man gesichert treffen kann:
- Zugängliches Webdesign ist keine Einbahnstraße, sondern ein Wechselspiel zwischen dem, was der Webdesigner anbietet und dem, was der Websurfer am Ende daraus macht.
- Wenn ein Nutzer User-Stylesheets kennt und nutzt, sind Onsite-Optimierungen für ihn nicht mehr so wichtig.
- Internet-Neulinge haben leider nichts davon, wenn viele andere Netzbewohner ihre Browser aus dem FF beherrschen.
Wer ist gefordert?
Sie ahnen es sicher schon: Ich komme auch in diesem Essay natürlich nicht zu einer Lösung! Dennoch möchte ich drei Appelle stellen, die sich an drei sehr unterschiedliche Gruppen richten.
Zunächst einmal die Webdesigner: Sie müssen sich des Problems der Zugänglichkeit stets bewusst sein, damit sie zumindest sinnvoll begründen können, warum sie diese und jede Funktion nicht eingebaut haben. Hier helfen keine Checklisten, sondern im Zweifelsfall der gesunde Menschenverstand und jede Menge Erfahrung.
Dann die Browserhersteller: Ihnen kommt die ehrenvolle Aufgabe zuteil, die Spezialfunktionen wie Textzoom, Seitenzoom, Tabnavigation, User-Stylesheets usw. besser zu promoten, damit sie mehr auffallen und immer mehr Leuten in Fleisch und Blut übergeht. Kein Mensch braucht einen Home-Button in der Kopfleiste! Aber ein deutlich zu erkennendes Plus und ein Minus, oder gar ein Schalter für einen automatischen Hochkontrast-Modus, das wäre doch mal was!
Nicht zuletzt appelliere ich an die betroffenen Nutzer, die auf zugängliches Webdesign besonders angewiesen sind: Ihr müsst dringend eine gemeinsame Stimme finden und den Webdesignern klar und deutlich mitteilen, was Ihr benötigt und was Euch weiterhilft. Es kann nicht sein, dass einige Screenreader-Nutzer postulieren, sie kämen mit Frame-Layouts am allerbesten zurecht, weil ihre veraltete Vorlesesoftware darauf zufällig optimiert ist. Oder dass niemand weiß, ob Serifenschriften für lernbehinderte Nutzer okay sind. Oder die Unsicherheit bei der Wahl der richtigen Seitenbreite für mobile Web-Anwendungen. Jeder erzählt einem was anderes, und das ist nicht sehr hilfreich.
Und sonst so?
Nicht umsonst werden zu diesem Thema viele Bücher geschrieben und Konferenzen abgehalten, deswegen füge ich der Diskussion keine wahrhaft neuen Erkenntnisse hinzu. Aber schaden tut meine kleine Übersicht sicher auch nicht! Wo ich selber derzeit stehe, wollen Sie wissen? Nun, ich tue mir zunehmend schwerer damit, mich als wahrhaft kompetenten Ansprechpartner für Fragen der Zugänglichkeit zu bezeichnen. Es ist ein bisschen wie in der Biochemie: Je mehr man weiß, desto weniger weiß man! Trotzdem: Ich bastele auf meine Weise weiter am zugänglichen Web und hoffe auf weitere spannende Diskussionen und Erkenntnisse.