EStudy und Accessibility

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Vorwort

Dieser Artikel soll den zukünftigen Entwickler/innen einen Einstieg in die Accessibility Programmierung speziell für eStudy bieten. Grundlage zu diesem Artikel sind die Web Accessibility Guidelines, die vom W3C spezifiziert werden. Daher wird bei Unklarheiten zu diesem Dokument empfohlen, diese Gudielines heranzuziehen. Auf der anderen Seite muss auch vieles experimentell herausgefunden werden, da sich vieles im Zuge von Web 2.0 und der Weiterentwicklung assistiver Technologien ändert.


Einfache Strukturelemente

Bezeichnungen

  • Die Bezeichnungen der visuellen Elemente ist so zu wählen, dass sie kurz und knapp ausfällt. Bei den Links sind es zum Beispiel die Realbezeichnungen, bei den Grafiken die Alt Tags. Hinweis: Das Title Attribut in der a href Klausel bringt bei Screenreadern kein Ergebnis. Der Text der nach dem > Zeichen notiert wird, wird auch von Screenreadern interpretiert. Konsultieren Sie bei Unsicherheiten das SelfHTML.
  • Verwenden sie auch Text für die Navigationslinks also beispielsweise auf der Seite der Suchergebnisse den Button Weiter>>. Dies gilt auch für Links, die Ein- und Ausblendfunktionen haben. Durch diese Maßnahmen weiß ein Screenreader-User sofort, um welche Funktion es sich handelt.
  • Vermeidung von Overhead: Bei grafischen Links wäre es theoretisch ideal, im Alt Tag und in der Realbezeichnung des Links denselben Text zu notieren. Dies muss nicht unbedingt umgesetzt werden, da der Screenreader beide Elemente interpretiert und daher die Labels doppelt liest. Beschränken Sie daher Ihre Notation auf die Links.Beachten Sie hierbei Punkt 1.

Formularelemente

  • Gestalten Sie Formularelemente so, dass sie einzeilig sind. Dadurch erschließt sich der Inhalt schneller. Das heißt auch das Br-Tags innerhalb diese Elemente nicht zulässig sind.

Tabellen

  • Verwenden Sie das Summarize-Tag, um eine kurze Tabellenbeschreibung am Anfang zu platzieren. Dies beschleunigt die Navigation und das Suchen der Tabelle, wenn der User sofort den Sinn und Zweck dieser mitbekommt.
  • Verwenden Sie die Th-Tags, um Spaltenüberschriften zu kennzeichnen. Bei der Navigation durch Tabellen greift ein Screenreader ständig auf diese Informationen zu, wenn sie verfügbar sind.

Tastenkombinationen

Tastenkombinationen erleichtern und beschleunigen die Navigation auf Webseiten. Dabei ist zu beachten:

  • Aufgrund verschiedenster Browser und damit verschiedener Menüs stehen für alle nur die Tastenkürzel Alt+0 bis Alt+9 zur Verfügung. Bei Nichteinhaltung entstehen eventuell Überschneidungen mit der aktuellen Menüleiste, die dann die Tastenkombinationen unnötig machen.
  • Verwenden Sie die Tastenkürzel jedoch so sparsam wie möglich, also zum Beispiel für das Foyer, Ausloggen usw..


Design neuer Module

Komplexität minimieren

Accessibility beginnt schon beim Entwurf. Das heißt, dass die Module nicht nur nach bestimmten Guidelines entworfen werden müssen. Je einfacher ein Modul ist, umso leichter ist es nach den WAI Richtlinien zu gestalten. Eventuell muss es dann nicht mehr komplett nach diesen Richtlinien gestrickt werden. Dies ist jedoch in jedem einzelnen Fall zu entscheiden. Die Entscheidungsfindung kann mit automatisierten Tests (s. u.) oder durch Heranziehung einer betroffenen Person erleichtert werden. Die Vereinfachung von Modulen erfordert evtl. höheren Programmieraufwand und Durchdachtheit, aber letztendlich werden davon alle User profitieren.

Strukturieren

Ein Modul sollte folgende Struktur aufweisen:

  • Beginn des Moduls mit einer Überschrift
  • Falls das Modul Subkategorien besitzt, sollten kleinere Überschriften zur Kennzeichnung verwendet werden
  • Teilen Sie Ihre Links in Kategorien ein und zeigen Sie sie auch so an. Die Einteilung ist strikt vorzunehmen. Zum Beispiel gehören die Kursmitteilungslinks nicht zum persönlichen Menü. Diese Einteilung kann wahrscheinlich eher für etwas komplexere Module vorgenommen werden, da erst mal Kategorien entstehen müssen.
  • Verwenden Sie Elemente durchgängig: Haben Sie zum Beispiel einen Löschen Button erstellt, darf nachher (vielleicht wegen veränderten Bedingungen) kein grafischer Link mit der Bezeichnung Löschen auftauchen.
  • Das Modul muss so platziert werden, dass eine Zugehörigkeit zu einem Kurs oder Foyer ersichtlich ist. Ist dies nicht der Fall, empfiehlt sich eine separierte Darstellung des Moduls z. B. (Kurslinks ausblenden). Da die Umsetzung von „nicht Betroffenen“ eher schwierig sein dürfte, empfiehlt sich folgendes Vorgehen:
    1. Modul kursspezifisch oder nicht?
    2. Wenn ja, übliche Integrationsmaßnahmen
    3. Falls nicht, Anzeigereihenfolge beachten und kontextuell an der richtigen Position einbinden (kann aber muss nicht die header.inc.php sein). Beachten Sie bitte dabei die strikte Unterteilung der Links in Kategorien.
  • Das Modul muss zu dem vom Admin gewählten barrierefreien Style kompatibel sein.


