Playlist: Add aria-label to prevent placeholder as label

[jeryj]

What?

Gives the Playlist Track block's inline title and artist fields their own aria-label, so they are no longer announced as "Add title" and "Add artist" even when there is a value set for those textareas.

Why?

RichText falls back to using placeholder as the field's accessible name:

aria-label={ bindingsLabel || props[ 'aria-label' ] || placeholder }

That fallback is not conditional on the field being empty, so a Playlist Track that already has a title is still announced as "Add title", and one that already has an artist as "Add artist".

How?

Adds aria-label to the two PlainText fields.

Testing Instructions

1. Insert a Playlist block and add a track that has a title and an artist
2. Inspect the track's title field in dev tools. It should be aria-label="Track title", and the artist field aria-label="Track artist" — previously "Add title" / "Add artist".
3. With a screen reader running, move focus into the title field of a track that already has a title. It should be announced as "Track title" followed by the field's content, rather than "Add title".
4. Add an empty track and confirm the visible "Add title" and "Add artist" placeholders still render as before.

Testing Instructions for Keyboard

No changes to keyboard behavior.

Screenshots or screencast

Not applicable — there is no visual change.

Use of AI Tools

Claude Code was used to investigate the cause, research the history and prior art (#1659, #5981, #26582, #33465), and draft this description.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jeryj <jeryj@git.wordpress.org>
Co-authored-by: scruffian <scruffian@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: +18 B (0%)

Total Size: 7.73 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-library/index.min.js	358 kB	+18 B (+0.01%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in 8cd7c21.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/32011152775
📝 Reported tests:

two users concurrently move list items (RTC WebSocket) in /test/e2e/specs/editor/collaboration/collaboration-stress.spec.ts, passed after 1 failed attempt.

TimeoutError: locator.click: Timeout 10000ms exceeded.
Call log:
  - waiting for locator('role=toolbar[name="Block tools"i]').locator('role=button[name="Move up"i]')
    - locator resolved to <button id=":rq:" type="button" tabindex="-1" aria-label="Move up" data-toolbar-item="true" aria-describedby="block-editor-block-mover-button__description-0" class="components-button block-editor-block-mover-button is-up-button is-next-40px-default-size has-icon">…</button>
  - attempting click action
    - waiting for element to be visible, enabled and stable
    - element is visible, enabled and stable
    - scrolling into view if needed
    - done scrolling
  - element was detached from the DOM, retrying

    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/collaboration/collaboration-stress.spec.ts:623:7
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/collaboration/collaboration-stress.spec.ts:602:3

[scruffian]

LGTM

Test needs fixing

[scruffian]

This changes the help text on the button itself. I've updated it and also updated the test. Another review required...

[scruffian]

I'm happy with this, but I'd appreciate another pair of eyes on my change.

[jeryj]

@scruffian

This changes the help text on the button itself.

I don't think that's true? There was no help text on the button. The button was made up of its contents, so the button would be announced as ${track number} ${track title} ${track artist} Duration: ${duration} Play. The change you added turns it into Play ${track number} ${track title}. Can you explain more of what you mean? Maybe I'm missing something.

Also, maybe it should not even say "Play" on the editor side. You can't click the track button to play the song. Playing only happens from clicking the top level Playlist block Play button. It's not like the frontend player where clicking a track plays it e. The player will load whatever song is currently selected though, so if you press play, then select a new track, that track loads and begins playing.

[scruffian]

Before this change, the button’s accessible name came from its visible child text, so it included the track title. After the new labels, those child spans contributed their labels instead of their values. Before the change, the playlist track button’s accessible name was roughly:

A bright abstract track image Song One The Artist 3:45 Play

After the original change added aria-label to the editable spans, it became:

A bright abstract track image Track title Track artist Play

That’s why name: /Song One/ stopped matching.

[scruffian]

Also, maybe it should not even say "Play" on the editor side. You can't click the track button to play the song.

You can, once a track is already playing.

[scruffian]

Sorry I looked at this some more and the problem was in the mock itself, so I have removed it. The test should pass now.

[afercia]

The problem with this approach is that it introduces a mismatch between:

• what users see (the placeholder used as visual label)
• the actual accessible name of the two editable fields

These placeholders are visible when the editable textboxes are empty:

This creates a barrier for some users. For example:

• Voice control users will not be able to issue a voice command, as the actual accessible name isn't visually exposed anywhere.
• Sighted screen reader users will be pretty confused, as they see 'Add title' but the screen reader will announce 'Track title'.

The root cause is that placeholders should not be used as a replacement for labels. They are not meant for that purpose. The accessibility team warned several times to avoid to use placeholders as replacement for labels but this keeps happening mostly because of design input.

I guess there are many other similar cases in the editor but we should really avoid to introduce new ones.

Can you please consider to revert this change?
Or, at least, make the visible labeling erroneously conveyed by the placeholder match the actual label?
If the strings 'Add title' and 'Add artist' are confusing, they should be changed in the first place and I don't mind that 'Add' is a pattern in the editor. Introducing such a mismatch is less than ideal.

[jeryj]

@afercia - Thanks for the history and context.

Or, at least, make the visible labeling erroneously conveyed by the placeholder match the actual label?

Does this mean changing the visible "Add Track" and "Add Artist" to be the aria-label values, "Track Title" and "Track Artists" instead?

I know this diverges from things like the Button Block that uses "Add text" as the visible placeholder even though the aria-label is "Button text":

In the playlist instance, I am fine with making the placeholder text say "Track Title" and "Track Artist." I would be surprised if people were confused by those as placeholder values. I know placeholder values should be actual examples of appropriate input, but I think that would be more confusing with the current design.

[jeryj]

@afercia - if my interpretation of your comment was correct, then I have a PR ready: #81762