fix(queue): name the queue header's two older actions

Clear queue and Add queue to playlist were named by a `title` attribute
and nothing else, while the close button beside them has carried an
`aria-label` since #24. They get one too.

`title` is a name, so this is the weak-name case rather than the missing
one: it is the *last* fallback in the accname order, so any content put
inside the button later silently outranks it, and a phone has no hover
to show it. The `title`s stay — on a desktop they are also the tooltip
for an icon-only control, which is a different job.

The assertion is the part worth reading. The obvious spec — `getByRole`
by name, which is what `queue-overlay.spec.ts` already does for the
close button — is **green on the broken build**: measured against the
running pre-fix app, both buttons matched. So the second test states the
property as what it is, that the name is not the tooltip: it removes the
`title` attributes and asks again, which was 0 and 0 on main and is 1
and 1 now.

Closes #170

CLAUDE.md

@@ -1470,28 +1470,6 @@ live**: a scrim over a menu item is that item's text surface, and the
 14px spends its weight below the last legible label, measured at 9.9:1
 on the light ramp, whose `bgElevated` is `#e9ecef`.
 
-**And the phone has two sheets, so that rule is one file both read**
-(#210). `bottom-nav`'s "More" is capped at the same 85vh and overflows
-for the same reason — measured at 424x439 with eight destinations,
-`scrollHeight` 412 against `clientHeight` 373, and eleven items at 48px
-would be 528, since #25 makes the count the user's. So the two layers
-live in `styles/sheet-scroll.css.ts` and each host says only what is
-local to it: the colour, handed over as `--yj-sheet-surface` on the same
-box, because the nav sheet paints the sidebar's `--yj-bg-surface` and
-the context sheet the menus' `--yj-bg-elevated` — a shared rule that
-hard-coded either would draw that seam across the other one.
-
-The half that is not the fade is what makes it visible: **nothing inside
-the sheet may repaint the surface**, because these are background layers
-on the scroller and an opaque child covers them. `menu-surface` already
-had it from the other side (`.context-menu-panel[data-sheet]` is
-`background-color: transparent`); `app-sidebar`'s host paints
-`--yj-bg-surface`, which in the shell is its own background and in the
-sheet is a second copy of the sheet's, so `bottom-nav` turns it off.
-Measured at 424x439 with the fade adopted and that rule missing: a flat
-52,58,64 to the bottom edge with 39px still below, which is the defect
-unchanged and every assertion about `background-attachment` passing.
-
 **The playlist submenu is a sheet too, and it had to be.** It is a
 `placement="right-start"` flyout, and making the menu full-width moved
 its anchor — measured at x −182 to 0, entirely off-screen, so "Add to
@@ -1854,6 +1832,21 @@ is not it.** A `placeholder` is an accname fallback, so an
 Explore's search box — the audit's own `a11y.26` — as clean. A sweep
 for *empty* names cannot see a *weak* one.
 
+**`title` is the same trap one rung lower, and it defeats the obvious
+spec as well as the obvious sweep.** `queue-panel`'s Clear queue and
+Add queue to playlist were named by `title` alone, so
+`getByRole('button', { name: 'Clear queue' })` matched them **before**
+the fix as well as after — a `getByRole` assertion, which is what
+catches every other nameless control in this app, would have been
+green on the broken build. `title` is the *last* fallback in the
+accname order, so content put inside the button later silently
+outranks it, and it is the one name a phone cannot show, having no
+hover. The property is therefore asserted as *the name is not the
+tooltip*: `queue-overlay.spec.ts` removes the `title` attributes and
+asks again, which is 1 and 1 with `aria-label` and was measured at 0
+and 0 without it. The `title`s stay, because on a desktop they are
+also the tooltip for an icon-only control and that is a different job.
+
 **The shell scrolls sideways and not down.** `body` is
 `overflow-x: auto; overflow-y: hidden`, and both halves are measured.
 Vertically there is nothing to fix: the middle grid row is `1fr` and

e2e/specs/queue-overlay.spec.ts

@@ -157,6 +157,62 @@ test.describe('an overlaid queue says it is over the content', () => {
   });
 });
 
