Digital informiert - im Job integriert - Di-Ji

Brotkrümmelpfad

Inhaltsbereich

Das Rahmenkonzept des Aktionsbündnisses für barrierefreie Informationstechnik zur Überprüfung von Barrierefreiheit entstand noch vor der Verabschiedung der Barrierefreien Informationstechnik-Verordnung - BITV 2.0. Prinzipiell kann das Rahmenkonzept mit drei aufeinander aufbauenden einzelnen Testverfahren bestehen bleiben. Die einzelnen Testverfahren müssen jedoch dabei an den gegenwärtigen Stand der Techniken angepasst werden.

Kritik am Vorprüfungstest

Der Vorprüfungstest wurde vom Aktionsbündnis für barrierefreie Informationstechnik in zwei Versionen angeboten: in einer Version zur damals gültigen BITV und in einer Version gemäß des damaligen Entwurfs der Web Content Accessibility Guidelines - WCAG 2.0 . Seit Verabschiedung der BITV 2.0 in Anlehnung an die WCAG 2.0 sollte nur noch ein Vorprüfungstest nach WCAG 2.0 durchgeführt werden.

Leider enthält diese Version des Vorprüfungstests keine Angaben zu Rahmenbedingungen wie zur Qualifikation der Prüfer, zu zeitlichen Angaben oder zur erforderlichen Testdokumentation.

Ebenso fehlt die Berücksichtigung der Anforderungen von Menschen mit Lernschwierigkeiten und hörbehinderten Menschen. Eine detaillierte Überprüfung dieser in Anlage 2der BITV 2.0 beschriebenen Anforderungen sollte innerhalb des dreistufigen Rahmenkonzepts in den Überprüfungen der Stufe 2 (BITV-Kurztest) und Stufe 3 (Hauptprüfung) erfolgen. Im Rahmen des Vorprüfungstests sollte aber zumindest überprüft werden ob überhaupt Angebote in Leichter Sprache oder in Gebärdensprache vorliegen.

Mit insgesamt 17 Prüfanweisungen ist der Vorprüfungstest des Aktionsbündnisses für barrierefreie Informationstechnik für eine kurze und bewusst oberflächliche Ersteinschätzung schon recht detailliert. Zum Vorprüfungstest gibt es drei Alternativen:

• die weniger aufwendige Durchführung eines Tests mit automatischen Prüfwerkzeugen,
• die Durchführung von wenigen und sehr leichten manuellen Überprüfungen zur Barrierefreiheit,
• die etwas aufwendigere Durchführung einer Selbstbewertung mit allen BITV-Test-Prüfpunkten.

Prüfwerkzeuge wie zum Beispiel Wave oder als Firefox-Add-On ) oder der egovmon eAccessibility Page Check überprüfen einige Aspekte der Barrierefreiheit automatisch. Automatische Prüfwerkzeuge haben einige Mängel und werden vermutlich nie Barrierefreiheit vollständig überprüfen können. Für eine erste Einschätzung der eingehaltenen Barrierefreiheit kann eine solche automatische Überprüfung aber durchaus genügen.

Um einen ersten Eindruck über die Zugänglichkeit von Webseiten zu erhalten können auch einfache und leicht durchführbare manuelle Überprüfungen durchgeführt werden (eine kurze Anleitung zu „Easy Checks“, liegt als W3C-Editor-Entwurfsversion vor: Easy Checks - A First Review of Web Accessibility).

Mit dem frei verfügbaren Bewertungswerkzeug BaNu (Barrieren finden, Nutzbarkeit sichern) des Bundesverwaltungsamtes oder mittels einer BITV-Test-Selbstbewertung können Tests zur Überprüfung der eingehaltenen Barrierefreiheit prinzipiell von jeder IT-Abteilung selbst durchgeführt werden.

Sowohl bisheriger Vorprüfungstest, als auch die genannten automatischen Bewertungswerkzeuge, die „Easy Checks“ des W3C und die Selbstbewertung beziehen sich ausschließlich auf Webseiten, und sind nicht ohne weiteres auch auf (Desktop-) Anwendungen übertragbar. Im folgenden Abschnitt „Ergänzungen zum Vorprüfungstest“ wird eine überarbeitete Fassung des AbI-Vorprüfungstests vorgestellt.

Ergänzung zum Vorprüfungstest

Dieser Artikel stellt eine vom Projekt Di-Ji überarbeitete Fassung des AbI-Vorprüfungstests auf Basis der WCAG 2.0 vor.

Vorwort

Der vorliegende Test basiert auf den WCAG 2.0 und dem Entwurf EN 301 549 ("Accessibility requirements for public procurement of ICT products and services in Europe"). Die Prüfschritte wurden so gewählt, dass grundlegende Ansprüche an die Zugänglichkeit einer Website oder einer Anwendung gewährleistet sind. Dabei wurde darauf geachtet, dass sowohl zu den 4 Grundprinzipien Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit, als auch für unterschiedliche Arten der Behinderung Prüfschritte ausgewählt wurden.

Die in den vorgeschlagenen Prüfschritten beschriebenen Testverfahren orientieren sich an denen des bisher vorliegenden BITV-Tests sowie an den von der WAI des W3C veröffentlichten Techniques zur WCAG 2.0.

Ziel des Vorprüfungstests

Ziel des empfohlenen Vorprüfungstests ist, einen ersten Eindruck von einem Webauftritt oder einer grafischen Programmoberflächen zu erhalten. Der hier empfohlene Vorprüfungstest ist im Zusammenhang mit dem Konzept zu sehen, das im Abschnitt: Rahmenkonzept zur Prüfung näher erläutert ist.

Mit Hilfe dieses Vorprüfungstests kann nicht festgestellt werden, ob ein Internetangebot oder eine Programmoberfläche alle Anforderungen der Barrierefreien Informationstechnik-Verordnung (BITV 2.0) erfüllt. Der Vorprüfungstest kann daher auch nicht als Grundlage für die Vergabe eines Zertifikats oder ähnliches dienen (z.B. nicht für Auszeichnungen wie "Vortest geprüft").

Mit Hilfe der im Rahmen des Vorprüfungstests erstellten Dokumentation können vom Betreiber des Web- oder Programmangebotes die exemplarisch in der Stichprobe aufgezeigten Barrieren auf das gesamte Angebot übertragen werden. Die Dokumentation der Testergebnisse ist eine erste Unterstützung für die Überarbeitung des Angebotes. Da die Testdokumentation des Vorprüfungstests keine konkreten Hinweise dazu enthält, wie jede einzelne Barriere individuell behoben werden kann, gibt es in der Dokumentation eine Liste mit Verweisen auf online verfügbare Informationsseiten, die bei der Korrektur hilfreich sind. Die Testdokumentation kann auch als Basis für einen Beratungsprozess genutzt werden.

