Make WordPress Core

Opened 4 years ago

Last modified 3 years ago

#50273 assigned defect (bug)

Media modal uses incorrect 'checkbox' role for list items

Reported by: talldanwp's profile talldanwp Owned by: joedolson's profile joedolson
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: accessibility Cc:


The media modal uses the role of 'checkbox' on list items (<li>) when selecting media (e.g. to add to a gallery.)

The specification of a role here is overriding the list item element's implicit listitem role.

The list item elements in this case should ideally have no role specified. The element with a checkbox role should be a child element of the list item and other associated attributes like aria-checked should also be moved to that element.

For context, this issue was caught by the automated Axe tests when writing an end-to-end test for the block editor:

To reproduce:

  1. Ensure some images are uploaded to the media library
  2. Add a gallery block to a post
  3. Click the 'Media Library' button
  4. Open the browser dev tools and inspect the HTML of an image
  5. Observe that the list item element for the image has the role of 'checkbox':
    <li tabindex="0" role="checkbox" aria-label="ac-kitchen" aria-checked="false" data-id="594" class="attachment save-ready">

Change History (13)

#1 @afercia
4 years ago

Thanks for reporting @talldanwp.

This is a known issue, together with several other, long standing, accessibility issues in the media views. The checkbox role is essential to make the JavaScript related to attachments selection work, especially when using assistive technologies. It is true it overrides the list item native semantics, and it worked this way since... forever.

Ideally, the media grid should not have a list semantics to start with. Actually, it's a grid with a JS-managed "spacial" navigation, meaning that Up/Right/Down/Left arrow keys allow to navigate the attachments in any direction. A list wouldn't convey this interaction model. The roles grid / gridcell would be more appropriate, but I'm not sure about their actual assistive technologies support.

Will discuss with the accessibility team.

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

4 years ago

#3 @afercia
4 years ago

Previously: #23560, #30390

#4 @afercia
4 years ago

Previously: #23560, #30390.

This ticket was mentioned in Slack in #core-media by joedolson. View the logs.

4 years ago

This ticket was mentioned in Slack in #core-media by antpb. View the logs.

4 years ago

#7 @antpb
4 years ago

  • Milestone changed from Awaiting Review to 5.7

In the recent Media component meeting we discussed this issue as being a great focus of 5.7. Theres a bit of discovery to do here to find the next best steps.

@joedolson mentioned this resource to keep in mind:
"Note that ARIA grid is totally separate from grid layout. Here’s a useful article: "

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

3 years ago

#9 @ryokuhi
3 years ago

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

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

3 years ago

#11 @joedolson
3 years ago

Based on exploring the status and expectations for using aria grid, I don't think that is an appropriate choice for this interface.

ARIA Grid comes with an expectation, like a table, that there are meaningful rows and columns - but in this interface, that's not the case. While a visual user can benefit from arrow navigation to move down a column rapidly, this is only because they can see the image they want and know how to navigate to it. For a non-visual interface, there's nothing meaningful about how the rows and columns are structured: unless you already know where in the grid the image you want is located, pressing arrow down or arrow left give you an equal chance of getting closer to it.

For that reason, we need to continue to think of this in a linearized format for non-visual navigation, and explore how to resolve this issue with that in mind.

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

3 years ago

#13 @joedolson
3 years ago

  • Milestone changed from 5.7 to Future Release
Note: See TracTickets for help on using tickets.