Kontakt aufnehmen Menü

Social Accessibility: Wir reparieren uns das Web selbst

Veröffentlicht am:

Vor kurzem haben zwei Projekte von sich reden gemacht, die sehr ähnliche Ambitionen verfolgen: Das Social Accessibility Projekt von IBM und die Firefox 3 Erweiterung WebVisum.

Vor kurzem haben zwei Projekte von sich reden gemacht, die sehr ähnliche Ambitionen verfolgen: Das Social Accessibility Projekt von IBM und die Firefox 3 Erweiterung WebVisum.

Beide Projekte setzen voll auf den Community-Aspekt und wollen Webseiten barrierefreier gestalten, indem Sie Nutzern die Möglichkeit bieten, Barrieren aufzuzeigen und zu reparieren. Das erscheint auf den ersten Blick neu, ist es aber nur bedingt. Zum einen greifen sie damit auf die gängige Praxis zurück, mittels Browser-Erweiterungen im Rahmen eines Netzwerkes Webseiten zu kommentieren und diese Informationen für alle abruf- und nutzbar zu machen (z. B. Fleck, Annotate Any Webpage oder ShiftSpace), zum anderen bauen Sie konzeptuell auf dem Vorläufer C-SAW (Community Supported Accessible Web) von Serotek auf. Auch C-SAW setzt auf ein Netzwerk von Nutzern, die sich gegenseitig helfen und Webseiten mit Kommentaren und Hinweisen versehen. Bei all diesen Projekten liegt der Fokus auf dem blinden und sehbehinderten Nutzer, der mit seinem Screenreader auf Webseiten immer wieder auf unüberwindbare Barrieren stößt.

Social Accessibility Project (IBM) 

Das Social Accessibility Project von IBM setzt das Reparaturkonzept im großen Stil um. Drei Bereiche kennzeichnen das Projekt: Der Screenreader-Nutzer meldet die Probleme, der Supporter (Freiwillige) repariert den Fehler und der Server speichert und tauscht die Daten zwischen der Community aus. Falls der Supporter den Fehler behoben hat, kann der Screenreader-Nutzer das nächste Mal auf die Korrektur zurückgreifen und steht vor einer Barriere weniger.

Damit das auch alles technisch klappt, gibt es für den Screenreader-Nutzer eine Erweiterung, die er in seinem Screenreader (derzeit nur für JAWS und Internet Explorer) installieren muss, für den Supporter steht eine Browser-Erweiterung (nur für Firefox) zur Verfügung. Stößt der Screenreader-Nutzer nun auf eine Barriere, drückt er die Tastenkombination CTRL und Semikolon, hört einen PING-Ton und die Nachricht, dass ein Nutzer-Skript geladen wird. Damit wird der Fehler an den Server rückgemeldet. Ist der Fehler behoben, kann die Seite mit der Tastenkombination CTRL und Punkt korrigiert aufgerufen werden.

Für den Supporter wartet in der Seitenleiste des Browsers eine Liste der fehlerhaften Webseiten. Bis dato sollte man, ohne vorab das Manual ausführlich studiert zu haben, keine Reparaturen vornehmen. Der einfachste Korrekturvorgang ist, die Inhalte der ALT-Attribute von Grafiken zu ergänzen oder zu korrigieren. Dafür steht bereits ein Quickfix-Assistent zur Verfügung, das geht dann - wie der Name schon sagt - wirklich sehr schnell von der Hand. Das Korrigieren von ALT-Attributen ist daher auch eindeutig das Zugpferd des IBM-Projektes.

Alle weiteren Möglichkeiten wie das Korrigieren von Formularlabeln, Überschriften oder das Setzen von Kommentaren und wichtigen Punkten sind weitaus komplexer in der Ausführung. Vor allem ist die lineare Darstellung der Webseiten, was ja durchaus einer Screenreader-Nutzung entspricht, für das Erkennen der Fehlerquellen noch gewöhnungsbedürftig. Die Seitenleiste ist für den Supporter schlicht noch zu überladen.

Grundsätzlich macht das Projekt jedoch einen sehr innovativen und aktiven Eindruck. Man kann bereits auf eine lange Liste von korrigierten Webseiten, aktiven Screenreader-Nutzern und Supportern zurückblicken. Ranking und Treuepunkte gibt es auch schon. Das Projekt wird von IBM Tokio vorangetrieben, was eine gewisse sprachliche Einschränkung auf das Englische und Japanische bedeutet. In Zukunft sollen noch weitere Screenreader unterstützt werden und eine Schnittstelle zu den Betreibern und Entwicklern von Webseiten geschaffen werden, damit sie ihre Fehler aufarbeiten können.

