# AuditBuffet: Mobile Responsiveness Audit **Audit Slug:** `mobile-responsiveness` **Version:** `1.0.0` **Prompt Hash:** `sha256:e71f4c682f147666187083d06c239cf5` ## What This Audit Does This audit evaluates your project's mobile responsiveness — how well it works on phones, tablets, and different screen sizes. It covers the essential patterns that AI-built projects commonly miss: viewport configuration, responsive layouts, touch-friendly interface sizing, and common mobile UX problems. This audit focuses on structural and configuration-level responsiveness issues. It does not include full visual testing across all device sizes (that requires browser-based testing) or detailed mobile performance optimization — those are covered in the Performance & Load Readiness Audit. This audit covers viewport and configuration, layout and scaling, touch and interaction, and mobile UX fundamentals. It does not cover mobile performance (payload size, image optimization, Core Web Vitals) — those are addressed in the Performance & Load Readiness Audit. Touch target sizing in the context of accessibility is also covered in the Accessibility Fundamentals Audit. ## About AuditBuffet AuditBuffet is a library of adversarially-tested audit prompts for AI-built projects. This audit analyzes your codebase and produces: 1. A structured JSON telemetry block (for benchmark comparisons at auditbuffet.com) 2. A human-readable report with actionable findings and remediation guidance The telemetry contains no source code, file contents, environment variables, API keys, URLs, or PII — only structural patterns and scores. --- ## Before We Begin **Project ID:** If you have a `project_id` from a previous AuditBuffet snapshot or audit, paste it here: ___ If you don't have one, I'll generate a new one for you. **Build Tool:** What AI coding tool are you using? (e.g., cursor, claude-code, bolt, lovable, v0, windsurf, copilot, aider, manual) If you haven't run the AuditBuffet Project Snapshot yet, consider running it first to set up your project profile — but it's not required. This audit is self-contained. --- ## Stack Detection Before running checks, detect the project's technology stack by examining these signals: 1. **Framework:** Check `package.json` dependencies for next, react, vue, nuxt, svelte, sveltekit, astro, remix, angular, gatsby, express, fastify, hono, etc. Check for framework config files (next.config.*, nuxt.config.*, svelte.config.*, astro.config.*, vite.config.*, etc.). 2. **Framework Version:** Read from `package.json` dependencies or lock file. 3. **Language:** Check for `tsconfig.json` (TypeScript) or absence thereof (JavaScript). Check file extensions (.ts, .tsx, .js, .jsx, .py, .go, .rs, etc.). 4. **Database:** Look for database connection patterns in config files, ORM config files (prisma/schema.prisma, drizzle.config.*, etc.), database-related dependencies (pg, mysql2, mongodb, @supabase/supabase-js, firebase, etc.). 5. **ORM:** Check for prisma, drizzle, typeorm, sequelize, mongoose, knex, kysely in dependencies. 6. **Auth:** Look for next-auth/authjs, clerk, lucia, supabase auth, firebase auth, auth0, kinde, better-auth in dependencies or config. 7. **Hosting:** Check for vercel.json, netlify.toml, fly.toml, railway.json, render.yaml, Dockerfile, .github/workflows with deployment targets, wrangler.toml (Cloudflare). 8. **UI Library:** Check for shadcn-ui (components.json), radix-ui, chakra-ui, mantine, material-ui, ant-design, headless-ui in dependencies. Check for tailwindcss, css-modules, styled-components, emotion in config/dependencies. 9. **Project Type:** Infer from structure — web-app (has both pages and API routes), api (primarily API routes/serverless), static-site (no server components or API routes), library (has build/publish config), cli (has bin field in package.json). 10. **Project Size:** Count routes/pages — small (<20), medium (20-100), large (100+). For each field, record what you detected. Use `null` for anything you cannot determine. Never guess — if the signal isn't clear, use `null`. --- ## How to Analyze **Next.js Route Group Shadowing:** When the detected framework is Next.js and route groups are used (e.g., `(marketing)/page.tsx`), check whether a plain `app/page.tsx` also exists at the same route level. If both exist, `app/page.tsx` takes precedence and the route group page is effectively shadowed. This commonly occurs when the create-next-app boilerplate `page.tsx` is not deleted after adding route groups. Treat the shadowing page as the actual served page for all checks targeting the `/` route. Examine the following in order: 1. `` section of root layout or HTML template — viewport meta tag configuration 2. Global CSS files and Tailwind config — base font size, responsive breakpoints, overflow rules 3. Layout components — check for fixed-width containers with pixel values exceeding 640 4. Image components — max-width, responsive sizing, width/height attributes 5. Navigation component — mobile menu implementation (hamburger, bottom nav, or equivalent pattern) 6. Form components — input sizing, label placement, touch target sizing 7. Modal and dialog components — viewport constraints, overflow handling on small screens 8. CSS media queries across the codebase — breakpoint coverage for phone (<=640px) and tablet (<=1024px) 9. Interactive elements — hover-only states, touch target dimensions, event handler types 10. Flex and Grid layouts — wrap behavior on narrow viewports, overflow direction --- ## Check Definitions ### Category: Viewport & Config **Slug:** `viewport` **Weight in overall score:** 0.25 #### Check: Viewport meta tag is present and correctly configured - **ID:** `mobile-responsiveness.viewport.viewport-meta` - **Severity:** `critical` - **What to look for:** Check the root layout or HTML template for a `` tag. Verify the content attribute includes `width=device-width` and `initial-scale=1`. Watch for `user-scalable=no` or `maximum-scale=1` which prevent user zooming (this is a separate accessibility concern but should be noted). - **Pass criteria:** A viewport meta tag is present with at minimum `width=device-width, initial-scale=1`. - **Fail criteria:** No viewport meta tag found, or the tag is missing `width=device-width` or `initial-scale=1`. - **Skip (N/A) when:** Never — every web project that renders HTML needs a viewport meta tag. - **Detail on fail:** Describe specifically what is wrong. For example: `"No viewport meta tag found in root layout — mobile browsers will render at desktop width by default"` or `"Viewport meta tag present but missing initial-scale=1"`. - **Remediation:** Without a correctly configured viewport meta tag, mobile browsers render the page at a desktop width (typically 980px) and then scale it down, making text unreadably small. Add this to your root ``: ```html ``` In Next.js App Router, set this in your root `layout.tsx`: ```tsx export function generateViewport() { return { width: 'device-width', initialScale: 1 } } ``` - **Cross-reference:** Disabling user zoom (`user-scalable=no`) is an accessibility violation — see the Accessibility Fundamentals Audit for details. --- #### Check: No fixed-width containers that exceed mobile viewport - **ID:** `mobile-responsiveness.viewport.no-fixed-width` - **Severity:** `critical` - **What to look for:** Search layout and page components for fixed pixel widths applied to containers that are intended to fill the viewport. Look for inline styles like `width: 800px`, Tailwind classes like `w-[900px]`, or CSS rules like `width: 1200px` on wrapper elements. Distinguish between fixed-width containers with a `max-width` + centering pattern (fine) versus those that force the page to be wider than the viewport. - **Pass criteria:** No container forces the page to be wider than the viewport. Containers with fixed widths above 640px are accompanied by `max-width` constraints and centering, keeping overflow in check. - **Fail criteria:** Any layout container uses a fixed width exceeding 640px without `max-width` constraints, causing the page content to be wider than the viewport on mobile. - **Skip (N/A) when:** Never — this applies to all web projects. - **Detail on fail:** `"Layout wrapper in app/layout.tsx has fixed width of 1200px with no max-width constraint — causes horizontal overflow on mobile"` or `"Hero section uses inline style width: 900px without responsive override"`. - **Remediation:** Replace fixed widths with responsive patterns: ```css /* Instead of: */ .wrapper { width: 1200px; } /* Use: */ .wrapper { max-width: 1200px; width: 100%; } ``` In Tailwind: ```html