Rahmenkonzept zur Prüfung

Der hier beschriebene Vorprüfungstest reiht sich in eine Folge von 3 aufeinander aufbauenden Tests ein:

1. Vorprüfungstest,
2. BITV Kurztest und
3. Hauptprüfung.

Der Vorprüfungstest dient dazu, eine erste Einschätzung des Angebots zu liefern. Der Test ist zeitlich stark begrenzt. Es wird lediglich eine kleine Stichprobe betrachtet, in der nach unterschiedlichsten Barrieren aus den Bereichen Wahrnehmbarkeit, Bedienbarkeit, technologische Robustheit und Verständlichkeit gesucht wird. Eine vollständige Überprüfung der BITV findet nicht statt.

Der BITV-Kurztest wird durchgeführt, wenn die im Vorprüfungstest aufgeführten Barrieren des Angebotes beseitigt worden sind, und die Betreiber dieses Angebotes sich intensiver mit dem Thema "Barrierefreies Informationstechnik" und der BITV beschäftigt haben. Hierbei wird nicht das gesamte Angebot, sondern lediglich eine Stichprobe betrachtet, die jedoch im Gegensatz zum Vorprüfungstest einem vollständigen BITV-Test unterzogen wird. Wird die Stichprobe (zum Beispiel überprüfte Webseiten oder Teile eines Programms) mit Hilfe des Testergebnisses überarbeitet, sollte diese Stichprobe anschließend barrierefrei sein. Auf alle anderen Seiten des Angebots, die nicht betrachtet worden sind, soll der Betreiber des Angebots die Testergebnisse selbständig übertragen. Als Empfehlung zur Durchführung von BITV-Kurztests für Webseiten gilt das Prüfverfahren zur BITV 2.0.

Die Hauptprüfung des Angebots könnte als Grundlage für eine Zertifizierung des Angebots dienen und enthält zusätzlich Hinweise auf die Selbstverpflichtung des Anbieters, sich ständig um die Einhaltung der Anforderungen, die ein barrierefreies Angebot erfüllen muss, zu halten. Eine Hauptprüfung sollte erst durchgeführt werden, wenn ein erfolgreicher Kurztest durchgeführt worden ist. Die Hauptprüfung sollte in regelmäßigen Abständen wiederholt werden.

Rahmenbedingungen für den Vorprüfungstest

Testumgebung

Bei den Instrumenten, die zur Verfügung stehen müssen, handelt es sich im wesentlichen um Software, d.h. um Prüfprogramme und unterschiedliche Browser. Die Anforderungen an die Hardware sind unerheblich. Es muss nur sichergestellt sein, dass die entsprechenden Prüfprogramme installiert oder online genutzt werden können und die Internetseiten aufgerufen werden können. Die Durchführung des Vorprüfungstests ist unter verschiedenen Windows-Betriebssystemen möglich. Es muss lediglich sichergestellt sein, dass alle eingesetzten Tools unter der verwendeten Plattform verfügbar sind. Die eingesetzte Testumgebung sollte auf jeden Fall in der Testdokumentation erwähnt werden, damit die festgestellten Barrieren für den Betreiber der getesteten Website nachvollziehbar sind. Zum Test werden immer die aktuellsten beziehungsweise gebräuchlichsten Versionen der angegebenen Software benutzt. Zum gegenwärtigen Zeitpunkt sind dies:

• Betriebssystem: Windows 7
• Browser: Mozilla Firefox 22, Internet Explorer 10
• Software: Color Contrast Analyzer 2.0 (Farbe-Kontrast Analysator), für Windows-Programme: UI Accessibility Checker, NVDA-Sreenreader
• Online-Werkzeuge: W3C-HTML-Validator
• Add-ons für Firefox: Web Developer
• Add-ons für Internet Explorer: AIS Web Accessibility Toolbar
• Bookmarklet "Inhalt gegliedert"

Qualifikation der Prüfer

Der Vorprüfungstest kann von einer einzelnen Person durchgeführt werden. Wenn eine einzelne Person den Test durchführt, muss diese Erfahrungen in allen genannten Bereichen besitzen, die im Folgenden aufgeführt werden. Der Tester sollte möglichst in ein Team zum Erfahrungsaustausch eingebunden sein. Die Teams bzw. die einzelnen Tester sollten in den folgenden Bereichen Erfahrungen besitzen.

Erforderliche Kenntnisse/Erfahrungen:

• Barrierefreie Informationstechnik-Verordnung (BITV)
• Erfahrungen im Umgang mit unterschiedlichen Browsern (Einstellungen/Optionen)
• Benutzung unterschiedlicher Evaluierungs-Tools zur Überprüfung der Zugänglichkeit von Internetangeboten und Kenntnisse über die Grenzen der eingesetzten halb-automatischen Evaluierungs-Tools.

Erwünschte Kenntnisse/Erfahrungen:

• Internet Markup-Sprachen
• Kenntnis der World Content Accessibility Guidelines (WCAG) 2.0 und des Dokuments "Techniques and Failures for Web Content Accessibility Guidelines 2.0" (die in diesem Dokument beschriebenen Techniken müssen nicht eingesetzt werden)
• Benutzung von assistiven Technologien
• Webdesign und Entwicklung
• Grundkenntnisse über Einfache Sprache (zum Beispiel: Auszug aus dem Wörterbuch für leichte Sprache, People First und Europäische Richtlinien für die Erstellung von leicht lesbaren Informationen für Menschen mit geistiger Behinderung).

Zeitlicher Aufwand

Der zeitliche Umfang für den hier empfohlenen Vorprüfungstest liegt bei ca. 1 bis 2 Stunden, inklusive der Testdokumentation und der Vorbereitungen (z.B. Seitenauswahl). Wird als zusätzlicher Service zum Vorprüfungstest eine Nutzerbeurteilung durchgeführt, verlängert sich der zeitliche Umfang je nach Umfang der Nutzerbeurteilung.

Prüfumfang für den Vorprüfungstest

Der Vorprüfungstest wird auf der Grundlage der Barrierefreien Informationstechnik-Verordnung (BITV) durchgeführt. Im Rahmen dieses Vorprüfungstests werden nicht alle Anforderungen mit den entsprechenden Bedingungen überprüft, da dies ein deutlich größerer zeitlicher Aufwand wäre, als für diesen Test vorgesehen ist. Die im Folgenden betrachteten Punkte reichen aus, um einige häufige und typische Barrieren aufzuzeigen. Alle Anforderungen lassen sich den 4 Grundprinzipien der Web Content Accessibility Guidelines (WCAG) 2.0 zuordnen:

