Tabs block: Home and End keys do not move focus within the tab list

[courtneyr-dev]

Description

Following up on #75402, which fixed the arrow-key navigation, roving tabindex, and button-element issues in the Tabs block. Those all behave correctly now. One key pair from the W3C APG tabs pattern is still unimplemented: Home and End.

handleTabKeyDown in packages/block-library/src/tabs/view.js handles only the two arrow keys:

handleTabKeyDown: withSyncEvent( ( event ) => {
    const { tabIndex } = state;
    if ( tabIndex === null ) return;
    if ( event.key === 'ArrowRight' ) { event.preventDefault(); actions.moveFocus( tabIndex + 1 ); }
    else if ( event.key === 'ArrowLeft' ) { event.preventDefault(); actions.moveFocus( tabIndex - 1 ); }
} ),

Per the APG tabs pattern, Home should move focus to the first tab and End to the last. Both are listed as optional there, so this may be better treated as an enhancement than a bug — happy for it to be relabelled.

Measured on the front end with a three-tab block (Alpha / Bravo / Charlie), using real keyboard input:

Key	Expected	Actual
ArrowRight from Bravo	focus Charlie	focus Charlie ✅
ArrowLeft from Bravo	focus Alpha	focus Alpha ✅
Home	focus Alpha	focus unchanged ❌
End	focus Charlie	focus unchanged ❌

Everything else from #75402 verified as working: arrow navigation moves focus without auto-activating (manual activation), roving tabindex is correct (0 on the active tab, -1 on the others), and Enter/Space activate via native button semantics since the handler does not preventDefault() those keys.

Noting that @t-hamano closed #75402 with "If there are any other points that need to be addressed, please reopen this issue or submit a new one" — filing separately rather than reopening, since the original scope is genuinely resolved. Related tracking issue: #73230.

Step-by-step reproduction instructions

1. Add a Tabs block to a post with three tabs, labelled Alpha, Bravo and Charlie.
2. Publish and view the post on the front end.
3. Click the "Bravo" tab so focus is on it.
4. Press ArrowRight. Focus moves to Charlie, as expected.
5. Press Home. Expected: focus moves to Alpha. Actual: focus stays where it is.
6. Press End. Expected: focus moves to Charlie. Actual: focus stays where it is.

Tested on WordPress 7.1-beta4 with the bundled block, PHP 7.4, front end. Verified with real keyboard input rather than synthetic events, since synthetic KeyboardEvent dispatch does not reproduce native button activation reliably.

Screenshots, screen recording, code snippet

Environment info

• WordPress 7.1-beta4 (bundled Tabs block; the Gutenberg plugin is not installed)
• Theme: Twenty Twenty-Five
• PHP 7.4.33, multisite (subdirectory). Also spot-checked on a PHP 8.2 single-site install.
• Browser: Chrome (desktop, macOS)
• Verified with all other plugins deactivated for the final run.

Note on method: this was confirmed with real keyboard input. Synthetic KeyboardEvent dispatch is not a reliable substitute here, since it does not trigger a native button's default activation, and the Interactivity API updates asynchronously — assertions need a short wait after each key press or they read stale state.

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[t-hamano]

This might be a bug worth fixing in the 7.1 release.