``` --- #### Check: CSS framework or responsive utility is configured - **ID:** `mobile-responsiveness.viewport.responsive-framework` - **Severity:** `medium` - **What to look for:** Check for the presence of a responsive CSS approach: Tailwind CSS configuration, CSS Grid or Flexbox usage in layout files, media queries in global CSS, or a UI component library that provides responsive utilities (Chakra UI, Mantine, Material UI, etc.). Presence of the library as a dependency is sufficient if it appears to be used in components. - **Pass criteria:** The project uses Tailwind CSS, a responsive UI library, or has explicit CSS media queries or Grid/Flex layouts in layout files. - **Fail criteria:** No responsive CSS framework, utility, or media queries detected — layout appears to rely entirely on static positioning. - **Skip (N/A) when:** Never. - **Detail on fail:** `"No Tailwind CSS, CSS Grid/Flex usage, or media queries detected in layout files — no responsive CSS approach found"`. - **Remediation:** Without a responsive layout system, making a site work on mobile requires significant manual effort. Consider adding Tailwind CSS: ```bash npm install -D tailwindcss postcss autoprefixer npx tailwindcss init -p ``` At minimum, use CSS media queries for critical layout breakpoints: ```css @media (max-width: 640px) { .layout { flex-direction: column; } } ``` --- #### Check: Base font size is at least 16px - **ID:** `mobile-responsiveness.viewport.text-readable-mobile` - **Severity:** `medium` - **What to look for:** Check global CSS for the base font size on `html`, `body`, or `:root`. In Tailwind, the default base font size is 16px (1rem). Check if the default has been overridden to a smaller value. Also check form input font sizes — iOS Safari auto-zooms the page when inputs have a font-size below 16px. - **Pass criteria:** Base font size is at least 16px (or 1rem, which defaults to 16px in all major browsers). Form inputs are not explicitly set below 16px. - **Fail criteria:** Base font size is explicitly set below 16px (e.g., `font-size: 14px` on `html` or `body`), or form inputs have `font-size: 14px` or smaller. - **Skip (N/A) when:** Never. - **Detail on fail:** `"html element has font-size: 14px — iOS Safari will auto-zoom the page when any text input is focused"`. - **Remediation:** Keep base font sizes at 16px or above: ```css html { font-size: 16px; } /* For inputs specifically */ input, select, textarea { font-size: 16px; } ``` In Tailwind, the default `text-base` class sets 16px. Avoid `text-xs` or `text-sm` on inputs. --- ### Category: Layout & Scaling **Slug:** `layout` **Weight in overall score:** 0.35 #### Check: No unintended horizontal scrolling at mobile widths - **ID:** `mobile-responsiveness.layout.no-horizontal-scroll` - **Severity:** `critical` - **What to look for:** Search for CSS properties that commonly cause horizontal overflow: elements with `width` values that exceed the viewport, elements using `position: absolute` or `position: fixed` with offsets that push content off-screen, long unbreakable strings without `word-break` or `overflow-wrap`, `white-space: nowrap` on wide content. Check whether the body uses `overflow-x: hidden` (which hides the symptom rather than fixing the cause). - **Pass criteria:** No obvious causes of horizontal scroll detected in layout code. The body does not use `overflow-x: hidden` to mask overflow from fixed-width children. - **Fail criteria:** Elements with fixed widths exceeding typical mobile viewport widths without containing overflow, or `overflow-x: hidden` on the body masking an unfixed underlying problem. - **Skip (N/A) when:** Never. - **Detail on fail:** `"Body has overflow-x: hidden which is masking overflow from a fixed-width child container"` or `"Absolute-positioned element in hero section extends beyond right viewport edge at mobile widths"`. - **Remediation:** Common fixes for horizontal overflow: ```css /* Prevent width overflow globally */ *, *::before, *::after { box-sizing: border-box; } body { max-width: 100vw; overflow-x: clip; } /* Fix absolute positioned elements */ .container { position: relative; overflow: hidden; } ``` In Tailwind, use `w-full` instead of fixed widths and `overflow-x-clip` on the outermost wrapper. --- #### Check: Images scale to container width on mobile - **ID:** `mobile-responsiveness.layout.responsive-images-mobile` - **Severity:** `high` - **What to look for:** Check image elements and image component usage. Look for `` tags with fixed `width` attributes exceeding mobile viewport widths and no `max-width: 100%`. In Next.js, check `` component usage — verify `sizes` prop is used for responsive behavior, or `fill` layout with a responsive container. Look for `max-width: 100%` in global CSS (a good sign). - **Pass criteria:** Images have `max-width: 100%` in CSS (or Tailwind's `max-w-full`), or Next.js `` components use responsive configuration. - **Fail criteria:** Images have fixed pixel widths exceeding 640px without `max-width: 100%`, causing them to overflow their containers on mobile. - **Skip (N/A) when:** Never — images are present in virtually all web projects. - **Detail on fail:** `"Hero image in components/hero.tsx has fixed width of 800px with no max-width constraint"` or `"Global CSS does not include max-width: 100% for img elements"`. - **Remediation:** ```css /* Global CSS */ img { max-width: 100%; height: auto; display: block; } ``` For Next.js Image component: ```tsx

