yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

The queue header's two older actions are named only by title #170

New Issue
Closed
opened 2026-08-21 02:16:33 +00:00 by logan · 2 comments
logan commented 2026-08-21 02:16:33 +00:00
Collaborator
Copy Link
Copy Source

Report

queue-panel's two header actions — Clear queue and Add queue to
playlist — are named by a title attribute and nothing else. The close
button beside them, added by #24, uses aria-label.

<button class="header-action-button" title="Clear queue">
<button class="header-action-button add-to-playlist-button" title="Add queue to playlist">
<button class="header-action-button" aria-label="Close queue" data-testid="queue-close">

Findings

  • title is an accname fallback, so these are not nameless and
    getFullAXTree reports them clean. This is the weak-name case
    a11y.26 describes: "a sweep for empty names cannot see a weak
    one", and the same reasoning that made the search box's placeholder
    insufficient.
  • It is weak in three specific ways rather than as a matter of taste.
    title is the last fallback in the accname order, so any content
    added inside the button silently outranks it. It is not exposed at all
    on a touch device — there is no hover — which is exactly the surface
    #55 just turned into a full screen. And it doubles as a tooltip, so
    the name and the tooltip cannot be worded differently even where they
    should be.
  • No spec asserts either name. queue-overlay.spec.ts asserts the close
    button's, by role and name, because #24 added it; the two older
    buttons predate that habit.
  • Found while measuring #55; not fixed there because it is not that
    issue's surface and a rename wants its own assertion.

Direction

aria-label on both, matching the close button, and a getByRole
assertion for each in queue-overlay.spec.ts — the file that already
makes exactly that assertion about the third button in the same row.

**Report** `queue-panel`'s two header actions — Clear queue and Add queue to playlist — are named by a `title` attribute and nothing else. The close button beside them, added by #24, uses `aria-label`. ``` <button class="header-action-button" title="Clear queue"> <button class="header-action-button add-to-playlist-button" title="Add queue to playlist"> <button class="header-action-button" aria-label="Close queue" data-testid="queue-close"> ``` **Findings** - `title` *is* an accname fallback, so these are not nameless and `getFullAXTree` reports them clean. This is the weak-name case `a11y.26` describes: "a sweep for *empty* names cannot see a *weak* one", and the same reasoning that made the search box's `placeholder` insufficient. - It is weak in three specific ways rather than as a matter of taste. `title` is the last fallback in the accname order, so any content added inside the button silently outranks it. It is not exposed at all on a touch device — there is no hover — which is exactly the surface #55 just turned into a full screen. And it doubles as a tooltip, so the name and the tooltip cannot be worded differently even where they should be. - No spec asserts either name. `queue-overlay.spec.ts` asserts the close button's, by role and name, because #24 added it; the two older buttons predate that habit. - Found while measuring #55; not fixed there because it is not that issue's surface and a rename wants its own assertion. **Direction** `aria-label` on both, matching the close button, and a `getByRole` assertion for each in `queue-overlay.spec.ts` — the file that already makes exactly that assertion about the third button in the same row.
logan self-assigned this 2026-08-26 09:33:13 +00:00
logan added the
Status
In Progress
 label 2026-08-26 09:33:13 +00:00
logan commented 2026-08-26 09:33:13 +00:00
Author
Collaborator
Copy Link
Copy Source

Picking this up on fix/170-queue-header-action-names.

Approach is the issue's own Direction: aria-label on both header
actions in queue-panel, matching the close button #24 added beside
them, plus a getByRole assertion for each in
e2e/specs/queue-overlay.spec.ts — the file that already makes that
assertion about the third button in the same row.

The title attributes stay. They are the desktop tooltip, and removing
them would take away an affordance the issue does not ask about;
aria-label outranks title in the accname order, so the two cannot
disagree.

One thing I will measure before writing the spec rather than assume:
title is itself an accname fallback, so a bare getByRole('button', { name: 'Clear queue' }) may well be green on the build before the
fix. If it is, the spec says so and asserts the mechanism beside it —
a spec named for the behaviour that measures the plumbing is the trap
this repo has been caught by three times.

Picking this up on `fix/170-queue-header-action-names`. Approach is the issue's own Direction: `aria-label` on both header actions in `queue-panel`, matching the close button #24 added beside them, plus a `getByRole` assertion for each in `e2e/specs/queue-overlay.spec.ts` — the file that already makes that assertion about the third button in the same row. The `title` attributes stay. They are the desktop tooltip, and removing them would take away an affordance the issue does not ask about; `aria-label` outranks `title` in the accname order, so the two cannot disagree. One thing I will measure before writing the spec rather than assume: `title` is itself an accname fallback, so a bare `getByRole('button', { name: 'Clear queue' })` may well be green on the build *before* the fix. If it is, the spec says so and asserts the mechanism beside it — a spec named for the behaviour that measures the plumbing is the trap this repo has been caught by three times.
logan commented 2026-08-26 09:54:17 +00:00
Author
Collaborator
Copy Link
Copy Source

PR: #223 — CI green
(run 18004, check and e2e, the WebKit step included).

Both header actions carry aria-label now, matching the close button.
The titles stay: on a desktop they are also the tooltip for an
icon-only control, which is a different job from naming it and one
aria-label does not do.

One finding worth recording on the issue itself, because it changes
what the Direction asks for. A bare getByRole('button', { name: 'Clear queue' }) in queue-overlay.spec.ts is green on the broken
build — measured against the running pre-fix app, before editing
anything:

getByRole button "Clear queue"           -> 1
getByRole button "Add queue to playlist" -> 1

title is an accname fallback, so this is a11y.26's "a sweep for
empty names cannot see a weak one" one rung lower, now defeating the
spec as well as the sweep. So the spec asserts the property as what
it really is — the name is not the tooltip: it strips the title
attributes and asks again, which was 0 and 0 on main and is 1 and 1
on the branch. Both rows were run rather than reasoned about (component
change stashed, frontend rebuilt, app restarted, committed spec run).

Not merging; leaving Status/In Progress on.

PR: https://git.ljones.me/yonlu/yellowjacket/pulls/223 — CI green (run 18004, `check` and `e2e`, the WebKit step included). Both header actions carry `aria-label` now, matching the close button. The `title`s stay: on a desktop they are also the tooltip for an icon-only control, which is a different job from naming it and one `aria-label` does not do. **One finding worth recording on the issue itself, because it changes what the Direction asks for.** A bare `getByRole('button', { name: 'Clear queue' })` in `queue-overlay.spec.ts` is green on the *broken* build — measured against the running pre-fix app, before editing anything: ``` getByRole button "Clear queue" -> 1 getByRole button "Add queue to playlist" -> 1 ``` `title` is an accname fallback, so this is `a11y.26`'s "a sweep for empty names cannot see a weak one" one rung lower, now defeating the *spec* as well as the sweep. So the spec asserts the property as what it really is — the name is not the tooltip: it strips the `title` attributes and asks again, which was 0 and 0 on `main` and is 1 and 1 on the branch. Both rows were run rather than reasoned about (component change stashed, frontend rebuilt, app restarted, committed spec run). Not merging; leaving `Status/In Progress` on.
logan closed this issue 2026-08-26 16:03:02 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-26 16:03:21 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Queue Kind/Bug Platform/Android Platform/Desktop
Priority
Low
4
Reviewed
Confirmed
1
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees logan
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#170