WordPress 7.1 Beta 1 introduces a Tabs block for organizing content into tabbed panels. A production test should cover arrow keys, Tab and Shift+Tab, Home and End where supported, focus visibility, roles, labels, selected state, panel relationships, nested links and forms, URL fragments, browser history, print, translation, responsive layouts, and behavior without JavaScript.
Use this for service comparisons, product details, documentation, pricing, support guides, and any WordPress page where important content is placed inside the new Tabs block.
Quick answer
WordPress 7.1 Tabs Block Keyboard, ARIA, and Deep-Link Test should be handled with a narrow evidence-first workflow: build a demanding fixture, trace keyboard focus, inspect aria relationships, then verify the result before making broader changes.
What to check first
- Build a controlled Tabs block with short and long labels, three panels, nested links, a form control, headings, images, duplicate labels, and enough content to scroll.
- Navigate from before the component through every tab and nested control using keyboard only, recording key, focus target, visible focus, selected tab, and visible panel.
- Inspect role, aria-selected, aria-controls, labelled-by relationships, IDs, hidden state, heading order, screen reader announcement, and behavior after duplicating or reordering tabs.
- Open a panel by URL fragment if supported, then test refresh, copy link, browser back and forward, same-page links, analytics page views, and server-rendered output.
- Test mobile reflow, zoom, long translations, print output, JavaScript disabled, cache, and a classic theme with inherited button styles.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build a demanding fixture | Build a controlled Tabs block with short and long labels, three panels, nested links, a form control, headings, images, duplicate labels, and enough content to scroll. | Keyboard users can enter, choose, leave, and return to the tab group without a trap. |
| Trace keyboard focus | Navigate from before the component through every tab and nested control using keyboard only, recording key, focus target, visible focus, selected tab, and visible panel. | Roles, IDs, aria-selected, controls, labels, hidden state, and screen reader announcements match the visible panel. |
| Inspect ARIA relationships | Inspect role, aria-selected, aria-controls, labelled-by relationships, IDs, hidden state, heading order, screen reader announcement, and behavior after duplicating or reordering tabs. | Deep links, refresh, back and forward navigation, analytics, and copied URLs follow the documented behavior. |
| Test URL and history | Open a panel by URL fragment if supported, then test refresh, copy link, browser back and forward, same-page links, analytics page views, and server-rendered output. | Long labels, zoom, mobile, translation, print, no script, duplication, and reordering preserve access to every panel. |
Why this usually happens
- Visual tab changes can occur without moving focus or updating accessible state.
- Duplicate or reordered tab labels can produce broken or repeated IDs.
- Nested controls can become unreachable when arrow-key handling captures the wrong event.
- Important content may disappear from print, no-script, search, or deep-link workflows when hidden panels are handled poorly.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
keyboard_case:
start: link_before_tabs
key: Tab
expected_focus: active_tab
next_key: ArrowRight
expected_selected: tab_2
expected_panel: panel_2
nested_control_reachable: true
focus_visible: true
browser_history: documented
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Build a demanding fixture
- Trace keyboard focus
- Inspect ARIA relationships
- Test URL and history
- Verify fallback and print
Decision rule
Use Tabs only when every user can reach and understand the content, focus and selected state stay synchronized, nested controls remain usable, and essential information has an approved server, print, and no-script behavior. Use headings or an accordion when the tab interaction adds no value.
What to tell the client or owner
Share the WordPress build, theme, block markup, tab and panel count, keyboard trace, ARIA snapshot, screen reader and browser, fragment behavior, history result, mobile and zoom result, print output, and no-script output.
Production verification checklist
- Keyboard users can enter, choose, leave, and return to the tab group without a trap.
- Roles, IDs, aria-selected, controls, labels, hidden state, and screen reader announcements match the visible panel.
- Deep links, refresh, back and forward navigation, analytics, and copied URLs follow the documented behavior.
- Long labels, zoom, mobile, translation, print, no script, duplication, and reordering preserve access to every panel.
Mistakes to avoid
- Do not test only mouse clicks in the editor preview.
- Do not put the only critical instruction inside a panel that has no fallback.
- Do not add custom arrow-key JavaScript before understanding the block's built-in behavior.
- Do not assume visually hidden content is available to search, print, or assistive technology.
Questions teams ask during testing
Should changing tabs update the URL?
Only if the product requirements include shareable or restorable panel state. If fragments are used, test history, duplicate IDs, scrolling, analytics, and server output rather than adding them casually.
Are tabs better than accordions on mobile?
Not always. Choose based on content length, comparison needs, navigation, accessibility, and fallback behavior. Test the real labels and panels at zoomed and narrow widths.
When HandL WP should help
HandL WP should help when tab focus disappears, panels are announced incorrectly, deep links break, or essential content vanishes outside the interactive view. We can test the component with real content and fix theme or plugin conflicts.
If this is active on a production site, test WordPress Tabs accessibility.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Run the companion Playlist media acceptance test
For the other stable WordPress 7.1 content block, use the Playlist block waveform, CORS, and performance test across offloaded audio, byte ranges, keyboard access, transcripts, mobile data, caches, and failure fallback.
Helpful references