Manuelle AT-Verifikation

Dies sind gezielte manuelle Verifikationsverfahren für einzelne Befunde und Behebungen – damit die QA einer Partneragentur, nicht nur ein Vollzeit-Barrierefreiheits-Spezialist, von Hand bestätigen kann, dass ein konkreter AllyProof-Fix mit Screenreader oder Tastatur tatsächlich funktioniert. Sie ersetzen kein professionelles manuelles Barrierefreiheits-Audit.

Für wen das gedacht ist

  • Agentur-QA, die den Fix eines Entwicklers bestätigt, bevor der Kunde ihn sieht.
  • Compliance-Teams von Anbietern, die VPAT-Selbstbewertungen abzeichnen, bei denen Automatisierung nicht ausreicht.
  • Beschaffungsprüfer, die eine Website stichprobenartig prüfen, von der sie Software kaufen möchten.

Bevor Sie beginnen

Jeder Fix pro Regel trägt auf der Problem-Detailseite einen Abschnitt Mit … prüfen – das ist das kanonische Rezept. Dieses Dokument ist die breitere Orientierung: wie man die Werkzeuge einrichtet und wie man einordnet, was man hört, wenn der Scanner "besteht" meldet.

Einmalige Einrichtung

Windows + NVDA (empfohlener Einstiegspunkt)

  1. Laden Sie NVDA von der NV-Access-Website herunter. NVDA ist kostenlos; AllyProof liefert es nicht mit.
  2. Am Standardort installieren. Beim ersten Start liest NVDA den Dialog laut vor – Lautstärke aufdrehen und bestätigen, dass Sie es hören.
  3. Firefox oder Chrome als Testbrowser konfigurieren. NVDA funktioniert mit beiden; Firefox hat ein etwas besseres Accessible-Tree-Verhalten.
  4. Lernen Sie die fünf Tastenkombinationen, die Sie 90 % der Zeit verwenden: Tab, H (nächste Überschrift), D (nächste Landmarke), F (nächstes Formularfeld), NVDA+Leertaste (Lese-/Fokusmodus umschalten).

macOS + VoiceOver

  1. Aktivieren über Systemeinstellungen → Bedienungshilfen → VoiceOver. Die Funktion ist integriert – keine Installation nötig.
  2. Lernen Sie die VO-Taste: Control + Option. Fast jede VoiceOver-Tastenkombination beginnt damit.
  3. Safari ist VoiceOvers nativer Partner. Chrome funktioniert, hat aber Eigenheiten bei dynamischen Inhalten.

Nur-Tastatur-Prüfung (beide Plattformen)

Die Hälfte des "manuellen AT-Testens" besteht einfach darin, die Maus abzustecken. Tab, Umschalt+Tab, Enter, Leertaste und die Pfeiltasten – wenn Sie nicht jedes interaktive Element erreichen und aktivieren können, versagt die Website, egal was ein Screenreader sagt.

So verifizieren Sie ein bestimmtes Problem

  1. Lesen Sie auf der AllyProof-Problemseite das Panel Mit … prüfen – es nennt das Werkzeug und die genauen Schritte.
  2. Öffnen Sie die betroffene Seite im angegebenen Browser mit der genannten laufenden AT.
  3. Folgen Sie den nummerierten Schritten. Im Rahmen der Verifikation dieses bekannten Defekts hat jeder Schritt ein einziges beobachtbares Ergebnis – entweder entspricht die Ankündigung/das Verhalten der Erwartung oder nicht, ohne Ermessensentscheidung pro Schritt. Genau das macht die Rezepte für Nicht-Spezialisten durchführbar; genau deshalb bestätigen sie aber auch nur das konkret erwartete Verhalten und nichts darüber hinaus.
  4. Besteht die Prüfung, hinterlassen Sie einen manuellen Testkommentar beim Problem (das Kommentarformular hat einen Typ Manuelle Verifikation) mit Werkzeugname, Betriebssystem und Datum. Das sieht Ihr Kunde im Audit-Trail.
  5. Schlägt die Prüfung fehl, eröffnen Sie das Problem erneut und notieren Sie genau, wo der Schritt gescheitert ist. Ein Screenshot oder ein Screenreader-Transkript ist ideal.

Was diese Rezepte nicht sind

Diese Rezepte prüfen konkret erwartete Verhaltensweisen. Ein vollständiges manuelles Barrierefreiheits-Audit erfordert zusätzlich kontextbezogenes Urteilsvermögen, das Testen vollständiger Prozesse, eine repräsentative Stichprobe und exploratives Testen mit assistiver Technologie. Wenn alle Rezepte auf dieser Seite bestehen, ist bestätigt, dass die einzelnen Fixes funktionieren – WCAG-Konformität der Website ist damit nicht belegt.

Häufige Fallstricke

  • Testen im Fokusmodus, obwohl Sie im Lesemodus sein sollten. NVDAs Lesemodus simuliert das Lesen der Seite; der Fokusmodus dient dem Ausfüllen eines Formulars. Wenn die Pfeiltasten nicht durch den Inhalt schreiten, drücken Sie NVDA+Leertaste.
  • Die AT im falschen Browser ausführen. Eine Seite, die in Safari/VoiceOver korrekt vorgelesen wird, kann sich in Chrome/VoiceOver wegen subtiler Accessible-Tree-Unterschiede falsch verhalten. Verwenden Sie den auf der Problemseite angegebenen Browser.
  • "Der Scanner besteht" als erledigt behandeln. Automatisierung erfasst Syntax; sie kann Ihnen nicht sagen, ob der Name einer Schaltfläche im Kontext Sinn ergibt. Führen Sie immer die aufgeführte manuelle Prüfung durch, nachdem der Scan grün wird.
  • Nur-Tastatur für Nur-Screenreader auslassen. Screenreader-Nutzer navigieren typischerweise mit der Tastatur; existieren Tastaturfallen, ist auch die Screenreader-Erfahrung kaputt. Führen Sie den Tastaturdurchgang zuerst durch.

Was als ausreichender Nachweis gilt

Für eine VPAT-Selbstbewertung oder eine öffentliche Barrierefreiheitserklärung:

  • Nennen Sie das Werkzeug (z. B. NVDA 2024.4), den Browser (z. B. Firefox 128 ESR) und das Betriebssystem (z. B. Windows 11), die für die Prüfung verwendet wurden.
  • Erfassen Sie das Datum, an dem die Prüfung durchgeführt wurde – Prüfer erwarten in der Regel, dass es im letzten Quartal liegt.
  • Bewahren Sie bei umstrittenen Befunden ein kurzes Transkript auf (Copy-paste der NVDA-Sprachausgabe-Ansicht oder eine VoiceOver-Aufnahme).

Wann an einen Barrierefreiheits-Spezialisten eskalieren

Partner-QA kann die rund 30 Regeln im AllyProof-Regelkatalog zuverlässig verifizieren. Eskalieren Sie an einen dedizierten Barrierefreiheitsprüfer, wenn eines der Folgenden zutrifft:

  • Das Problem betrifft ARIA-Live-Regionen, benutzerdefinierte Widgets (Comboboxen, Bäume, Grids) oder das Verhalten dynamischer Inhalte – die Verifikation ist nicht Schritt-für-Schritt mechanisch.
  • Die Website ist ein Ziel im Bereich Regierung, Gesundheitswesen oder Finanzen, bei dem eine Fehleinschätzung rechtliche Konsequenzen hat.
  • Der VPAT-Prüfer verlangt ausdrücklich eine Bestätigung durch einen externen Experten – in diesem Fall ist automatisierte + Partner-QA-Abdeckung die Untergrenze, nicht die Obergrenze.