Einführung BIT inklusiv Anwendungssoftware-Test

Aus BIT inklusiv Wiki und Test-Case-Datenbank
Version vom 10. Dezember 2016, 15:57 Uhr von Admin (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Vorbemerkung

Das Prüfverfahren bezieht sich auf Anwendungs-Software. Es stellt einen Katalog von Erfolgskriterien und Prüfanleitungen zur Verfügung, die zur Ermittlung der Barrierefreiheit einer Anwendung dienen. Die Erfolgskriterien sind aus den Richtlinien EN 301549 und ISO 9241-171 abgeleitet und technik-neutral formuliert, sie sind grundsätzlich auf alle Betriebssystem-Umgebungen anwendbar. Die praktischen Prüfanleitungen mit den darin verwendeten Prüftools sind technik-spezifisch, sie beziehen sich beim jetzigen Stand des Verfahrens ausschließlich auf das Windows-Betriebssystem, wobei Desktop-Rechner mit Standard-Display, Tastatur und Maus eingesetzt werden. Touch-Bedienung wurde vorerst nicht berücksichtigt.

Testausstattung

Befragung zu technischen Voraussetzungen

Im Vorfeld einer Prüfung sollten die technischen Voraussetzungen geklärt werden. Hierzu zählen neben der empfohlenen Rechner-Ausstattung unter anderem auch Angaben über bereits erfolgte Bemühungen im Bereich Barrierefreiheit, die empfohlene Hilfsmittelausstattung etc. Der für diesen Zweck vorbereitete Fragebogen wird an den Kunden geschickt. Ein beantworteter Fragebogen ist Test-Voraussetzung. Folgende Kriterien sollten mindestens erfasst werden:

  • Rechner-Konfiguration (Rechner, Betriebssystem, Bildschirm-Auflösung)
  • Konfiguration der Anwendung für die Nutzung mit assistiven Technologien
  • ggf. spezielle Produkte (Screenreader, Vergrößerungssoftware), mit denen die Anwendung entwickelt wurde oder die im Betrieb eingesetzt werden
  • ggf. Scripte für spezielle Produkte (Screenreader, Vergrößerungssoftware)
  • ggf. Programmiersprache und GUI-Framework, mit denen die Anwendung entwickelt wurde
  • Erklärung des Auftraggebers, mit welcher Hilfsmittelausstattung getestet werden soll:
    a) spezielle Ausstattung nach Angaben des Herstellers, und/oder
    b) Standard-Testtools des Prüfverfahrens
  • Umfang und Art der Dokumentation
  • in den Test einzubeziehende Bereiche der Anwendung

Der Auftraggeber muss darüber informiert werden, dass eine Prüfung nur mit spezieller Hilfsmittelausstattung nicht als Konformitätsprüfung (s.u. „Konformitätsstufen“) gewertet werden kann.

Genaueres kann dem Fragebogen zur Vorbereitung einer Prüfung von Anwendungssoftware auf Barrierefreiheit entnommen werden (Download, Word-Datei).

Werkzeugliste

Tool die Bestandteil des Windows-SDK sind, kann man nach der Installation des SDK unter dem Pfad C:\Programme\Windows Kits\8.1\bin\x64 (bzw. x86 oder arm, je nach Systemarchitektur) finden.

Bildschirmlineal: bisher am besten geeignet ist das kostenpflichtige Tool von Keseling https://www.keseling.de/sli.htm. Das Lineal muss mit einem physischen Lineal kalibriert werden, die Kalibrierung muss bei einer Änderung der Auflösung oder der Textgröße (dpi) wiederholt werden.

Testsystem

