Layout Reflow Supported

WayneEDick's original issue (wcag21#846, copied into #198 by michael-n-cooper) showed screenshots of content squished between a fixed header and footer, arguing the low-resolution assumption is a phone in portrait while a low-vision user is actually in landscape, and that non-collapsible vertical panes growing with zoom leave no usable space. StommePoes says these are simply non-functional pages: at 150% on a 12-inch laptop she gets about three lines of text, and she names Medium.com and news sites as the worst offenders, failing them under text-resize in her own audits. mraccess77 adds breakages with the same cause — hover content that appears off-screen and vanishes when you scroll to it, snap scrolling that jumps past content you are trying to reach at zoom, and scroll jacking that takes away ctrl plus mouse wheel. All three treat the fix as cheap and known — WayneEDick's three techniques are switch fixed to static at low resolution, replace the bar with a control limited to 10% of the screen, or make it collapsible, and StommePoes adds that developers already write width-based media queries, so a height-based one in ems can simply drop the stickiness, since the sticky content is usually the site name or social buttons.

patrickhlauke would support a percentage or ratio rule — roughly, sticky and fixed elements not covering more than a third of the visible viewport — with the understanding doc requiring testing in both portrait and landscape, down to 320 CSS px width and 256 CSS px height. He insists on "down to" rather than mandating that exact viewport dimension, because otherwise the requirement is pointless. StommePoes agrees, citing content that passed at 400% on a 1280 px viewport but broke around 250% when a media query did not fire, leaving the user to choose between 175% (too small) and 300% (larger than needed); she also reports that showing designers sticky elements eating a quarter to a half of viewport height draws no pushback, because they find it ridiculous too.

Sticky headers create reading viewports that are too short, but mraccess77 doubts the group can reach consensus on what height is acceptable: is the metric percent of viewport height, or the number of lines of text that fit? Full coverage is clearly a failure, but two or three visible lines forcing the user to read through a slot is harder to draw a line around. He notes the LVTF concluded these issues were too challenging for WCAG 2.2's framework and belonged in Silver, and that the working group's impression is that low-vision issues are already solved — leaving him unsure which spec is the right home. alastc was more optimistic, suggesting a limit could build on reflow's existing 256 px minimum height and tie in with device orientation.

PAFaieta opened #156 asking that the standard name a baseline native viewport resolution and DPI, or a baseline minimum magnification such as 200% as a satisfactory technique, on the grounds that vague language invites compliance arguments. patrickhlauke answered that CSS px is already density-independent and that authors cannot predict or test the physical resolution and dimensions users run — a person on a physically small monitor at very high resolution has chosen that, and adapting the device is their call, not the author's. alastc added that WCAG 3 deliberately avoids technology-specific language at the provision level and expects metrics to live in technology-specific methods, and asked for concrete ground-level examples of the "liberties" being taken; PAFaieta left the thread without supplying them.

chaals set font-size to 64px in Safari and browsed roughly 100 pages: news sites were generally unusable (abc.net.au the least bad), search engines were terrible, whitehouse.gov and un.org worked reasonably, and idealista was the one usable shopping site. He reports that pretty much every serious problem traced to layouts set in pixels — most commonly line-heights derived from the screen's pixel width and far below 64px, then large text squeezed into too-small boxes. His proposal is to trigger breakpoints on character counts rather than screen width in px, and to express any measure larger than half the expected font-size in rem, with layouts expected to work between 4px and 72px (about 1.5mm to 25mm). graphic-designer (#642) argues the same conclusion from user autonomy: px ignores a user's configured root font size, so a px-based architecture is rigid by construction while rem lets the layout breathe.

Responding to #642, alastc says WCAG 3 has no mention of 16px, that its only CSS px requirements are text resizing to 200% of the platform default body size and text reflow at 320 CSS px, and that CSS px is itself relative to an assumed viewing distance and translates to platforms that have no rem. He argues browser zoom is the default, easier-to-find setting that persists across sites, that text-only sizing breaks text out of layouts, and that sizing the whole layout in rem just re-invents zoom; his draft response would close the issue without changing provisions. Myndex says the CSS px is defined as a unit of visual angle, which is what vision science uses, while rem has no fixed relation to it, and that Chrome is the only major browser he knows with an independent default font size setting. GreggVan says rem says nothing about how large something is, so an accessibility minimum cannot be written in it, and that CSS px values are cited in standards only as minimums. chaals, after testing, agreed zoom works better than increased text size on most sites, while still seeing a use case for text-only sizing to keep headings and images from becoming unworkable.

An emailed objection from an unnamed sender, which alastc posted as #664, argues that forcing a 320 px mobile-style layout on a desktop display at 400% zoom increases cognitive load for older users by hiding familiar navigation and breaking established mental models. It claims this breaks complex interfaces such as legal document portals, preventing citizens from accessing documents, and characterises the mobile-first target as favouring the ecosystems of major W3C corporate members. The request is for a Desktop-Preservation Mode or a reduced requirement — 200% — that does not trigger a full layout change. Nobody has replied.