ONMA Ratgeber

Responsive Website Design technisch umsetzen und abnehmen

Der Leitfaden zeigt Viewport-Setup, fluide Raster, responsive Bilder und Container Queries sowie Tests für Touch und 320-Pixel-Reflow.

30. August 2026

Frau vor einer Wand mit bunten Haftnotizen, davor sechs Personen mit Laptops an einem Besprechungstisch

Ein responsives Layout entsteht nicht dadurch, dass drei Gerätebreiten ordentlich aussehen, sondern dadurch, dass eine Seite jede Breite dazwischen aushält. Die Bausteine dafür beschrieb Ethan Marcotte am 25. Mai 2010 in seinem Artikel für A List Apart: ein fluides Raster, flexible Bilder und Media Queries. Dieser Leitfaden zeigt, in welcher Reihenfolge diese Bausteine heute gebaut werden, mit welchem CSS, und woran die Abnahme am Ende scheitert oder gelingt.

Die Umsetzung folgt einer festen Reihenfolge, weil jeder Schritt den nächsten trägt: Viewport und Basis-CSS, Breakpoints aus dem Inhalt, fluides Raster, flüssige Typografie, Bildquellen, Touch-Ziele, Navigation, breite Inhalte wie Tabellen, Komponenten mit Container Queries, danach Fehlersuche und Abnahme.

Viewport und Basis-CSS setzen

Der erste technische Schritt gehört in den <head> jeder Seite:

<meta name="viewport" content="width=device-width, initial-scale=1">

Fehlt dieses Meta-Tag, rendern mobile Browser die Seite in einem virtuellen Viewport von rund 980 CSS-Pixeln und skalieren sie anschließend herunter. Media Queries sehen dann nicht die tatsächliche Displaybreite, sondern diesen erfundenen Wert. Jede weitere Arbeit am Layout läuft ins Leere, solange dieser Fehler besteht.

maximum-scale=1 und user-scalable=no gehören nicht in dieses Tag. Beides kann das manuelle Vergrößern unterbinden und nimmt Nutzern eine Bedienhilfe, auf die sie angewiesen sein können.

Darunter liegt ein knappes Fundament, das drei der häufigsten Überlaufursachen ausschaltet:

*,
*::before,
*::after {
  box-sizing: border-box;
}

html {
  overflow-wrap: break-word;
}

img,
svg,
video {
  display: block;
  max-width: 100%;
  height: auto;
}

border-box verhindert, dass Innenabstände Elemente über ihre gesetzte Breite hinaus verbreitern. overflow-wrap erlaubt langen URLs, Dateinamen und Produktcodes den Umbruch. Die Medienregel bindet Bilder und Videos an die Breite ihres Containers.

Breakpoints aus dem Inhalt ableiten

Breakpoints nach Gerätenamen zu benennen ist der teuerste Fehler in diesem Prozess, weil Gerätelisten veralten und ein Layout danach an Breiten bricht, für die niemand eine Regel geschrieben hat. Der belastbare Weg ist umgekehrt: schmalste sinnvolle Darstellung aufbauen, Viewport langsam verbreitern, und genau dort einen Breakpoint setzen, wo der Inhalt sichtbar leidet.

Typische Auslöser sind:

Navigationspunkte, die umbrechen oder ineinanderlaufen
Kartenreihen, deren einzelne Karte so breit wird, dass ihr Inhalt verloren wirkt
Textzeilen jenseits einer bequem lesbaren Länge
Formularfelder, die sich von ihren Beschriftungen lösen
Seitenleisten, die den Hauptinhalt zu stark einengen

Die Media Query kommt dann an genau diese Stelle, nicht an eine gerundete Wunschzahl:

.page {
  display: grid;
  gap: 1.5rem;
}

@media (min-width: 48rem) {
  .page {
    grid-template-columns: minmax(0, 1fr) 18rem;
  }
}