Die Anwendung wird in einem Testsystem mit Hilfsmitteln und Testtools installiert. Die Ausstattung wird im Prüfbericht dokumentiert.

  • Windows-Version nach Stand der Technik – nicht die allerneueste, sondern die neueste mit Hilfsmitteln gut eingeführte. Nicht älter als Win7 wg. Inspect.
  • RAM und Massenspeicher nach Bedarf der Anwendung
  • Standard-Bildschirm
    • Flachbildschirm, keine Retina-Auflösung (wegen Vergleichbarkeit der Vergrößerungsfunktionen)
    • Größe der nutzbaren Bildfläche mindestens 332 x 199,2 mm. Dies wird erreicht bei handelsüblichen Widescreens im Seitenverhältnis 16:9 bei einer Bildschirmdiagonale ab 16“. Ebenfalls geeignet sind der etwas kleinere ältere Widescreen-Standard WSXGA+ im Seitenverhältnis 16:10 bei einer Bildschirmdiagonale von 15,4“ sowie der Bürostandard SXGA im Seitenverhältnis 5:4 bei einer Bildschirmdiagonale von 17“. Größere Bildschirme erlauben eine komfortablere Handhabung.
      Marktübersicht siehe http://www.elektronik-kompendium.de/sites/com/1904101.htm
    • Native Auflösung des Displays beibehalten (der empfohlene Wert unter Systemsteuerung\Anzeige\Bildschirmauflösung)
    • Schriftgröße einstellen
      • Keseling Bildschirmlineal kalibrieren (siehe Werkzeugliste)
      • Schriftgröße im Windows Desktop messen: soll laut DIN mindestens 2,9 mm hoch sein (Höhe der der Großbuchstaben E, Z etc., Außenmaß).
      • Falls Schriftgröße nicht ausreichend: dpi-Einstellung ändern. In Win7 unter Systemsteuerung\Anzeige\Benutzerdefinierte DPI-Einstellung, in Win10 unter Systemsteuerung -> Anzeige -> Link "eine benutzerdefinierte Skalierungsstufe festlegen". Hier kann ein frei wählbarer Wert eingetragen werden.
      • Vor erneutem Messen Bildschirmlineal kalibrieren.
      • Anmerkung: Der Standard-Bildschirm ist auf einen Sehabstand von 50 cm ausgerichtet. Größere Bildschirme ab 19“ sollten laut DIN in größerer Entfernung aufgestellt und mit größerer Schrift betrieben werden, dies kann in der Prüfung ignoriert werden.
    • Fenstergröße einstellen
      • Im Sizer (siehe Werkzeugliste) die Größe des Anwendungsfensters auf 1280x768px einstellen, oder auf die für die Anwendung empfohlene Mindestauflösung, falls diese größer sein sollte.
      • Die Begrenzung des Fensters sollte zu sehen sein, andernfalls größeren Bildschirm verwenden.
    • Anmerkung: Falls die Anwendung im Standard-Bildschirm mit unscharfen oder pixeligen Zeichen dargestellt wird, kann vermutlich die DPI-Einstellung nicht richtig ausgewertet werden. Dem Software-Hersteller ist Gelegenheit zu geben, einen Bildschirm mit ausreichender Zeichengröße und scharfer Zeichendarstellung zu empfehlen.
  • Soundkarte, soweit die Anwendung mit Ton arbeitet
  • Verzicht auf Virenscanner u.ä. Hintergrundprogramme, soweit möglich
  • zu testende Anwendung mit Peripherie wie für das Szenario erforderlich, u.a.
    • Drucker-Installation ohne Hardware, z.B. PDF-Drucker
    • Internet-Zugang mit Virenscanner
    • weitere Kommunikationskanäle
  • Konfiguration der Anwendung für die barrierefrei Nutzung nach Angaben des Herstellers
  • ausreichende Testdaten wie für das Szenario erforderlich
  • Hilfsmittelausstattung nach Angaben des Auftraggebers/Herstellers
  • Standard-Testtools des Prüfverfahrens (siehe Werkzeugliste)

Technische Prüfung