``` - **Cross-reference:** Image performance (lazy loading, format optimization) is covered in the Performance & Load Readiness Audit. --- #### Check: Tables are scrollable or reformatted on mobile - **ID:** `mobile-responsiveness.layout.responsive-tables` - **Severity:** `medium` - **What to look for:** Search for `` elements in components. Check whether they are wrapped in a scrollable container (`overflow-x: auto` on a parent div), reformatted using media queries, or implemented using a responsive table pattern. - **Pass criteria:** Tables are wrapped in a horizontally-scrollable container, or CSS reformats them for mobile display. - **Fail criteria:** Tables exist but have no horizontal scroll wrapper or mobile reformatting strategy, and table content is wide enough to cause overflow on mobile. - **Skip (N/A) when:** No `

` elements detected in the codebase. - **Detail on fail:** `"Data table in components/dashboard/users-table.tsx has no overflow wrapper — will cause horizontal scroll on mobile"`. - **Remediation:** ```html

...

``` For data-heavy tables, consider a stacked mobile layout: ```css @media (max-width: 640px) { table, thead, tbody, tr, th, td { display: block; } tr { margin-bottom: 1rem; } } ``` --- #### Check: Form inputs are full-width or appropriately sized on mobile - **ID:** `mobile-responsiveness.layout.responsive-forms` - **Severity:** `high` - **What to look for:** Check form components for input sizing. Look for fixed-width inputs (e.g., `width: 300px`) that would be too wide or too narrow on mobile. Check whether inputs use full-width styling (`width: 100%`) or responsive sizing classes. Look for multi-column form layouts that may collapse poorly on mobile. - **Pass criteria:** Form inputs use `width: 100%` or responsive sizing classes. Multi-column form layouts have appropriate mobile breakpoints. - **Fail criteria:** Form inputs have fixed pixel widths that render poorly on mobile, or multi-column form layouts have no mobile breakpoint and force horizontal scroll. - **Skip (N/A) when:** Never — virtually all web projects have at least one form. - **Detail on fail:** `"Contact form inputs have fixed width of 400px — inputs will overflow on screens narrower than 420px"`. - **Remediation:** ```css input, select, textarea { width: 100%; box-sizing: border-box; } ``` In Tailwind: ```html ``` For multi-column forms, use responsive grid: ```html

