Für diese besondere Art des Testens bietet unser reguläres Bug-Formular nicht genügend Felder für alle erforderlichen Informationen. Darüber hinaus gelten für Accessibility-Reports zusätzliche Anforderungen neben den Anforderungen für reguläre Bug-Reports, die in den Academy-Artikeln "Anforderungen an Bug-Reports" und "Anhänge für Bug-Reports" formuliert sind.

Zusätzliche Verpflichtungen, denen jeder Accessibility-Report folgen muss, sind in den folgenden Kapiteln beschrieben. Am Ende des Artikels findest du zwei Beispiele, die Accessibility-Reports mit den angewandten Regeln demonstrieren.

Der Titel deines Reports muss das folgende Format je nach Barrierefreiheitsstufe (A oder AA) und WCAG-Erfolgs-Checkpoint erfüllen:

Der Platzhalter muss durch eine Beschreibung des Bugs ersetzt werden, die du für reguläre Bug-Reports verwenden würdest. Zum Beispiel:

Hier sind Beispiele für Bug-Überschriften für die häufigsten Barrierefreiheitsprobleme. Du kannst sie verwenden und an deine Bedürfnisse anpassen:

Erster Schritt: Gib zusätzlich zum Aufruf der Test-URL den Namen des Tools an, das du im ersten Schritt verwendet hast. Ersetze den Platzhalter <tool> in der folgenden Vorlage durch z. B. NVDA, JAWS, WAVE usw:

Mehrere Elemente: Wenn ein Prüfpunkt für mehrere Elemente desselben Typs fehlschlägt (z. B. Button oder Link), fasse diese Wiederholungen in einem Bericht zusammen.

Mehrere Vorkommnisse: Um mehrere identische Vorkommnisse eines Problems auf derselben Seite oder auf verschiedenen Seiten zu dokumentieren, liste sie in deinem aktuellen Ergebnis unter dem Abschnitt "Andere Vorkommnisse:" auf.

Beschriebene Aktionen: Da Sehbehinderte oder Blinde keine Computermaus verwenden, beschreibe hier bitte keine Mausaktionen. Beschreibe stattdessen Tastatur- und Touchpad-Aktionen wie:

Automatisierte Tools: Du kannst gerne Tools wie WAVE verwenden, um Probleme zu identifizieren. Dein Bericht, einschließlich deiner Schritte, muss jedoch aus der Sicht eines Benutzers beschrieben werden. Du darfst in deinen Schritten nicht beschreiben, wie du ein automatisiertes Tool verwendest und was es meldet. Beschreibe stattdessen alles so, als hättest du kein Tool verwendet, sondern dich nur auf die WCAG-Prüfpunkte gestützt.

Deine Schritte müssen wie folgt aufgelistet sein (Platzhalter ersetzen):

Probleme mit dem gleichen Farbschema dürfen nur einmal gemeldet werden. Zum Beispiel ist ein Problem mit blauer Schrift auf weißem Hintergrund und weißer Schrift auf blauem Hintergrund dasselbe Farbschema und kann nicht zweimal gemeldet werden.

Gib im Feld "Tatsächliches Ergebnis" an (neben dem üblichen tatsächlichen Ergebnis, das du in regulären explorativen Tests eingeben musst), welcher Prüfpunkt fehlgeschlagen ist, z. B.:

Welcher Anhang beigefügt werden muss, hängt von der Art des Accessibility-Problems ab:

Bildschirmfotos: Wie in regulären Tests muss das Problem auf den Screenshots markiert sein.

Screencasts: Verlangsame bitte deine Aktionen bei der Aufnahme deines Screencasts, bevor du das Element erreichst, welches das Problem aufweist. Wenn du deine Aktionen in normaler Geschwindigkeit aufzeichnest, wird der Betrachter möglicherweise sonst das Problem übersehen. Wenn du deine Aktionen beim Aufnehmen zu schnell ausführst, könnte der Teamleiter dich um eine verbesserte Aufzeichnung bitten.

Dein Screencast muss auch die Tasten zeigen, die du während der Aufnahme gedrückt hast, da Zuschauer sonst das Problem nicht nachvollziehen können. Aktiviere die Bildschirmtastatur auf deinem Computer, die sowohl für Windows als auch macOS verfügbar ist. Eine virtuelle Tastatur überlagert einen Teil deines Bildschirms und du musst einfach auf eine Taste drücken, um die entsprechende Tastenbetätigung zu simulieren.

Derzeit haben wir kein Formular für Accessibility-Reports. Daher verwenden wir vorübergehend das Formular für Usability-Reports. Damit alle Berichte gleich aussehen, müssen sie formatiert werden. Unten bieten wir eine formatierte Vorlage an und wir bitten dich, diese zu verwenden.

Kopiere die Vorlage und füge sie in das Textfeld des Usability-Formulars ein, ersetze die Platzhalter (z.B. <tool>, <URL>, usw.) und trage deine Informationen ein.

​Hinweise:

##### Schritte

1. Unter Verwendung von <tool>, öffne <URL>

2.

3.

4.

5.

##### Tatsächliches Ergebnis

<tatsächliches ergebnis>

**Gescheiterte WCAG 2.1 Prüfpunkte**: X.X.X Stufe <A/AA>

##### Erwartetes Ergebnis

<erwartetes ergebnis>

Titel:

[AA] [2.4.3]: Der Fokus wird nicht in das Hamburger-Menü-Modal gesetzt

Schritte:

Tatsächliches Ergebnis:

Der Fokus bewegt sich weiterhin durch den Hintergrundinhalt hinter dem Modal, der nicht zum vordergündigen Hamburger-Menü gehört.

Gescheiterte WCAG 2.1 Prüfpunkte: 2.4.3 Stufe AA

Erwartetes Ergebnis:

Der Fokus sollte sich im Hamburger-Menü-Modal befinden. Versteckte Elemente von der darunterliegenden Seite sollten nicht fokussiert und (durch den Screenreader) angekündigt werden.

Titel:

[AA] [2.4.7] Der Link 'Get Demo' hat keine sichtbaren Fokusränder

Schritte:

Tatsächliches Ergebnis:

Der „Get a Demo“-Link im Abschnitt „Nehmen Sie Qualität persönlich“ hat keine Fokusrandlinie.

Weitere Vorkommen: Symbole für soziale Medien

Gescheiterte WCAG 2.1 Prüfpunkte: 2.4.7 Stufe AA

Erwartetes Ergebnis:

Aktionselemente müssen sichtbare Fokusränder haben, wenn sie den Fokus erhalten.

Titel:

[AA] [1.4.3] Weißer Text auf blauem Hintergrund für den Link „Demo anfordern“ erfüllt nicht die Anforderungen an den Farbkontrast

Schritte:

Tatsächliches Ergebnis:

Der Link "Get a Demo" erfüllt die Anforderungen an den Farbkontrast nicht. Der blaue Text im Vordergrund (#21BEF4) auf dem weißen Hintergrund (#FFFFF) hat ein Kontrastverhältnis von nur 2,15:1.

Gescheiterte WCAG 2.1 Prüfpunkte: 1.4.3 Stufe AA

Erwartetes Ergebnis:

Kleiner Text sollte ein Kontrastverhältnis von mindestens 4,5:1 haben. Großer Text (14 pt fett oder 18 pt und größer) sollte ein Kontrastverhältnis von mindestens 3:1 haben.