= Testverfahren Teil I

  1. Konnten Screenreader und Testtools im Testsystem vollständig installiert werden? Falls nein– Abbruch der Prüfung.
  2. Stichprobenartige Anwendung des Prüfschritts 4.01.0 mit Screenreader NVDA: liest er die sichtbaren Texte (Beschriftungen, Inhalte) der Anwendung größtenteils vor? Falls nein – Abbruch der Prüfung.

Dokumentenprüfung

= Testverfahren Teil II

Dokumentation der Tastaturkommandos

EN 301549 Nr. 12.1.1 Accessibility and compatibility features

1. Sichtprüfung: Handbücher bzw. Online-Hilfen enthalten ein Verzeichnis der Tastaturkommandos in zusammenhängender Darstellung. Falls nicht vorhanden: Feststellen, ob die Anwendung Tastaturkommandos direkt in der Bedienoberfläche nennt oder als kontextsensitive Hilfe punktuell anbietet.

Barriere / Abbruch der Prüfung: Eine Dokumentation der Tastaturkommandos ist nicht verfügbar.

Einschränkung: Tastaturkommandos werden ausschließlich in der Bedienoberfläche der Anwendung oder als kontextsensitive Hilfe dokumentiert.

2. Die Richtigkeit und Vollständigkeit der Dokumentation kann im Rahmen der Dokumentenprüfung nicht festgestellt werden. Diese Anforderung aus DIN EN 82079 Erstellen von Gebrauchsanleitungen wird exemplarisch in der praktischen Prüfung im Prüfschritt „Vollständige Dokumentation der Tastaturkommandos“ geprüft. Das Ergebnis dieses Prüfschritts geht in das Ergebnis der praktischen Prüfung ein und wird zusätzlich im Ergebnis der Dokumentenprüfung berichtet.

Beschreibung der Accessibility-Features

EN 301549 Nr. 12.1.1 Accessibility and compatibility features

Erforderlich ist eine Beschreibung der für Menschen mit Behinderungen eingerichteten Bedienfunktionen (Vergrößerung, Orientierungspunkte, etc. (weiter ausführen).

Barrierefreiheit von Dokumentation und Dienstleistungen

EN 301549 Nr. 12.1.2 Accessible documentation

  1. Praktische Prüfung: Handbücher und Online-Hilfen sind in zugänglichem Format, d.h. die Anforderungen für barrierefreie Dokumente sind eingehalten. Verlinktes Inhaltsverzeichnis und Suchfunktion sind vorhanden. Hierzu werden die entsprechenden formatspezifischen Prüfverfahren herangezogen, u.a. BITV-Test, PDF-Accessibility-Test.
  2. Praktische Prüfung: Die Dokumentation ist über die Bedienoberfläche der Anwendung zugänglich. Hierzu werden die entsprechenden Prüfpunkte der Praktischen Prüfung = Teil III des Testverfahrens herangezogen.
    1. Ein Link zur Dokumentation ist in jedem Arbeitsschritt verfügbar. Beispiel: Die Anwendung hat im Hauptmenü einen Punkt „Hilfe“ mit dem Unterpunkt “Tastaturbefehle”.
    2. Der Link zur Dokumentation ist mit Tastatur und Screenreader bedienbar.
  3. Internetquellen, soweit darauf zur Dokumentation verwiesen wird, sind barrierefrei entsprechend WCAG Level AA. Test: BITV-Test.

ISO 9241-171 Nr. 11.2.1 Zugängliche Unterstützungsdienste zur Verfügung stellen: Sofern Support mit eingekauft wurde, muss dieser barrierefrei erfolgen. Herstellerbefragung.

Praktische Prüfung

= Testverfahren Teil III

Generelles Vorgehen

Die Prüfung muss im Vergleich mit dem BITV-Test eine höhere Komplexität bewältigen. Wir haben zwei Listen abzuarbeiten, a) den Arbeitsablauf im Sample (Szenario/Drehbuch), b) die Erfolgskriterien/den Prüfkatalog. An sich müssten die Listen kreuzweise kombiniert werden, d.h. bei jedem Erfolgskriterium ist das komplette Szenario abzuarbeiten, oder anders herum bei jedem Arbeitsschritt der komplette Prüfkatalog. Das ergäbe eine unüberschaubare Datenfülle und wäre nicht praktikabel. Im Mikro-Handling entsteht noch eine dritte Folge nach dem eingesetzten Testtool bzw. der Bearbeitungsmodalität: normale Darstellung, Mausbedienung, Tastaturbedienung, Screenreader-Darstellung, Kontrastmodus, Vergrößerung. Wie kann diese Komplexität in einen Ablauf gebracht werden?

