Unterschiede zwischen den Revisionen 10 und 11
⇤ ← Revision 10 vom 2009-07-07 19:12:08 →
Größe: 2518
Autor: Lars Stetten
Kommentar:
← Revision 11 vom 2009-07-16 14:11:09 → ⇥
Größe: 2264
Autor: Lars Stetten
Kommentar:
Gelöschter Text ist auf diese Art markiert. Hinzugefügter Text ist auf diese Art markiert.
Zeile 3: Zeile 3:
Konzept: Sowohl Hobby-Entwickler, Firmen als auch Distributoren sollen die Chance bekommen ihre Software auf Barrierefreiheit zu testen. Dazu haben wir einen Kriterienkatalog erarbeitet, anhand dessen
eine Bewertung stattfinden kann.
Neben schon existierenden Applikationen sollen besonders Entwickler motiviert werden, ihre selbst geschriebene Software auf Zugägnlichkeit zu testen.
Zeile 5: Zeile 7:
Sowohl Hobby-Entwickler, Firmen als auch Distributoren sollen die Chance bekommen ihre Software zu testen. Dazu wird ein Kriterienkatalog erarbeitet, anhand dessen
eine bewertung stattfinden soll und Verbesserungsvorschläge gemacht werden können. Denkbar wären z.B. das Testen von Installationsroutinen aktueller Distributionen wie Ubuntu, Mandriva, Debian oder Suse, Testen von zentraler Software sowohl auf der Konsole als auch unter X11, dazu zählt z.B. mc, evolution, firefox oder OpenOffice.
Besonders motiviert sollen aber Entwickler werden, die ihre selbst geschriebene Software auf Zugägnlichkeit testen wollen.

Kriterienkatalog		 === Kriterienkatalog ===

Accessibility-Tests für Entwickler

Sowohl Hobby-Entwickler, Firmen als auch Distributoren sollen die Chance bekommen ihre Software auf Barrierefreiheit zu testen. Dazu haben wir einen Kriterienkatalog erarbeitet, anhand dessen eine Bewertung stattfinden kann. Neben schon existierenden Applikationen sollen besonders Entwickler motiviert werden, ihre selbst geschriebene Software auf Zugägnlichkeit zu testen.

Kriterienkatalog

  • alle Funktionen per Sprache oder Braille nutzen
  • alle Funktionen per Tastatur bedienbar
  • Tastatur-Kürzel
  • logische Tab-Reihenfolge
  • keine Störungen mit anderen Keyboard-Features
  • Hilfsmittelsoftware müssen genug Informationn über User-Interface Objekte erhalten
  • Zu den Icons müssen Text-Informationen verfügbar sein
  • Icons sollten konsistent eingesetzt werden (d.h. die Symbole mit gleichem aussehen sollten anwendungsübergreifend die gleiche Funktion ausüben)
  • für alle Sounds sollte es eine visuelle Rückmeldung geben (für Gehörlose)
  • Sounds sollten abgestellt werden können und die Lautstärke muss einstellbar sein
  • der Textinhalt, Texteingaben, Ort des Cursors und Textattribute sollten an Hilfsmittelsoftware übermittelt werden
  • Informationen und auswahl Elemente sollten nicht ausschliesslich über Farben kenntlich gemacht werden, sondern auch textuell unterscheidbar sein.
  • die Schriften und Farben sollten individuell einstellbar sein
  • es sollte kein Zeitmimit für Eingabefelder oder Textmeldungen geben
  • wichtige Funktionen sollten auf verschiedene Arten verfügbar gemacht werden (z.B. Text-Menüpunkt, Icon, Tastenkombination)
  • alle Steuerelemente sollten Textlabels haben
  • Textlayouts sollten einspaltig sein
  • Buttons sollten logische Namen und Reihenfolge haben

Mögliche Projektpartner

  • Open Usability
  • Sun

Mögliche Durchführung:

Die Basis für jede Bewertung ist der Kriterienkatalog

  • während einer Messe: Entwickler können am Stand ihre Software live testen lassen
  • im Rahmen eines Vereins-Workshops: Im Rahmen eines Workshops beschäftigen sich alle Teilnehmer z.B. eine Wochenende mit dem Testen verschiedener Software
  • erfahrene Anwender testen eine ihnen vertraute Software

LinAccess/Projekte/Ally-Tests] (zuletzt geändert am 2009-07-18 09:54:19 durch Lars Stetten)