+/**
+ * #170 — the other two buttons in that same row.
+ *
+ * Clear queue and Add queue to playlist predate the close button and
+ * were named by a `title` attribute and nothing else. Unlike the
+ * sliders in `control-names.spec.ts`, that is not a *missing* name:
+ * `title` is the last fallback in the accname order, so
+ * `getByRole('button', { name: 'Clear queue' })` matched them before
+ * this fix as well as after it — measured, 1 and 1. A sweep for empty
+ * names cannot see a weak one, which is `a11y.26`'s complaint and the
+ * reason this file could have grown a green test that proved nothing.
+ *
+ * So the name is asserted twice, and the second assertion is the one
+ * that fails on the broken build. Taking the tooltip away and asking
+ * again is the property in words: **the name is not the tooltip**. It
+ * is what makes the button survive content being put inside it later,
+ * and it is the only one of the two a phone has — there is no hover on
+ * the surface #55 turned into a full screen. Measured on `main` before
+ * the fix: 0 and 0.
+ *
+ * Both buttons are disabled here, because the queue starts empty and
+ * naming is not enablement. A disabled button is still in the
+ * accessibility tree, which is exactly where the complaint was.
+ */
+test.describe('the queue header says what its actions do', () => {
+  const ACTIONS = ['Clear queue', 'Add queue to playlist'];
+
+  test('names both of the older actions', async ({ app }) => {
+    await openQueue(app);
+
+    for (const name of ACTIONS) {
+      await expect(
+        app.getByRole('button', { name, exact: true }),
+      ).toHaveCount(1);
+    }
+  });
+
+  test('and the names do not come from the tooltip', async ({ app }) => {
+    await openQueue(app);
+
+    await app.locator('#queue-panel').evaluate((el) => {
+      for (const button of el.shadowRoot!.querySelectorAll(
+        '.header-action-button',
+      )) {
+        button.removeAttribute('title');
+      }
+    });
+
+    for (const name of ACTIONS) {
+      await expect(
+        app.getByRole('button', { name, exact: true }),
+      ).toHaveCount(1);
+    }
+  });
+});
+
 /**
  * The inline panel is the mode that already worked, and the one every
  * other queue spec is written against. It keeps its resize handle and

frontend/src/components/bottom-nav/bottom-nav.ts

@@ -4,7 +4,6 @@ import '@awesome.me/webawesome/dist/components/icon/icon.js';
 import '@awesome.me/webawesome/dist/components/drawer/drawer.js';
 import type WaDrawer from '@awesome.me/webawesome/dist/components/drawer/drawer.js';
 import { designTokens } from '../../styles/tokens.css';
-import { sheetScrollFade } from '../../styles/sheet-scroll.css';
 import '../sidebar/app-sidebar.js';
 import { nameDialog } from '@utils/name-dialog';
 import { ICON_PLAYLIST } from '@utils/icon-language';
@@ -168,15 +167,6 @@ export class BottomNav extends LitElement {
             overflow: hidden;
         }
 
-        /* And this list does not fit (#210): measured at 424x439 with
-           the seed's eight destinations, the body is scrollHeight 412
-           against clientHeight 373, and eleven items at 48px would be
-           528 -- the count is the user's since #25. So the sheet says
-           where the fold is, with styles/sheet-scroll.css's two layers
-           rather than a second answer to the question #207 settled for
-           the context sheet. The colour is the local half: the sidebar
-           paints --yj-bg-surface, so the cover does too, or the fade
-           draws the menus' grey across the bottom of this one. */
         wa-drawer::part(body) {
             padding: 0;
             /* A scroll that reaches the end of this list must not
@@ -187,23 +177,6 @@ export class BottomNav extends LitElement {
                on a gesture-navigation phone -- the same allowance the
                bar itself makes above. */
             padding-bottom: env(safe-area-inset-bottom, 0);
-            --yj-sheet-surface: var(--yj-bg-surface, #212529);
-            ${sheetScrollFade}
-        }
-
-        /* And the sheet paints that surface once. The sidebar's host
-           paints the same grey -- which in the shell is the sidebar's
-           own background and here is a second, opaque copy of the
-           sheet's, drawn *over* the body's layers. So the fade was
-           painted and then covered: measured at 424x439 before this
-           rule, the last 32px read a flat 52,58,64 with 39px still
-           below. menu-surface meets the same requirement from the
-           other side, where .context-menu-panel[data-sheet] is
-           background-color: transparent; nothing changes visually
-           here, because the colour underneath is the one being
-           removed. */
-        app-sidebar {
-            background-color: transparent;
         }
 
         /* A sheet is dragged at with a thumb, so it says where its top

frontend/src/components/menu-surface/menu-surface.ts

@@ -65,7 +65,6 @@ import '@awesome.me/webawesome/dist/components/popup/popup.js';
 import '@awesome.me/webawesome/dist/components/dialog/dialog.js';
 import type WaPopup from '@awesome.me/webawesome/dist/components/popup/popup.js';
 
-import { sheetScrollFade } from '../../styles/sheet-scroll.css';
 import { PHONE_QUERY } from '@utils/breakpoints';
 import { nameDialogsIn } from '@utils/name-dialog';
 
@@ -165,17 +164,46 @@ export class MenuSurface extends LitElement {
            and worse when the cut lands on a row boundary, where the
            sheet ends in a clean edge that reads as the end of the list.
 
-           The two layers that say it live in styles/sheet-scroll.css
+           Two layers, and the *order* is what asks the question: a
-           (#210), because the phone has a second sheet -- bottom-nav's
+           shadow pinned to the bottom of the box (attachment scroll),
-           "More" -- which overflows for the same reason and must not
+           and over it a cover of the sheet's own colour painted at the
-           arrive at its own answer for what a fold looks like. What is
+           end of the *content* (attachment local), which therefore
-           local to this sheet is the colour the cover is painted in:
+           scrolls up over the shadow and hides it exactly when there is
-           the menus' elevated grey, handed over as --yj-sheet-surface
+           nothing more to see. So the affordance is absent on a menu
-           on the same box. */
+           that fits, present the moment one does not, and gone again at
+           the end of the list -- with no scroll listener, no
+           measurement, and nothing reaching into wa-dialog's shadow
+           root for the scroller. background-attachment is Chrome 4;
+           the reference device is Chrome 113.
+
+           **The curve is steep because the rows under it stay live.**
+           A scrim over a menu item is that item's text surface, and
+           this app's rule is that text clears 4.5:1 on every surface it
+           can sit on -- which the light ramp, whose bgElevated is
+           #e9ecef, is what makes non-theoretical. A row is 48px with
+           its label centred, so 32px of scrim that is already down to
+           a quarter strength at 14px reaches y-centre at about 0.06 and
+           spends its weight on the strip below the last legible label.
+           Measured on the dark ramp at x=300, flat 52,58,64 throughout
+           before: 50,56,62 at y=330, 33,37,40 at y=350 and 22,24,27 at
+           the bottom edge, and flat again at the end of the list. The
+           light ramp puts 9.9:1 on the last label. */
         wa-dialog::part(body) {
             padding: 0;
-            --yj-sheet-surface: var(--yj-bg-elevated, #343a40);
+            overflow-y: auto;
-            ${sheetScrollFade}
+            background:
+                linear-gradient(
+                        var(--yj-bg-elevated, #343a40),
+                        var(--yj-bg-elevated, #343a40)
+                    )
+                    bottom / 100% 32px no-repeat local,
+                linear-gradient(
+                        to top,
+                        rgba(0, 0, 0, 0.6) 0%,
+                        rgba(0, 0, 0, 0.25) 45%,
+                        rgba(0, 0, 0, 0) 100%
+                    )
+                    bottom / 100% 32px no-repeat scroll;
         }
 
         /* A sheet is dragged at with a thumb, so it says where its top

frontend/src/components/queue-panel/queue-panel.ts

@@ -2201,11 +2201,25 @@ export class QueuePanel
                             `
                             : nothing}
                     </div>
+                    <!-- **Every action here is named by aria-label**, like
+                         the close button #24 added beside them (#170). A
+                         title alone *is* a name, which is why a sweep for
+                         empty names reports these clean and why an
+                         assertion by role and name is green either way --
+                         but it is the weakest one: title is the last
+                         fallback in the accname order, so any content put
+                         inside the button later silently outranks it, and
+                         a phone has no hover to show it as a tooltip.
+
+                         The titles stay. On a desktop they are the tooltip
+                         for an icon-only control, which is a different job
+                         from naming it, and aria-label does not do it. -->
                     <div class="header-actions">
                         <button
                             class="header-action-button"
                             @click=${() => void this.handleClearQueue()}
                             ?disabled=${tracks.length === 0}
+                            aria-label="Clear queue"
                             title="Clear queue"
                         >
                             <wa-icon
@@ -2216,6 +2230,7 @@ export class QueuePanel
                             class="header-action-button add-to-playlist-button"
                             @click=${this.handleAddToPlaylist}
                             ?disabled=${tracks.length === 0}
+                            aria-label="Add queue to playlist"
                             title="Add queue to playlist"
                         >
                             <wa-icon

frontend/src/styles/sheet-scroll.css.ts

@@ -1,68 +0,0 @@
-import { css } from 'lit';
-
-/**
- * A bottom sheet whose body scrolls says so, in one rule both sheets
- * read.
- *
- * The app has two sheets — `menu-surface`'s context menu (#60) and
- * `bottom-nav`'s "More" navigation (#71) — and both are capped at 85vh,
- * because a surface covering the whole screen is a page rather than a
- * sheet. So both overflow, and both used to overflow *silently*: the
- * menu at 424x439 with eight items ending at y=470 (#207), the nav
- * sheet at the same viewport with `scrollHeight` 412 against
- * `clientHeight` 373 (#210). Where the cut lands on a row boundary the
- * sheet ends in a clean edge that reads as the end of the list.
- *
- * The mechanism is #207's and is unchanged by being shared: two
- * background layers on the scrolling box, whose *attachments* are the
- * conditionality. A cover of the sheet's own colour is painted at the
- * end of the *content* (`local`) over a shadow pinned to the box
- * (`scroll`), so the cover scrolls up over the shadow exactly when
- * there is nothing more to see. The fade is therefore absent on a sheet
- * that fits, present the moment one does not, and gone again at the end
- * of the list — with no scroll listener, no measurement and nothing
- * reaching into another component's shadow root for the scroller.
- * `background-attachment` is Chrome 4; the reference device is
- * Chrome 113.
- *
- * Three things about it are load-bearing.
- *
- * **The cover takes the sheet's own colour, from a custom property.**
- * The two sheets are different greys — the nav sheet paints
- * `--yj-bg-surface`, because it holds the sidebar and two greys in one
- * sheet is a seam across the middle of it, while the context sheet
- * paints the menus' `--yj-bg-elevated`. A shared rule that hard-coded
- * either would put that seam back on the other one, so the host sets
- * `--yj-sheet-surface` on the same box and this reads it.
- *
- * **The curve is steep because the rows under it stay live.** A scrim
- * over a menu item is that item's text surface, and this app's rule is
- * that text clears 4.5:1 on every surface it can sit on — which the
- * light ramp, whose `bgElevated` is `#e9ecef`, makes non-theoretical. A
- * row is 48px with its label centred, so 32px of scrim already down to
- * a quarter strength at 14px spends its weight on the strip below the
- * last legible label: measured at 9.9:1 on that label on the light ramp,
- * against 5.0:1 for a linear 48px draft at 0.8. The dark-ramp pixel
- * table is in `.planning/NOTES.md` (2026-08-23).
- *
- * **The box is declared a scroller here too.** `overflow-y: auto` is
- * part of the same statement rather than left to each host: a fade over
- * a box that is not the scroller is a fade that never moves, and the
- * component tier asserts the pair together for that reason.
- */
-export const sheetScrollFade = css`
-    overflow-y: auto;
-    background:
-        linear-gradient(
-                var(--yj-sheet-surface, #343a40),
-                var(--yj-sheet-surface, #343a40)
-            )
-            bottom / 100% 32px no-repeat local,
-        linear-gradient(
-                to top,
-                rgba(0, 0, 0, 0.6) 0%,
-                rgba(0, 0, 0, 0.25) 45%,
-                rgba(0, 0, 0, 0) 100%
-            )
-            bottom / 100% 32px no-repeat scroll;
-`;

frontend/test/components/bottom-nav.test.ts

@@ -243,62 +243,6 @@ describe('bottom-nav', () => {
     expect(getComputedStyle(body).overscrollBehaviorY).toBe('contain');
   });
 
-  it('says where the fold is, in the sheet\'s own colour', async () => {
-    const el = await fixture<Nav>('bottom-nav');
-    const drawer = shadow<HTMLElement & { open: boolean }>(el, 'wa-drawer');
-
-    if (!drawer) throw new Error('no drawer');
-
-    const shown = once(drawer, 'wa-after-show');
-
-    shadow<HTMLButtonElement>(el, '[data-testid="tab-more"]')?.click();
-    await shown;
-
-    const body = drawer.shadowRoot?.querySelector('[part~="body"]');
-
-    if (!body) throw new Error('no body part to scroll');
-
-    const style = getComputedStyle(body);
-
-    // #210. This list does not fit the phone — measured at 424x439,
-    // `scrollHeight` 412 against `clientHeight` 373 with the seed's
-    // eight destinations — and said nothing about it, which where the
-    // cut lands on a row boundary reads as the end of the list.
-    //
-    // The mechanism is #207's and is asserted the same way: the pair of
-    // attachments *is* the feature. A cover of the sheet's own colour
-    // painted at the end of the content (`local`) over a shadow pinned
-    // to the box (`scroll`), so the fade is absent on a sheet that
-    // fits, present the moment one does not, and gone again at the end.
-    expect(
-      style.backgroundAttachment,
-      'the cover must be local and the shadow must not',
-    ).toBe('local, scroll');
-    expect(style.backgroundPosition).toBe('50% 100%, 50% 100%');
-    expect(style.backgroundSize).toBe('100% 32px, 100% 32px');
-
-    // And the colour is the local half of a shared rule: this sheet
-    // paints the sidebar's `--yj-bg-surface` (#212529) rather than the
-    // menus' elevated grey, or the fade draws the *other* sheet's
-    // colour across the bottom of this one — which is the seam a
-    // shared fragment would otherwise reintroduce.
-    expect(style.backgroundImage).toMatch(
-      /^linear-gradient\(rgb\(33, 37, 41\), rgb\(33, 37, 41\)\)/,
-    );
-
-    // And nothing paints over it. The sidebar's host carries the same
-    // grey, which inside the sheet is a second opaque copy of the
-    // surface drawn on top of these layers -- measured at 424x439 with
-    // the rule removed, the last 32px read a flat 52,58,64 with 39px
-    // still below, so the fade was painted and covered. That is
-    // `.context-menu-panel[data-sheet]`'s transparency, one sheet over.
-    const sidebar = shadow<HTMLElement>(el, 'app-sidebar');
-
-    if (!sidebar) throw new Error('no sidebar');
-
-    expect(getComputedStyle(sidebar).backgroundColor).toBe('rgba(0, 0, 0, 0)');
-  });
-
   it('gives the sheet the whole width, which the sidebar does not take', async () => {
     const el = await fixture<Nav>('bottom-nav');
 

frontend/test/components/menu-surface.test.ts

@@ -254,15 +254,6 @@ describe('menu-surface', () => {
       // Both sit at the bottom, or the cover hides nothing.
       expect(style.backgroundPosition).toBe('50% 100%, 50% 100%');
       expect(style.backgroundSize).toBe('100% 32px, 100% 32px');
-
-      // The layers are shared with `bottom-nav`'s sheet since #210, and
-      // the colour is what each host still says for itself: this one
-      // paints the menus' `--yj-bg-elevated` (#343a40). A shared rule
-      // that hard-coded one grey would draw a seam across the other
-      // sheet, which is why the fragment reads a custom property.
-      expect(style.backgroundImage).toMatch(
-        /^linear-gradient\(rgb\(52, 58, 64\), rgb\(52, 58, 64\)\)/,
-      );
     });
 
     /**