Das Testverfahren stellt Hilfen für die praktische Durchführung der Prüfung bereit:

  1. Der Prüfkatalog ist nach den Bearbeitungsmodalitäten gegliedert, hierdurch werden praktisch zusammenhängende Prüfpunkte gruppiert, so dass die Anzahl der Durchläufe durch das Szenario reduziert werden kann.
  2. Das Prüftool/Prüfprotokoll enthält die Möglichkeit, bei jedem Prüfpunkt für jedes auffällige UI-Element des Szenarios eine Protokollzeile einzufügen. Hierdurch kann das Prüfprotokoll auch nach Kriterien der Anwendung sortiert und zusammengefasst werden.

Sample / Szenario / Drehbuch

= Testverfahren Teil III A

Mit Ausnahme einfacher Apps wird eine Anwendung niemals vollständig geprüft werden können. Es bedarf einer Auswahl typischer Elemente der Anwendung (Sample). Um eine relevante Auswahl zu treffen, geht man in Anlehnung an das Vorgehen bei Usability-Reviews von typischen Arbeitsaufgaben/ Use Cases aus, für die die Anwendung üblicherweise eingesetzt wird (Szenario). Die Arbeitsschritte des Szenarios werden als Drehbuch festgelegt und so detailliert wie nötig aufgeschrieben. Das Drehbuch ist während des Tests mehrfach abzuarbeiten.

Je nach Komplexität der Anwendung können die wesentlichen Use Cases anhand der Dokumentation ermittelt oder in Zusammenarbeit mit dem Auftraggeber der Prüfung oder mit erfahrenen Anwendern erarbeitet werden. Ein allgemeiner Teil kann formuliert werden, um immer vorkommende UI-Elemente, z.B. das Hauptmenü, zu isolieren und Dopplungen in der Feststellung von Mängeln zu vermeiden. Eine Zufallsstichprobe ist zusätzlich erforderlich, um mit begrenztem Aufwand eine Aussage über die gesamte Anwendung machen zu können.

Bei der Erstellung der Use Cases muss sich der Prüfer die fachlichen Inhalte der Anwendung soweit aneignen, dass er die Prüfschritte des Prüfkatalogs darauf anwenden kann. Ein inhaltliches Verständnis ist z.B. erforderlich für die Prüfschritte 1.05.1 „Prägnante Beschriftungen“ und 2.07.1 „Hilfen bei Fehleingaben“.

Über das Sample kann der Aufwand der Prüfung gesteuert werden. Eine vollständige Prüfung der Anwendung mit dem Ziel, alle Fehler zu finden, kann im Rahmen der betrieblichen Qualitätssicherung implementiert werden. Für einen Konformitätstest muss eine Auswahl nach standardisiertem Verfahren getroffen werden, wobei die Entscheidung über das Sample beim Prüfer liegt. Für einen Basistest (s.u. „Konformitätsstufen“) kann das Szenario je nach Beratungsauftrag stichprobenartig verkürzt werden.

Regeln für die Erstellung eines Drehbuchs

