All 20 checks with why-it-matters prose, severity, and cross-references to related audits.
Without a viewport meta tag, mobile browsers render the page at a hardcoded desktop width of roughly 980px and scale it down to fit the screen. Text becomes unreadably small, tap targets shrink below usable size, and pinch-zoom becomes the only way to interact. Search engines treat this as a mobile-unfriendly signal, demoting rankings under Google's mobile-first indexing. More than half of global traffic is mobile — a missing viewport tag breaks the primary user experience and kills SEO.
Why this severity: Critical because a single missing line breaks the mobile experience for every visitor and tanks mobile search rankings.
mobile-responsiveness.viewport.viewport-metaSee full patternA wrapper element with `width: 1200px` and no `max-width` forces the document to be wider than any phone viewport. The browser shows a horizontal scrollbar, content spills off-screen, and users must swipe sideways to read anything. Buttons and forms placed on the right edge become unreachable without scrolling. This is one of the most common causes of a failed mobile render — and it persists even when the viewport meta tag is correctly configured.
Why this severity: Critical because even one uncontrolled fixed-width container causes horizontal overflow that breaks every page it appears on.
mobile-responsiveness.viewport.no-fixed-widthSee full patternA project with no responsive CSS primitives — no Tailwind config, no media queries, no Flexbox or Grid — is shipping a fixed-layout site. Every viewport outside the single width the developer tested will render with broken spacing, cut-off content, or awkward whitespace. Retrofitting responsiveness after the fact is significantly more expensive than adopting a responsive system from the start, because every component needs to be re-evaluated.
Why this severity: Medium because static layouts are recoverable but require rework across every component touched.
mobile-responsiveness.viewport.responsive-frameworkSee full patterniOS Safari auto-zooms the entire page whenever a form input with a font-size below 16px receives focus. That zoom disrupts the layout, forces users to manually zoom back out, and abandons the tap position — effectively breaking the form submission flow on iPhone for a significant share of mobile users. WCAG 2.2 SC 1.4.4 (Resize Text) requires text to be resizable without loss of content or functionality; a base font below 16px often means inputs are already too small to use comfortably before any zoom occurs. Smaller base fonts also reduce legibility on high-DPI screens where antialiasing assumptions change below the 16px threshold.
Why this severity: Medium because the failure degrades the form experience on iOS Safari specifically, causing involuntary page zoom rather than full inaccessibility.
mobile-responsiveness.viewport.text-readable-mobileSee full patternUnintended horizontal scroll breaks the fundamental contract of a mobile layout: that the viewport shows the full page width. Users on touch devices cannot easily discover off-screen content and may not realise navigation controls or call-to-action buttons are hidden to the right. WCAG 2.2 SC 1.4.10 (Reflow) requires content to reflow at 320px viewport width without horizontal scrolling; violating it is a WCAG AA failure that also creates a Section 508 Refresh 502.3.3 barrier for assistive technology users. Applying `overflow-x: hidden` to `<body>` hides the symptom but leaves the broken layout in place, meaning the content is silently truncated rather than accessible.
Why this severity: Critical because horizontal scroll at mobile widths silently hides content and controls — including navigation and CTAs — and constitutes a WCAG 2.2 SC 1.4.10 (Reflow) AA failure.
mobile-responsiveness.layout.no-horizontal-scrollSee full patternAn `<img>` tag with `width="1200"` and no `max-width: 100%` renders at 1200 physical pixels even on a 375px-wide phone, forcing horizontal scroll and cutting off surrounding content. This breaks layout for every page containing the image and undermines the viewport meta configuration that would otherwise keep the page mobile-friendly. Images are one of the most common causes of accidental overflow because `<img>` defaults do not include any responsive constraint.
Why this severity: High because image overflow is visible on every page the image appears on and degrades every mobile visitor's experience.
mobile-responsiveness.layout.responsive-images-mobileSee full patternHTML tables have no built-in responsiveness. At mobile widths, a data table with more than four or five columns will overflow the viewport — either forcing horizontal scroll on the entire page (a WCAG 2.2 SC 1.4.10 Reflow violation) or getting clipped silently. Users lose access to the rightmost columns, which often contain the most actionable data: status, actions, amounts. Scrollable table wrappers preserve all data while keeping the page layout intact. Reformatted stacked layouts are a stronger solution for complex tables but require deliberate CSS work.
Why this severity: Medium because wide tables cause horizontal scroll or data truncation on mobile, but only when tables are present — the impact is conditional on content width.
mobile-responsiveness.layout.responsive-tablesSee full patternA form with `width: 400px` inputs renders fine on desktop but overflows phones below 420px wide, forcing horizontal scroll on every keystroke. Two-column form layouts that don't collapse to one column on mobile cram fields into half the screen width and make typing error-prone. Forms are the primary conversion surface — sign-ups, checkout, contact — and a form that is hard to complete on mobile directly reduces business outcomes.
Why this severity: High because form friction maps directly to conversion loss on the highest-value pages.
mobile-responsiveness.layout.responsive-formsSee full patternBreakpoints are the contract between your layout and the device. With only a desktop layout, a phone at 375px renders the desktop grid crammed into a third of the intended width; with only a mobile layout, a desktop user sees a stacked single-column site wasting screen real estate. Covering at least the phone and tablet ranges gives you three distinct layouts — mobile base, tablet, desktop — which matches how real traffic is distributed.
Why this severity: Medium because missing breakpoints degrade layout on whichever viewport class was skipped, but the site remains functional.
mobile-responsiveness.layout.breakpoint-coverageSee full patternA flex container with six nav items and the default `flex-wrap: nowrap` will push items off-screen on a 320px phone, or shrink them until labels overlap. Card grids that refuse to wrap force horizontal scroll within the grid itself, hiding half the cards. `nowrap` is the default — every flex container holding three or more items needs an explicit decision about what happens at narrow widths, and the default is almost always wrong.
Why this severity: Low because most sites layer `flex-wrap` on critical layouts, so this tends to affect secondary surfaces like nav bars.
mobile-responsiveness.layout.flex-wrapSee full patternA hero section with `height: 100vh` becomes roughly 350px tall when the user rotates their phone to landscape. Headline, subhead, and CTA button get crammed into that tiny vertical window — often only the headline remains visible, with the CTA below the fold. `100vh` also misbehaves on iOS Safari because mobile browser chrome shrinks and grows dynamically. `100dvh` (dynamic viewport height) is the modern replacement that handles both cases correctly.
Why this severity: Info because landscape use on phones is a minority of sessions, but the fix is cheap and worth doing.
mobile-responsiveness.layout.landscape-supportSee full patternTouch targets that are too small cause mis-taps, especially for users with larger fingers, motor impairments, or when holding a phone one-handed in motion. A 16px icon button with no padding gives an actual tap area of roughly 256 px² — 25% of the 1936 px² that WCAG 2.2 SC 2.5.8 (Target Size, Minimum) requires at 44×44px. Repeated mis-taps on close buttons, icon actions, or navigation links create genuine usability failures that drive abandonment. WCAG 2.2 SC 2.5.5 (Target Size, Enhanced, AAA) sets 44×44px; SC 2.5.8 (AA) requires 24×24px minimum with spacing — either way, 16px icons without padding fail both levels.
Why this severity: High because undersized touch targets directly cause interaction failures and mis-taps on mobile, with WCAG 2.2 SC 2.5.8 AA compliance at stake.
mobile-responsiveness.touch.touch-target-sizeSee full patternCSS `:hover` does not fire reliably on touch devices — there is no cursor, so hover states either never trigger or trigger on first tap and then persist, breaking the interaction model. Dropdown menus that only open on hover are completely inaccessible on touch screens. Tooltips that only appear on hover convey information that touch and keyboard users never receive — a WCAG 2.2 SC 2.1.1 (Keyboard) and SC 1.4.13 (Content on Hover or Focus) violation. The practical business impact is that users on iPhone or Android simply cannot reach menu items, card actions, or contextual controls gated behind hover states.
Why this severity: High because hover-only functionality is completely unreachable on touch devices, locking out the majority of mobile users from affected features.
mobile-responsiveness.touch.no-hover-onlySee full patternAn email field with `type="text"` gives mobile users the default alphabetic keyboard with no `@` key and no autocomplete hint to the browser. Phone fields with `type="text"` force the user to hunt for numeric keys on a letter keyboard. Beyond typing friction, the wrong input type blocks browser-native validation, autofill, and password manager integrations. Correct input types are a two-character change that materially improves mobile form completion rates.
Why this severity: Medium because wrong input types add friction to every form submission on mobile, reducing conversion across sign-up and checkout.
mobile-responsiveness.touch.input-typesSee full patternLegacy mobile browsers inserted a 300ms delay on tap events to distinguish between a single tap and a double-tap-to-zoom gesture. That delay makes buttons feel sluggish and unresponsive compared to native apps. Modern browsers eliminate the delay when a correct viewport meta tag is present, but older WebViews and some embedded browsers still apply it. `touch-action: manipulation` disables the double-tap-zoom gesture on interactive elements, removing the delay explicitly.
Why this severity: Low because the primary mitigation (viewport meta tag) is already required by another check, and modern browsers no longer impose the delay.
mobile-responsiveness.touch.tap-delaySee full patternA horizontal navigation bar with seven items needs roughly 700-900px of horizontal space. On a 375px phone, those items either overflow the viewport, shrink until labels overlap, or get truncated with ellipses. Navigation is the spine of a site — if users can't reach secondary pages, they bounce. A hamburger menu or bottom nav bar is the standard mobile pattern; both require a toggle state and a responsive breakpoint that swaps layouts.
Why this severity: High because broken navigation blocks access to every page beyond the current one, collapsing site depth on mobile.
mobile-responsiveness.mobile-ux.mobile-navigationSee full patternA 64px fixed header with no corresponding top padding on `<main>` hides the first 64 pixels of every page — headlines cut off, form labels disappear, the top of a modal sits beneath the header. A fixed cookie banner or chat widget at the bottom does the same thing in reverse, covering the footer and any sticky CTA. The fix is trivial but easy to overlook because the bug is invisible on desktop where scroll position forgives the overlap.
Why this severity: Medium because the obscured content is reachable via scroll once users figure out the offset, but CTA buttons and form submits near edges may be tapped through the overlay.
mobile-responsiveness.mobile-ux.no-fixed-elements-overlapSee full patternBody text set below 16px forces mobile users to pinch-to-zoom to read paragraph content — a friction that most users will not perform, choosing instead to abandon the page. WCAG 2.2 SC 1.4.10 (Reflow) requires content to present without loss of information at 320px viewport width, and SC 1.4.4 (Resize Text) requires text to scale to 200% without loss of content. Text rendered inside `<img>` elements cannot reflow at all and pixelates when zoomed. Overly wide line lengths (beyond ~75ch) cause the opposite problem on tablets: long horizontal eye travel that increases reading error rates and fatigue.
Why this severity: Low because pinch-to-zoom remains available as a workaround, meaning content is technically accessible despite the degraded reading experience.
mobile-responsiveness.mobile-ux.readable-without-zoomSee full patternA modal with `width: 600px` on a 375px phone renders with its right edge off-screen, clipping the close button and any right-aligned action buttons. If the close mechanism is off-screen, the user has no way to dismiss the modal except reloading. Modals also commonly lack `overflow-y: auto`, so long content gets clipped at the bottom of the viewport with no scroll to reach the submit button. Both failure modes trap users.
Why this severity: Low because modals are a minority of screens, but a user trapped in a broken modal has no recovery path short of reloading.
mobile-responsiveness.mobile-ux.mobile-modalsSee full patternWithout a print stylesheet, printing an invoice, receipt, blog post, or documentation page produces output with the full site chrome: navigation, hamburger menus, footers, chat widgets, and hover-state buttons — all wasting ink and pushing the content onto extra pages. Users expecting to save a clean PDF or print a receipt get a page of noise. This is low-severity because most web apps don't ship printable surfaces, but every content-heavy site (docs, blogs, transactional receipts) benefits.
Why this severity: Info because printing is rare but broken print output makes users feel the site is unpolished where it matters.
mobile-responsiveness.mobile-ux.print-stylesheetSee full patternRun this audit in your AI coding tool (Claude Code, Cursor, Bolt, etc.) and submit results here for scoring and benchmarks.
Open Mobile Responsiveness Audit