WordPress 7.1 introduces an accessible tooltip mechanism across Core and the editor. Translation can make a short English command much longer, change shortcut order, increase overlay width, and expose clipping inside sidebars or modals. Plugins can also combine title, aria-label, description, and tooltip text so a screen reader announces the same command twice. Visual and spoken output need to be tested together.
Use this for multilingual WordPress sites, plugin teams, agencies, accessibility reviewers, localization teams, and custom admin interfaces with icon-only controls.
Quick answer
Select the longest supported translations, then test each important control at 100, 200, and 400 percent zoom with mouse, keyboard, narrow viewport, high contrast, and a screen reader. Record role, accessible name, tooltip, shortcut, overlay position, clipping, focus, and spoken output. The command should be named once without hover, while the tooltip adds useful visible context and remains inside the viewport.
What to check first
- Inventory Core, plugin, builder, list-table, modal, settings, and block controls that use tooltips or title attributes.
- Choose locales with materially longer labels and include translated keyboard shortcuts.
- Test pointer, keyboard focus, Escape, narrow viewport, 200 and 400 percent zoom, high contrast, and screen reader speech.
- Inspect role, name, description, duplicated IDs, overlay ownership, stacking layer, wrapping, and viewport clipping.
- Repeat after dynamic route changes, modal opens, block insertion, AJAX updates, and disabled states.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| English toolbar | 100 percent zoom | One name and readable context |
| German sidebar | 200 percent zoom | Wraps without covering target |
| French modal | 400 percent zoom | Overlay stays reachable |
| RTL locale | Keyboard and screen reader | Direction and shortcut are correct |
Decision rule
Approve the control when its command is understandable without hover, spoken once, and visually readable at supported zoom without covering the target or leaving the active viewport.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Give each control one stable role and concise accessible name.
- Remove duplicate title, label, or description sources after inspecting the accessibility tree.
- Allow wrapping and constrain the overlay to the current viewport and modal layer.
- Repair keyboard dismissal, focus behavior, dynamic initialization, and RTL placement.
- Retest supported locales and zoom levels before the WordPress 7.1 rollout.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Give each control one stable role and concise accessible name. | Inventory Core, plugin, builder, list-table, modal, settings, and block controls that use tooltips or title attributes. | Every tested control has one correct accessible name. |
| Remove duplicate title, label, or description sources after inspecting the accessibility tree. | Choose locales with materially longer labels and include translated keyboard shortcuts. | Long translated tooltips wrap and stay inside the active viewport. |
| Allow wrapping and constrain the overlay to the current viewport and modal layer. | Test pointer, keyboard focus, Escape, narrow viewport, 200 and 400 percent zoom, high contrast, and screen reader speech. | Keyboard and screen reader users can reveal, understand, and dismiss context. |
| Repair keyboard dismissal, focus behavior, dynamic initialization, and RTL placement. | Inspect role, name, description, duplicated IDs, overlay ownership, stacking layer, wrapping, and viewport clipping. | Dynamic controls initialize one tooltip and preserve focus. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
locale,control,role,name,tooltip,shortcut,zoom,screen_reader,clipping,result
en_US,save,button,Save,Save,Ctrl+S,100,Save,none,pass
de_DE,insert,button,Block einfugen,Block einfugen,Alt+B,200,duplicate,right,fix
ar,settings,button,Settings,Translated label,,400,correct,modal,inspect
Production verification checklist
- Every tested control has one correct accessible name.
- Long translated tooltips wrap and stay inside the active viewport.
- Keyboard and screen reader users can reveal, understand, and dismiss context.
- Dynamic controls initialize one tooltip and preserve focus.
Why this usually happens
- Translated strings can exceed the overlay assumptions used for English labels.
- Portals can render under a modal or outside a clipped admin container.
- Multiple labeling attributes can turn one helpful tooltip into duplicated speech.
Field notes
- Test the actual longest strings, not placeholder lorem ipsum.
- Do not place required instructions only inside a tooltip.
- Keep screenshots and screen reader transcripts tied to locale and browser versions.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a successful request, quiet log, or correct screenshot as proof that the complete user outcome is correct.
- Do not leave debug logs, test records, broad credentials, temporary roles, or browser overrides active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, roles, data volume, cache, browser behavior, and integrations. Finish with one controlled production fixture when the result depends on the real CDN, email provider, worker clock, crawler response, or browser storage.
What evidence should be retained?
Keep exact versions, stable IDs, UTC timestamps, sanitized requests or logs, expected result, actual result, decision, and final verification. Redact customer data, cookies, secrets, order keys, and full advertising identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, accessibility, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, repair a translated admin tooltip.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references