#43095 closed defect (bug) (fixed)
Audit the usage of `aria-haspopup` in the admin menu
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.6 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | has-patch has-screenshots commit |
Focuses: | ui, accessibility | Cc: |
Description
In the admin menu (the one in the left sidebar, not the toolbar one) items that have a sub-menu have an aria-haspopup
attribute. While the intent is good, I'm not sure this is a 100% appropriate usage. We've discussed this during today's accessibility team meeting and agreed it's worth investigating.
In the previous ARIA 1.0 recommendation it was clearly stated that aria-haspopup
is meant to be used on controls that require user activation to reveal additional content. Then, in the new ARIA 1.1 recommendation, the sentence "This means that activation renders conditional content" was removed. Regardless, this doesn't necessarily change things and the new values for aria-haspopup
don't seem to suggest the current usage in WordPress is 100% correct.
What does "user activation" means?
The aria-haspopup
makes perfectly sense when users of assistive technologies land on an interactive item and need to be informed that activating the item reveals additional content.
That's not the case with the admin menu. Both when tabbing or arrowing when using a screen reader, all the menu items including the sub-menu items get revealed without requiring any special user action.
In this case, the information provided by aria-haspopup
seems pointless, if not confusing.
Only in the responsive view, the admin menu works differently and the top level items do require user activation to reveal the sub menus. Seems aria-haspopup
should be used only in the responsive view.
We should further investigate this issue and test with assistive technologies, not only screen readers but also, for example, speech recognition software.
For reference, the major screen readers announce aria-haspopup
this way, as of January 2018:
NVDA "sub menu" JAWS "has pop-up" VoiceOver "Menu pop-up"
Attachments (2)
Change History (29)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
6 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
6 years ago
This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.
6 years ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
10 months ago
#9
@
6 months ago
@joedolson Is this on your radar still for 6.5? Looks like a punt candidate given the lack of activity.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
6 months ago
#11
@
6 months ago
- Milestone changed from 6.5 to 6.6
I'm not going to get to this one for 6.5. Leaving on my radar for 6.6, though.
This ticket was mentioned in PR #6634 on WordPress/wordpress-develop by @khokansardar.
2 months ago
#12
- Keywords has-patch added
Improve wordpress admin menu accessibility for screen readers.
Trac ticket: #43095
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
2 months ago
This ticket was mentioned in Slack in #accessibility by rcreators. View the logs.
8 weeks ago
#16
@
8 weeks ago
- Keywords needs-refresh needs-patch added; has-patch needs-testing removed
Looks like added PR is not solving the issue.
Its just changing aria-haspopup="true" to aria-haspopup="menu"
I don't think that will solve the issue which is mentioned in the ticket.
@joedolson is it still on your radar for 6.6?
This ticket was mentioned in PR #6818 on WordPress/wordpress-develop by @afercia.
8 weeks ago
#17
- Keywords has-patch added; needs-refresh needs-patch removed
Trac ticket: https://core.trac.wordpress.org/ticket/43095
#18
@
8 weeks ago
https://github.com/WordPress/wordpress-develop/pull/6818 Proposes a simple approach to add aria-haspopup
only for the responsive menu. Patch submitted at WordCamp Europe 2024 Contributor Day, by contributors at the accessibility table.
#19
@
7 weeks ago
Noting @ryokuhi as a person I know should also be propped on this issue from the WCEU contributor day; if there are others, let me know!
#20
@
7 weeks ago
I'm going to attach a couple screenshots to illustrate the new behavior with the patch applied.
@
7 weeks ago
Default menu: the submenu fly-outs open automatically when tabbing and when arrowing with a screen reader. No need to announce there is a popup.
@
7 weeks ago
Responsive menu: the submenus require user activation to expand. The presence of a popup is announced as 'menu popup'.
#22
@
7 weeks ago
- Keywords reviewing added
I'll do a final review and commit when I get back on Wednesday.
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
7 weeks ago
#24
@
7 weeks ago
In reviewing this, I determined that the currentMenuItemHasPopup
function was no longer relevant, since it was predicated on the aria-haspopup attribute always being present on items. I also determined that this really needed the aria-expanded
attribute.
#25
@
7 weeks ago
- Keywords commit added; reviewing removed
Testing:
- Verify that there is a
data-ariahaspopup
attribute, noaria-haspopup
attribute, and noaria-expanded
attribute in desktop view. - Verify that the
aria-haspopup
attribute and thearia-expanded
attribute are added in responsive view. - Verify that the
aria-haspopup
attribute shows up on links with submenus that are *not* the current section. - Verify that the
aria-expanded
attribute defaults to 'false', and toggles to 'true' when expanded.
I've confirmed all of these in my testing.
@joedolson commented on PR #6818:
7 weeks ago
#27
In [r58449]
Moving to Future Release. Will need research and testing but it's worth exploring.