![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 6 years ago
Last modified 42 hours ago
#50921 accepted task (blessed)
Consider adding tooltips for metabox order buttons
| Reported by: | ibachal | Owned by: | joedolson |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.1 |
| Component: | Editor | Version: | 5.5 |
| Severity: | normal | Keywords: | has-screenshots tooltips has-patch has-unit-tests |
| Cc: | Focuses: | ui, accessibility |
Description
It's obvious but I feel the title attribute for new metabox indicators will be helpful for some users to know what will these indicator buttons do by browser's tooltip.
Attachments (1)
Change History (27)
This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.
6 years ago
#2
follow-up:
↓ 3
@
6 years ago
- Milestone Awaiting Review → Future Release
- Owner set to
- Status new → accepted
This ticket was mentioned in Slack in #hosting-community by javier. View the logs.
5 years ago
#6
@
14 months ago
- Summary Consider adding title attributes for metabox order buttons → Consider adding tooltips for metabox order buttons
#8
@
3 months ago
- Milestone Future Release → 7.1
With CSS anchor positioning having meet the basic criteria for WordPress browser support, let's go ahead and work on a new patch to get this resolved using native tooltips.
This ticket was mentioned in PR #11945 on WordPress/wordpress-develop by @khokansardar.
2 months ago
#9
- Keywords has-patch has-unit-tests added
## Summary
- Adds visible tooltips to the meta box order up/down buttons in the post editor.
- Uses CSS anchor positioning with an absolute-position fallback, shown on hover and keyboard focus (
:focus-visible). - Avoids
titleattributes in favor of accessible, supplemental visual hints while preserving existingscreen-reader-textandaria-describedbybehavior.
## Why
Sighted users had no visual hint for what the meta box order indicator buttons do. Core has moved away from title attributes for accessibility reasons (#24766). Per recent committer feedback on the ticket, this uses native CSS tooltips now that CSS anchor positioning meets WordPress browser support criteria.
## Changes
src/wp-admin/includes/template.php— Outputpostbox-order-tooltipspans inside order buttons.src/wp-admin/css/common.css— Tooltip styling and anchor-positioning support.tests/phpunit/tests/admin/includesTemplate.php— Assert tooltip markup is rendered bydo_meta_boxes().
Props ibachal. Fixes #50921.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
3 weeks ago
#11
@
7 days ago
As 7.1 Beta1 is approaching, I would like to check the status of this ticket. My understanding is that this ticket depends on #51006, and the mechanism using native tooltips needs to be implemented in the core first.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
5 days ago
This ticket was mentioned in PR #12528 on WordPress/wordpress-develop by @joedolson.
5 days ago
#13
This PR wraps the existing buttons in markup for existing styles and scripts, but doesn't change the function signature to support adding all of the custom markup.
It may be desirable to add a modified path to inject this markup into existing patterns.
This could be done similar to wp_get_admin_notice(), which has a bunch of parsers for attributes, but I think this isn't appropriate here. Open to ideas, but I was thinking of something that accepted existing button markup, used the HTML API to inject the additional button markup, then accepted a string for tooltip text.
I don't think this is needed for toggletips, but for existing markup needing tooltips, it may be helpful.
Trac ticket: https://core.trac.wordpress.org/ticket/50921
## Use of AI Tools
None
#14
@
5 days ago
New PR applies the markup expectations for wp_get_tooltip() to the buttons used for metabox handling. Updates the names so that the visible name shown by tooltips matches the accessible name of the control.
@joedolson commented on PR #12528:
4 days ago
#15
That's an interesting case, and bears some considering. As a non-operable but focusable control, it should be different in some way, but I'm not sure that's the best option.
@wildworks commented on PR #12528:
4 days ago
#16
This could be done similar to
wp_get_admin_notice(), which has a bunch of parsers for attributes, but I think this isn't appropriate here. Open to ideas, but I was thinking of something that accepted existing button markup, used the HTML API to inject the additional button markup, then accepted a string for tooltip text.
I think this is a good idea, but if we are to ship it, we should address it during the 7.1 Beta release cycle at the very least. Once a function is exposed, it becomes increasingly difficult to change its parameters. If we are to expose an API for tooltips in 7.1, I believe we need to consider all scenarios now and make the API robust.
This ticket was mentioned in Slack in #core by adrianduffell. View the logs.
4 days ago
#18
@
4 days ago
- Milestone 7.1 → Future Release
With the 7.1 beta being released in a few hours, I will punt this as it looks like there is still some action left on the PR. This would be good to return to early in the 7.2 cycle.
#19
@
4 days ago
- Milestone Future Release → 7.1
- Type enhancement → defect (bug)
Re-defining this as a bug to consider this implementation as an improvement to the accessibility enhancement added in #51006.
@peterwilsoncc commented on PR #12528:
4 days ago
#21
Even greyed out, I find it a little confusing to get the tool tip on the up arrow. Maybe that's a different bug and the arrow shouldn't be displayed?
A difference I am seeing is that unavailable up arrow has a hover effect on this branch, whereas there is none on trunk.
@joedolson commented on PR #12528:
3 days ago
#22
I wouldn't expect to see it on trunk; this code isn't present on trunk.
In my opinion, sighted users should get more or less the same information that non-sighted users get. Non-sighted users get focus on the control, the full name of the control, and the information that it's disabled. I'm not sure whether it makes sense to just eliminate the tooltip for disabled controls - there could still be scenarios where it's necessary to know which control something is.
@afercia Any opinion here?
@afercia commented on PR #12528:
3 days ago
#23
I'm currently on mobile and looking into the code isn't an option for me now. However I'd like to stress a couple things.
First: the mover buttons shouldn't get disabled with a disabled attribute. Instead, they should use aria-disabled and be noop-ed. Otherwise, when keyboard users reach the first or last position, they will face a focus loss. Gutenberg uses this pattern in many places, to avoid focus losses.
Using aria-disabled also helps discoverability for non-sighted users. And given these buttons would be focusable, I think they should show the tooltip. Again, it's the same pattern used in Gutenberg.
@joedolson commented on PR #12528:
3 days ago
#24
@afercia The mover buttons don't get the disabled attribute; nothing has changed there, however, they do get aria-disabled, as their functionality is not relevant.
What you said essentially agrees with me; any control that is focusable should have a valid tooltip to explain it. The problem is in the question of how to indicate via the tooltip that it's a disabled control, and whether we need to do so.
I believe that Gutenberg does not have any indication in the tooltip that a control is not functional; they're the same in all cases. In that case, the most consistent option is to use the same expectation in core, which means removing the visual differences for non-functional controls and leaving it the same as other controls.
@afercia commented on PR #12528:
2 days ago
#25
I agree we should use the same expectation and pattern used in Gutenberg.
We've largely expunged title attributes from core, due to their lack of accessibility. Adding an accessible tooltip for these controls is a viable option to consider, however.
It will depend on developing a core method to implement accessible tooltips, however, so this ticket isn't fixable until there are accessible tooltips in core.