1. Wahrnehmbarkeit,
2. Bedienbarkeit,
3. Verständlichkeit und
4. Technologische Robustheit.

Alle diese Bereiche müssen berücksichtigt werden. Für den Vorprüfungstest sind aus jedem Bereich mindestens 2 Prüfkriterien ausgewählt worden, die den entsprechenden BITV-Anforderungen (möglichst der Priorität I) zugeordnet werden können.

Die folgende Aufzählung zeigt die ausgewählten Prüfkriterien. Diese spiegeln jeweils nur einen Teilaspekt der BITV-Anforderungen bzw. Bedingungen wieder:

• Wahrnehmbarkeit
  • Anforderung 1.1:
    Für jeden Nicht-Text-Inhalt sind Alternativen in Textform bereitzustellen, die an die Bedürfnisse der Nutzerinnen und Nutzer angepasst werden können.
    • Bedingung 1.1.1: Nicht-Text-Inhalte
  • Anforderung 1.2
    Für zeitgesteuerte Medien sind Alternativen bereitzustellen.
    • Bedingung 1.2.5: Audio-Deskription
  • Anforderung 1.4
    Nutzerinnen und Nutzern ist die Wahrnehmung des Inhalts und die Unterscheidung zwischen Vorder- und Hintergrund so weit wie möglich zu erleichtern.
    • Bedingung 1.4.3: Kontrast
    • Bedingung 1.4.4: Veränderbare Textgröße
• Bedienbarkeit
  • Anforderung 2.1
    Für die gesamte Funktionalität ist Zugänglichkeit über die Tastatur sicherzustellen.
    • Bedingung 2.1.1: Tastaturbedienbarkeit
  • Anforderung 2.4
    Der Nutzerin oder dem Nutzer sind Orientierungs- und Navigationshilfen sowie Hilfen zum Auffinden von Inhalten zur Verfügung zu stellen.
    • Bedingung 2.4.1: Umgehen von Elementgruppen
    • Bedingung 2.4.4: Zweck eines Links (im Kontext)
    • Bedingung 2.4.7: Sichtbarer Fokus
• Verständlichkeit
  • Anforderung 3.1
    Texte sind lesbar und verständlich zu gestalten.
    • Bedingung 3.1.1: Sprache
    • Bedingung 3.1.2: Sprache einzelner Abschnitte
  • Anforderung 3.2
    Webseiten sind so zu gestalten, dass Aufbau und Benutzung vorhersehbar sind.
    • Bedingung 3.2.2: Bei Eingabe
    • Bedingung 3.2.3: Einheitliche Navigation
  • Anforderung 3.3
    Zur Fehlervermeidung und -korrektur sind unterstützende Funktionen für die Eingabe bereitzustellen.
    • Bedingung 3.3.2: Beschriftungen
    • Bedingung 3.3.4: Fehlervermeidung
• Technologische Robustheit
  • Anforderung 4.1
    Die Kompatibilität mit Benutzeragenten, einschließlich assistiver Technologien, ist sicherzustellen.
    • Bedingung 4.1.1: Syntaxanalyse

Da der Vorprüfungstest zeitlich begrenzt ist und nur eine erste Einschätzung des Angebots liefern soll, wird ein sehr begrenzter Prüfumfang gewählt.

Seitenauswahl für den Vorprüfungstest von Internetangeboten

Für den Vorprüfungstest von Internetangeboten werden 3 Seiten ausgewählt, die zur Überprüfung aller Kriterien betrachtet werden:

• Die Startseite des Angebots (Einstiegsseite).
  Anmerkung: Umfasst die Startseite keine Navigation, sondern nur eine Begrüßung (z.B. "Herzlich willkommen"), eine Sprachauswahl oder einen Intro-Film, dann ist die Folgeseite die zu prüfende Einstiegsseite. Es muss jedoch sichergestellt sein, dass diese Seite von der ersten sogenannten "Introseite" aus barrierefrei erreichbar ist. Dies ist im Testbericht zu vermerken.
• Eine thematische Seite, die direkt von der Startseite aus erreichbar ist. Sie sollte möglichst Bilder, Multimedia-Elemente oder Aufzählungen enthalten.
• Eine zusätzliche Seite, die Formulare (beispielsweise ein Kontaktformular) enthält.

Weitere Seiten als die zu Beginn des Tests ausgewählten können zur Beurteilung einzelner Prüfkriterien zusätzlich betrachtet werden. Es muss entweder der Navigationspfad, wie eine Seite erreicht werden kann oder die Adresse der Seite im Testbericht aufgeführt werden.

Prüfumfang für den Vorprüfungstest von Programmangeboten

Für den Vorprüfungstest von Programmangeboten werden 3 Funktionen ausgewählt, die zur Überprüfung aller Kriterien betrachtet werden:

• Ansicht bei Start des Programms
• Ansicht bei einer wesentlichen Funktion des Programms
  (bei einem E-Mailprogramm ist dies zum Beispiel das Lesen und Verfassen einer Nachricht)
• Mindestens ein Dialogelement bei Auswahl einer Unterfunktion

Prüfanweisungen

Nachfolgend sind für ausgewählte BITV-Bedingungen Beschreibungen und Prüfanweisungen für Internetseiten und Programmoberflächen aufgeführt.

Bedingung 1.1.1: Nicht-Text-Inhalte

Für jeden Nicht-Text-Inhalt, der dem Nutzer oder der Nutzerin präsentiert wird, ist eine Text-Alternative bereitzustellen, die den Zweck dieses Inhalts erfüllt.

Text-Alternativen müssen in den folgenden Fällen nicht bereitgestellt werden (vgl. Richtlinien für barrierefreie Webinhalte, Richtlinie 1.1):

