Testen der Verfügbarkeit von Schnittstellen

1) Warum und was wir als „fertig“ betrachten

• WCAG 2 Kriterien erfüllt sind. 1/2. 2 AA-Stufen für Zielplattformen;
• die Schnittstelle ist vollständig über die Tastatur erreichbar;
• korrekte Arbeit mit Screenlesern;
• Kontraste entsprechen den Normen;
• alle Zustände/Fehler/Zustände sind außer Sicht und ohne Maus zugänglich;
• berücksichtigt werden Lokalisierung, RTL, Bewegungsreduzierung und mobile Features.

2) Teststrategie (Pyramide A11y)

1. Autotests/Linter (schnelle Abdeckung von bis zu 40-60% der Problemklassen).
2. Manuelle Musterprüfung (Tastatur, Fokus, Inhalt, Logik).
3. Assistive Tech (AT) Sitzungen: Bildschirmleser, Skalierung, Farbfilter.
4. Feldversuche mit Anwendern (wenn möglich).

Das Ziel: Systemdefekte auf Komponenten-/Musterebene auffangen, damit sie sich nicht in Filamenten vermehren.

3) Checkliste der Basisprüfungen (Schnelldurchlauf)

• Tastatur: alles durch Tabs/Pfeile erreichbar; die Reihenfolge des Fokus ist logisch; Die Falle des Fokus in modalki ist; ESC/Enter/Space funktionieren.
• Der Fokus-Indikator ist in jedem Thema/auf jedem Hintergrund zu sehen.
• Kontrast: Text ≥ 4. 5:1 (normal), ≥ 3:1 (groß), Icons/Kontrollen sind lesbar.
• Semantik: korrekte Tags ('button','a', 'label', 'ul/li', 'th/td'), Rollen und 'aria-' nur bei Bedarf.
• Screenrider: Überschriften nach Hierarchie, semantische Namen von Buttons/Links, Alternativen für Icons/Bilder.
• Formulare: explizite' label', Hinweise/Fehler verlinkt ('aria-describedby'), Fehlertexte spezifisch.
• Dynamik: Toast/Banner/Bugs werden über 'aria-live' ('polite '/' assertive') angekündigt.
• Animationen respektieren 'prefers-reduced-motion'; ohne „Schütteln“ der Schnittstelle.
• Lokalisierung/RTL: Schlüsselbildschirme werden ausgerichtet, Zahlen/Daten/Währungen mit Dienstprogrammen formatiert.
• Mobilität: Touch-Ziele ≥ 44 × 44 px, Zoom ist nicht verboten, Bildschirmdrehung bricht den Inhalt nicht.

4) Rollen, Verantwortlichkeiten und Artefakte

Design-System: A11y-Anforderungen in der Beschreibung der einzelnen Komponenten.
Entwickler: Autoprüfungen, Unit/Interaction-Tests mit A11y-Assert.
QA: manuelle Skripte + AT-Sitzungen; Bericht mit Schweregrad/Häufigkeit.
UX/Content: Mikrokopie von Fehlern/Status, Lesbarkeit laut.
Artefakte: Checklisten, Skripte, AT-Screencasts, Mängelliste mit WCAG-Referenzen, Empfehlungen.

5) Automatisierte Kontrollen

Linter/Analysatoren: axe, eslint-plugin-jsx-a11y, pa11y, Lighthouse.
In der Pipeline: Wir blockieren PR bei kritischen Verstößen (Rolle/Label/Kontrast/Tab-Fallen).
Kontrast-Schnappschüsse: visuelle Tests von Themen/Zuständen.

6) Manuelle Prüfung: Szenarien

6. 1 Tastatur

Gehen Sie die Seite nur mit der Tastatur durch (Tab/Shift + Tab/Enter/Space/Pfeile).
Überprüfen Sie: die Sichtbarkeit des Fokus, die Reihenfolge, die Verfügbarkeit aller Aktionen, das Fehlen von „Fallen“ und „toten“ Elementen.
Im Modalka: Der Fokus liegt im Inneren, beim Schließen kehrt er zum Initiator zurück.

6. 2 Screenrider (Mindestsatz)

Desktop: NVDA/JAWS (Windows), VoiceOver (macOS).
Mobile: VoiceOver (iOS), TalkBack (Android).
Wir überprüfen: korrekte Überschriften (H-Hierarchie), Namen von Buttons/Links, Lesen von Tabellen ('th '/' scope'), Deklaration von Status, verständliche Formfehler.

