5 Mobile-Web-Stolpersteine (und wie man sie behebt)

Sie haben Ihr Layout an jedem Breakpoint getestet, Ihr responsives Grid sieht sauber aus und alles funktioniert einwandfrei in den Chrome DevTools. Dann öffnen Sie die Website auf einem echten Smartphone und irgendetwas ist leicht, aber hartnäckig falsch. Das sind Mobile-Web-Stolpersteine – kleine Bugs, die die Seite nicht kaputtmachen, aber die User Experience unmerklich verschlechtern.

Hier sind fünf Probleme, die in realen Projekten immer wieder auftauchen, und die modernen Lösungen dafür.

1. Full-Height-Layouts brechen wegen 100vh

Symptom: Ein Fullscreen-Hero oder Modal ist auf iOS Safari etwas zu hoch, wodurch Inhalte abgeschnitten werden oder eine Scrollbar erscheint.

Warum es passiert: 100vh wird gegen die volle Viewport-Höhe berechnet und ignoriert die dynamische UI-Chrome des Browsers (Adressleiste und Navigationssteuerelemente). Wenn diese Elemente sichtbar sind, läuft 100vh über.

Die Lösung: Verwenden Sie die neueren CSS-Viewport-Einheiten. Für die meisten Full-Height-Layouts ist 100svh (Small Viewport Height) eine stabile Wahl, da es den sichtbaren Bereich mit vorhandener Browser-UI darstellt. Verwenden Sie 100dvh, wenn sich das Layout dynamisch anpassen soll, während die Browser-Chrome ein- und ausgeblendet wird. Die moderne Browser-Unterstützung für diese Einheiten ist weitreichend verfügbar, wie auf https://webstatus.dev/features/viewport-unit-variants zu sehen ist.

.hero {
  height: 100svh; /* stable default */
}

2. Bottom-Fixed-UI wird hinter Device Safe Areas versteckt

Symptom: Ein Sticky-Footer, eine untere Navigationsleiste oder ein Action-Button wird teilweise vom Home-Indikator auf dem iPhone oder durch andere Device Safe Areas verdeckt.

Warum es passiert: Fixed-Elemente, die bei bottom: 0 positioniert sind, sitzen bündig am Rand des Viewports, nicht am Safe Area des Geräts. Auf Geräten mit Home-Indikatoren oder abgerundeten Ecken kann die System-UI das Element überlagern.

Die Lösung: Fügen Sie viewport-fit=cover zu Ihrem Meta-Viewport-Tag hinzu und verwenden Sie dann CSS-Safe-Area-Umgebungsvariablen wie env(safe-area-inset-bottom), um das Element nach oben zu verschieben.

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

.bottom-nav {
  padding-bottom: env(safe-area-inset-bottom);
}

3. iOS zoomt in Formular-Inputs hinein

Symptom: Das Antippen eines <input> auf iOS Safari führt dazu, dass die Seite unerwartet hineinzoomt und das Layout stört.

Warum es passiert: iOS Safari zoomt automatisch, wenn die Schriftgröße eines Inputs kleiner als 16px ist, und behandelt dies als Lesbarkeits-Hilfe.

Die Lösung: Setzen Sie font-size: 16px (oder größer) für alle Inputs. Deaktivieren Sie den Zoom nicht über user-scalable=no – das schadet der Barrierefreiheit. Verwenden Sie dabei auch inputmode, um die richtige Tastatur anzufordern, autocomplete, um Reibung zu reduzieren, und enterkeyhint, um die Return-Taste zu beschriften.

<input
  type="email"
  inputmode="email"
  autocomplete="email"
  enterkeyhint="done"
  style="font-size: 16px;"
/>

4. Scroll läuft aus Modals und Drawers heraus

Symptom: Wenn ein Benutzer innerhalb eines Modals oder Bottom Sheets scrollt und das Ende erreicht, beginnt die Seite dahinter ebenfalls zu scrollen.

Warum es passiert: Das ist Scroll Chaining – der Browser propagiert Scroll-Events zum Parent, wenn der Child-Scroll-Container seine Grenze erreicht.

Die Lösung: Wenden Sie overscroll-behavior: contain auf den scrollbaren Container an. Die moderne Browser-Unterstützung ist breit gefächert, einschließlich Safari 16 und später, wie auf https://webstatus.dev/features/overscroll-behavior zu sehen ist.

.modal-body {
  overflow-y: auto;
  overscroll-behavior: contain;
}

5. Tap-Targets fühlen sich träge an oder triggern das falsche Element

Symptom: Buttons fühlen sich träge an oder Taps werden auf dem falschen Element registriert – besonders in dichter UI wie Navigationsmenüs oder Listen.

Warum es passiert: Touch-Targets, die zu klein sind, erzeugen Hit-Testing-Mehrdeutigkeit. Moderne Browser handhaben Tap-Events ohne die historische 300ms-Verzögerung (solange Ihr Viewport-Meta-Tag korrekt ist), aber zu kleine Targets führen dennoch zu verfehlten oder falsch geleiteten Taps.

Die Lösung: Streben Sie Touch-Targets gemäß der WCAG-Target-Size-Empfehlung von etwa 44×44 CSS-Pixeln an. Verwenden Sie Padding statt Margin, um die Hit-Area zu vergrößern, ohne das Layout zu beeinflussen.

.nav-link {
  min-height: 44px;
  min-width: 44px;
  display: flex;
  align-items: center;
  padding: 0 12px;
}

Fazit

Diese Mobile-Web-Stolpersteine treten selten isoliert auf – ein Layout, das abgeschnitten wird, ein Button, der sich versteckt, ein Formular, das zoomt. Jeder einzelne ist für sich genommen geringfügig, aber zusammen signalisieren sie eine Website, die nicht wirklich auf einem Gerät getestet wurde. Modernes CSS gibt Ihnen saubere, standardbasierte Werkzeuge, um all diese Probleme zu beheben. Wenden Sie diese Fixes einmal an und sie werden Bestand haben, während sich Browser weiterentwickeln.

FAQs

Truly understand users experience

See every user interaction, feel every frustration and track all hesitations with OpenReplay — the open-source digital experience platform. It can be self-hosted in minutes, giving you complete control over your customer data. . Check our GitHub repo and join the thousands of developers in our community..