Stylesheets

Zu Stylesheets kann man allgemein folgendes sagen:

  • Verwenden Sie kontrastreiche Farben, wobei auch die einzelnen Bereiche abgegrenzt werden sollten.
  • Die Media-Klausel zur Spezifizierung spezieller Ausgabegeräte brauchen Sie nicht zu verwenden. Die heutigen Screenreader sind nicht darauf angewiesen, da sie schon entsprechend hoch entwickelt sind.
  • Vermeiden Sie besonders die Farbkombination grün und rot.

Validierung

Automatische Validierung / Validierungstools

Webseiten kann man hinsichtlich WAI durch Tools validieren lassen. Ein Beispiel dafür ist die Web Developer Extension unter Firefox. Klicken Sie zur Validierung im Firefox auf Extras ->Web Developer Tools ->Tools ->Validate WAI. Unter Umständen muss der lokale Source validiert werden, was in diesem Menü ebenfalls möglich ist. Nach Abschluss der Validierung wird das Ergebnis präsentiert, wo auch weiterführende Hinweise angezeigt werden. Hinweis: Für detailierte Valildierungsergebnisse konfigurieren Sie bitte die Web Developer Extension so, dass sie die WAI Kriterien auf allen Stufen untersucht. Gehen Sie hierzu auf Extras->Web Developer Extension->Options->Options. Daraufhin öffnet sich ein Dialogfeld Klicken Sie dann auf Validation und haken Sie alles an, wo Accessibility steht.


Manuelle Validierung

Die automatische Validierung hat ihre Grenzen. Zum Beispiel kann kein Tool sagen, ob der Kontrast einer Seite ausreichend gut ist. Ein Tool kann zwar eine theoretische Abschätzung treffen, aber den betroffenen User kann es nicht ersetzen, da es die unterschiedlichsten Augenkrankheiten gibt.

Es gibt folgende Möglichkeiten eine manuelle Validierung durchführen zu lassen:

  1. Testen durch assistive Software
  2. Testen durch betroffene Personen

Testen durch assistive Software

Diese Tests können sie selbst durchführen, indem Sie eine spezielle Software, die den Zugang zum Internet einem betroffenen Personenkreis ermöglicht, installieren und dann einfach mal durch die Seiten browsen. Konkret gesagt handelt es sich hier um Vergrößerungssoftware und Screenreader. Für den Screenreader JAWS for Windows von Freedomscientific steht im eStudy Wiki der Artikel Jaws Installationsguide zur Verfügung. Sie werden es in den meisten Fällen mit Demoversionen zu tun haben, da die Lizenzen sehr teuer sind. Für eine Validierung dürfte es jedoch reichen, da die Limitation, zumindest im Fall von JAWS, zeitlich ist.

Das Problem dieser Testmethode ist der ungewohnte Umgang mit assistiver Software. Sehr oft werden alternative Darstellungsmethoden von diesen Softwareprodukten generiert, die den "Standarduser" zur Konfusität treiben können.

Testen durch betroffene Personen

Hier testen betroffene Personen die Webseite selbst. Im Idealfall sind es mehrere Personen mit verschiedenen Handicaps. Das einzige Problem ist, solche Personen für die Testzwecke zu engagieren, da man in der Regel keine Personen in seinem Umfeld findet oder sonst nicht Bescheid weiß wie man an solche Personen kommt. Ansonsten bietet dieses Verfahren folgende Vorteile:

  • Diese Personen wissen am besten über ihre benötigten Technologien Bescheid
  • Sie brauchen sich nicht an andere Darstellungsformen umzugewöhnen
  • Sie achten auf Dinge, die dem "Standarduser" entgehen, da die assistive Technologien auf diese Feinheiten angewiesen ist


eStudy, Ajax und Accessibility

Allgemeines

Das Problem besteht darin, den sich aktualisierenden Inhalt irgendwie zugänglich zu machen. Ist die Periode der Aktualisierung eher unregelmäßig (z. B. Benutzereingaben) oder liegt sie im Minutenbereich wird es keine Probleme hinsichtlich der Navigation geben. Eventuell muss jedoch ein kompletter Refresh der Seite angestoßen werden, da der Screenreader evtl. die Aktualisierung nicht "mitbekommt". Hier müssen weitere Tests durchgeführt werden, um das Verhalten des Screenreaders zu erforschen. Noch problematischer werden Webanwendungen, die sich in Intervallen von Sekunden aktualisieren.

Vorläufige Richtlinien

  • Weisen Sie zumindest bei Ihrem Ajax Modul auf die automatische Aktualisierung hin
  • Auch hier muss Die Ajax Anwendung mit dem vom Admin gewählten barrierefreien Style kompatibel sein. Zusätzlich sind die aktualisierbaren Bereiche optisch hervorzuheben.
  • Beträgt das Aktualisierungsintervall nur Sekunden, ist eine alternative Version dieser Anwendung unumgänglich.

Zusammenfassung

Ajax Anwendungen sind grundsätzlich zumindest für Screenreader Nutzer bedienbar. Durch Weiterentwicklung der Screenreader wird die Kompatibilität verbessert. Die dargelegten Richtlinien sollen daher nur als Orientierungshilfe dienen.


Weblinks