Typische Arbeitsaufgaben: Wähle exemplarische Arbeitsaufgaben, die für die Anwendung charakteristisch sind und am häufigsten genutzt werden. Beispiel: bei einem E-Mail-Client teste das Senden und Beantworten von E-Mails, nicht die Konfiguration der Internetverbindung. Marginale Programmfunktionen kommen erst dran, wenn die zentralen ausreichend getestet sind.
Wähle Arbeitsaufgaben, die im Prinzip auch von Menschen mit Behinderungen ausgeführt werden können, d.h. nicht wesentlich auf der Kontrolle grafischer oder akustischer Inhalte beruhen. Beispiel: den Zuschnitt von Bildern können Blinde und hochgradig Sehbehinderte auch dann nicht ausführen, wenn die entsprechenden Bedienelemente der Software für sie zugänglich sind.

Typischer Ablauf: Erfasse vollständige Abläufe, vom Erkunden des Bildschirms über den Aufruf einer Funktion, Kontrolle der notwendigen Einstellungen, Nutzereingaben, Meldungen der Anwendung, Ergebnis der Aufgabe. Neben dem positiven Ablauf provoziere auch Störungen und Fehlersituationen: Fehleingaben in Formularen, Abbruch von Programmfunktionen.

Typische UI-Elemente: Erfasse die UI-Elemente entlang des typischen Ablaufs vollständig. Achte auf die Übergänge zwischen den Bildschirmen und Programmsituationen. Stelle sicher, dass alle vorkommenden Typen von UI-Elementen im Sample repräsentiert sind. Falls erforderlich ergänze den typischen Ablauf um einzelne Programmsituationen.

Zufällige UI-Elemente: Während des Tests überprüfe stichprobenartig auch Elemente, die nicht zum typischen Ablauf gehören. Wenn ausreichend Zeit ist, überprüfe alle Bedienelemente und Anzeigen der ausgewählten Bildschirme/Masken/Dialoge. Ziel ist es, Abweichungen von der Standardausführung von UI-Elementen, Flüchtigkeitsfehler und Probleme bei erratischen Interaktionen zu entdecken.

Ausreichende Testdaten: Wähle ausreichend komplexe Testdaten. Beispiel: in einer Suchfunktion gib ein Suchwort ein, das eine mehrseitige Ergebnisliste ergibt. Manche Probleme treten in einfachen Fällen nicht auf, z.B. mehrfache gleich benannte Buttons edit/löschen etc.
Sorge dafür, dass Abläufe mehrmals in vergleichbarer Form wiederholt werden können, z.B. durch eine ausreichende Menge an Testdaten.

Flexible Detailtiefe: Detailliere das Drehbuch während des Tests. Bei Auffälligkeiten gehe einen Schritt tiefer ins Detail als bei positivem Ergebnis. Beispiel: Ein Button ist im Screenreader nicht als Button deklariert. Bediene den Button, auch wenn dieser Schritt im typischen Ablauf nicht vorgesehen ist, um ggf. mehr Informationen über den zugrundeliegenden Fehler zu erhalten.

Prüfkatalog / Erfolgskriterien / Prüfschritte

= Testverfahren Teil III B

Zugrundeliegende Standards / Konformitätsstufen

Die Erfolgskriterien sind unterteilt in 3 aufeinander aufbauende Stufen.

  • Stufe 0 = Basistest. Stufe 0 ist keine Konformitätsstufe, sondern kann als niedrigschwelliges Beratungsangebot aus der Gesamtprüfung herausgelöst und als Praxistauglichkeitstest verwendet werden.
  • Stufe I = Konformität nach EN 301 549, Richtlinie für IT-Beschaffungen im öffentlichen Dienst.
  • Stufe II = ergonomische Ergänzungen nach ISO 9241-171, Bildschirmarbeitsverordnung.

