“Vorzeigebehinderungen”, Teil 2.

Körperlich Behinderte fahren immer Rollstuhl

Im ersten Teil ging es um Sehbehinderungen, hier geht es um motorisches. Der „Vorzeigebehinderte“ für motorische Einschränkungen ist meistens – genau – Rollstuhlfahrer. Warum?

Die Frage ist – meiner Meinung nach – einfach zu beantworten: Er ist am auffälligsten. Sein Hilfsmittel ist das größte (räumlich) und schränkt immer noch extrem ein: Treppen sind tabu, Rampen/Gefälle dürfen nicht zu stark sein.

Krücken sind auch ein beliebtes Hilfmittel, neben Gehstöcken, sind aber bei weitem nicht so sperrig wie ein Rollstuhl.

Nachtrag zu „Vorzeigebehinderungen Teil 1“

Besser hätte das Timing nicht sein können. Kurz nachdem ich den Artikel „Vorzeigebehinderungen“, Teil 1. geschrieben habe, entdeckte ich bei ChaosRadio Express eine neue Podcastfolge über Barrierefreiheit im Web:

Accessibility war lange Zeit das schwarze Schaf im Web, kommt aber durch eine Reihe von Gesetzen zur Verfplichtung zur Barrierefreiheit und auch durch einen brandneuen Standard der W3C zu neuer Aufmerksamkeit. Im Gespräch mit Tim Pritlove erzählen Tomas Caspers und Jan Eric Hellbusch von der Entstehung der Accessibility-Bewegung, über technische Standards und was man bei Ihrer Anwendung berücksichtigen sollte.

Unter anderem geht es um folgende Themen: Geburt des Web Standards Project, Auswirkung der Farbwahl in Webseiten für Farbenfehlsichtige, Bedeutung der Struktur und semantischem Markup für Blinde, Vorteile von barrierefreiem Design für nicht-behinderte Nutzer, Screenreader-Programme und vergleichbare Funktionalitäten in Betriebssystemen, Aspekte der Gebärdensprache, Aufbau, Anwendung und Testbarkeit der Web Content Accessibility Guidelines der W3C, Gesetzliche Vorgaben und Verpflichtung zur Barrierefreiheit für Behörden und öffentliche Körperschaften und Accessibility für Podcasts.

Podcast bei Chaosradio Express.

Ich bin gespannt, was dabei rumkommt.

„Vorzeigebehinderungen“, Teil 1.

Okay, ein weniger provokantes und genauso aussagekräftiges Schlagwort ist mir jetzt nicht eingefallen, es tut mir ja auch leid, das ganze zielt nicht auf Diskrimierung oder die „Besserstellung“ der einen oder anderen Behinderung ab. Ich versuche nur mal darzulegen, was man im allgemeinen Sprachgebrauch als Pauschaleinschränkungen heranzieht, um Problemstellungen für Behindertengerechte Lösungen zu beschreiben.

Da ich als Webdesigner und Anwendungsentwickler (Schwerpunkt Webbasierte Informationssysteme) arbeite, fange ich doch gleich mal mit dem „besten“ an, welches mir am häufigsten begegnet:

Barrierefreie Webseiten sind für Blinde

Sicher, ganz falsch ist es nicht. Ein blinder Internetnutzer ist für den Designer das absolute Worst-Case-Szenario. Dieser Mensch sieht nicht, wie toll der Designer in Photoshop malen kann, dieser Mensch „sieht“, wie der Designer seine Seite geschrieben hat. Und dazwischen liegen meistens Welten. Ein guter Maler kann ja nicht automatisch gut Romane schreiben. Der Schriftsteller kann vielleicht auch nicht sonderlich gut malen, aber das sieht er ja auch nicht als seine Aufgabe. Bei den meisten Designern, die auch Webseiten bauen ist das allerdings eine rare Erkenntnis.

Barrierefreiheit betrifft auch Menschen, die schlechte Kontraste sehen können, die kleine Schriften schlecht lesen können, oder die sonstige Probleme mit der visuellen Wahrnehmung haben, auch der durchschnittliche Rot-Grün-Schwächelnde fällt schon unter die Zielgruppe der WAI. Ebenso jeder, der eine Lesebrille benötigt. Insgesamt ist die Zielgruppe der Initiative recht groß, die Problemstellung der WAI konkret und so gehalten, dass jegliche Form visueller Wahrnehmungsschwäche ebenso wie motorische Schwächen ausgeglichen werden können.

Die vierzehn Punkte zur Barrierefreiheit werden in der Wikipedia wie folgt gelistet:

1. Stellen Sie äquivalente Alternativen für Audio- und visuellen Inhalt bereit.
2. Verlassen Sie sich nicht auf Farbe allein (beim Auszeichnen von Struktur/Semantik).
3. Verwenden Sie Markup und Stylesheets und erledigen Sie dies auf korrekte Weise.
4. Verdeutlichen Sie die Verwendung natürlicher Sprache (verwenden Sie beispielsweise das HTML-lang Attribut für das gesamte Dokument und Teile in einer spezifischen Sprache).
5. Erstellen Sie Tabellen, die geschmeidig transformieren (verwenden Sie Tabellen für tabuläre Daten, aber nicht für das Layout allein. Verwenden Sie die entsprechenden Elemente wie thead und tbody für die Auszeichnung von Tabellenbereichen).
6. Sorgen Sie dafür, dass Seiten, die neue Technologien verwenden, geschmeidig transformieren (und damit auch auf älteren bzw. für Accessibility geeigneten Benutzeragenten lauffähig sind).
7. Sorgen Sie für eine Kontrolle des Benutzers über zeitgesteuerte Änderungen des Inhalts (indem beispielsweise eine Abschaltung oder eine Verzögerung erlaubt wird – gilt im Besonderen auch für den Ablauf der Benutzersitzung oder für den Refresh von Seiten).
8. Sorgen Sie für direkte Zugänglichkeit eingebetteter Benutzerschnittstellen (Applets/Skripts sollten über dieselbe Art und Weise wie die Browserschnittstelle selbst bedienbar sein).
9. Wählen Sie ein geräteunabhängiges Design (unabhängig vom Eingabegerät, sei es Tastatur, Maus, Sprache, Kopfstab).
10. Verwenden Sie Interim-Lösungen (bis die Standards in diesem Bereich von allen Eingabegeräten vollständig unterstützt werden).
11. Verwenden Sie W3C-Technologien und -Richtlinien.
12. Stellen Sie Informationen zum Kontext und zur Orientierung bereit.
13. Stellen Sie klare Navigationsmechanismen bereit.
14. Sorgen Sie dafür, dass Dokumente klar und einfach gehalten sind.

Wenn man alleine nur versuchen würde, als Webseiten“ersteller“ möglichst viele Punkte abzudecken, wäre das ein merklicher Schritt in Richtung barriereärmere Seiten, was eine absolute Verbesserung wäre. Im übrigen auch für den Seitenbetreiber:

Besonders die Punkte 1, 4, 5, 6, 9, 11, 12, 13 und 14 haben einen unbewussten aber damatischen Nebeneffekt: Sie verbessern die Wahrnehmung einer Seite in Suchmaschinen deutlich, sie verringern, wenn man gerade eine Seite mit vielen Tabellen gemäß Punkt 5. umsetzt, die Serverlast und den Traffic. Das bringt Besucher und spart dabei trotzdem Kosten. Und natürlich noch mehr Pluspunkte für Besucher der Webseite. Aber das ist für Entscheider viel zu oft kein Argument. Leider.

Das nächste mal geht es dann mit motorischen Einschränkungen weiter.