6. 3 Inhalt und Microcopy

Wir lesen kritische Texte laut vor - ohne Unklarheiten, ohne „Fehler 400“.
Fehler = „Was ist falsch + wie zu beheben + Einschränkung/Format“.

6. 4 Dynamik und lebendige Regionen

Der Toast des Erfolgs ist 'aria-live =' polite', der Fehler ist 'assertive'.
Fortschritt/Download wird im Text erklärt; Skelett ist dem Spinner vorzuziehen.

7) Formen und Fehler (vertieft)

Jedem Feld ist ein Label (kein Placeholder) zugeordnet.
Die Fehler beziehen sich auf das Feld: 'aria-invalid =' true'', 'aria-describedby =' [error id]''.
Formatformeln (Datum, Telefon) werden im Voraus angegeben; Masken brechen die Eingabe/Einfügung nicht.
Summenfehler Banner bei submit + auto-scrolling und Fokus auf den ersten Fehler.
Fehlertexte: konkret, ohne Fachjargon.

8) Tabellen, Listen, Grafiken

Tabellen: Überschriften „th“ mit „scope =“ col/row „“, Unterschriften, Zusammenfassungen.
Die Listen sind echte' ul/ol/li', keine Diven.
Diagramme - alternative Tabellen/Beschreibungen; Legenden sind verfügbar; Farben ≠ das einzige Signal.

9) Multimedia und Animationen

Video: Untertitel/Entschlüsselung; Steuerung über Tastatur; ohne Autoplay (oder mit Ruhe).
GIF/Mikroanimationen: Ausschalten bei 'prefers-reduced-motion'; Ausbrüche vermeiden.
Vibrationen/Geräusche - optional und visuell/Text dupliziert.

10) Mobile Verfügbarkeit

Interaktiv ≥ 44 × 44 px, ausreichende Intervalle.
Skalierung nicht verbieten (meta viewport ohne' user-scalable = no').
Form/Tastatur: Die richtigen Typen ('tel', 'email', 'number') verstecken die Systemfunktionen nicht.
Check im dunklen Thema und mit System-Schriftarten „mehr“.

11) Lokalisierung, Zahlen und RTL

Strings über i18n-Schlüssel mit Kontext; lange Sprachen (DE/TR) machen das Layout nicht kaputt.
Datums-/Währungsformate sind Dienstprogramme, keine Zeichenfolgen.
RTL-Modus: Spiegeln Sie die Navigationssymbole, überprüfen Sie die Reihenfolge von Fokus und Wagen, bidirektionale Eingabe.

12) Besonderheiten kritischer Flows (iGaming)

Zahlungen/Schlussfolgerungen

Klare Anweisungen, Grenzen/Fristen/Gebühren - Text.
Fehler des Anbieters werden explizit ohne Codes angekündigt; Es gibt eine Alternative zum Handeln.
Operationsbestätigung: Fokus auf logischem CTA, Stornierungsmöglichkeit.

CUS/Verifizierung

Schritt-für-Schritt-Tipps für Fotos/Dokumente; Fortschritt und ETA.
Fehler „verschwommen/blendend/beschnitten“ - mit Korrekturbeispielen.
Neutraler Ton, kein Humor.

13) Beurteilung der Schwere der Mängel

Blocker: Schlüsselaufgabe kann nicht abgeschlossen werden (mit Tastatur/Screenreader).
Kritisch: Kritische Funktionalität funktioniert, aber mit großen Barrieren.
Major: stört, es gibt einen Workaround.
Minor: Kosmetik/Mismatch zu Gaidas ohne Einfluss auf die Aufgabe.

Jeder Fehler ist ein Verweis auf das WCAG-Kriterium und ein reproduzierbares Szenario.

14) Abnahmekriterien (Definition of Done, A11y)

Übergeben Sie das Tastaturskript ohne Maus zu 100%.
axe/Leuchtturm: keine kritischen/hohen Störungen.
AA-Kontrast in allen Themen/Zuständen.
Screenrider-Run Schlüsselpfade (navbar, Formen, modalki, Toast).
Dokumentation A11y für neue Komponenten/Teile (Rollenmodell, aria, Fokus, Beispiele).
Die Regression der A11y-Tests ist im CI grün.