Media Queries sind seit der W3C Recommendation zu CSS Media Queries Level 3 vom 19. Juni 2012 die formale Grundlage breitenabhängiger Layouts. Sie sind trotzdem das grobe Werkzeug: Sie sollten nur echte Strukturwechsel schalten, also die Anzahl der Spalten oder die Anordnung von Bereichen. Größen, Abstände und Schriftgrade brauchen sie meistens nicht. Einheiten in rem machen die Umbruchpunkte außerdem unabhängiger von einer veränderten Browser-Schriftgröße, und Klassennamen wie with-sidebar beschreiben die Layoutfunktion statt eines vermeintlichen Zielgeräts.

Fluide Raster mit Grid und Flexbox bauen

CSS Grid ordnet Flächen in Zeilen und Spalten, Flexbox verteilt Elemente entlang einer Achse. Ein Kartenraster organisiert sich damit ganz ohne Breakpoint:

.card-grid {
  display: grid;
  grid-template-columns:
    repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
  gap: clamp(1rem, 2vw, 2rem);
}

auto-fit erzeugt so viele Spalten, wie in den verfügbaren Raum passen. minmax() sichert eine Mindestbreite und lässt die Spalten den Rest der Zeile füllen. Das min(100%, 16rem) ist der entscheidende Zusatz: Es senkt die Mindestbreite auf sehr schmalen Viewports, damit die 16rem dort keinen horizontalen Überlauf erzwingen.

Bedienleisten kommen mit Flexbox aus:

.actions {
  display: flex;
  flex-wrap: wrap;
  gap: 0.75rem;
}

.actions > * {
  flex: 1 1 10rem;
}

Ein Detail entscheidet über viele unerklärliche Überläufe: Grid- und Flex-Kinder haben eine automatische Mindestgröße, die sich am Inhalt orientiert. Eine lange Tabelle oder ein Codeblock drückt die Spalte dadurch auf, statt zu scrollen.

.main-content,
.sidebar {
  min-width: 0;
}

Feste Breiten bleiben die Ausnahme. Für Inhaltsbereiche ist die Kombination aus maximaler Zeilenlänge und flexiblem Seitenabstand robuster:

.content {
  width: min(100% - 2rem, 70rem);
  margin-inline: auto;
}

Schrift und Abstände flüssig skalieren

clamp() nimmt Minimum, bevorzugten Wert und Maximum entgegen und ersetzt damit ganze Ketten von Media Queries:

h1 {
  font-size: clamp(2rem, 1.3rem + 3vw, 4.5rem);
  line-height: 1.05;
}

.section {
  padding-block: clamp(2rem, 6vw, 6rem);
}

Der bevorzugte Wert sollte immer einen rem-Anteil enthalten, wie oben das 1.3rem. Eine reine vw-Formel skaliert nicht mit dem Browserzoom mit und kann Text bei 200 Prozent Vergrößerung unverändert klein lassen. Prüfen Sie außerdem die Zwischenbreiten: Eine mathematisch saubere Kurve ist wertlos, wenn die Überschrift bei 700 Pixeln in das Bild darunter läuft.

Responsive Bilder mit srcset, sizes und picture

max-width: 100% sorgt nur dafür, dass ein Bild nicht überläuft. Welche Datei geladen wird, entscheiden srcset und sizes, beide Teil des HTML Living Standard:

<img
  src="motiv-800.jpg"
  srcset="
    motiv-480.jpg 480w,
    motiv-800.jpg 800w,
    motiv-1280.jpg 1280w
  "
  sizes="
    (min-width: 64rem) 50vw,
    (min-width: 40rem) 75vw,
    100vw
  "
  width="1280"
  height="720"
  alt="Beschreibung des sichtbaren Motivs"
>

sizes beschreibt nicht die Bilddatei, sondern den Platz, den das Bild im fertigen Layout voraussichtlich einnimmt. Diese Angabe muss deshalb bei jeder Layoutänderung mitgepflegt werden, sonst wählt der Browser dauerhaft die falsche Größe. width und height halten das Seitenverhältnis fest, damit der Platz schon vor dem Laden korrekt reserviert ist.

