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

[afercia]

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 :)

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.

[afercia]

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

[ocean90]

@adamsilverstein Can you provide some help here?

[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? 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?

[adamsilverstein]

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.

[afercia]

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 :)

[afercia]

Discussed during today's accessibility bug-scrub and agreed we'd like to try this ticket again for 5.0.

[desrosj]

36925.2.diff​ needs to be dusted off and refreshed.

[adamsilverstein]

This isn't ready for 5.1, punting to 5.2.

[afercia]

@adamsilverstein when you have a chance: is this on your radar for 5.2? Ten days left to 5.2 beta 1. I'd really appreciate some feedback to not punt this ticket again to a next release. Thank you :)

[adamsilverstein]

@afercia I am reviewing this again. Looking at the media modal that opens in Gutenberg, I do see h1 and h2 tags where I expect them.

Do you think this is still a valid issue, what do you see that needs changing?

[afercia]

@adamsilverstein thanks for looking again into this :) Actually we don't need to change the existing headings. We need to add more of them. Headings are used by screen reader users to navigate through content. Adding more heading would greatly help them to use the media modal. So we'd need a reusable heading view that:

• can be placed anywhere in the media stuff UI
• can be passed a param or something to change the heading level h2, h3, h4, etc.
• optionally, can have a screen-reader-text class to be visually hidden

[adamsilverstein]

We need to add more of them... So we'd need a reusable heading view...

Aha!

I see in 36925.diff​ you add this new reusable heading view. Overall the code looked good based on your described goals.

Do we want to test adding/using this in one location to demonstrate and test its use then we can tackle additional uses in subsequent tickets? Do we want to replace existing headers with the new view?

[afercia]

Oh yes. I'd start with a h2 heading "Attachments list" before the grid. Thanks!

[antpb]

Hello! This ticket was discussed in the recent Media meeting and I think we are still deciding the full scope of the task. If that is true, we may need to punt to 5.3 for the sake of the timing of 5.2. @adamsilverstein how do you feel about that? Do you think there are any pieces of this that can land with future task to finish it out?

[afercia]

@antpb thanks for sharing the team feedback. I'm not sure there's anything that needs a decision here. Building the tool and actually using it are 2 different phases:

• phase 1: we need a reusable heading view, and this ticket is waiting since 3 years
• phase 2: once we have the tool, we'll take care of using it where necessary in the media views: this can be done in the next releases

[adamsilverstein]

The code for the reusable heading view looks good, I'm going to work on implementing an initial heading to validate the use.

[adamsilverstein]

In 36925.3.diff​

• Add a new 'Attachments list' Heading above the attachments list. Hidden using the screen-reader-text class.

I tested this with voiceover and could hear the heading announced when I used the 'Next Heading' keyboard shortcut.

@afercia I'm not certain about the exact placement of the heading in the HTML structure, right now it is directly above the attachments list - does that look right?

[afercia]

@adamsilverstein right before the <ul> is perfect. Thanks! Ship it! 🚢

[adamsilverstein]

OK, will do that now, thanks for reviewing.

[afercia]

P.S. missing semicolon after return this.options.level || 'h1'

[adamsilverstein]

good catch! caught that when running tests in jshint:media. Fixed in 36925.4.diff​

[adamsilverstein]

In 44969:

Media: introduce a "Heading" view for improved accessibility.

• Add a new media view: wp.media.view.Heading designed to add accessibility friendly headers in the media library/modal.
• Add an initial "Attachments list" heading above the attachments list.

Props afercia.
Fixes #36925.