Briefing für die Beauftragung
Was gehört zur Prüfung auf Barrierefreiheit?
Definiere wichtige Abläufe, Stichprobe, Testmethoden und Befundformat vor der Beauftragung. Behebung und Nachprüfung werden gesondert vereinbart.
Besprich deinen QA-UmfangKurze Antwort
Ein brauchbares Briefing nennt Aufgaben, Stichprobe, Kriterien und Methoden und verlangt reproduzierbare Befunde sowie klare Angaben zu ungeprüften Bereichen.
Passt für
- Teams vor Relaunch oder Release
- die eine Prüfung beauftragen.
- Produktverantwortliche mit Bedarf an umsetzbaren Befunden und Nachtests.
Nicht Gegenstand
- Einen automatischen Wert als Nachweis für die gesamte Website behandeln.
- Aus einer technischen Checkliste eine rechtliche Zertifizierung ableiten.
Die Optionen im Vergleich
Nutze dies als Einkaufscheckliste, nicht als Testergebnis.
Vollständige Anmeldung, Formulare, Zahlung oder Dokumentaufgaben
Nur die Startseite prüfen
Automatisierung plus vereinbarte Tastatur- und Hilfsmitteltests
Scannerscore mit Konformität gleichsetzen
Auswirkung, Schritte, Umgebung, Kriterium und Handlung
Unsortierte Toolwarnungen
Behebungsverantwortung, Nachtest und offene Punkte
Behebung als automatisch enthalten ansehen
Wo Wavect hier steht
Beginne bei Menschen und Aufgaben. Berücksichtige Seitentypen, interaktive Zustände, Fehlerpfade, mobile Ansichten und benötigte Dokumente. Eine Stichprobe belegt den geprüften Umfang, nicht sämtliche Seiten. Frage nach Browsern, assistiven Technologien und der Fachkenntnis zur Auswertung.
W3C WAI erklärt, dass Tools allein Barrierefreiheit nicht feststellen können . WCAG 2.2 enthält prüfbare Kriterien. Ziel und Umfang sind zu vereinbaren; eine technische Prüfung ist keine Rechtsberatung. Quellen geprüft am 19. Oktober 2026.
Illustrativer Befund: Eine Person öffnet per Tastatur einen Dialog, erreicht aber dessen Schließen-Element nicht. Dokumentiere Seite und Zustand, Browser und Schritte, Auswirkung, erwartetes Fokusverhalten, tatsächliches Verhalten, passendes Kriterium und Lösungsvorschlag. Prüfe nach der Reparatur die gesamte Aufgabe einschließlich sinnvoller Fokusrückgabe. Das Beispiel ist fiktiv, keine geprüfte Kundenseite.
Besprich den Umfang mit Software-QA und nutze die Launchcheckliste für weitere Risiken. Fachliche Lieferfähigkeit, Behebung und Nachprüfung müssen vor Beauftragung bestätigt werden.
Die Stichprobe nach Aufgaben und Zuständen wählen
Beschreibe einen vollständigen Weg: Leistung finden, Anfrage ausfüllen und eine Validierungsfehlermeldung verstehen. Nimm alle beteiligten Vorlagen und Zustände auf, etwa Navigation, Dialog, leere Suche, fehlgeschlagenes Absenden und Bestätigung. Dokumente und Drittkomponenten gehören dazu, wenn sie für die Aufgabe nötig sind. Eine reine Seitenliste kann die blockierende Interaktion übersehen.
Begründe, warum die Auswahl repräsentativ ist, und benenne Ausschlüsse. Gleiche Vorlagen, Sprachversionen und mobile Ansichten können sich unterschiedlich verhalten. Browser, Gerät, assistive Technik und Datum ermöglichen die Reproduktion. Eine ungetestete Seite besteht nicht automatisch, nur weil sie denselben Header verwendet.
Aus dem Dialogbeispiel einen behebbaren Befund machen
Ein brauchbarer Befund nennt Öffnungsstelle, Fokusweg, unerreichbares Steuerelement und blockierte Aufgabe. Dokumentiere Schritte, erwartetes und beobachtetes Verhalten, relevantes Kriterium und Nachweise. Trenne Nutzerauswirkung von Projektpriorität: Reihenfolge und Verantwortung muss das Release-Team trotzdem vereinbaren.
Nach der Reparatur werden ursprüngliche Schritte und angrenzende Zustände wiederholt. Öffnen, Bedienung, Schließen und Rückkehr an eine sinnvolle Stelle prüfen. Ein Nachtest nur des geänderten Buttons kann denselben Fehler in einem anderen Dialogzustand übersehen. Originalbefund, Änderung und Nachtestergebnis zusammenhalten.
Ein Ergebnis verlangen, mit dem das Umsetzungsteam arbeiten kann
Verlange Befundregister, geprüften Umfang, Methode und Umgebungsdetails sowie eine Besprechung offener Punkte. Vereinbare, wie daraus Umsetzungstickets werden und wo Spezialwissen nötig ist. Prüfung, Reparatur und Verifikation hängen zusammen, brauchen aber jeweils eine klare Zuständigkeit.
Wo das meistens schiefgeht
- Ein Crawler prüft öffentliche Seiten, erreicht aber weder angemeldete Formulare noch deren Fehlerzustände. Zugriff und Testkonten in der Vorbereitung vereinbaren.
- Der Bericht gibt allen Warnungen dieselbe Schwere, ohne blockierte Aufgaben zu erklären. Auswirkungen und reproduzierbare Nachweise für die Priorisierung verlangen.
- Eine Reparatur ändert das Designsystem, andere Vorkommen bleiben ungetestet. Neben dem Originalbefund eine repräsentative Regressionsstichprobe vereinbaren.
Die Checkliste
Nutze diese Punkte für deinen Umfang.
- Kritische Abläufe, repräsentative Seiten und Dokumente auflisten.
- Kriterien, Browser, Geräte und assistive Technologien vereinbaren.
- Qualifizierte Prüfpersonen und nötige Nutzerbeteiligung klären.
- Auswirkung, Reproduktionsschritte und Umfangsgrenzen verlangen.
- Behebungsverantwortung und Nachprüfung vereinbaren.
- Zuständigkeit für Berichtsabnahme und Zuweisung von Reparaturen benennen.
- Zugriff auf angemeldete Abläufe und Drittkomponenten vereinbaren.
- Befunde mit Änderungen und Nachtestergebnissen verknüpfen.
Wie das in unserer Arbeit aussieht
MyMerch zeigt angrenzende Storefront-Verbesserung, keinen Nachweis einer Konformitätsprüfung zur Barrierefreiheit.
Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 75+ Produkte ausgeliefert.