WordPress.org

Make WordPress Core

Opened 10 months ago

Last modified 8 months ago

#36925 assigned defect (bug)

Media views: introduce a "Heading" view for better accessibility

Reported by: afercia Owned by: adamsilverstein
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Media Keywords: has-screenshots media-a11y has-patch
Focuses: ui, accessibility, javascript Cc:

Description

See #30512.
One of the main accessibility issues in the media views is that they're difficult to navigate using only the keyboard. Consider for example the "Add Media" modal, see the screenshot below. Potentially, there can be hundreds of attachments. There's no easy way to "jump" through the main areas of the modal.

A new approach to improve the media accessibility was recently discussed and it was agreed to propose small changes. Headings could greatly help, especially screen reader users who can use shortcuts to jump through headings.

New headings on the main workflow areas, together with the already existing headings, would give screen reader users the ability, for example, to "jump" from the attachments grid to the Insert button without being forced to tab through all the attachments.

Heading details can be discussed, but first of all there's the need to build a new "Heading" Backbone view. I guess it should be flexible enough to allow to set the heading level at runtime and an optional CSS class to show or visually hide the heading.

Any thoughts and help very welcome. Especially, help from someone with great Backbone knowledge :)

https://cldup.com/9mhj8uA7-W.png

Side note: working on the screenshot, I've noticed for the first time there's maybe some terminology inconsistency. Maybe the usage of the terms "Media" and "Attachment" should be reviewed a bit.

Attachments (2)

36925.diff (802 bytes) - added by afercia 10 months ago.
36925.2.diff (1.4 KB) - added by adamsilverstein 10 months ago.

Download all attachments as: .zip

Change History (11)

@afercia
10 months ago

#1 @afercia
10 months ago

  • Keywords has-patch added

Really, not a Backbone expert :) This is just a very first try, uploading here for discussion.

#2 @ocean90
10 months ago

@adamsilverstein Can you provide some help here?

#3 follow-up: @adamsilverstein
10 months ago

@ocean90 happy to!

@afercia This is a good start, thanks. I am happy to continue refining the Backbone code if you can help with the CSS and A11y concerns. Quick question: I am assuming all the highlighted areas in your screenshot are new divs (is that correct 'div' tags?) - these just sit above/in front of an area and that enables you to jump to them? I'm not a regular screen reader user so can you explain how these areas are exposed there? Also clarifying, these aren't wrapping around the target area like a label tag, right?

#4 @adamsilverstein
10 months ago

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

#5 @adamsilverstein
10 months ago

Reviewing the locations you added headers, I think we can just insert the headers you want directly into the templates used by Backbone to generate the views. Still not sure about proper naming/tagging, will upload a first pass.

#6 in reply to: ↑ 3 @afercia
10 months ago

Replying to adamsilverstein:

@ocean90 happy to!

@afercia This is a good start, thanks. I am happy to continue refining the Backbone code if you can help with the CSS and A11y concerns. Quick question: I am assuming all the highlighted areas in your screenshot are new divs (is that correct 'div' tags?) - these just sit above/in front of an area and that enables you to jump to them?

@adamsilverstein hi, no they're not divs. They need to be <h1> - <h6> headings to properly identify a main "section" of content and because screen readers have shortcuts to jump through headings. With NVDA and JAWS users can just press the 1-6 keys. VoiceOver with default settings uses Control-Option-Command-H and doesn't distinguish the heading level.

Regardless, screen reader users use headings as the predominant mechanism for finding content in a page. For example, with a couple of key presses they could jump from the left sidebar to the details sidebar on the right, completely skipping the (potentially hundreds of) attachments in the grid.

Also, depending on the heading hierarchy, the new headings could be h1, h2, h3 (rarely h4, h5, h6) so the view should have a way to set the heading level dynamically.

Lastly, some headings could be visually hidden but still accessible using the CSS class screen-reader-text while others can be visible. That's why I was trying to find a way to dynamically add a CSS class :)

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


8 months ago

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


8 months ago

#9 @rianrietveld
8 months ago

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