Stop the fixed bar and the toast sitting on the keyboard's focus

WCAG 2.2 SC 2.4.11 asks that a focused control not be completely hidden
by something the page has put on top of it. The bar is fixed over the
bottom and is not in the flow, so the browser does not know it is there:
Tab to a control near the bottom and it is scrolled flush against the
edge of the window, under the bar, and the browser considers it done.

Tabbing the whole page measured 16 stops resting completely covered on a
390x844 phone and 27 more partly, plus four under a toast on the desktop.
It is now 0 and 0 on desktop, phone and a phone on its side — clean
against 2.4.12 (AAA) as well, which allows no overlap at all.

Three things were wrong and they needed different answers.

scroll-padding-bottom on the scroll container, sized from the bar's own
published height and the toast's, handles the case where the browser has
to scroll to reach the control. That is half of it, and the half that
looks like all of it: a control the browser already considers visible is
one it will not scroll to, and a fixed overlay on top does not enter into
that decision. Measured — tabbing to Common rulings with a toast up left
it 100% covered and scrollIntoView({block:"nearest"}) moved nothing. So a
focusin handler measures the overlap and scrolls by it, and when the page
has no room left (26px against 94px wanted) the toast gives way instead.
Sizing the page padding for the toast would have fixed that by making the
page grow and shrink 64px whenever anything was announced.

The page's room to scroll past the bar was 9rem on the sidebar alone,
which left the table's column — most of a desktop — with none. It is now
on the whole app and taken from the bar's real height, so it is also 0 in
the layout where the bar is a rail down the side.

And the seat editor's bottom sheet was put away with a transform, which
moves a thing without putting it away: its Done button sat at y=850 on an
844px screen, focusable, announced, and impossible to scroll to, because
a fixed element does not move when the page does. visibility:hidden puts
it away, transitioned so the slide-out still runs.

uiAudit.js gained focusHasRoom() and focusablesReachable() for the two
static halves. Audit unchanged at 2 failing configurations and 3
offenders, both pre-existing. 805 unit tests pass.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb

tests/holdem/README.md

@@ -292,6 +292,44 @@ skipped rather than judged, since it is not in the tree to begin with.
 Removing the one `aria-label` this round added makes it report all five buttons, which is
 how it was checked.
 
+## Where the keyboard lands
+
+Two checks in `uiAudit.js` cover WCAG 2.2 SC 2.4.11, which says a focused control must
+not be completely hidden by something the page has put on top of it. Tabbing the whole
+page on a 390x844 phone found **16 stops resting completely covered and 27 more partly**,
+under the action bar; on the desktop, four more under a toast.
+
+They are checked as the fix rather than as the symptom, because the symptom needs a
+keyboard and this file has no automation of its own:
+
+- **`focusHasRoom()`** — `scroll-padding-bottom` on the scroll container has to reserve at
+  least as much room as the fixed furniture standing at the bottom of the window. Only
+  furniture crossing the middle of the screen counts, or the rail a landscape phone puts
+  down the right-hand side would demand scroll padding the height of the whole window;
+  and sticky elements inside a panel that scrolls on its own are excluded, because
+  scroll-padding on the document would do nothing about them.
+- **`focusablesReachable()`** — nothing focusable may sit entirely outside the viewport
+  inside a `position: fixed` subtree, since scrolling can never bring it back. The seat
+  editor's bottom sheet was put away with `transform: translateY(105%)`, which moves a
+  thing without putting it away: its Done button sat at y=850 on an 844px screen, still in
+  the tab order and still on the accessibility tree. `visibility: hidden` puts it away.
+
+### Half a fix looks exactly like a whole one
+
+`scroll-padding-bottom` alone was written up as the answer and it is only half of it. It
+applies when the browser has to scroll to reach the control at all; a control the browser
+already considers visible is one it will not scroll to, and a fixed overlay on top of it
+does not enter into that decision. Measured: tabbing to Common rulings with a toast up
+left it 100% covered, and `scrollIntoView({block: "nearest"})` moved nothing, because
+"nearest" was already satisfied. The sweep had shown clean only because 89 tab presses
+outlast an eight-second toast.
+
+So the other half is a `focusin` handler that measures the overlap and scrolls by it —
+and, when the page has no room left to scroll (26px available against 94px wanted, at
+1280x900), dismisses the toast instead. Sizing the page's bottom padding for the toast as
+well would have fixed it by making the page grow and shrink by 64px every time anything
+was announced, which is worse than the fault.
+
 ## Why the hand evaluator is tested the way it is
 
 `handRank.js` is the only module here that can pay the wrong person without anybody