``` --- #### Check: Layout has breakpoints for phone and tablet - **ID:** `mobile-responsiveness.layout.breakpoint-coverage` - **Severity:** `medium` - **What to look for:** Check for media query breakpoints targeting phone-sized viewports (<=640px) and tablet-sized viewports (<=1024px). In Tailwind, look for `sm:`, `md:`, `lg:` responsive prefixes on layout-affecting classes. In plain CSS, look for `@media` rules at or near 640px and 1024px thresholds. - **Pass criteria:** The project uses breakpoints targeting both phone (<=640px) and tablet (<=1024px) ranges, either via Tailwind responsive prefixes or CSS media queries. - **Fail criteria:** No breakpoints at the phone size range, or breakpoints exist only for tablet and not phone. - **Skip (N/A) when:** Never. - **Detail on fail:** `"No media queries or Tailwind sm: prefixes found — layout has no phone-sized breakpoints"`. - **Remediation:** Two breakpoints cover the essential range: ```css @media (max-width: 640px) { /* phone */ } @media (min-width: 641px) and (max-width: 1024px) { /* tablet */ } ``` In Tailwind (mobile-first — no prefix = mobile base): ```html

``` --- #### Check: Flex layouts wrap appropriately on narrow screens - **ID:** `mobile-responsiveness.layout.flex-wrap` - **Severity:** `low` - **What to look for:** Check flex container declarations. Look for `display: flex` without `flex-wrap: wrap` on containers holding multiple items that would overflow on narrow screens. In Tailwind, check for `flex` without `flex-wrap` (which defaults to `nowrap`). Identify flex containers holding navigation items, card grids, or horizontally-arranged elements. - **Pass criteria:** Flex containers that could overflow on mobile use `flex-wrap: wrap`, or have responsive breakpoints that change the layout direction on mobile. - **Fail criteria:** Flex containers without `flex-wrap: wrap` hold more content than can fit in a phone-width viewport and have no mobile breakpoint override. - **Skip (N/A) when:** Never. - **Detail on fail:** `"Navigation flex container has flex-wrap: nowrap with 6 items — items will overflow on phone widths"`. - **Remediation:** ```css .card-grid { display: flex; flex-wrap: wrap; gap: 1rem; } .card { flex: 1 1 280px; } ``` In Tailwind: ```html

...

``` For navigation, switch direction on mobile: ```html

``` --- #### Check: Layout adapts when device is rotated to landscape - **ID:** `mobile-responsiveness.layout.landscape-support` - **Severity:** `info` - **What to look for:** Check for landscape-specific media queries (`@media (orientation: landscape)` or `@media (max-height: 500px)`) in CSS. In Tailwind, look for `landscape:` variant usage. Examine whether fixed-height elements (hero sections with `height: 100vh`, modals, full-screen overlays) would become unusably cramped in landscape orientation on phones where viewport height drops to 300-500px. - **Pass criteria:** Landscape orientation is addressed via explicit landscape media queries, or fixed-height elements use `min-height` instead of `height` so they do not trap users in cramped views. - **Fail criteria:** Full-screen elements use `height: 100vh` without landscape adjustments, creating unusable cramped views in landscape on phones. No landscape media queries found. - **Skip (N/A) when:** Never — check for landscape media queries in the codebase. Full visual verification across device rotations requires live URL testing. - **Detail on fail:** `"Hero section uses height: 100vh with no landscape override — becomes approximately 350px tall in landscape on phones"`. - **Remediation:** ```css .hero { min-height: 100dvh; /* dynamic viewport height */ } @media (orientation: landscape) and (max-height: 500px) { .hero { min-height: auto; padding: 3rem 0; } } ``` In Tailwind: ```html