Der Basistest (Stufe 0) wurde konzipiert, um mit relativ geringem Aufwand eine Aussage über den Stand der Barrierefreiheit einer Anwendung treffen zu können. Hiermit soll der gegenwärtig in der betrieblichen Praxis verbreiteten Situation Rechnung getragen werden, dass die Anpassung von Software an Hilfstechniken wie Screenreader und Vergrößerungssoftware mangelhaft oder uneinheitlich umgesetzt ist. Der Basistest enthält einige grundlegende Kriterien und kann, in Verbindung mit der vom Hersteller der Software empfohlenen Hilfsmittelausstattung (s.o. „Befragung zu technischen Voraussetzungen“), als Test auf Basis-Zugänglichkeit angesehen werden.

Stufe I – Konformität nach EN 301549 – enthält den für die Standardkonformität entscheidenden Schnittstellentest, die Bedienung der Accessibility-Schnittstellen des Betriebssystems. Eine Konformitäts-Aussage kann nur getroffen werden, wenn die gesamte Prüfung (auch Stufe 0) mit den im Verfahren festgelegten Standard-Testtools und ohne produktspezifische Screenreader-Skripte durchgeführt wurde. Eine spezielle, vom Hersteller oder vom einsetzenden Betrieb gewünschte Hilfsmittelausstattung kann zusätzlich in einem separaten Prüfdurchgang verwendet werden, dessen Ergebnisse nicht in die Konformitäts-Aussage eingehen.

Im Prüfbericht muss die verwendete Hilfstechnik und ggf. das Vorliegen einschränkender Hersteller-Empfehlungen für die Hilfsmittelausstattung deutlich dokumentiert werden.

Gliederung des Prüfkatalogs

Das Prüfverfahren führt verschiedene Standards zusammen, benötigt daher eine eigene übergeordnete Logik.

Der Prüfkatalog folgt einer zweiten Ordnung, er steuert den Ablauf der praktischen Prüfung. Der Prüfkatalog gruppiert die Prüfschritte nach Bearbeitungsmodalitäten. Durch die Zusammenfassung von Prüfschritten mit gleichartiger Prüftechnik können die Wiederholungen des Szenarios in der Abarbeitung des Prüfkatalogs reduziert werden, idealerweise auf einen Durchlauf je Gruppe.

Die Nummern der verschiedenen Bezugssysteme – Prüfkatalog, Konformitätsstufen, Standards – werden bei den einzelnen Prüfschritten vermerkt. So können die Prüfpunkte und Testergebnisse flexibel nach verschiedenen Gesichtspunkten sortiert werden.

Bearbeitungsmodalitäten

Abschnitte des Prüfkatalogs:

  1. Sichtprüfung bei normaler Darstellung
  2. Bedienung mit Zeigegeräten (Maus, Touch)
  3. Bedienung mit Tastatur
  4. Darstellung im Screenreader
  5. Personalisierte visuelle Darstellung
  6. Personalisierte Eingabe
  7. Standardkonforme Programmierung

Für Touch und für Spracheingabe wird die Ausarbeitung zurückgestellt, da aktuell eine rasche technische Entwicklung stattfindet, die abzuwarten ist. Im Prüftool werden entsprechende Prüfschritte ohne Bewertung eingestellt, die als Sammelpunkt für Beiträge der Fachcommunity dienen sollen.

Es ist zu betonen, dass diese Einteilung der Prüfschritte sich aus der Laborsituation der Prüfung ableitet und nicht die reale Hilfsmittelnutzung der behinderten Anwender abbilden will. Es geht darum, Erfolgskriterien adäquat und effizient zu testen.

Nummerierung

Da die Prüftechnik dem technischen Wandel unterworfen ist, muss die Gliederung des Prüfkatalogs veränderbar sein. Die Nummerierung muss erweiterbar sein, d.h. auf jeder Ebene offene Stellen enthalten. So können Ergänzungen und Veränderungen eingeordnet werden, ohne gleich das ganze System zu reorganisieren.

Aufbau eines Prüfpunktes

Prüfpunkt = Test eines Erfolgskriteriums. Die Begriffe Prüfpunkt und Prüfschritt werden synomym gebraucht. „Prüfpunkt“ betont die Unabhängigkeit eines Erfolgskriteriums, „Prüfschritt“ die Einordnung in eine sinnvolle Reihenfolge.

