Responsive Webdesign ist keine Zutat, die nach dem Entwurf hinzukommt, sondern die Grundbedingung: Eine Seite muss auf jeder Bildschirmbreite lesbar, bedienbar und vollständig sein. Der überwiegende Teil der Besucher kommt vom Telefon, und eine Seite, die am 27-Zoll-Bildschirm entstanden ist und dort geprüft wurde, hat mit hoher Wahrscheinlichkeit ein Problem.
Warum von der kleinen Breite aufwärts
Wer mit der kleinen Breite beginnt, muss entscheiden, was wirklich gebraucht wird. Auf 375 Pixel Breite ist kein Platz für drei Spalten, eine Seitenleiste, einen Slider und eine Kachelnavigation. Diese Beschränkung erzwingt Priorisierung.
Wer umgekehrt arbeitet, hat am Ende ein volles Layout und muss es zusammenfalten. Das führt zu den typischen Symptomen: Inhalte werden ausgeblendet statt umsortiert, eine Seitenleiste landet unten und wird nie gesehen, ein Menü mit zwölf Punkten wird zu einer sehr langen Liste.
Praktisch heißt es: Zuerst die Reihenfolge festlegen, in der Inhalte auf einer schmalen Spalte stehen sollen. Diese Reihenfolge ist die inhaltliche Priorität, und sie sollte auf jeder Breite erkennbar bleiben.
Breakpoints
Ein Breakpoint gehört dorthin, wo der Inhalt es verlangt, nicht auf die Maße eines Gerätemodells. Geräteabmessungen ändern sich, Inhalte nicht.
Ein brauchbarer Satz für die meisten Projekte:
| Ab Breite | Typische Änderung |
|---|---|
| Basis | eine Spalte, Drawer-Menü, gestapelte Karten |
| 640 Pixel | zweispaltige Karten, größere Abstände |
| 768 Pixel | zweispaltige Inhaltsbereiche, größere Überschriften |
| 1024 Pixel | Hauptnavigation sichtbar, Seitenleiste neben dem Inhalt, dreispaltige Raster |
| 1280 Pixel | maximale Inhaltsbreite erreicht, Ränder wachsen |
Wichtig bei der technischen Umsetzung: Wenn ein Werkzeug mit vorgegebenen Breakpoints verwendet wird und einzelne davon überschrieben werden, müssen alle in aufsteigender Reihenfolge deklariert sein. Sonst stehen die Medienabfragen im erzeugten Stylesheet in falscher Reihenfolge, und die Regel für die größere Breite verliert gegen die für die kleinere.
Umbau-Muster, die funktionieren
Raster von 1 auf 2 auf 3 Spalten. Das häufigste und robusteste Muster. Karten mit gleicher Struktur, die sich stapeln.
Navigation zu Drawer. Ab der kleinen Breite ein Menü, das von rechts einfährt. Wichtig: Es muss mit der Tastatur bedienbar und mit Escape schließbar sein, und die Schaltfläche braucht eine erkennbare Beschriftung. Siehe Tastaturbedienung.
Seitenleiste unter den Inhalt. Sinnvoll, wenn die Seitenleiste ergänzend ist. Enthält sie eine wichtige Handlungsaufforderung, gehört diese zusätzlich in den Inhaltsfluss.
Tabelle mit eigenem seitlichen Scrollbereich. Eine breite Tabelle wird in einen Bereich gelegt, der selbst seitwärts scrollt. Wichtig ist, dass die Seite dabei nicht mitscrollt, sonst entsteht der klassische horizontale Überlauf des ganzen Dokuments.
Zwei Zeilen statt einer. Eine Kopfzeile mit Logo, Navigation und Schaltfläche wird auf zwei Zeilen verteilt, statt alles zu verkleinern.
Bilder mit festem Seitenverhältnis. Damit das Layout beim Laden nicht verrutscht und der Zuschnitt auf allen Breiten funktioniert.
Bilder und Assets responsiv
Layout ist die halbe Miete, die andere Hälfte sind die Inhalte, die es füllen. Bilder und eingebundene Dateien brauchen eigene Antworten:
Bilder in mehreren Größen ausliefern. Ein Telefon mit 375 Pixel Breite braucht kein 2.400-Pixel-Bild. Moderne Systeme und Generatoren erzeugen aus einem Original mehrere Größen und überlassen dem Browser die Wahl; wer das nicht nutzt, bezahlt mit Ladezeit genau dort, wo die Verbindungen am schlechtesten sind.
Festes Seitenverhältnis reservieren. Bilder bekommen Breite und Höhe beziehungsweise ein reserviertes Seitenverhältnis, damit das Layout beim Laden nicht springt. Das Springen ist nicht nur unschön, es lässt Nutzer danebentippen.
Zuschnitt als Entscheidung. Ein Querformat-Teamfoto, das auf dem Telefon auf ein Drittel schrumpft, zeigt keine Gesichter mehr. Für wichtige Motive gehört festgelegt, ob auf schmalen Breiten ein anderer Ausschnitt oder ein anderes Bild erscheint.
Text nie im Bild. Er skaliert nicht mit, wird unlesbar und ist für niemanden auffindbar, siehe WCAG-Grundlagen.
Videos und Karten in Container mit Seitenverhältnis legen, sonst ragen sie heraus oder schrumpfen zu Briefmarken. Eingebettete Fremdinhalte (Karten, Formulare, Buchungswidgets) auf jeder Breite einzeln prüfen, sie sind der häufigste Grund für horizontales Scrollen.
Icons als Vektorgrafik, damit sie auf hochauflösenden Bildschirmen scharf bleiben, statt als vergrößerte Pixelgrafik auszufransen.
Was auf Telefonen typischerweise bricht
- Horizontaler Überlauf. Ursache ist fast immer ein einzelnes Element: eine breite Tabelle, ein Codeblock, ein Bild mit festgelegter Breite, ein sehr langes Wort ohne Umbruchmöglichkeit. Findbar, indem man in den Entwicklerwerkzeugen die Breite des Dokuments prüft.
- Zu kleine Klickflächen. Unter etwa 44 Pixel Höhe wird das Treffen zur Glückssache. Betrifft besonders Icon-Schaltflächen und Links, die direkt untereinander stehen.
- Feste Höhen. Ein Element mit fester Höhe, in dem auf schmaler Breite mehr Text steht, schneidet Inhalt ab.
- Text in Bildern. Bei Verkleinerung unleserlich, weil er nicht mitfließt.
- Überlagerungen mit Bildschirmhöhe. Ein Element mit 100 Prozent Viewporthöhe wird auf Telefonen durch die Adressleiste beschnitten.
- Menüs, die auf Überfahren reagieren. Auf Touchgeräten gibt es kein Überfahren; ein Untermenü, das nur so öffnet, ist unerreichbar.
- Formulare mit engen Feldern. Beim Fokussieren fährt die Bildschirmtastatur ein und verdeckt die Hälfte der Seite. Wichtige Elemente dürfen nicht unmittelbar unter dem Feld liegen.
- Bildschirmtastatur mit falschem Typ. Ein Telefonnummernfeld ohne passenden Eingabetyp zeigt die Buchstabentastatur.
Die Testmatrix
Responsives Testen scheitert selten am Willen und meist an der Systematik. Die Matrix unten deckt mit sechs Durchläufen die Fälle ab, in denen Seiten tatsächlich brechen:
| Prüfung | Werkzeug | Worauf achten |
|---|---|---|
| Breiten 360, 768, 1024, 1440, dazwischen ziehen | Gerätemodus der Entwicklerwerkzeuge | Umbrüche, Überläufe, Zwischenbreiten, für die niemand entworfen hat |
| Horizontaler Überlauf | Entwicklerwerkzeuge, Dokumentbreite prüfen | einzelnes zu breites Element finden (Tabelle, Bild, langes Wort) |
| Echtes Telefon, veröffentlichte Seite | das eigene Gerät, zusätzlich ein älteres | Klickflächen treffen, Formular ausfüllen, Menü öffnen und schließen, Ladezeit im Mobilfunknetz |
| Vergrößerte Systemschrift | Systemeinstellung am Telefon | Seiten mit festen Pixelwerten ignorieren die Einstellung |
| 200 Prozent Zoom am Rechner | Browser-Zoom | Barrierefreiheitskriterium: lesbar und erreichbar, nichts abgeschnitten |
| Querformat | Telefon drehen | bricht regelmäßig bei Elementen mit voller Bildschirmhöhe |
Der wichtigste Einzelpunkt darin: die Breite nicht nur auf die vier Standardwerte springen, sondern langsam ziehen. Layouts brechen in den Zwischenbreiten, und der Gerätesimulator zeigt Maße, aber nicht Touch-Verhalten, echte Netzgeschwindigkeit, Systemschriftgrößen und das Verhalten von Adressleiste und Bildschirmtastatur. Deshalb ersetzt kein Simulator den Durchlauf auf dem echten Gerät.
Wer die Matrix einmal pro Relaunch und danach nach jeder größeren Änderung durchgeht, findet praktisch alle responsiven Fehler, bevor es die Besucher tun.