• Steuerelemente, Eingabe: Wenn es sich bei dem Nicht-Text-Inhalt um ein Steuerelement handelt oder Eingaben durch den Benutzer akzeptiert, dann hat dieses Element einen Namen, der seinen Zweck beschreibt.
• Zeitbasierte Medien: Wenn es sich bei den Nicht-Text-Inhalten um zeitbasierte Medien handelt, dann stellen Textalternativen zumindest eine deskriptive Identifizierung des Nicht-Text-Inhalts bereit.
• Test: Wenn es sich bei dem Nicht-Text-Inhalt um einen Test oder eine Übung handelt, die nichtig wäre, wenn sie als Text dargestellt würde, dann stellen Textalternativen zumindest eine deskriptive Identifizierung des Nicht-Text-Inhalts bereit.
• Sensorisch: Wenn Nicht-Text-Inhalt hauptsächlich dafür gedacht ist, eine bestimmte Sinneserfahrung zu schaffen, dann stellen Textalternativen zumindest eine deskriptive Identifizierung des Nicht-Text-Inhalts bereit.
• CAPTCHA: Wenn der Zweck des Nicht-Text-Inhalts der ist zu bestätigen, dass eine Person und nicht ein Computer auf den Inhalt zugreift, dann werden Textalternativen bereitgestellt, die den Zweck des Nicht-Text-Inhalts identifizieren. Außerdem werden alternative Formen von CAPTCHAs bereitgestellt, die Ausgabeformen für verschiedene Arten der sensorischen Wahrnehmung nutzen, um verschiedenen Behinderungen Rechnung zu tragen.
• Dekoration, Formatierung, unsichtbar: Wenn der Nicht-Text-Inhalt reine Dekoration ist, nur für visuelle Formatierung benutzt wird oder dem Benutzer gar nicht präsentiert wird, dann wird der Inhalt so implementiert, dass er von assistierender Technik ignoriert werden kann

Prüfanweisung zu Nicht-Text-Inhalten für Internetseiten:

• Rufen Sie die Seite im Internet Explorer auf
• Lassen Sie sich durch die AIS Web Accessibility Toolbar die Alternativtexte anzeigen. Verwenden Sie dazu am besten die Funktion „Images > Toggle Images/Alt“.
• Prüfen Sie dann, ob grafische Bedienelemente und Abbildungen einen sinnvollen und aussagekräftigen Alternativtext besitzen.

Informative Abbildungen sollen einen Alternativtext besitzen, der die visuell gegebene Information in einer Textvariante wiedergibt, das heißt bei Schriftgrafiken sollte der Alternativtext den dargestellten Text enthalten, bei einem Foto eine kurze Beschreibung des abgebildeten Inhalts.

Alternativtexte für Bedienelemente, wie beispielsweise eine Grafik zum Abschicken eines Formulars, sollen die Aktion (zum Beispiel Abschicken eines Formulars) oder das Ziel (bei verknüpften Grafiken) enthalten.

Layoutgrafiken, die ausschließlich gestalterischen dekorativen Zwecken dienen, sollen einen leeren Alternativtext enthalten.

Prüfanweisung zu Nicht-Text-Inhalten in Programmoberflächen unter Windows:

• Starten Sie die zu prüfende Anwendung
• Starten Sie den UI Accessibility-Checker
• Wählen Sie das zu prüfende Anwendungsfenster aus
• Überprüfen Sie im Reiter „Results“ ob alle Elemente mit einem Namen versehen sind, ist dies nicht der Fall wird dies als „Error“ gelistet.
• Wählen Sie zusätzlich im MSAA-Baum die Bildelemente aus und überprüfen Sie ob für diese ein Name vergeben wurde.

Prüfanweisung zu Nicht-Text-Inhalten für in sich abgeschlossene Programmoberflächen, bei denen ein Zugriff von assistiven Technologien wie Screenreader nicht möglich sind:

• Überprüfen Sie ob eine Sprachausgabe der Nicht-Text-Inhalte möglich ist
  (zum Beispiel weil es die Anwendung selbst ermöglicht oder weil die der Anwendung zugrunde liegende Plattform dies ermöglicht)

Bedingung 1.2.3: Audio-Deskription oder Volltext-Alternative

Eine Alternative für zeitbasierte Medien oder eine Audiodeskription des aufgezeichneten Videoinhalts wird für synchronisierte Medien bereitgestellt, außer die Medien sind eine Medienalternative für Text und als solche deutlich gekennzeichnet.

Prüfanweisung zur Audio-Deskription oder Volltext-Alternative in Internetseiten:

Sollte Multimedia einen zentralen Teil der Site bilden, ist zu überprüfen, ob es eine Alternative für sehbehinderte, blinde und gehörlose Nutzer zu diesen Inhalten gibt.

• Dazu wird geprüft, ob eine Audio-Deskription oder Volltext-Alternative für die Multimedia-Inhalte existiert, oder ob es Captions für Audio-Inhalte von Medien gibt.
  Multimedia-Elemente, die selbst bereits eine Alternative zu anderen Inhalten darstellen, benötigen keine Alternativen.

Prüfanweisung zur Audio-Deskription oder Volltext-Alternative in Programmoberflächen:

• Überprüfen Sie, ob eine Audio-Deskription oder Volltext-Alternative für die Multimedia-Inhalte existiert, oder ob es Captions für Audio-Inhalte von Medien gibt.
  Multimedia-Elemente, die selbst bereits eine Alternative zu anderen Inhalten darstellen, benötigen keine Alternativen.

Die Alternative kann über die Software selbst oder über eine BITV-konforme alternative Version bereitgestellt werden

Bedingung 1.4.3: Kontrast

Bei der visuellen Präsentation von Text und Schriftgrafiken ist das Kontrastverhältnis zwischen Vordergrund- und Hintergrundfarbe mindestens 4,5:1. Für Großschrift und Schriftgrafiken mit Großschrift gilt ein Kontrastverhältnis von mindestens 3:1. Kein Mindestkontrast ist erforderlich für nebensächliche Texte und Schriftgrafiken,

• die Teil einer inaktiven Komponente der Benutzerschnittstelle sind,
• die rein dekorativ sind,
• bei denen es sich um nebensächlichen Text in einem Bild handelt,
• die für den Nutzer oder die Nutzerin nicht sichtbar sind
• die Bestandteil eines Logos oder eines Markennamens sind.

Prüfanweisung zum Kontrast für Internetseiten und Programmoberflächen:

• Führen Sie eine einfache Sichtprüfung der Elemente durch.
• Verwenden Sie im Zweifelsfall den Color Contrast Analyzer 2.0.
  Wählen Sie mit diesem Werkzeug einen Punkt des Vordergrundes und einen Punkt des diesen umgebenden Hintergrundes aus. Die Software teilt Ihnen mit, ob der Kontrast ausreichend ist oder nicht.

Bedingung 1.4.4: Veränderbare Textgröße

Der Text lässt sich ohne assistive Technologie bis auf 200 % vergrößern, ohne dass es zu einem Verlust von Inhalt oder Funktionalität kommt.

Prüfanweisung zur veränderbaren Textgröße von Internetseiten:

