a11y.21 (WCAG 1.4.10), measured rather than taken as filed. The
finding's mechanism is vertical — "the 4em bars grow while the viewport
does not, and anything that no longer fits is clipped with no
scrollbar" — and that is not what happens. The middle row is `1fr` and
absorbs the growth exactly: at 200% text on 800x600 the bars go 64px to
128px and the panel 472px to 344px, with the footer still landing on
600. Nothing is clipped vertically, and Settings stays reachable
because the sidebar scrolls (007 phase 5).
What is real is the axis the finding does not mention. At 200% text the
shell is 1014px wide in an 800px viewport, and at 320px — 400% page
zoom of 1280, the width 1.4.10 names — it is 784px, so 464px of the
app including the job indicator and the queue button sat behind
`overflow: hidden` with no way to reach it.
So the horizontal axis scrolls and the vertical one stays fixed, which
also keeps the transport where a desktop player's transport belongs. At
every size this app promises there is no overflow on either axis and no
scrollbar appears, which the three viewport cases assert.
The first version of the spec passed on the broken build: `overflow:
hidden` still permits programmatic scrolling, so `scrollLeft = 9999`
proves nothing. It is a wheel gesture now.
a11y.30: `<main id="main-content">` existed and nothing linked to it,
so a keyboard user walked the library filter, the search box, the job
indicator and eleven nav items before reaching content, on every
navigation. Two things in it are load-bearing and only checkable
against the running document: the link is out of flow in *both* states,
because `body` is a grid with named areas and an in-flow extra child is
auto-placed into one of them; and `<main>` needs tabindex="-1", or the
fragment link moves the scroll, leaves the tab sequence where it was,
and looks like it worked.
a11y.29: `<h1>` followed by `<h3>` for type size. An `hgroup` takes one
heading plus paragraphs, so a `<p>` is also what it was meant to hold.
a11y.34: the sort arrow was 10px, below the type scale's own floor,
with a comment acknowledging it. Half of that finding was closed by
Phase 1 — the direction is announced now, via aria-sort — and the other
half is one declaration.
And the state that landed in: the hgroup measured 67px inside a 64px
bar, so dropping the h3's bottom margin shortened the block, moved the
flex-centred pair down, and clipped the subtitle's descenders. The
overflow was pre-existing; `margin-block: 0` on the title is the fix,
pinned by a new layout-overflow case.
The track list shared out its whole clientWidth across the resizable
columns while every row spends 24px on the favourite column and 2x8px
on its own padding before the first one starts, so the grid was always
exactly 40px wider than the box holding it and the last column was
clipped at every size (scrollWidth 1280 vs clientWidth 1240, measured).
Both numbers now live in one place and are read by the two call sites
that had written them out separately, which is how they came to
disagree.
The enforced minimum was 512x384, which the layout had never
supported: at 700x480 the eleven sidebar items needed 406px of a 352px
pane, overflow:hidden cut the last two off with nothing to scroll, and
Settings and Jobs could not be reached at all. The pane scrolls now,
the sidebar collapses to icons below 900px (its .collapsed mode existed
and only a manual drag ever reached it), the subtitle hides at the same
breakpoint so the title stops wrapping out of the 4em bar, and the
minimum is 800x600 - measured as where the shell still works rather
than picked as a round number.
logan