Small-screen portal experience: reflow, target size and navigation accessibility #67
Etiketter
Inga etiketter
area/backups
area/ci
area/control-panel
area/identity
area/infra
area/observability
area/payments
area/security
area/storage
area/web
blocked
needs-info
needs-triage
ready-for-implementation
type
bug
type
chore
type
docs
type
epic
type
feature
type
task
wontfix
Ingen milstolpe
Inget projekt
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Inget förfallodatum satt.
Beroenden
Inga beroenden satta
Referens
bitborg/bitborg-docs#67
Läser in…
Hänvisa till i nytt ärende
Ingen beskrivning angiven.
Ta bort grenen "%!s()"
Borttagning av en gren är permanent. Även om den borttagna grenen kan fortsätta existera en kort tid innan den faktiskt tas bort, kan det INTE ångras i de flesta fall. Vill du fortsätta?
The portal has no small-screen navigation pattern: no disclosure, no hamburger, and no JavaScript in
the header. That is a genuine strength — none of the usual failure modes (expanded-state desync,
focus traps, scroll-lock bugs) can occur — and this epic does not propose adding one. What it
does propose is fixing the layout, target sizes and accessibility of the navigation we already have.
Measured in headless Chromium at 320/360/375/390/414/480/600/768 px, with and without JavaScript,
across the home page, the documentation, the FAQ, pricing and sign-up.
scrollWidth 347againstclientWidth 320. WCAG 2.2 SC 1.4.10 (Reflow, AA) is failed. Swedish is the worse case, andSwedish is the default language.
floor.
/auth/loginlink anywhere on the page.minimum target token and applies it to buttons, the FAQ filter and the logo — but to no navigation
link. SC 2.5.8 currently passes only through the spacing exception, which is compliance by
accident.
WebKit, so it fails on every iOS browser;
viewport-fit=coveris set with no safe-area insets.Scope
Decision taken
The language switcher moves to the footer below the medium breakpoint — the largest single space
win on a phone, accepted in the knowledge that the portal has no
Accept-Languagedetection, so areader who lands in the wrong language must scroll to change it.
Sequencing
Fix the reflow before enlarging targets — taller targets multiply the height of a navigation row
that cannot currently wrap.
Done when
No page scrolls in two directions at 320 px, sign-in and sign-up survive without JavaScript, every
navigation target meets the minimum size below the medium breakpoint, and no two landmarks on a page
share a name.
Status — 2026-08-02
Six of nine merged and deployed. Reflow is fixed at every width from 320 px on six pages, every
navigation target now meets 48 px, the landmarks are distinct in both languages, the skip link moves
focus, and the safe area is honoured.
The three left are not leftovers of the same kind:
arguably the most consequential: with JavaScript off there is no sign-in or sign-up anywhere in
the header. Still
ready-for-implementation, back in Todo.the header from 278 px to 210 px — but its ≤170 px target is arithmetically incompatible with the
48 px touch targets chosen for #155. Three 48 px rows are 144 px of targets; the remaining 66 px
is padding. Reaching 170 means cutting ~40 px of gaps, which is a density decision, not a layout
one. Open for that call.
All nine tasks are delivered, so this closes. Recording what shipped and what did not, so the Shipped column is not read as more than it is.
Delivered
medium, and the brand band was compacted.Not reached
One defect in the body above is only partly fixed: "278-360 px of chrome before content on a 375 px phone: 41-54 % of the viewport".
Measured today at 375 px: the header is 234 px, down from 278, and
<main>starts at 311 px on a page with breadcrumbs. That is still about 47 % of a 667 px viewport.#156 set a 170 px target and closed without meeting it. The reason is recorded there:
.main-navigationalone is 130 px, because five links wrap to two rows and each row is held to the 48 px WCAG 2.5.8 minimum added for #159. Even a perfect one-row header band leaves roughly 178 to 210 px. Getting under 170 px needs fewer or regrouped navigation rows, smaller touch targets, or a JavaScript disclosure pattern, and this epic explicitly ruled all three out.Accepted as good enough for now. If the chrome budget is revisited, it needs a new epic rather than reopening this one, because the remaining options are the ones this epic set out not to take.