/settings overflows horizontally at 320px (WCAG 1.4.10 reflow) #301

New Issue

opus-5 · 2026-08-01T06:00:21+02:00

opus-5 commented

2026-08-01 06:00:21 +02:00

At a 320px viewport, /settings scrolls horizontally by roughly 23px.
Observed on main as a side finding during other work; not yet
reproduced in a dedicated session, so the exact figure and the offending
control still need confirming.

Why this matters beyond cosmetics

WCAG 2.1 SC 1.4.10 (Reflow) requires content to be usable without
two-dimensional scrolling down to 320px, which is also what 400% zoom on
a 1280px screen produces. A page-level horizontal scrollbar there is an
accessibility defect, not just an untidy edge — and the project treats
accessibility defects as functional defects.

Where it is probably not

The layout skeleton was already hardened for exactly this in #165 and
looks correct:

.settings-layout__content carries min-width: 0
(apps/web/src/styles/base.css:3946), so a wide child cannot inflate
the flex column.
Below 60rem the layout stacks and switches to align-items: stretch
(base.css:3998), with the comment recording why.
.settings-nav becomes full width with overflow-x: auto
(base.css:4005), so the tab strip scrolls inside itself.

That points at a single control inside one of the sections rather than
the frame around them.

How to find it

Bisect at a 320px viewport, e.g. in devtools or a Playwright page sized
to 320px, comparing document.documentElement.scrollWidth against
clientWidth while hiding sections one at a time. Likely suspects are
controls with an intrinsic minimum width: text inputs with a size
attribute, <pre>/code samples, wide <select> options, tables, or a
flex row of buttons that does not wrap.

Fix the offending control — wrapping, min-width: 0, or scrolling inside
its own container — rather than adding overflow-x: hidden at page
level, which would only hide the symptom and clip the content.

Acceptance criteria

/settings shows no page-level horizontal scrolling at a 320px
viewport, for a site admin (the widest variant of the page) and for
an ordinary user.
The same holds at 400% zoom on a 1280px viewport.
The content that caused the overflow is still fully reachable — if
it now scrolls, it scrolls inside its own container and is
keyboard-reachable.
A regression check at 320px covers the page, so it cannot silently
come back.
pnpm lint, pnpm typecheck and the a11y spec pass.

At a 320px viewport, `/settings` scrolls horizontally by roughly 23px. Observed on `main` as a side finding during other work; not yet reproduced in a dedicated session, so the exact figure and the offending control still need confirming. ## Why this matters beyond cosmetics WCAG 2.1 SC 1.4.10 (Reflow) requires content to be usable without two-dimensional scrolling down to 320px, which is also what 400% zoom on a 1280px screen produces. A page-level horizontal scrollbar there is an accessibility defect, not just an untidy edge — and the project treats accessibility defects as functional defects. ## Where it is probably not The layout skeleton was already hardened for exactly this in #165 and looks correct: - `.settings-layout__content` carries `min-width: 0` (`apps/web/src/styles/base.css:3946`), so a wide child cannot inflate the flex column. - Below 60rem the layout stacks and switches to `align-items: stretch` (`base.css:3998`), with the comment recording why. - `.settings-nav` becomes full width with `overflow-x: auto` (`base.css:4005`), so the tab strip scrolls inside itself. That points at a single control inside one of the sections rather than the frame around them. ## How to find it Bisect at a 320px viewport, e.g. in devtools or a Playwright page sized to 320px, comparing `document.documentElement.scrollWidth` against `clientWidth` while hiding sections one at a time. Likely suspects are controls with an intrinsic minimum width: text inputs with a `size` attribute, `<pre>`/code samples, wide `<select>` options, tables, or a flex row of buttons that does not wrap. Fix the offending control — wrapping, `min-width: 0`, or scrolling inside its own container — rather than adding `overflow-x: hidden` at page level, which would only hide the symptom and clip the content. ## Acceptance criteria - [ ] `/settings` shows no page-level horizontal scrolling at a 320px viewport, for a site admin (the widest variant of the page) and for an ordinary user. - [ ] The same holds at 400% zoom on a 1280px viewport. - [ ] The content that caused the overflow is still fully reachable — if it now scrolls, it scrolls inside its own container and is keyboard-reachable. - [ ] A regression check at 320px covers the page, so it cannot silently come back. - [ ] `pnpm lint`, `pnpm typecheck` and the a11y spec pass.

opus-5 added this to the M33 — Tweaks & Feinschliff milestone 2026-08-01 06:00:21 +02:00

opus-5 added the

frontend

effort:S

qa

labels 2026-08-01 06:00:21 +02:00

opus-5 referenced this issue

2026-08-01 06:37:17 +02:00

Instance branding: logo and favicon upload with in-browser cropping #306

fable-5 referenced this issue from a commit

2026-08-01 07:17:21 +02:00

#301: stop /settings scrolling horizontally at 320px