Aufbau in Anlehnung an den BITV-Test.

  • Nummer im Prüfkatalog
  • Name
  • Konformitätsstufe
  • Beschreibung - Technikneutrale Beschreibung des Erfolgskriteriums
  • Beispiele – Typische Anwendungsbeispiele aus verschiedenen Plattformen
  • Begründung – Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen
  • Anwendbarkeit – manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar
  • Prüfanleitung – Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests
  • Bewertungsalternativen – nicht anwendbar, erfüllt, nicht erfüllt. Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade“, „Barriere“ und „Einschränkung“
  • Einordnung – Abgrenzung zu anderen Prüfschritten
  • Offene Fragen– Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen
  • Referenznummern zu WCAG, EN301549, ISO9241-171, Synopse.
  • Weitere Quellen: WCAG Techniques, BITV-Test, andere Standards, wiss. Literatur

Bewertung

Die Bewertung der Software findet nicht, wie im BITV-Test, summarisch je Prüfschritt statt. Bewertet werden einzelne Befunde, bezogen auf einzelne UI-Elemente, nach „erfüllt“ und „nicht erfüllt“.

3-stufige Bewertung von nicht erfüllten Prüfschritten: Blockade, Barriere, Einschränkung .

  • Blockade: a) Störung, die die Nutzbarkeit der gesamten Anwendung beeinträchtigt,
    b) wesentliche Funktion nicht ausführbar, alternativer Weg nicht verfügbar
  • Barriere: a) marginale Funktion nicht ausführbar, b) wesentliche Funktion fehlerhaft ausgeführt, aber Alternative vorhanden.
  • Einschränkung: Orientierungs-/Darstellungsproblem, Bedienung erfordert dauerhaft, d.h. auch nach Einweisung, vermeidbaren Aufwand.

Demnach wären Blockaden als „nicht zugänglich“ und Barrieren/Einschränkungen als „zugänglich, aber ineffizient“ einzuordnen.

Die Bewertung zu „Blockade/Barriere“ orientiert sich an der Situation des routinierten Anwenders, der die Bedienoberfläche kennt. Die Bewertung zu „Einschränkung“ orientiert sich an der Situation des seltenen Nutzers, der die angebotenen Funktionen im Prinzip kennt, sich aber orientieren muss, um die Bedienelemente wiederzufinden. Nicht berücksichtigt wird die Situation des Novizen, der die Anwendung nicht kennt und alleine erkunden möchte. Zur Beurteilung der Erlernbarkeit muss in unserem Rahmen die Prüfung der Dokumentation ausreichen.

Die Bewertung bezieht sich auf Einzelbefunde, eine Zusammenfassung der Einzelbefunde je Prüfschritt bzw. ein Gesamtergebnis der Prüfung sind im bisherigen Stand des Verfahrens nicht vorgesehen. Ein aussagekräftiges Ergebnis der Prüfung entsteht aus einer Auszählung bzw. Auflistung der vorgefundenen Blockaden, Barrieren und Einschränkungen. Dopplungen (dasselbe UI Element für dasselbe Erfolgskriterium mehrmals bemängeln) sollten ausgeschlossen werden, um belastbare Kennwerte zu gewinnen. Hierauf ist im Szenario zu achten. Im Prüfkatalog wird in der Abgrenzung der Prüfpunkte auf Überschneidungen und Anschlüsse aufmerksam gemacht.

In einer Weiterentwicklung des Verfahrens kann ein numerisches Ergebnis (Score) der Prüfung eingeführt werden. Ein Ansatz hierzu könnte sein, die bemängelten Elemente zu der Grundgesamtheit aller Elemente der Anwendung ins Verhältnis zu setzen (prozentualer Wert). Ein Verfahren zur Ermittlung der Grundgesamtheit wäre zu erproben.

