Make WordPress Core

Opened 7 years ago

Closed 4 weeks ago

Last modified 4 weeks ago

#43095 closed defect (bug) (fixed)

Audit the usage of `aria-haspopup` in the admin menu

Reported by: afercia's profile afercia Owned by: joedolson's profile joedolson
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)

default.png (511.1 KB) - added by afercia 5 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.
responsive.png (678.4 KB) - added by afercia 5 weeks ago.
Responsive menu: the submenus require user activation to expand. The presence of a popup is announced as 'menu popup'.

Download all attachments as: .zip

Change History (29)

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 afercia. View the logs.


6 years ago

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


6 years ago

#5 @afercia
6 years ago

  • Milestone changed from Awaiting Review to Future Release

Moving to Future Release. Will need research and testing but it's worth exploring.

#6 @joedolson
13 months ago

  • Owner set to joedolson
  • Status changed from new to accepted

#7 @joedolson
9 months ago

  • Milestone changed from Future Release to 6.5

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


9 months ago

#9 @swissspidy
5 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.


5 months ago

#11 @joedolson
5 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.


8 weeks 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.


6 weeks ago

#14 @hmbashar
6 weeks ago

  • Keywords needs-testing added

This ticket was mentioned in Slack in #accessibility by rcreators. View the logs.


6 weeks ago

#16 @rcreators
6 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.


5 weeks ago
#17

  • Keywords has-patch added; needs-refresh needs-patch removed

#18 @afercia
5 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 @joedolson
5 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 @afercia
5 weeks ago

I'm going to attach a couple screenshots to illustrate the new behavior with the patch applied.

@afercia
5 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.

@afercia
5 weeks ago

Responsive menu: the submenus require user activation to expand. The presence of a popup is announced as 'menu popup'.

#21 @afercia
5 weeks ago

  • Keywords has-screenshots added

#22 @joedolson
5 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.


5 weeks ago

#24 @joedolson
4 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 @joedolson
4 weeks ago

  • Keywords commit added; reviewing removed

Testing:

  • Verify that there is a data-ariahaspopup attribute, no aria-haspopup attribute, and no aria-expanded attribute in desktop view.
  • Verify that the aria-haspopup attribute and the aria-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.

#26 @joedolson
4 weeks ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 58449:

Administration: A11y: Use aria-haspopup only if item has popup behavior.

Update behavior of admin menu so that the aria-haspopup attribute is only applied in responsive mode, when there is a popup behavior present. Add aria-expanded attributes to report current popup state.

Props afercia, khokansardar, ryokuhi, joedolson.
Fixes #43095.

@joedolson commented on PR #6818:


4 weeks ago
#27

In [r58449]

Note: See TracTickets for help on using tickets.