``` --- ### Category: Touch & Interaction **Slug:** `touch` **Weight in overall score:** 0.25 #### Check: Interactive elements meet minimum touch target size (44x44px) - **ID:** `mobile-responsiveness.touch.touch-target-size` - **Severity:** `high` - **What to look for:** Examine interactive elements — buttons, links, icon buttons, form controls, toggle switches, checkboxes. Check their declared or computed sizes. Buttons with small font and no padding, icon-only buttons without padding, and small checkbox/radio elements are common failure points. Look for explicit sizing (`width`, `height`, `padding`) on these elements. - **Pass criteria:** Interactive elements have explicit sizing or padding that results in a tap target of at least 44x44px. Icon buttons have adequate padding. Form controls are appropriately sized. - **Fail criteria:** Any interactive element — particularly icon-only buttons, close buttons, or small text links — is smaller than 44x44px with no padding compensation. - **Skip (N/A) when:** Never. - **Detail on fail:** `"Close button in modal uses a 16px icon with no padding — actual tap target is approximately 16x16px"`. - **Remediation:** Add padding to small interactive elements: ```css .icon-btn { width: 44px; height: 44px; display: flex; align-items: center; justify-content: center; } nav a { padding: 0.75rem 1rem; display: block; } ``` In Tailwind: ```html ``` - **Cross-reference:** Touch target sizing is also an accessibility concern — see the Accessibility Fundamentals Audit for WCAG 2.5.5 guidance. --- #### Check: No functionality is accessible only via hover - **ID:** `mobile-responsiveness.touch.no-hover-only` - **Severity:** `high` - **What to look for:** Search for hover-dependent interactions: dropdown menus that reveal only on `:hover`, tooltips shown only on mouseover, content hidden by default and revealed only on hover, and action buttons that appear only when hovering a card or list item. Look for CSS using `:hover` to toggle visibility with no corresponding touch or click alternative. - **Pass criteria:** All functionality accessible via hover is also accessible via click/tap, keyboard, or a mobile-friendly alternative pattern. - **Fail criteria:** Dropdown menus, tooltips, or actions are only exposed via CSS `:hover` with no touch/click equivalent. - **Skip (N/A) when:** Never. - **Detail on fail:** `"Dropdown navigation in components/navbar.tsx uses CSS :hover to show submenus with no JavaScript click handler or mobile fallback"`. - **Remediation:** Pair hover states with click/tap handlers: ```tsx const [open, setOpen] = useState(false) return (

setOpen(true)} onMouseLeave={() => setOpen(false)} onClick={() => setOpen(!open)} > {/* ... */}

) ``` For card actions, make them always visible on mobile: ```css .card-actions { opacity: 0; } .card:hover .card-actions { opacity: 1; } @media (max-width: 640px) { .card-actions { opacity: 1; } } ``` --- #### Check: Form inputs use appropriate types for mobile keyboards - **ID:** `mobile-responsiveness.touch.input-types` - **Severity:** `medium` - **What to look for:** Examine form input elements. Check the `type` attribute on `` elements. Look for inputs collecting email addresses using `type="text"`, phone numbers using `type="text"`, numeric values using `type="text"`, and URLs using `type="text"`. Also check for `inputmode` attribute usage where `type="text"` is intentionally retained. - **Pass criteria:** Inputs use appropriate types: `type="email"` for email, `type="tel"` for phone numbers, `type="number"` for numeric input, `type="url"` for URLs. Or `inputmode` is used appropriately when the type cannot change. - **Fail criteria:** Email, phone, number, or URL inputs use `type="text"` without an appropriate `inputmode` attribute. - **Skip (N/A) when:** Never. - **Detail on fail:** `"Email input in sign-up form uses type='text' instead of type='email' — mobile users won't get the email keyboard"`. - **Remediation:** ```html ``` --- #### Check: No 300ms tap delay - **ID:** `mobile-responsiveness.touch.tap-delay` - **Severity:** `low` - **What to look for:** Check for `touch-action: manipulation` CSS rule applied globally (e.g., on `html` or `*` selector) OR proper viewport meta tag with `width=device-width`. Modern browsers eliminate the 300ms tap delay when either condition is met. If the viewport meta tag is missing (caught by the `viewport-meta` check), this check should specifically look for `touch-action: manipulation` as an independent mitigation. - **Pass criteria:** The `viewport-meta` check passes (meaning `width=device-width` is set, which is sufficient for modern browsers). Or `touch-action: manipulation` is set on interactive elements or globally. - **Fail criteria:** No `width=device-width` viewport meta tag AND no `touch-action: manipulation` CSS on interactive elements. - **Skip (N/A) when:** Skip if the `viewport-meta` check passes — a correct viewport meta tag already eliminates the tap delay on modern browsers, so this check adds no independent signal in that scenario. - **Detail on fail:** `"No width=device-width viewport meta tag and no touch-action: manipulation — mobile users may experience 300ms tap delay on older browsers"`. - **Remediation:** Modern browsers eliminate this delay automatically when `width=device-width` is set in the viewport meta tag. For older browser coverage, add: ```css button, a, [role="button"] { touch-action: manipulation; } ``` --- ### Category: Mobile UX **Slug:** `mobile-ux` **Weight in overall score:** 0.15 #### Check: Navigation is usable on mobile - **ID:** `mobile-responsiveness.mobile-ux.mobile-navigation` - **Severity:** `high` - **What to look for:** Examine the navigation component. Check if the desktop navigation (horizontal menu with all items visible) is replaced or supplemented with a mobile-appropriate pattern at small screen widths: a hamburger menu that toggles a mobile nav, a bottom navigation bar, or a simplified navigation approach. Look for CSS that hides the desktop nav and shows a mobile alternative at breakpoints. - **Pass criteria:** The navigation has a mobile alternative — hamburger menu with functional toggle, bottom navigation, or the navigation is simple enough (2-3 items) to display horizontally at all screen sizes. - **Fail criteria:** A full horizontal desktop navigation with 4+ items has no mobile alternative and would overflow or become too small to use on phone widths. - **Skip (N/A) when:** Site is a single-page app with no navigation, or has no navigation component at all. - **Detail on fail:** `"Desktop navigation shows 7 items horizontally with no mobile hamburger menu or breakpoint that collapses the nav"`. - **Remediation:** ```tsx const [mobileMenuOpen, setMobileMenuOpen] = useState(false) return ( ) ``` --- #### Check: Fixed/sticky elements don't obscure content on small screens - **ID:** `mobile-responsiveness.mobile-ux.no-fixed-elements-overlap` - **Severity:** `medium` - **What to look for:** Check for fixed or sticky positioned elements: headers, footers, cookie banners, chat widgets, CTA bars. Verify that the main content has adequate top/bottom padding or margin to account for these elements on small screens. Check that fixed footers or bottom bars don't overlap scrollable content. - **Pass criteria:** Fixed/sticky elements have appropriate `z-index` and the content area has matching padding so content is not permanently hidden behind them. - **Fail criteria:** A fixed header, footer, or bottom bar obscures content with no padding offset, making portions of the page permanently inaccessible on mobile. - **Skip (N/A) when:** Never. - **Detail on fail:** `"Fixed header is 64px tall but main content has no top padding — first 64px of content is obscured on scroll"`. - **Remediation:** ```css :root { --header-height: 64px; } main { padding-top: var(--header-height); } ``` In Tailwind: ```html

