Coverage um Kundenaufgaben herum aufbauen
Liste die Routen und Ergebnisse, die Wert schaffen: eine Dienstleistung finden, suchen, einen Artikel in den Warenkorb legen, buchen, anmelden, Hilfe anfordern oder bezahlen. Benenne für jede Route die Komponenten, die ihre Form ändern oder ausfallen können: Navigation, Filter, Cards, Tabellen, Bilder, Banner, Formulare, Drawers und eingebettete Widgets. Teste Breiten, bei denen dein Inhalt eingeschränkt wird, und nicht bloß eine Aufzählung aktueller Handymodelle. Teste knapp unterhalb, an und knapp oberhalb jeder Breakpoint‑Stelle.
Beziehe schmale und mittelbreite Telefone, eine tablet‑ähnliche Breite, Laptop, breiten Desktop und Landscape mit ein, wenn die Orientierung die Aufgabe ändert.
Verwende lange Titel, leere Suchergebnisse, Validierungsfehler, Preis‑Badges, vollständige Adressen und längere Beschriftungen, sofern diese Zustände existieren.
Reflow, Lesbarkeit und Zoom nachweisen
Bestätige, dass die Seite eine geeignete Viewport‑Einstellung hat, und prüfe dann auf seitenweites horizontales Scrollen. Fixe Bilder, breite Felder, negative Margins, Off‑Canvas‑Panels und Banner sind häufige Ursachen. WCAG 2.1 Reflow beschreibt vertikal scrollbarenen Inhalt bei einer Breite von 320 CSS‑Pixeln, einschließlich eines 1280‑Pixel‑Viewports bei 400% Zoom. Wenn dieses Kriterium relevant ist, teste das tatsächliche Zoom‑Szenario. Eine Karte, ein Video oder eine Datentabelle kann eine zweidimensionale Anordnung benötigen, aber halte das Scrollen innerhalb der Komponente und lasse die umgebende Seite umfließen (reflowen).
Prüfe Header, Hauptinhalt, Footer, Sticky‑Bars, Dialoge und Fehlerzusammenfassungen an jeder getesteten Grenze.
Organisiere Informationen für einen schmalen Bildschirm um; entferne nicht stillschweigend Pflichtangaben, Preisinformationen oder Hilfepfade.
Inhalte und Formulare belasten
Content‑Operationen können responsive Fehler ohne CSS‑Release verursachen. Teste die längste freigegebene Überschrift, mehrere Badges, ein fehlendes Bild, einen ausgewählten Filter, einen großen Rechtshinweis und ein vom Browser ausgefülltes Feld. Wenn Spalten umbrechen, bestätige, dass Reihenfolge beim Lesen und per Tastatur weiterhin Sinn ergibt. Führe das echte Formular auf einem kleinen Gerät komplett durch: Steuerungen öffnen, einen Fehler korrigieren und absenden. Teste Drittanbieter‑Widgets in einer produktionsähnlichen Seite, denn ihr Container, Consent‑Status, Fonts und Styles können das Ergebnis verändern.
Spiegle wahrscheinliche Maximal‑Längen und Kombinationen wider, aber inkludieren keine Kunden‑ oder Zahlungsdaten in QA‑Belegen.
Öffne Hinweise, Chat, Promotionen und Validierungs‑Messages zusammen; keines darf die primäre Aktion oder das fokussierte Feld verdecken.
Jeden Eingabepfad durchspielen
Ein großer Bildschirm garantiert keine Maus, und ein kleiner Bildschirm garantiert nicht nur Touch. Das Hover‑Media‑Feature prüft, ob eine primäre Eingabe bequem hovern kann; Hover sollte daher ergänzen und nicht der einzige Weg zu einer Aktion oder Erklärung sein. Teste Tastatur und Pointer auf dem Desktop, Tippen und Scrollen auf einem Touch‑Gerät sowie Geräte mit gemischter Eingabe, wo relevant. Prüfe kompakte Schließen‑Buttons, Steppers, Chips, Kalender und Icon‑Aktionen. WCAG 2.2 Target Size (Minimum) spezifiziert eine Zielgröße von 24 mal 24 CSS‑Pixeln mit definierten Ausnahmen, inklusive Abstand und Inline‑Links. Das ist ein Kriterium mit Umfang und Ausnahmen, kein Versprechen, dass jedes 24‑Pixel‑Control für alle gleich einfach ist.
Tabbe durch die Seite. Der Fokus sollte sichtbar bleiben, einer sinnvollen Reihenfolge folgen und Menüs sowie Dialoge vorhersehbar betreten und verlassen.
Mache ein essentielles Hover‑Reveal per Fokus, Tippen oder sichtbarer Steuerung verfügbar und verhindere verwirrendes Erst‑Tippen‑Verhalten.
Assets und Performance unter Einschränkung verifizieren
Ein Bild kann in seinen Container passen und trotzdem die falsche Datei für das Gerät sein. Prüfe, dass Medien enthalten bleiben, wo nötig Layout‑Platz reservieren, die nützliche Zuschneidung bewahren und geeignete Kandidaten anfordern. srcset und sizes geben dem Browser Informationen zur Auswahl zwischen gelieferten Bildquellen; sie garantieren keine bestimmte Anfrage. Nutze DevTools‑Throttling, um Probleme früh zu entdecken, aber deren CPU‑ und Netzwerksteuerung simuliert Bedingungen relativ zum Entwicklungsrechner. Wiederhole Schlüsseljournies auf einem echten Gerät und einer echten Verbindung. Untersuche Fonts, Hero‑Medien, Karussells, clientseitige Arbeit und Drittanbieter‑Skripte auf Verzögerungen, Verschiebungen oder blockierte Taps.
Erfasse Route, Viewport, reale oder simulierte Verbindung und was langsam oder instabil wurde; vergleiche unter gleichen Bedingungen.
Verzögere, wo sicher, nicht‑essentielle Embeds in einem Test‑Build, um zu lernen, ob die Kernaufgabe nutzbar bleibt.
Beheben als proaktive Uptime‑Arbeit
Für Status Is UP ist responsive Readiness proaktive Uptime‑Optimierung: Identifiziere einen nutzerblockierenden Gerätepfad, behebe seine Ursache, beweise die Reparatur und verhindere ein Wiederauftreten. Es ist kein Anspruch, dass ein Monitoring‑Alert jedes Layout‑ oder Interaktionsdefizit beurteilen kann. Priorisiere nach Aufgabenimpact und Reichweite. Teste vor der Bereitstellung benachbarte Breiten und die geänderte Journey auf realer Hardware. Plane ein Rollback für Änderungen an gemeinsamer Navigation, Styles, Skripten, Zahlungen oder Integrationen. Nach dem Release wiederhole die Prüfungs‑Schritte und hänge die Belege an den Change‑Record an.
Gib Route, Gerät oder Viewport, Orientierung, Eingabe, Zustand, erwartetes Ergebnis, tatsächliches Ergebnis und eine redigierte Aufnahme an.
Bevorzuge eine Komponenten‑, Layout‑Regel‑, Token‑ oder Bild‑Delivery‑Korrektur gegenüber einer reinen Routen‑Override; gib Ausnahmen einen Eigentümer und einen Plan zur Entfernung.