1. Bestimme die Aufgabe der Seite, bevor du das Layout wählst
Beginne mit Seiten, die eine Kunden‑ oder Geschäftsaufgabe tragen: Service‑Seiten, Produktseiten, Lead‑Formulare, Buchung, Kontoanmeldung, Warenkorb und Hilfe. Formuliere für jede eine Abschlussaussage, z. B.: „Eine Erstbesucherin kann diesen Service verstehen, relevante Nachweise sehen und einen Rückruf anfordern.“ Hat die Seite mehr als eine Aufgabe, entscheide, welche zuerst erscheint.
Liste ihre Inhalte als wesentlich, unterstützend oder optional. Wesentlich heißt nicht kurz; eine Besucherin braucht möglicherweise Preiszusammenhang, Anspruchsbedingungen, Lieferdetails oder Vergleichsinformationen. Gib diesem Material einen klaren Weg im schmalen Layout. Google empfiehlt äquivalenten primären Inhalt auf Mobil und Desktop, erlaubt aber eine andere Präsentation wie Tabs oder Akkordeons.
Bei schmaler Breite sollte eine Kollegin sagen können, was die Seite anbietet, wem sie hilft und welche sinnvolle nächste Aktion ist.
2. Mache die schmale Basisversion vollständig
Beginne mit einem funktionierenden Einspaltenpfad statt ein Desktop‑Layout zu verkleinern. Verwende flexible Container, lasse Text umfließen und setze ein Viewport‑Setting, das dem Browser erlaubt, das Layout an die Gerätebreite anzupassen. Verhindere das Zoomen nicht. Prüfe, dass Menüs, Hinweise, Bilder, eingebettete Inhalte und Formularfehler im Viewport bleiben; unbeabsichtigtes seitenweites horizontales Scrollen ist normalerweise ein Fehler.
Nutze 320 CSS‑Pixel als anspruchsvollen Reflow‑Check für gewöhnlichen Lesetext und Aufgabeninhalte. WCAG 2.2 beschreibt, vertikalen Inhalt bei dieser Breite ohne Informations‑ oder Funktionsverlust oder zweidimensionales Scrollen darzustellen. Eine Karte, ein Diagramm oder eine Datentabelle kann einen eigenen Scrollbereich brauchen, aber das rechtfertigt nicht, die umgebende Seite seitwärts scrollbar zu machen.
Passe Bilder an ihren Container an und gib Abmessungen an, damit der Browser vor dem Laden Platz reservieren kann.
3. Ergänze Verbesserungen, ohne den Basispfad fragil zu machen
Progressive Enhancement bedeutet, dass wesentliche Inhalte und Funktionen als Basis funktionieren, während fähigere Browser und größere Bildschirme Extras erhalten. Adresse, Produktdetails, Formularbeschriftungen, Preiserklärung und Absendeweg dürfen nicht von Animation, Hover oder einem späten Script abhängen. Ein breiteres Layout kann eine Vergleichs‑Spalte, persistente Navigation oder reichere Filter hinzufügen, ohne die Basis unvollständig zu machen.
Fordere den Implementierenden auf, einen Breakpoint hinzuzufügen, wenn der Inhalt zu gedrängt oder verschwenderisch wird — nicht weil ein Geräte‑Name in einer Liste auftaucht. Ein Breakpoint ist einfach der Punkt, an dem eine Layout‑Regel sich ändert. Verwende schmale Layouts nicht, um stillschweigend Hilfetexte, Richtlinien, Bewertungen, Metadaten oder wichtige strukturierte Details zu entfernen.
Zeige zuerst ein einfaches Galeriebild und eine Beschreibung, ergänze dann Zoom‑ oder Swipe‑Kontrollen, wenn deren Skripte verfügbar sind.
4. Gestalte Steuerelemente für Touch, Klarheit und Wiederherstellung
Touch‑Ergonomie heißt, für Hände statt für einen präzisen Mauszeiger zu entwerfen. Gib Buttons, Checkboxen, Schließ‑Symbole, Mengenauswahlen und Formularoptionen genug Größe und Abstand, um Fehl‑Taps zu reduzieren. Beschrifte Icons, wenn ihre Bedeutung nicht offensichtlich ist. Mache Hover nicht zur einzigen Möglichkeit, einen Preis, ein Untermenü, eine Erklärung oder eine Aktion sichtbar zu machen.
WCAG 2.2 enthält ein Level‑AA‑Kriterium zur Mindestzielgröße von mindestens 24 × 24 CSS‑Pixel für Pointer‑Ziele, mit aufgeführten Ausnahmen einschließlich Abstand und Inline‑Links. Behandle das als Mindestreferenz, nicht als Komfortgarantie. Kritische Aktionen verdienen klare Beschriftungen, großzügige Abstände und einen reversiblen Bestätigungsschritt. Ziehe eine fachkundige Accessibility‑Überprüfung für risikoreiche Journeys oder formale Konformitätsansprüche hinzu.
Bleibe mit sichtbaren Labels, zeige nutzbares Validierungs‑Feedback und erhalte eingegebene Werte nach einem Fehler.
5. Behandle Medien und Einbettungen als Teil der Besucherreise
Entscheide, ob jedes Bild informativ, überzeugend oder dekorativ ist. Ein informatives Bild braucht eine passende Textalternative und einen schmalen Layout‑Zuschnitt, der das notwendige Detail bewahrt. Responsive‑Bildoptionen erlauben Browsern, eine geeignete Ressource zu wählen, anstatt allen Besucherinnen die größte Desktop‑Asset herunterzuladen. Lass ein Hero‑Bild oder Video nicht den Seitenzweck und die primäre Aktion verdecken.
Inventarisiere Karten, Chat, Video, Zahlungs‑, Terminbuchungs‑, Consent‑ und Bewertungs‑Widgets. Prüfe auf schmalen Bildschirmen deren Ladezustand, Steuergröße, begrenztes Layout und eine praktikable Fallback‑Route. Bei Zahlungs-, Identitäts‑ oder regulierten Datenflüssen binde qualifizierte Security‑, Datenschutz‑ und Compliance‑Reviewer ein; visuelle Tests sind keine Sicherheitsbewertung.
Dokumentiere jede externe Komponente, ihren Besitzer, ihre Geschäfts‑Funktion und den genehmigten Fallback, falls sie langsam oder ausgefallen ist.
6. Teste Aufgabenpfade vor dem Release und plane die Behebung
Nutze frühzeitig den Browser‑Responsive‑Modus, um schmale, mittlere und breite Breiten zu inspizieren. Chrome Device Mode kann Viewport, Touch, Orientierung, Netzwerk und CPU‑Bedingungen annähern, aber Chrome beschreibt es als Näherung, nicht als echte Geräteausführung. Schließe kritische Pfade auf echten Handys und relevanten Browsern ab, wenn möglich.
Teste eine Aufgabe, nicht nur einen Screenshot: Kalter Erstladevorgang, Navigation, ungültige und gültige Formularübermittlung, Orientierungswechsel, Zoomen und Rückkehr von einer Drittanbieterseite. Dokumentiere URL, Browser oder Gerät, Aufgabe, erwartetes Ergebnis, Verantwortlichen und Rollback‑Entscheidung. Bei größeren Template‑, Checkout‑, CMS‑ oder Abhängigkeitsänderungen stage den Release und bereite vor, den vorherigen Pfad wiederherzustellen, statt unter Druck zu improvisieren.
Genehmige erst, wenn die kritische Aufgabe funktioniert, Bedienelemente nutzbar sind, seitenweites horizontales Scrollen fehlt und Schlüsselabhängigkeiten einen Fallback haben.