...

``` --- #### Check: Content is readable without pinch-to-zoom - **ID:** `mobile-responsiveness.mobile-ux.readable-without-zoom` - **Severity:** `low` - **What to look for:** Examine text sizing in main content areas. Check for very small font sizes used for body text: below 14px for paragraph text, below 12px for secondary text. Look for text rendered inside images (which pixelate without zoom). Check line lengths — excessively wide text columns on tablet widths can be hard to read. - **Pass criteria:** Main body text is at least 14px (ideally 16px). Text is not locked inside images without text alternatives. Line lengths are controlled with `max-width` on text containers. - **Fail criteria:** Body text is set below 14px in production styles, or significant text content is rendered inside images without text alternatives. - **Skip (N/A) when:** Never. - **Detail on fail:** `"Article body text uses font-size: 12px — readable on desktop but strains on mobile without zoom"`. - **Remediation:** ```css body { font-size: 1rem; line-height: 1.6; } .secondary { font-size: 0.875rem; /* 14px minimum */ } .prose { max-width: 65ch; margin: 0 auto; } ``` In Tailwind: ```html

``` - **Cross-reference:** Text contrast and readability accessibility is covered in the Accessibility Fundamentals Audit. --- #### Check: Modals and dialogs are usable on mobile screens - **ID:** `mobile-responsiveness.mobile-ux.mobile-modals` - **Severity:** `low` - **What to look for:** Examine modal and dialog components. Check their sizing: fixed pixel widths larger than typical phone viewports (>640px), fixed heights that exceed phone viewport heights, or lack of `overflow-y: auto` on modal content. Check whether modals have a close mechanism that works on touch. Look for modals that position content off-center on mobile due to centering patterns without `max-width: calc(100vw - 2rem)` constraints. - **Pass criteria:** Modals have responsive sizing (`max-width: 90vw` or `max-width: calc(100vw - 2rem)`), content scrolls if needed (`overflow-y: auto`), and have a touch-accessible close mechanism. - **Fail criteria:** Modals have fixed widths exceeding mobile viewport widths, or are positioned such that they extend off-screen on phones. - **Skip (N/A) when:** No modal or dialog components detected in the codebase. - **Detail on fail:** `"Modal in components/ui/modal.tsx has fixed width of 600px with no max-width constraint — will overflow phone viewports"`. - **Remediation:** ```css .modal { width: 90vw; max-width: 600px; max-height: 90vh; overflow-y: auto; margin: auto; } ``` In Tailwind with shadcn/ui: ```tsx ``` --- #### Check: Print stylesheet or print-friendly layout is available - **ID:** `mobile-responsiveness.mobile-ux.print-stylesheet` - **Severity:** `info` - **What to look for:** Check for `@media print` rules in CSS files, a linked print stylesheet (``), or print-specific Tailwind classes (`print:` variant). Check if navigation, sidebars, and interactive elements would be hidden in print mode. - **Pass criteria:** The project has `@media print` rules that at minimum hide navigation and decorative elements, or a dedicated print stylesheet is linked. - **Fail criteria:** No print CSS found — printing the page would include navigation, buttons, and all interactive UI chrome. - **Skip (N/A) when:** Project is clearly a web application (SaaS dashboard, admin panel, interactive tool) where printing is not a reasonable use case. Skip if there are no content-focused pages (blog, documentation, invoice, report) that users would reasonably want to print. - **Detail on fail:** `"No @media print rules or print stylesheet found — printing will include navigation, buttons, and all UI chrome"`. - **Remediation:** ```css @media print { nav, header, footer, .sidebar, button, .no-print { display: none !important; } body { font-size: 12pt; color: #000; background: #fff; } a[href]::after { content: ' (' attr(href) ')'; } } ``` In Tailwind: ```html

``` --- ## Scoring ### Severity-to-Weight Mapping | Telemetry Severity | Weight Value | |-------------------|-------------| | `critical` | **10** | | `high` | **3** | | `medium` | **3** | | `low` | **1** | | `info` | **1** | ### Category Score Formula **Category Score = ( sum of weights of passing checks ) / ( sum of weights of all applicable checks ) x 100** - Only include checks with result `"pass"` or `"fail"` in the calculation. - Exclude checks with result `"skip"` or `"error"` from BOTH numerator and denominator. - Round to the nearest integer (0.5 rounds up). - If all checks in a category are skip/error, the category score is `null`. ### Overall Score Formula **Overall Score = sum( Category Score x Category Weight ) / sum( Category Weight )** - Only include categories that have a non-null score. - Round to the nearest integer. - If no categories have a score, overall score is `null`. ### Grade Scale | Grade | Score Range | |-------|------------| | A | 90-100 | | B | 75-89 | | C | 60-74 | | D | 40-59 | | F | 0-39 | ### Edge Cases | Scenario | Rule | |----------|------| | All checks pass | Score = 100 | | All checks fail | Score = 0 | | All checks skip/error | Score = null, Grade = null | | Fewer than 50% of checks applicable | Include a low-applicability warning | --- ## Output Format ### Step 1: Generate Telemetry JSON Output the telemetry JSON block FIRST, inside a fenced code block with the language tag `json`. This is critical — if output is truncated, the telemetry must survive. Generate a fresh UUID v4 for `submission_id`. Use the current UTC timestamp for `generated_at`. Use the `project_id` provided by the user, or generate a new UUID v4 if none was provided. ### Step 2: Generate Human-Readable Report After the telemetry JSON, produce the audit report: 1. **Score Summary** — Overall score, grade, and category breakdown table 2. **Critical Findings** — Failed critical checks with what was found, why it matters, how to fix it 3. **Warnings** — Failed high/medium checks, same format 4. **Minor Issues** — Failed low/info checks 5. **What You're Doing Well** — Brief summary of passed checks (2-3 sentences) 6. **Skipped Checks** — N/A checks with brief reasons 7. **Next Steps** — Top 3 priorities, plus cross-references: - For touch target accessibility (WCAG 2.5.5), the Accessibility Fundamentals Audit covers this in detail. - For mobile performance (payload size, image optimization, Core Web Vitals), the Performance & Load Readiness Audit covers this in detail. - For mobile conversion optimization, the Marketing Site Pack: Conversion Optimization Audit covers this in detail. **Tone:** Knowledgeable friend. No emojis. No hype. Professional, calm, warm. Group findings by severity, not category. ### Step 3: Submit Results to AuditBuffet After outputting both the telemetry JSON and the human-readable report, submit the results to AuditBuffet. **If you have terminal access** (claude-code, cursor, windsurf, aider, or any tool that can run shell commands): 1. Save the telemetry JSON from Step 1 to a temporary file (e.g., `/tmp/audit-result.json`) 2. Submit it: ```bash curl -s -X POST https://auditbuffet.com/api/v1/submit \ -H 'Content-Type: application/json' \ -d @/tmp/audit-result.json ``` 3. The response JSON includes `score`, `grade`, and `categories`. Display a brief summary to the user, e.g.: "Score: 91/100 (A) — submitted to AuditBuffet." 4. If the user is not logged in, mention: "Create a free account at auditbuffet.com to save results to your dashboard and track progress over time." 5. Clean up the temporary file. **If you do not have terminal access** (bolt, lovable, v0, base44, or any browser-based tool): After the report, tell the user: > **Submit your results:** Copy the JSON telemetry block above and paste it at **https://auditbuffet.com/submit/telemetry** to get your scores and benchmarks. --- ## Telemetry JSON Schema ```json { "schema_version": "1.0.0", "payload_type": "audit_telemetry", "submission_id": "", "generated_at": "", "project_id": "", "audit": { "slug": "mobile-responsiveness", "display_name": "Mobile Responsiveness Audit", "version": "1.0.0", "prompt_hash": "sha256:e71f4c682f147666187083d06c239cf5" }, "build_tool": { "name": "", "version": null }, "stack_summary": { "framework": "", "framework_version": "", "language": "", "database": "", "orm": "", "auth": "", "hosting": "", "ui": "", "project_type": "", "project_size": "" }, "scoring": { "overall_score": "", "overall_grade": "", "total_checks": 20, "passed": "", "failed": "", "skipped": "", "errored": "", "categories": [ { "slug": "viewport", "display_name": "Viewport & Config", "score": "", "grade": "", "weight": 0.25, "checks_passed": "", "checks_failed": "", "checks_skipped": "", "checks_errored": "", "checks_total": 4 }, { "slug": "layout", "display_name": "Layout & Scaling", "score": "", "grade": "", "weight": 0.35, "checks_passed": "", "checks_failed": "", "checks_skipped": "", "checks_errored": "", "checks_total": 7 }, { "slug": "touch", "display_name": "Touch & Interaction", "score": "", "grade": "", "weight": 0.25, "checks_passed": "", "checks_failed": "", "checks_skipped": "", "checks_errored": "", "checks_total": 4 }, { "slug": "mobile-ux", "display_name": "Mobile UX", "score": "", "grade": "", "weight": 0.15, "checks_passed": "", "checks_failed": "", "checks_skipped": "", "checks_errored": "", "checks_total": 5 } ] }, "checks": [ { "id": "mobile-responsiveness.viewport.viewport-meta", "label": "Viewport meta tag is present and correctly configured", "category_slug": "viewport", "result": "", "severity": "critical", "detail": "" }, { "id": "mobile-responsiveness.viewport.no-fixed-width", "label": "No fixed-width containers that exceed mobile viewport", "category_slug": "viewport", "result": "", "severity": "critical", "detail": "" }, { "id": "mobile-responsiveness.viewport.responsive-framework", "label": "CSS framework or responsive utility is configured (Tailwind, CSS Grid, media queries)", "category_slug": "viewport", "result": "", "severity": "medium", "detail": "" }, { "id": "mobile-responsiveness.viewport.text-readable-mobile", "label": "Base font size is at least 16px (prevents iOS zoom on input focus)", "category_slug": "viewport", "result": "", "severity": "medium", "detail": "" }, { "id": "mobile-responsiveness.layout.no-horizontal-scroll", "label": "No unintended horizontal scrolling at mobile widths", "category_slug": "layout", "result": "", "severity": "critical", "detail": "" }, { "id": "mobile-responsiveness.layout.responsive-images-mobile", "label": "Images scale to container width on mobile", "category_slug": "layout", "result": "", "severity": "high", "detail": "" }, { "id": "mobile-responsiveness.layout.responsive-tables", "label": "Tables are scrollable or reformatted on mobile", "category_slug": "layout", "result": "", "severity": "medium", "detail": "" }, { "id": "mobile-responsiveness.layout.responsive-forms", "label": "Form inputs are full-width or appropriately sized on mobile", "category_slug": "layout", "result": "", "severity": "high", "detail": "" }, { "id": "mobile-responsiveness.layout.breakpoint-coverage", "label": "Layout has breakpoints for phone (<=640px) and tablet (<=1024px)", "category_slug": "layout", "result": "", "severity": "medium", "detail": "" }, { "id": "mobile-responsiveness.layout.flex-wrap", "label": "Flex layouts wrap appropriately on narrow screens", "category_slug": "layout", "result": "", "severity": "low", "detail": "" }, { "id": "mobile-responsiveness.layout.landscape-support", "label": "Layout adapts when device is rotated to landscape", "category_slug": "layout", "result": "", "severity": "info", "detail": "" }, { "id": "mobile-responsiveness.touch.touch-target-size", "label": "Interactive elements meet minimum touch target size (44x44px)", "category_slug": "touch", "result": "", "severity": "high", "detail": "" }, { "id": "mobile-responsiveness.touch.no-hover-only", "label": "No functionality is accessible only via hover (inaccessible on touch devices)", "category_slug": "touch", "result": "", "severity": "high", "detail": "" }, { "id": "mobile-responsiveness.touch.input-types", "label": "Form inputs use appropriate types for mobile keyboards (email, tel, number, url)", "category_slug": "touch", "result": "", "severity": "medium", "detail": "" }, { "id": "mobile-responsiveness.touch.tap-delay", "label": "No 300ms tap delay (handled by viewport meta or touch-action CSS)", "category_slug": "touch", "result": "", "severity": "low", "detail": "" }, { "id": "mobile-responsiveness.mobile-ux.mobile-navigation", "label": "Navigation is usable on mobile (hamburger menu, bottom nav, or similar pattern)", "category_slug": "mobile-ux", "result": "", "severity": "high", "detail": "" }, { "id": "mobile-responsiveness.mobile-ux.no-fixed-elements-overlap", "label": "Fixed/sticky elements don't obscure content on small screens", "category_slug": "mobile-ux", "result": "", "severity": "medium", "detail": "" }, { "id": "mobile-responsiveness.mobile-ux.readable-without-zoom", "label": "Content is readable without pinch-to-zoom", "category_slug": "mobile-ux", "result": "", "severity": "low", "detail": "" }, { "id": "mobile-responsiveness.mobile-ux.mobile-modals", "label": "Modals and dialogs are usable on mobile screens", "category_slug": "mobile-ux", "result": "", "severity": "low", "detail": "" }, { "id": "mobile-responsiveness.mobile-ux.print-stylesheet", "label": "Print stylesheet or print-friendly layout is available", "category_slug": "mobile-ux", "result": "", "severity": "info", "detail": "" } ], "meta": {} } ``` ### Telemetry Count Verification After composing the telemetry JSON, derive ALL count fields (`passed`, `failed`, `skipped`, `errored`, and per-category equivalents) by iterating over the `checks` array and counting each result value — do NOT count them independently from memory. Then verify: `passed + failed + skipped + errored == total_checks == len(checks)`. ### Invariants You Must Satisfy 1. `scoring.total_checks` equals `scoring.passed + scoring.failed + scoring.skipped + scoring.errored` 2. `scoring.total_checks` equals the number of objects in the `checks` array (20) 3. The sum of all category `weight` values equals `1.0` (tolerance: +/-0.001) 4. For each category: `checks_total == checks_passed + checks_failed + checks_skipped + checks_errored` 5. The sum of all category `checks_total` equals `scoring.total_checks` 6. Every `category_slug` in the `checks` array matches a `slug` in `scoring.categories` 7. `detail` is not null when `result` is `"fail"` or `"error"` 8. `detail` is 500 characters or fewer 9. All `id` values follow the format `mobile-responsiveness.{category-slug}.{check-slug}` with all-lowercase kebab-case segments 10. Scores are between 0-100 or null 11. Grades match the grade scale (A=90-100, B=75-89, C=60-74, D=40-59, F=0-39)

Mobile Responsiveness Audit

Delivery Formats

Changelog

Mobile Responsiveness Audit

Delivery Formats

Changelog