Abgesehen davon, dass man als Supporter eine ganze Portion Engagement und vor allem Wissen um Barrierefreiheit mitbringen muss, kann man dieses Projekt auch jetzt schon im deutschen Bereich nutzen. Jede Korrektur oder Anmerkung, die man vornimmt, steht - wenn auch nur registrierten - Screenreader-Nutzern zur Verfügung. Und es gibt ein weiteres Plus: Die Seitenleiste spricht auf jede Webseite an und eine Art Assistent erkennt sofort mögliche Probleme. Insofern kann man diese Erweiterung auch für die eigene Entwicklung nutzen, um Webseiten weiter zu optimieren.

WebVisum 

Etwas weniger technisch ausgefeilt und mehr nutzerlastig geht WebVisum an den Start. Auch hier geht es darum, Barrieren für Screenreader-Nutzer zu beheben, indem man verschiedenste Reparaturmöglichkeiten bereitstellt. Dreh- und Angelpunkt dabei ist eine Browser-Erweiterung für Firefox 3 (auch in Zukunft wird kein anderer Browser unterstützt werden). Das Zugpferd in diesem Projekt ist das Auslesen von CAPTCHAs, was auch in den meisten Fällen recht gut funktioniert. Man aktiviert das Feld, in das die Lösung des CAPTCHAs einzutragen ist, aktiviert eine Tastenkombination oder das Kontextmenü. Der Server meldet dann nach einigen Sekunden die Lösung, die dann in das Feld kopiert werden kann. Zu dieser Funktion gibt es auch sehr viele positive Rückmeldungen von Nutzern, die sonst auf Webseiten ohne Audio-CAPTCHAs gnadenlos scheitern. Sicherlich ruft das auch die Spam-Problematik ins Gedächtnis. Die Betreiber von WebVisum entgegnen diesem Problem derart, dass nur angemeldete Nutzer in den Genuss dieser Funktion kommen und nicht beliebig viele CAPTCHAS ausgelesen werden können.

Initiator Marc Dohnal betont in einem Interview, dass die anderen Reparaturfunktionen des Projektes wie das Korrigieren und Beschriften von Grafiken, Formularfeldern und Verlinkungen viel größere Priorität haben. Der Umfang der Bearbeitungsmöglichkeiten ist in WebVisum tatsächlich weitaus größer und freier, das liegt vor allem daran, dass das Labeling – das Beschriften - auf jedes Element der Webseite angewendet werden kann. Marco Zehe macht in seiner Rezension deutlich, wie weit dieser nutzerzentrierte Ansatz ausgeführt und ausgelegt werden kann. So könnten etwa Audioinhalte für gehörlose Nutzer mit einem Textlabel, Videos nachträglich mit einem Untertitel versehen werden, es kann schlicht von jedem eine Optimierung von Inhalten vorgenommen werden, wo eben eine von Nöten ist. Ein weiteres Highlight von WebVisum ist die OCR-Funktion von Grafiken, die Text enthalten. Dieses Feature hat noch nicht wirklich überzeugt, keine der angewählten Textgrafiken wurde ausgelesen. Ähnlich wie im IBM-Projekt soll es zukünftig eine Auflistung von Webseiten geben (Hotlist) und eine Schnittstelle für Betreiber und Entwickler.

Der entscheidende Unterschied zum IBM-Projekt liegt jedoch darin, dass jeder Nutzer seine Barrieren selbst korrigieren kann und muss. Man darf dann doch die Frage stellen, ob ein Screenreader-Nutzer einen fehlerhaften Link korrigieren kann, wenn ihm nicht alle Informationen zur Verfügung stehen. Das Projekt operiert aktuell daher noch eher schlicht: Tritt konkret ein Fehler auf, dann repariert man das einfach. Diese Korrektur steht dann allen im Netzwerk und plattformunabhängig zur Verfügung. Als Browsererweiterung könnte sich WebVisum auch aus Entwicklersicht als typischer Hyrbid durchsetzen. So bietet das Plugin auch Zusatzdienste an, wie Flash auszuschalten, Kontraste der Webseite zu ändern oder Bilder zu verstecken. Aber vielleicht ist das auch das Problem, dass WebVisum an zu viele Ecken andocken will. Das IBM-Projekt zeigt da einen ganz klaren Fokus: Aufgabe ist das Reparieren von Webseiten, nicht mehr und nicht weniger.

Fazit

Auch wenn beide Projekte divergierende Werkzeuge favorisieren, verfolgt das IBM-Projekt doch einen umfassenderen Ansatz. Allein Überschriftenhierarchien zu korrigieren und zu ergänzen, macht ganze Webseiten verständlicher. Gerade dieses Beispiel macht jedoch die Grenzen durch Freiwillige klar: Es ist sehr viel Wissen um Barrierefreiheit notwendig, um großräumige Korrekturen vorzunehmen. Mal hier und da eine Audiodatei mit Text zu versehen, dort ein fehlerhaftes ALT-Attribut zu korrigieren, eine Überschrift oder Sprunglinks zu ergänzen, ist keine große Sache.