• Öffnen Sie die zu prüfende Webseite im Internet Explorer
• Wählen Sie eine Fenstergröße von 1024x768 Pixeln (z.B. in der Web Accessibility Toolbar über die Option „Resize“)
• Wählen Sie im Menü Ansicht den Menüpunkt Textgröße und stellen Sie diese auf mittel.
• Wählen Sie im Menü Ansicht den Menüpunkt Zoom und stellen Sie diesen auf 200%.
• Prüfen Sie, ob alle Inhalte ohne Überlagerungen dargestellt werden und alle Funktionalitäten bedienbar bleiben
• Öffnen Sie die zu prüfende Webseite zusätzlich im Mozilla Firefox
• Wählen Sie eine Fenstergröße von 1024x768 Pixeln (z.B. in der Web Developer Toolbar über die Option „Resize“ bzw. „Größe ändern“)
• Wählen Sie Menü Ansicht den Unterpunkt Zoom.
• Deaktivieren Sie zunächst die Option „Nur Text zoomen“ und stellen Sie die Zoomstufe auf „Normal“
• Wählen Sie im Menü Ansicht den Unterpunkt Zoom und rufen Sie sechs Mal die Funktion Vergrößern auf (alternativ sechs Mal die Tastenkombination „STRG++“ betätigen)
• Prüfen Sie, ob alle Inhalte ohne Überlagerungen dargestellt werden und alle Funktionalitäten bedienbar bleiben
• Stellen Sie im Menü Ansicht im Unterpunkt Zoom die Zoomstufe auf Normal zurück
• Aktivieren Sie die Funktion Nur Text zoomen
• Wählen Sie im Menü Ansicht den Unterpunkt Zoom und rufen Sie sechs Mal die Funktion Vergrößern auf (alternativ sechs Mal die Tastenkombination „STRG++“ betätigen)
• Prüfen Sie erneut, ob alle Inhalte ohne Überlagerungen dargestellt werden und alle Funktionalitäten bedienbar bleiben

Um diesen Prüfschritt zu erfüllen, müssen alle Textinhalte nach der Vergrößerung lesbar sein und dürfen sich nicht überschneiden. Bei Schrift, die sich nicht vergrößern lässt, ist dieser Prüfpunkt nicht erfüllt.

Prüfanweisung zur veränderbaren Textgröße von Programmoberflächen:

Softwareplayer, Viewer oder Editoren mit einer internen 200%-Vergrößerung für Schrift erfüllen das Prüfkriterium automatisch, es sei denn Inhalte funktionieren mit dieser Vergrößerung nicht.

Falls die Programmoberfläche selbst keine Möglichkeit zur Schriftvergrößerung bietet, sollte die Software mit den Vergrößerungsmöglichkeiten des zugrundeliegenden Betriebssystems funktionieren.

• Überprüfen Sie ob Einstellmöglichkeiten für Schriftvergrößerung in der Anwendung selbst vorliegen.
• Ist dies nicht der Fall überprüfen Sie ob sich alle Textinhalte mit Verändern der Systemparameter zur Anzeige vergrößern lassen

Bedingung 2.1.1: Tastaturbedienbarkeit

Die gesamte Funktionalität des Inhalts muss über eine Tastaturschnittstelle bedient werden können, ohne dass bestimmte Zeitvorgaben für die einzelnen Tastenanschläge einzuhalten sind. Dies gilt nicht, wenn die zugrundeliegende Funktion Eingaben verlangt, die nicht nur von den Endpunkten, sondern auch vom Verlauf der Benutzerbewegung abhängen.

In den WCAG 2.0 sind die Ausnahmen näher erläutert (vgl. Richtlinien für barrierefreie Webinhalte, Richtlinie 2.1):

Anmerkung 1: Diese Ausnahme bezieht sich auf die zugrundeliegende Funktion und nicht auf die Eingabetechnik. Zum Beispiel: Wenn man Handschrift benutzt, um Text einzugeben, dann verlangt die Eingabetechnik (Handschrift) Pfad-abhängige Eingaben, die zugrunde liegende Funktion (Texteingabe) verlangt dies aber nicht.

Anmerkung 2: Es ist nicht verboten, noch sollte es Sie davon abhalten, eine Maus-Eingabe oder andere Eingabemethoden zusätzlich zur Tastaturbedienung zur Verfügung zu stellen.

Prüfanweisung zur Tastaturbedienbarkeit von Internetseiten:

• Laden Sie die Seite in allen Browsern mit F5 neu und wechseln Sie mit F6 in die Adresszeile.
• Danach wird bei ausschließlicher Nutzung der Tastatur geprüft, ob alle Inhalte erreichbar und auch bedienbar sind. Gehen Sie mit der Tabulatortaste die Links und Formularelemente durch.
• Überprüfen Sie, ob alle Links und Formularelemente erreichbar und bedienbar sind.

Prüfanweisung zur Tastaturbedienbarkeit von Programmoberflächen:

Dieses Prüfkriterium bedeutet nicht, dass Anwendungen direkt eine Tastatur oder ein „Keyboard Interface“ unterstützen müssen. Es bedeutet auch nicht, dass Anwendungen eine Bildschirmtastatur bereit stellen müssen. Das der Anwendung zugrunde liegende Betriebssystem kann eingabegerätunabhängige Eingabedienste für Anwendungen bereit stellen, die eine Bedienung über eine Tastatur ermöglichen. Software, welche die Bedienung von solchen vom Betriebssystem bereit gestellten Eingabediensten unterstützt, wäre im Sinne des Prüfkriterium durch eine Tastatur bedienbar und würde diesen Prüfschritt erfüllen.

• Überprüfen Sie, ob die Anwendung mittels Tastatur bedienbar ist.
  (Üblicherweise gelangen Sie durch Betätigen der Tabulatortaste von Bedienelement zu Bedienlement, bei Formularen auch durch Betätigen der Cursortasten von Formularelement zu Formularlement)
  Falls das zugrundeliegende Betriebssystem üblicherweise andere eingabegerätunabhängige Eingabemöglichkeiten bereit stellt, überprüfen Sie ob die Anwendung mit diesen Methoden bedienbar ist.

Bedingung 2.4.1: Umgehen von Elementgruppen

Für Gruppen von Elementen, die auf mehreren Webseiten wiederholt werden, sind Mechanismen verfügbar, um diese zu umgehen.

Prüfanweisung zum Umgehen von Elementgruppen von Internetseiten:

• Rufen Sie die zu prüfenden Seiten im Firefox auf.
• Deaktivieren Sie CSS in der Webdeveloper-Toolbar (Menü CSS, Unterpunkt Stile deaktivieren, Befehl Alle Stile deaktivieren)
• Rufen Sie das Bookmarklet "Inhalte gegliedert" auf
• Überprüfen Sie, ob Bereiche mit für sich nutzbaren Inhalten (Navigation, Inhalt, Textabschnitte, etc.) eigene Überschriften besitzen. Sollte dies nicht der Fall sein, wird überprüft, ob zumindest eine Skip-Navigation vorhanden ist.

