Mobile Usability: die Defekte, die ein Desktop-Review nie sieht

Viewport, Tap-Targets, horizontales Scrollen und die Tastatur, die den Button verdeckt. Die Prüfungen, die entscheiden, ob ein Handy-Besucher ans Ziel kommt.

Mobil · Veröffentlicht: 4. September 2026 · 3 Min. Lesezeit · Дмитрий Орлов

Die meisten Teams sehen sich ihre Website auf dem Laptop an und deployen. Der meiste Traffic kommt vom Handy. In der Lücke zwischen diesen beiden Sätzen wohnt eine eigene Familie von Defekten: Keiner davon ist bei 1440 Pixel Breite sichtbar, und jeder kann einen Kauf beenden.

Fangen Sie beim Viewport an

Eine fehlende Zeile lässt ein Handy die Seite in Desktopbreite rendern und schrumpfen:

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

Zwei Varianten davon sind schlimmer als das Weglassen. maximum-scale=1 und user-scalable=no blockieren den Pinch-Zoom — ein harter Barrierefreiheitsfehler für alle mit eingeschränktem Sehvermögen, und Browser ignorieren sie ohnehin zunehmend. Kein Layout ist es wert, einem Leser das Zoomen zu nehmen.

Tap-Targets

Eine Fingerkuppe misst etwa neun Millimeter. Die Richtlinien einigen sich auf rund 44 × 44 CSS-Pixel als Minimum, plus ein paar Pixel Abstand. Darunter landen Berührungen neben dem Ziel, und der Besucher gibt der Website die Schuld, nicht seinem Daumen.

Es geht vorhersehbar schief: für Mobil verkleinerte Icon-Buttons, Links in einem dichten Footer, nicht klickbare Checkbox-Labels und eine für die Maus entworfene Paginierung. Suchen Sie nach einem kleinen Bedienelement neben einem anderen kleinen Bedienelement: Ein Fehlgriff auf einen einzelnen Button kostet einen Moment, einer in einer Reihe von fünf eine falsche Aktion.

Horizontales Scrollen

Ist ein Element breiter als der Viewport, rutscht die ganze Seite zur Seite und Text läuft über den Rand. Die üblichen Verdächtigen: eine Tabelle mit fester Breite, ein Bild ohne max-width: 100%, ein Codeblock oder ein Container mit einer aus dem Desktop-Design kopierten min-width.

Der Test ist eine Zeile in der Konsole:

document.documentElement.scrollWidth > window.innerWidth

Führen Sie ihn bei 360 Pixeln für jedes Template aus, nicht nur für die Startseite.

Das Tastaturproblem

Auf dem Handy verdeckt die Bildschirmtastatur das untere Drittel. Ein Absenden-Button, der am unteren Rand des Formulars klebt, landet darunter. Ebenso die Fehlermeldung, die erklärt, warum das Formular nicht abgeschickt wurde. Das ist der häufigste Grund, warum ein mobiles Formular "nichts tut": Die Rückmeldung existiert — außerhalb des Sichtfelds.

Prüfen Sie mit geöffneter Tastatur, nicht mit einem im Desktop-Emulator bloß fokussierten Feld.

Text und Eingabefelder

Schriftgrößen unter 16 Pixel in einem Eingabefeld lassen iOS beim Fokus zoomen, und das Layout erholt sich davon nicht mehr richtig. Fließtext unter 14 Pixel ist bei Tageslicht ein Lesbarkeitsproblem. Und jedes Feld verdient das richtige inputmode und autocomplete — ein Ziffernblock für die Telefonnummer ist eine Änderung an zwei Attributen, die die Abschlussquote messbar hebt.

Bei echten Breiten testen

Die Emulation in den DevTools erwischt das Layout; sie erwischt nicht die Tastatur, nicht die Browserleisten, die hundert Pixel fressen, und keinen Fehlgriff um zwei Millimeter. Gehen Sie die wichtigen Flows einmal pro Release auf einem echten Gerät durch — und automatisieren Sie den mechanischen Teil (Viewport-Meta, Zielgrößen, Overflow, Feldattribute) auf jeder Seite bei jedem Deploy.