15) Prozesse und Automatisierung

Vor der Entwicklung: A11y-Kriterien in Aufgaben, Layouts mit Fokus-/Fehlerzuständen.
In Entwicklung: Linters/ahe bei lokaler Montage; visuelle Schnappschüsse von Kontrasten/Fokus.
In CI: pa11y/axe-scan auf kritischen Seiten; Bildverfall unter Blocker/Kritisch.
Nach der Veröffentlichung: vierteljährliche Audits, Überwachung von Benutzerbeschwerden durch A11y-Tag.

16) Anti-Muster

Platzhalter statt Label.
„div“ anstelle von „button “/„ a“.
Deaktivierte Fokusringe „für die Schönheit“.
Farbe als einziger Statusträger.
Modalki ohne Focus-Trap/ESC.
Verbot der Skalierung auf Mobile.
„400/500 Fehler“ ohne menschliche Erklärung.

17) Vorlagen für Testszenarien

Szenario 1 - Tastaturnavigation (Formularseite)

1. Tab zum ersten Feld, geben Sie die Daten ein.
2. Shift + Tab zurück - Stellen Sie sicher, dass die Reihenfolge korrekt ist.
3. Validierung aufrufen (submit) - Fokus wird auf den ersten Fehler übertragen.
4. Schließen Sie das Modal mit der ESC-Taste, der Fokus ist wieder auf den Initiator gerichtet.

Szenario 2 - Screenrider (Zahlungsseite)

1. Gehen Sie zum Seitentitel (h1), hören Sie sich die Abschnitte an.
2. Öffnen Sie die Methodenauswahl - die Deklaration der Rollen/Zustände ist hörbar.
3. Machen Sie bewusst einen Betragsfehler - die Nachricht wird gelesen und mit dem Feld verknüpft.
4. Ein erfolgreicher Toast auf die Zahlung wird als „polite“ deklariert.

Szenario 3 - Dynamik

1. Starten Sie die Operation mit einer Wartezeit> 3 s - es gibt Text über den Prozess/ETA.
2. Bei einem Netzwerkfehler - Banner 'assertive', über die Tastatur erreichbar, gibt es einen Weg „wiederholen/helfen“.

18) Nützliche Mikro-Templates

Rollen/aria für Toast

html
<div role = "status" aria-live = "polite"> Payment accepted. Balance updated. </div>
<div role = "alert" aria-live = "assertive"> The payment was denied. Try another method. </div>

Verknüpfen eines Fehlers mit einem Feld

html
<label for = "amount "> Amount </label>
<input id="amount" aria-invalid="true" aria-describedby="amount-error">
<div id = "amount-error "> Minimum 100 UAH. Please enter a larger amount. </div>

Modalka (semantische Attribute)

html
<div role="dialog" aria-modal="true" aria-labelledby="m-title">
<h2 id =" m-title "> Confirm Payment </h2>
<! -- content -->
<button> Confirm </button>
<button> Cancel </button>
</div>

19) Schneller Implementierungsplan für A11y-Praktiken

1. Prüfung der aktuellen Komponenten/Muster (Kontrast/Fokus/Rollensemantik).
2. Design System Edits: Fügen Sie jeder Komponente eine A11y-Partition hinzu.
3. Werkzeuge: Konfigurieren Sie die Linter/axe/pa11y/Lighthouse lokal und im CI.
4. Training: Kurze Tipps für Designer/Entwickler/Texter.
5. Pilot: Reparieren Sie 3-5 der häufigsten Defekte (Modale, Formen, Toast).
6. Reglement: DoD mit A11y-Kriterien; vierteljährliche Prüfung.

Abschließender Spickzettel

Überprüfen Sie Tastatur, Fokus, Kontraste, Bildschirmleser, Dynamik.
Erklären Sie Status durch aria-live; Fehler - feldbezogen.
Respektieren Sie die Reduzierung der Bewegung, verbieten Sie nicht die Skalierung.
Denken Sie an Semantik (Tags/Rollen) und nicht an „wie es aussieht“.
Automatisieren Sie die Kontrollen, aber immer ergänzen Sie manuell.
Erfassen Sie die Mängel mit Bezug auf WCAG, Schweregrad und Reproduktionsszenario.