Elementgruppen können auch durch Verwenden von Frames oder Iframes erstellt werden. In diesem Fall sollten die so erstellten Gruppen entsprechend bezeichnet sein: mit einem title-Attribut für frame- beziehungsweise iframes-Elemente.

• Rufen Sie die zu prüfenden Seiten im Internet Explorer auf.
• Wählen Sie im Menü der AIS-Toolbar den Menüpunkt Frames und den Befehl Frame Name / Title
• Überprüfen Sie jeweils ob ein aussagekräftiger Titel vergeben ist.

Prüfanweisung zum Umgehen von Elementgruppen von Programmoberflächen:

Dieses Prüfkriterium ist nach dem Entwurf EN 301 549 nicht auf Software anwendbar.

Bedingung 2.4.4: Zweck eines Links (im Kontext)

Ziel und Zweck eines Links sind aus dem Linktext selbst ersichtlich oder aus dem Linktext in Verbindung mit dem durch Programme bestimmten Link-Kontext.

Hinweis (vgl. Understanding WCAG 2.0, Understanding Success Criterion 2.4.4): Der Zweck eines Links geht in der Regel aus dem Linktext hervor. Ergänzende Information kann auch in einem zugeordneten Tooltip angegeben sein (bei HTML im title-Attribut). Bei verlinkten Grafiken ist der Linktext der alt-Text eines img-Elements. Der Zweck eines Links kann auch aus dem umgebenden Absatz, der übergeordneten Überschrift oder der zugeordneten Tabellenzelle mit entsprechenden Tabellenüberschriften hervorgehen, in welcher sich der Link befindet. Bei Webseiten kann der Zweck eines Links auch durch zusätzlichen, überCSS versteckten Linktext angegeben sein.

Prüfanweisung zum Zweck eines Links in Internetseiten:

• Prüfen Sie, ob der Linktext allein Auskunft über Ziel oder Zweck des Links gibt.
• Gibt der Linktext allein keine Auskunft über Ziel oder Zweck, überprüfen Sie folgende Kontextmöglichkeiten:
  Überprüfen Sie, ob ein Link am Seitenbeginn die Linktexte auf der Seite erweitert,
  Schalten Sie die CSS aus (In der Web-Developer- oder in der AIS-Toolbar) und überprüfen Sie, ob versteckter ergänzender Linktext vorhanden ist,
  überprüfen Sie für Grafiklinks, ob Sinn und Zweck durch den Alternativtext oder aus dem title-Attribut einer mit im selben a-Element verlinkten Grafik hervorgehen,
  Überprüfen Sie ob Ziel oder Zweck eines Links aus übergeordneten Elementen (p, li, td/th, h1-h6) hervorgeht

Prüfanweisung zum Zweck eines Links bei Programmoberflächen:

Nach dem Entwurf EN 301 549 gilt:
Bei Software ist ein “link” jegliche Textfolge oder Bild in der Benutzeroberfläche außerhalb eines Kontrollelementes der Benutzeroberfläche, welche sich wie ein Link verhält. Dies schließt allgemeine Kontrollelemente nicht ein (Eine OK-Schaltfläche ist beispielsweise kein Link).

• Prüfen Sie, ob der Linktext allein Auskunft über Ziel oder Zweck des Links gibt.
• Gibt der Linktext nicht allein Auskunft über Ziel oder Zweck, überprüfen Sie den umgebenden Kontext; nehmen Sie im Zweifelsfall für Windows-Programme den UI Accessibility-Checker zu Hilfe (siehe „Prüfanweisung zu Nicht-Text-Inhalten in Programmoberflächen unter Windows“)

Bedingung 2.4.7: Sichtbarer Fokus

Bei Tastaturbedienung ist immer ein Tastaturfokus sichtbar.

Prüfanweisung zum sichtbaren Focus von Internetseiten:

• Laden Sie die Seite in allen Browsern mit F5 neu und wechseln Sie mit F6 in die Adresszeile.
• Danach wird bei ausschließlicher Nutzung der Tastatur geprüft, ob alle Inhalte erreichbar und auch bedienbar sind. Gehen Sie mit der Tabulatortaste die Links und Formularelemente durch.
• Überprüfen Sie, ob für jedes Bedienelement ein ausreichend sichtbarer Tastaturfokus vorhanden. Falls kein ausreichender Tastaturfokus vorhanden ist, überprüfen Sie ob der Mausfokus für dieses Element ebensowenig sichtbar ist.

Prüfanweisung zum sichtbaren Focus von Programmoberflächen:

• Wenn die Anwendung mittels Tastatur bedienbar ist, überprüfen Sie ob die einzelnen Bedienelemente einen sichtbaren Tastaturfokus besitzen.

Bedingung 3.1.1: Sprache

Die vorherrschend verwendete natürliche Sprache jeder Webseite ist durch Programme erkennbar.

Prüfanweisung zur Sprachangabe von Internetseiten:

• Rufen Sie die zu überprüfenden Internetseiten im Internet Explorer auf.
• Wählen Sie aus dem AIS-Toolbar-Menü den Unterpunkt „Seite“ (Doc Info.) und hier die Funktion „lang-Attribute anzeigen“ (Show Lang Attributes)
• Überprüfen Sie ob für das html-Element (bzw. für das xml-Element) das lang-Attribut verwendet wird und korrekt angegeben ist.

Prüfanweisung zur Sprachangabe von Programmoberflächen:

Hinweis: In der BITV werden für dieses Prüfkriterium lediglich Webseiten genannt. Die Entsprechung für Anwendungen lautet nach dem Entwurf EN 301 549:
„Die voreingestellte menschliche Sprache jeder Software-Bedienoberfläche kann durch Software bestimmt werden.“
Screenreader sollen dadurch zum Beispiel in der Lage sein ein korrektes Aussprachelexikon zu laden und Webseiten oder Programmoberflächen korrekt vorlesen zu können.

• Starten Sie die zu prüfende Anwendung und einen Screenreader (z.B.NVDA) oder die Vorlesefunktion des zugrundeliegenden Betriebssystems
  (Beachten Sie, dass Sie je nach ausgewählter Vorlesesoftware eventuell zusätzliche Wörterbücher oder Sprachen nachträglich installieren müssen)
• Überprüfen Sie, ob Wörter in der korrekten Aussprache vorgelesen werden.

Bedingung 3.1.2: Sprache einzelner Abschnitte

Die natürliche Sprache aller verwendeten Textpassagen oder Ausdrücke ist durch Programme erkennbar.

