CogniPrep's 320px audit found nearly every real defect at the bottom of the screen

"The top of a page looks fine at 320px because the top of a page is a heading," the author of CogniPrep's post on dev.to wrote ^[6]. The failures sat lower: an action bar over the last row, a button strip pushed under the browser chrome, a label running outside its own button ^[5]. Two of those three are fixed strips. Action bars, review rails and summary strips that work at 1280 cover the last item at 320, or the phone keyboard covers them when an input takes focus ^[15].

The author's case for 320px is cost. It is "the width where every layout decision that was going to fail has already failed, and it is cheap to check," the post says ^[3]. Per test, it still adds up: five screens, or six where a confirmation screen exists, across three widths is 15 to 18 views ^[1].

"Lorem ipsum wraps politely. Product copy does not," the author wrote ^[8]. The label "Start, the clock starts now" would not fit a 320px button, and the fix was shorter copy, not smaller text ^[16]. Four- and five-column tables clipped, split words or pushed a column off screen. The team's standard fix is now the table from the md breakpoint up and a labelled card per row below it ^[14]. The remaining shape was a screen that opened scrolled down, or a layout centred in a container wider than the viewport ^[17].

I think the best engineering in the post is how the team reached screens no signed-in auditor could open. It built a temporary preview route that mounted the real component tree over mocked API responses, so the auditor saw the real UI with no entitlement and no server state ^[10]. The routes were never committed, and nothing in the real tree changed to accommodate them ^[10]. "If a preview route needs a change inside the component to work, the audit is no longer auditing what ships," the author wrote ^[11]. Audio items ran silently in a headless browser, so "does the sound play" went on record as out of scope ^[12].

The same care shows in what the team declined to touch. Breadcrumb links on 52 hub pages are 18 pixels tall. They meet the spacing exception in WCAG 2.5.8, and the markup is inline in all 52 pages, so enlarging them would be a deliberate site-wide pass outside the release branch ^[19]. Chart axis labels spill a few pixels past the SVG viewBox, but the SVG is overflow-visible and nothing is clipped ^[20]. "An audit that reports everything it noticed is a worse artefact than one that separates defects from preferences," the author wrote ^[21].

For the next audit, the author plans to paste two snippets into the DevTools console at a 320 viewport before anyone opens a browser by hand ^[22]. The text ends at the first snippet's comment, "// 1. Does the page itself scroll", and does not estimate how many findings the checks would have caught ^[22]. At a 320 viewport, that comment suggests a test for sideways overflow. I'd expect such a check to flag a table pushing a column off screen, or a layout centred in a container wider than the viewport ^[14][17]. A strip sitting over the last row does not widen the page, and neither does a bar hidden by the keyboard ^[15]. Those findings still need a person scrolling to the bottom of a middle item.