Wenn ein schmaler Viewport einen anderen Bildausschnitt braucht, übernimmt <picture>:

<picture>
  <source
    media="(max-width: 39.99rem)"
    srcset="motiv-hochformat.jpg"
  >
  <img
    src="motiv-querformat.jpg"
    width="1280"
    height="720"
    alt="Beschreibung des sichtbaren Motivs"
  >
</picture>

Dieser Austausch ist eine redaktionelle Entscheidung, keine technische: Der schmale Ausschnitt muss dieselbe Aussage tragen und darf das Bildmotiv nicht anschneiden.

Touch-Ziele und Bedienbarkeit

Ohne präzisen Mauszeiger entscheidet die Größe der Trefferfläche. Das WCAG-2.1-Kriterium 2.5.5 nennt auf Konformitätsstufe AAA 44 mal 44 CSS-Pixel als Mindestgröße für Bedienelemente. Als Prüfmaßstab für Schaltflächen, Menüsteuerungen und einzeln stehende Links ist dieser Wert auch dann brauchbar, wenn AAA nicht das Projektziel ist.

Das sichtbare Symbol darf kleiner bleiben, die Fläche darum nicht:

.icon-button {
  display: inline-grid;
  width: 2.75rem;
  min-height: 2.75rem;
  place-items: center;
}

Dazu kommt genügend Abstand zwischen benachbarten Zielen. Und keine Funktion darf allein über hover erreichbar sein: Untermenüs, Tooltips und Bildaktionen brauchen einen Zustand, der per Tippen und per Tastatur ausgelöst wird, mit sichtbarem Fokus.

Eine Desktop-Navigation wird auf schmalen Viewports nicht verkleinert, sondern in einen anderen Zustand überführt. Die Abnahme dieses Umbaus prüft sechs Punkte:

Der Menüschalter ist ein echtes <button>, kein div mit Klick-Handler.
aria-expanded gibt den offenen oder geschlossenen Zustand wieder.
aria-controls verweist auf das gesteuerte Navigationselement.
Die Fokusreihenfolge ist nachvollziehbar und die Fokusmarkierung sichtbar.
Die Escape-Taste schließt das geöffnete Menü.
Vergrößerter Text schneidet keine Einträge ab.

Das Layout selbst bleibt eine CSS-Aufgabe. JavaScript steuert nur den Zustand und die Tastaturbedienung.

Datentabellen sind die zweite große Ursache für horizontales Scrollen. Welche Lösung passt, hängt von den Daten ab: Schlüssel-Wert-Zeilen lassen sich als Karten stapeln, große Vergleichstabellen bleiben besser in einem gekennzeichneten Scrollbereich, und Spalten dürfen nur entfallen, wenn dabei keine Information verloren geht. Bei jedem strukturellen Umbau muss die Zuordnung von Spaltenüberschrift zu Zelle erhalten bleiben.

.table-scroll {
  max-width: 100%;
  overflow-x: auto;
  overscroll-behavior-inline: contain;
}

Der Scrollbereich braucht Tastaturzugang und einen sichtbaren Hinweis darauf, dass es rechts weitergeht. Ein pauschales overflow-x: hidden auf body ist keine Lösung, sondern schneidet den Inhalt ab und versteckt den eigentlichen Fehler.

Komponenten mit Container Queries anpassen

Media Queries kennen nur den Viewport. Eine wiederverwendbare Karte weiß dadurch nicht, ob sie im breiten Hauptbereich oder in einer schmalen Seitenleiste steht. Container Queries lösen genau das:

.card-wrapper {
  container-type: inline-size;
}

.card {
  display: grid;
  gap: 1rem;
}

@container (min-width: 32rem) {
  .card {
    grid-template-columns: 10rem 1fr;
    align-items: start;
  }
}