Ganze Webseiten jedoch barrierefrei durchzugestalten - obwohl das etwa das IBM-Projekt mit einer Kopierfunktion durchaus zulässt -, ist schlicht ein Unding und steht in keiner Relation zu Aufwand und Ergebnis. Allein der schlichte Hinweis, dass sich Layout und Inhalt einer Webseite schließlich ändern können, macht klar, dass es nicht wirklich sinnvoll ist, derartig große Korrekturen auf einer Webseite vorzunehmen. Dazu muss man sich auch noch mit teilweise widersprechenden Korrekturen auseinandersetzen, ganze Korrekturagenden durchlesen und berücksichtigen, Kommentare von Nutzern und anderen Freiwilligen einarbeiten und sich mit der oft nicht immer verständlichen Nomenklatur der einzelnen Projekte befassen.

Das setzt schon ganz real Grenzen. Wie bereits das C-SAW-Projekt von Serotek gezeigt hat, kann die Community viel leisten – es wurden wohl an die 4000 Webseiten im Netzwerk zugänglicher gemacht und von den Nutzern für alle mit Kommentaren versehen. Beide aktuellen Projekte zeigen tatsächlich eine interessante, neue Tendenz, gegen Barrieren auf Webseiten vorzugehen. Das passt auch alles bis zu einem gewissen Grad in die Web 2.0-Tendenz, die den Nutzer aktiviert und seine Inhalte miteinbringt. Aber wir müssen auch ehrlich sein, genauso divers werden diese Projekte dann auch bleiben.

Was derartige Projekte leisten können, ist, punktuelle Probleme auf Webseiten aufzuarbeiten und nachzubessern. Damit schaffen sie schnell und kurzfristig barrierefreie Schneisen. Mehr kann eine wie auch immer willige und aktive Community nicht auffangen. Was diese Projekte jedoch nicht leisten können, ist, Barrierefreiheit auf ganzen Webseiten von Anfang an durch- und umzusetzen. Dazu ist umfassendes Wissen notwendig, dazu gehört Erfahrung und ein Verständnis, wie unterschiedlich Nutzer an Webseiten herangehen. Hier beginnt dann für uns die eigentliche barrierefreie Basisarbeit und das ist gut so.

Die Autorin

Sylvia Egger arbeitet als Senior Webproducerin in Köln und setzt sich aktiv für die Barrierefreiheit von modernen Webseiten ein.

Kontakt: www.sprungmarker.de

BITV-Test und Beratung

Wir sind bereits mehrere Jahre offizielle Prüfstelle im BITV-Test-Prüfverbund und können Ihnen den BIK BITV-Tests anbieten – entweder als Konformitätstest (BITV-Test zur Veröffentlichung) oder einen Projekt begleitenden BITV-Test, der aufgrund einer geringeren Seitenauswahl (Stichprobe) zwar günstiger ist, aber nicht veröffentlicht werden darf. Sprechen Sie uns an, wir erstellen Ihnen gerne ein unverbindliches Angebot für einen BIK BITV-Test. Neben diesen Tests können wir Ihnen auch eine vereinfachte Überprüfung sowie unseren eigenen Barriere-Check Pro (erweiterter BITV-Test) anbieten

BITV-Prüfung anfragen

Barrierefreie PDF

Tag-Baum Barrierefreie PDF-UA PDF erstellen nach BITV und EN301549

Von uns erhalten Sie garantiert barrierefreie PDF. Alle Dokumente werden mit Screenreader und dem PDF Accessibility Checker überprüft und validiert. Auf Wunsch erhalten Sie auch einen Prüfbericht von uns.

Barrierefreie PDF von anatom5

Barrierefreies Internet

Als Agentur für Universelles Design und Herausgeber des Barrierekompass, hat anatom5 seit 2003 eine weitreichende Expertise im Bereich barrierefreie Informationstechnologie erlangt.

Spezialisierte BITV-Agentur

Die Leistungsfelder umfassen das gesamte Thema Barrierefreiheit nach BITV: Barrierefreies Internet, Barrierefreie PDF, Barrierefreies Responsive Design, Usability & Accessibility Konzeption, Leichte Sprache, Einfache Sprache, UI-Design, BITV-Testing, Schulungen und Workshops.

Ausgezeichnete Barrierefreiheit

Die intensive Beschäftigung mit digitaler Barrierefreiheit spiegelt sich auch in diversen Auszeichnungen wider, die anatom5 seit 2003 erhalten hat, darunter 10 Nominierungen für einen BIENE-Awards der Aktion Mensch.

Digitale Barrierefreiheit