Add ariaLabel supports for Tab List Block

[jeryj]

Part of #73230 (comment)

What?

Add label field to the Tab List Block Inspector Sidebar so users can add an aria-label.

Why?

Allow labelling the tab list, as recommended by the APG tabs pattern guidelines for the Tabs HTML.

How?

• Adds ariaLabel block supports to the tab list block in packages/block-library/src/tab-list/block.json
• Adds a Label field to the Tab List Inspector sidebar, and outputs this value as the aria-label on the tablist element.
• Adds a fallback to "Tabbed content" if Label field is empty

Follow-up

• Somehow associate an existing element as the label for the tab list instead of using the label field.

Testing Instructions

• Add a Tabs block to a page
• Save
• View this on the frontend and make sure the tablist has the default aria-label="Tabbed content" value
• Go back to the editor
• Select the Tab List block
• Open the inspector sidebar
• Add a value to the Label field
• Save
• View this on the frontend and make sure the tablist has the aria-label value that matches the Label value you added

Testing Instructions for Keyboard

Screenshots or screencast

Before	After

Use of AI Tools

[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: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>

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

[t-hamano]

This change should be unnecessary because the Tab list block is fundamentally a static block, and the ariaLabel support is serialized into the block HTML.

In other words, I believe the expected HTML looks something like this.

<!-- wp:tab-list {"ariaLabel":"My Label"} -->
<div role="tablist" aria-label="My Label" class="wp-block-tab-list">
  <button type="button" role="tab">Tab</button><button type="button" role="tab">Tab</button>
</div>
<!-- /wp:tab-list -->

[jeryj]

I didn't realize you have to manually add the aria-label in as well, which seems like a difficult UX. I thought ariaLabel supports did more than just allow the attribute to be present :)

I'm reworking it to have a Accessible Label text field in the inspector sidebar, with a fallback to "Tabbed content" if the field is empty.

[t-hamano]

If we want to apply fallback labels on the server-side, we might be able to resolve the double parsing by WP_HTML_Tag_Processor. It would probably look something like this.

	$tag_processor = new WP_HTML_Tag_Processor( $content );
	if ( $tag_processor->next_tag( array( 'class_name' => 'wp-block-tab-list' ) ) ) {
		$tag_processor->set_attribute( 'aria-label', $aria_label );
	}

	if ( empty( $tabs_list ) ) {
		return $tag_processor->get_updated_html();
	}

	$tab_index = 0;

	while ( $tag_processor->next_tag( 'button' ) ) {
		// ...
	}
	return $tag_processor->get_updated_html();

[github-actions]

Size Change: +145 B (0%)

Total Size: 7.67 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-library/index.min.js	333 kB	+145 B (+0.04%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in 1943199.
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/28881435634
📝 Reported issues:

• [Flaky Test] activate block theme when live previewing in edit mode #77712 in /test/e2e/specs/site-editor/activate-theme.spec.js
• [Flaky Test] three users concurrently edit a large post with diverse blocks (RTC WebSocket) #79926 in /test/e2e/specs/editor/collaboration/collaboration-stress.spec.ts

[Mamaduka]

Do we need this test? Seems to be testing that serialize works, which isn't the responsibility of the block's unit test. Plus, the PHP unit test is already testing the output.

[jeryj]

You're right - it's unnecessary.

[Mamaduka]

Let's make this generic to Tabs. The tab list is always rendered as part of the set.

[jeryj]

Moved to Tabs instead of Tab List. I agree that's a better place.

[t-hamano]

As far as I know, there are two ways to apply the default label. The current PR adopts the first approach. I don't have a strong opinion, but which approach do you think is better?

1. Fall back to the default label on the server side

The default label is not serialized. It is dynamically localized based on the site's locale.

2. Add the default label when inserting the block

Create a block variation to apply the default label upon insertion. Take the Search block as an example; the label is localized and serialized the moment the block is inserted.

[t-hamano]

If we want to apply fallback labels on the server-side, we might be able to resolve the double parsing by WP_HTML_Tag_Processor. It would probably look something like this.

	$tag_processor = new WP_HTML_Tag_Processor( $content );
	if ( $tag_processor->next_tag( array( 'class_name' => 'wp-block-tab-list' ) ) ) {
		$tag_processor->set_attribute( 'aria-label', $aria_label );
	}

	if ( empty( $tabs_list ) ) {
		return $tag_processor->get_updated_html();
	}

	$tab_index = 0;

	while ( $tag_processor->next_tag( 'button' ) ) {
		// ...
	}
	return $tag_processor->get_updated_html();

[jeryj]

@t-hamano

As far as I know, there are two ways to apply the default label. The current PR adopts the first approach. I don't have a strong opinion, but which approach do you think is better?

I think we'd need to have the if-empty aria-label output fallback on the server render regardless (if someone deletes the field), so I think I prefer "Fall back to the default label on the server side." Also, if we put "Tabbed content" within the Label field, I would worry people will think that's a good label and not try to fill it out with their own content.

[jeryj]

@t-hamano

If we want to apply fallback labels on the server-side, we might be able to resolve the double parsing by WP_HTML_Tag_Processor. It would probably look something like this.

Updated! Good catch.

[t-hamano]

LGTM!