Abbruchbedingungen werden in der praktischen Prüfung nicht definiert. In den vorgelagerten Prüfungen und durch die Basisstufe 0 gibt es ausreichende Möglichkeiten, „Showstopper“ mit begrenztem Aufwand festzustellen. Sollte im Einzelfall dennoch ein Zustand eintreten, der den Abbruch der Prüfung rechtfertigt, so ist dies im Prüfbericht zu begründen und detailliert zu dokumentieren.

Prüfprotokoll / Reporting-Tool

Das Reporting-Tool wird als Datenbankanwendung entwickelt. Es enthält Eingabeformulare zur Erfassung des Prüfprotokolls sowie verschiedene Reports zur Auswertung der Ergebnisse.

Die Erfassung des Prüfprotokolls folgt den Prüfschritten des Prüfkatalogs, die nach Bearbeitungsmodalitäten gegliedert sind. Zu jedem Prüfschritt wird vermerkt, ob er anwendbar ist oder nicht. Zu jedem Prüfschritt können Fundstellen zugeordnet werden, je Fundstelle eine Protokollzeile/Datensatz. Fundstellen sind UI-Elemente oder Programmsituationen, in denen ein Mangel festgestellt wurde. Der Prüfer trägt die Fundstellen nach der Reihenfolge des Szenarios ein und notiert einen Kommentar sowie die Bewertung des Mangels (Blockade, Barriere, Einschränkung). Der Prüfschritt ist erfüllt, wenn keine Mängel aufgetreten sind. Es können auch Fundstellen ohne Bewertung eingetragen werden, wenn derselbe Sachverhalt bereits in einem früheren Prüfschritt gewertet wurde, oder um Beobachtungen mitzuteilen, die ein „nicht erfüllt“ nicht rechtfertigen würden.

Mängel sind per Screenshot zu dokumentieren. Das Reporting-Tool bietet idealerweise eine Möglichkeit, Screenshots und Screencasts incl. Ton anzufertigen und bei der jeweiligen Protokollzeile abzurufen.

Prüfbericht

Der Prüfbericht umfasst

  • Den Prüfauftrag (Konformitätsstufe, ggf. ausgeschlossene Teile der Anwendung)
  • Die technische Ausstattung der Prüfung, speziell die eingesetzten assistiven Technologien
  • Ggf. Hinweis auf Herstellerempfehlungen für die Hilfsmittelausstattung
  • Das Ergebnis der Dokumentenprüfung
  • Das Szenario (typische Arbeitsaufgaben), nach dem geprüft wurde
  • Anzahl der festgestellte Mängel, gegliedert nach Schweregrad (Blockade, Barriere, Einschränkung)
  • Ggf. Gründe für einen Abbruch der Prüfung
  • Eine Aussage, ob die Konformitätsprüfung bestanden wurde, kann nach gegenwärtigem Stand des Verfahrens nur dann erteilt werden, wenn keine Mängel festgestellt wurden.

Zu diskutieren wäre, ob eine Auswertung nach Art der Behinderung gewünscht wird. Nach dem Beispiel eines Mitglieds im Expertenkreis (T-Systems Multimedia Solutions Accessibility Test Center) könnten Mängel nicht nur nach Schweregrad, sondern zusätzlich nach Art der Behinderung klassifiziert werden. Hierfür wäre der Prüfkatalog entsprechend zu erweitern. Bei jedem Prüfpunkt wären die betroffenen Behinderungen anzugeben, wobei zumeist mehrere in Frage kommen. Die Zuordnungen wären aus Understanding WCAG sowie aus ISO9241-171 abzuleiten.

SW-Feature Blinde Sehbehindert Tastaturnutzer Kognitiv Behinderte
Feature N A C B
  • Legende: A= Blockade, B= Barriere, C = Einschränkung

Literatur

Abgerufen von „https://biti-wiki.de/index.php?title=Einführung_BIT_inklusiv_Anwendungssoftware-Test&oldid=1339“