Prüfanweisung zur Sprachangabe einzelner Abschnitte und Wörter von Internetseiten:

• Rufen Sie die zu überprüfenden Internetseiten im Internet Explorer auf.
• Wählen Sie aus dem AISToolbar-Menü den Unterpunkt „Seite“ (Doc Info.) und hier die Funktion „lang-Attribute anzeigen“ (Show Lang Attributes)
• Überprüfen Sie ob andersprachige Abschnitte oder Wörter vorhanden sind und ob diese durch das lang-Attribut ausgezeichnet sind.
  (Fremdwörter, die in den allgemeinen Sprachgebrauch übergegangen sind und im Duden aufgeführt werden, müssen nicht ausgezeichnet werden).

Prüfanweisung zur Sprachangabe einzelner Abschnitte und Wörter von Programmoberflächen:

Dieses Prüfkriterium ist nach dem Entwurf EN 301 549 nicht auf Software anwendbar.

Bedingung 3.2.2: Bei Eingabe

Wird die Einstellung eines Elements der Benutzerschnittstelle geändert, führt dies nicht automatisch zu einer Änderung des Kontextes, es sei denn, die Nutzerin oder der Nutzer wurde vor Benutzung des Elements über dieses Verhalten informiert.

Hinweis: Hier müssen Kontextänderungen von Inhaltsänderungen unterschieden und abgegrenzt werden (siehe: Understanding WCAG 2.0, Understanding Success Criterion 3.2.2):

Unter Kontextänderungen werden wesentliche Änderungen am Inhalt einer Webseite verstanden. Wenn solche Änderungen vorgenommen werden, ohne dass dies dem Benutzer bewusst ist, kann dies zur Desorientierung derjenigen Benutzer führen, die nicht die gesamte Seite zeitgleich sehen können.
(Dies sind z.B. Änderungen des Benutzeragenten, des Viewports, des Fokus oder sonstige Änderungen des Inhalts, der zu einer Bedeutungsänderung der Webseite führt.)

Anmerkung: Eine Änderung des Inhalts ist nicht immer eine Änderung des Kontextes. Änderungen am Inhalt, wie zum Beispiel eine expandierende Gliederung, ein dynamisches Menü oder eine Steuerung über Reiter, ändern nicht zwangsläufig den Kontext, außer sie ändern auch eines der oben genannten (z.B. den Fokus).

Prüfanweisung zu Kontextänderungen bei Eingabe in Internetseiten und bei Programmoberflächen:

• Überprüfen Sie bei der Bedienung der Webseite oder Programmoberfläche mit der Tabulatortaste und den Cursor-Tasten, ob sich zentrale Inhalte der Seite ungewollt verändern, zum Beispiel ob Links automatisch aktiviert werden oder Pop-Ups automatisch geöffnet werden.

Bedingung 3.2.3: Einheitliche Navigation

Navigationsmechanismen, die innerhalb eines Webangebots wiederholt werden, treten bei jeder Wiederholung in der gleichen Reihenfolge auf, es sei denn, die Nutzerin oder der Nutzer veranlasst eine Änderung.

Prüfanweisung zur einheitlichen Navigation von Internetseiten:

• Prüfen Sie ob Navigationselemente vorhersehbar in immer der gleichen relativen Reihenfolge auftauchen.
  (Als Navigationselemente gelten Menüs und Untermenüs, Suchfelder, Verknüpfung des Logos des Seitenbetreibers mit der Startseite usw.)

Prüfanweisung zur einheitlichen Navigation bei Programmoberflächen:

Dieses Prüfkriterium ist nach dem Entwurf EN 301 549 nicht auf Software anwendbar.

Bedingung 3.3.2: Beschriftungen

Für notwendige Eingaben der Nutzerinnen und Nutzer sind Hinweise oder Label (Beschriftungen) zur Verfügung zu stellen.

Prüfanweisung zu Beschriftungen von Formularen in Internetseiten oder Programmoberflächen

Eine Beschriftung soll in Formularfeldern direkt über oder vor dem Feld stehen, bei Checkboxen und Radiobuttons soll eine Beschriftung nach dem Formularelement stehen. In HTML-Dokumenten sollten die Formularelemente über label oder legend verknüpft sein. Ist dies nicht der Fall, sollte zumindest eine Beschriftung und eine ausführliche Textanweisung zum Ausfüllen einzelner Formularelemente vorhanden sein.

• Rufen Sie die zu prüfenden Seiten im Firefox auf.
• Deaktivieren Sie CSS in der CSS, Unterpunkt Stile deaktivieren, Befehl Alle Stile deaktivieren)
• Prüfen Sie ob Beschriftungen vorhanden und korrekt angeordnet sind
• Klicken Sie zur Überprüfung einer Verknüpfung mit label auf die vor oder über den Eingabe-Elementen angeordneten Texte und prüfen Sie, ob das jeweilige Element den Fokus erhält.
• Ist dies nicht der Fall, überprüfen Sie ob beschreibende Beschriftungen und ausführliche Beschreibungen zum Ausfüllen einzelner Elemente in Textform vorhanden sind.

Bedingung 3.3.4: Fehlervermeidung

Bei Webseiten, die rechtliche Verpflichtungen begründen oder zu finanziellen Transaktionen der Nutzerinnen und Nutzer führen oder von Nutzerinnen und Nutzern kontrollierbare Daten in Datenspeichersystemen ändern bzw. löschen oder Testantworten der Nutzerinnen und Nutzer absenden, haben Nutzerinnen und Nutzer mindestens eine der folgenden Möglichkeiten:

• (Reversibel: ) Die Ausführung kann rückgängig gemacht werden.
• (Geprüft: ) Die eingegebenen Daten werden auf Eingabefehler überprüft und es besteht die Möglichkeit, diese gegebenenfalls zu korrigieren.
• (Bestätigt: ) Die Informationen können durchgesehen, korrigiert und bestätigt werden, bevor sie endgültig abgeschickt werden.

Prüfanweisung zur Fehlervermeidung bei Internetseiten und bei Programmoberflächen:

Dieses Prüfkriterium ist anwendbar, wenn Nutzer durch das Ausfüllen von Formularen oder durch Tätigen sonstiger Aktionen rechtlich bindende Verpflichtungen eingehen (zum Beispiel Online-Bestellvorgänge und andere finanzielle Transaktionen)