@container ist seit Chrome 105 (August 2022), Safari 16 (September 2022) und Firefox 110 (Februar 2023) in den großen Browser-Engines verfügbar. Die einspaltige Grunddarstellung außerhalb der Query muss trotzdem für sich allein vollständig nutzbar bleiben.

Überlauf gezielt finden

Wenn bei 320 Pixeln ein waagerechter Scrollbalken auftaucht, ist Raten die langsamste Methode. In der Konsole der Entwicklerwerkzeuge benennt eine Abfrage die Verursacher direkt:

document.querySelectorAll('*').forEach((el) => {
  if (el.getBoundingClientRect().right > document.documentElement.clientWidth) {
    console.log(el);
  }
});

In der Regel landen dabei immer dieselben Kandidaten: ein Element mit fester Pixelbreite, ein Grid- oder Flex-Kind ohne min-width: 0, ein negativer Außenabstand, eine unumbrechbare Zeichenkette oder ein eingebettetes iframe ohne max-width.

Testen und abnehmen

Chrome DevTools, der Firefox Responsive Design Mode und der Safari Web Inspector simulieren Viewport-Breite, Pixeldichte und Touch-Eingabe. Ziehen Sie die Breite dabei stufenlos durch den gesamten Bereich, statt nur die voreingestellten Geräte anzuklicken: Die meisten Fehler sitzen zwischen den Presets. Diese Emulation ersetzt keinen Test auf echter Hardware, weil Browseroberflächen, Bildschirmtastaturen, Zoomverhalten und Gesten dort abweichen. Mindestens ein iOS- und ein Android-Gerät gehören in jede Abnahme.

Den harten Prüfpunkt liefert das WCAG-2.1-Erfolgskriterium 1.4.10 (Reflow): Inhalte müssen bei einer Breite von 320 CSS-Pixeln ohne zweidimensionales Scrollen darstellbar bleiben. Ausgenommen sind nur Inhalte, deren Bedeutung eine zweidimensionale Anordnung erfordert, etwa bestimmte Datentabellen und Karten. Da für die Indexierung seit Oktober 2023 durchgängig die mobile Fassung einer Seite zählt, darf dieser schmale Zustand auch inhaltlich keine Kürzung sein.

Abnahmefähig ist die Seite, wenn alle folgenden Punkte erfüllt sind:

Bei 320 CSS-Pixeln entsteht auf Seitenebene kein horizontaler Scrollbalken.
Auch bei 375, 768, 1024 und 1440 Pixeln sowie an allen Zwischenbreiten bleibt das Layout intakt.
Hoch- und Querformat wurden beide geprüft.
Bei 200 Prozent Browserzoom bleibt der Text lesbar und vollständig sichtbar.
Künstlich verlängerte Texte und sehr lange Wörter brechen das Layout nicht.
Die Lesereihenfolge bleibt nach jedem Layoutwechsel logisch.
Alle Funktionen sind per Touch und per Tastatur erreichbar, Fokusmarkierungen werden nicht von fixierten Elementen verdeckt.
Navigation, Dialoge und Aufklappbereiche melden ihren Zustand korrekt.
Bilder bleiben im Container, behalten ihr Seitenverhältnis und zeigen im schmalen Zustand den inhaltlich richtigen Ausschnitt.
Tabellen, Videos und Codeblöcke haben eine erkennbare Lösung für schmale Bereiche.
Komponenten wurden im Hauptinhalt und in einem schmalen Container getestet.
Formulare funktionieren mit Bildschirmtastatur und sichtbaren Fehlermeldungen.
Reale Geräte bestätigen das Ergebnis der Emulation.

Ein responsives Layout ist damit nicht fertig, wenn drei Bildschirmgrößen gut aussehen. Es ist fertig, wenn die freien Zwischenbreiten, extreme Inhalte, Zoom, Touch, Tastatur und der 320-Pixel-Reflow es nicht mehr aus der Fassung bringen.