• Überprüfen Sie ob die Transaktion unmittelbar rückgängig gemacht werden kann (zum Beispiel das Löschen von angelegten Datensätzen).
• Überprüfen Sie bei Formularen, ob die eingegebenen Daten dem Benutzer vor dem Abschicken noch einmal angezeigt werden oder ob andere Möglichkeiten bestehen die Daten zu korrigieren.
• Überprüfen Sie, ob ein Absenden von Daten erst nach Bestätigung eines Dialogs erfolgt, der die Konsequenzen der Transaktion beschreibt.

Bedingung 4.1.1: Syntaxanalyse

Inhalte, die mit Markup-Sprachen erstellt werden, bestehen aus Elementen, für die folgende Eigenschaften gelten:

• Sie verfügen über vollständige Start- und End-Tags,
• sie werden entsprechend ihren Spezifikationen verschachtelt,
• sie enthalten keine doppelten Attribute und
• alle ihre IDs sind eindeutig,
• es sei denn, ihre Spezifikationen erlauben diese Besonderheit.

Prüfanweisung zur Syntaxanalyse von Internetseiten

• Rufen Sie die zu prüfenden Seiten im Firefox auf.
• Wählen Sie im Webdeveloper den Menüpunkt Werkzeuge und den Befehl HTML validieren (falls sich die Webseiten hinter einem Login befinden oder nicht öffentlich verfügbar sind, wählen Sie stattdessen den Befehl Lokales HTML validieren).
• Prüfen Sie das Ergebnis des W3C-Validators (Fehler, die aufgrund des Einsatzes von WAI ARIA-Rollen, -Zuständen und –Eigenschaften angeführt sind, werden hierbei nicht negativ bewertet)

Prüfanweisung zur Syntaxanalyse von Programmoberflächen

Nach dem Entwurf EN 301 549 gilt:

Anforderungen zur Syntaxanalyse sind nur anwendbar für Inhalte, die getrennt dargestellt und für assistive Technologien verfügbar gemacht werden. Wenn Markup-Sprachen verwendet werden, um Rahmenbedingungen für Benutzerschnittstellen intern zu beschreiben, und diese dabei assistiven Technologien nicht zur Verfügung stehen, weder direkt noch über ein Dokument-Objekt-Modell (DOM), ist diese Bedingung automatisch erfüllt.

• Wählen Sie zur Validierung für HTML / XML-Dokumente den W3C-Validator.
  (Für andere Validierungen Markups wählen Sie Prüfverfahren entsprechend der DTD, für eine Validierung des XML-Schemas können Sie zum Beispiel den XML Schema Validator des W3C verwenden).
• Prüfen Sie das Ergebnis des W3C-Validators (Fehler, die aufgrund des Einsatzes von WAI ARIA-Rollen, -Zuständen und –Eigenschaften angeführt sind, werden hierbei nicht negativ bewertet)
• Für Windows-Programme starten Sie den "aViewer 2013", drücken Sie die Funktionstaste "F5" oder wählen sie den Beobachtungscursor aus und setzen Sie diesen auf die zu überprüfende Software.
• Überprüfen Sie im Bereich Interface ob für mindestens eine der verschiedenen Schnittstellen Werte für "Name" und "Rolle" vergeben wurden:
  • MSAA: accName, accRole
  • iAccessible2: Name, Role.
  • UI Automation: CurrentName, CurrentAriaRole
  Bitte überprüfen Sie zuvor die Einstellungen des "aViewer2013" und wählen Sie die genannten Eigenschaften zur Anzeige aus.

BITV 2.0 Anlage 2

BITV-Text: Auf der Startseite des Internet- oder Intranetangebotes einer Behörde im Sinne des § 7 Absatz 1 Satz 1 des Behindertengleichstellungsgesetzes sind gemäß Anlage 2 folgende Erläuterungen in Deutscher Gebärdensprache und in Leichter Sprache bereitzustellen:

1. Informationen zum Inhalt,
2. Hinweise zur Navigation sowie
3. Hinweise auf weitere in diesem Auftritt vorhandene Informationen in Deutscher Gebärdensprache oder in Leichter Sprache.

Prüfanweisung zur Anlage 2 (bei Inter- oder Intranetseiten)

1. Rufen Sie die zu prüfenden Seiten im Firefox auf.
2. Überprüfen Sie, ob Angebote in Leichter Sprache und in Gebärdensprache vorliegen.

Testdokumentation

Die Testdokumentation sollte die Testumgebung, die Methoden, mit denen getestet wird (z.B. eingesetzte Testtools, Nutzerbeteiligung usw.), ausgewählten Seiten und alle Testergebnisse beinhalten und sich am Entwurf zu Evaluationsberichten zur Barrierefreiheit orientieren (W3C: Template for Accessibility Evaluation Reports). Die formalen Daten, die in der Dokumentation enthalten sein sollten, sind im Einzelnen:

• Datum, an dem der Test durchgeführt worden ist.
• In den Test einbezogene Seiten (mit vollständiger Uniform Resource Locator (URL) und Navigationspfad).
• Tester (Organisation, Name, evtl. Qualifikation siehe Abschnitt: Qualifikation der Prüfer).
• Ansprechpartner für diesen Test (Name, E-Mail-Adresse, Telefonnummer).
• Überprüfte Kriterien.
• Eingesetzte Methoden (Testtools usw.).
• Daten und Ergebnisse des Tests durch behinderte Nutzer, falls dieser erfolgte.

Aus dem Bericht muss hervorgehen, auf welche Seite und auf welches Element sich die beschriebenen Barrieren beziehen.

Die Ergebnisse der einzelnen Überprüfungen unterschiedlicher Seiten sollten im Testbericht zusätzlich zum ausführlichen Ergebnis kurz zusammengefasst werden, indem z.B. darauf hingewiesen wird, dass das Angebot kleinere Barrieren enthält oder vollständig unzugänglich ist. Es sollte erwähnt werden in welchen Bereichen (z.B. Wahrnehmung oder Bedienbarkeit) die meisten Probleme aufgetreten sind. Außerdem ist anzugeben wie die Auswirkungen dieser Barrieren für bestimmte Nutzergruppen sind, z.B. Navigation von blinden Menschen nicht bedienbar.

Alle Aspekte, die die Barrierefreiheit der Seite unterstützen, sollten positiv erwähnt werden, unabhängig davon, ob sie bewusst zur Erreichung von Barrierefreiheit eingesetzt werden oder nicht.

Fallen bei der Prüfung weitere Mängel auf, die nicht im Prüfumfang dieser Vorprüfungstestempfehlung enthalten sind, können diese in einem Anmerkungsfeld dokumentiert werden. Dies sollte aber nicht zu einer erheblichen Vergrößerung des Testaufwandes führen. Bei einer solchen Ausweitung des Aufwandes sollte der Auftraggeber stattdessen generell auf das Vorhandensein hingewiesen werden.