In the media library, announce the type of media being selected

Accessibility issues generally aren't features; they're bugs or at least tasks. Calling it a major task for now since it sounds like this could make the form less confusing for non-sighted users, but if it's more of a "would be nice but not a big deal" we can downgrade it back to normal/could-have.

Also adding issue credit for @rainbreaw who identified this issue.

I'm not entirely sure I understand what's proposed.

The problem section here talks about the "Select media button" (Rain's old comment from another issue), but the proposed solution talks about the checkboxes. The issue summary needs clarification.

Based on Rain's comment, at first I thought it meant the footer button which completes the dialog. That button is called "Insert selected", so I guess that's not the one. FWIW, I don't think this button should change.

So if it's the checkboxes...

The thing that I wish, however, is that once I get into the select media button, that it would tell me what type of media I'm selecting. I have to remember that I was on Audio first, and then tabbed through the image and video options without selecting them,

Early designs for the media library grid view included the bundle name as a little badge, but it was axed in the name of keeping the grid clutter free. It's one of the reasons we kept the table listing on admin/content/media-table, which does include the bundle as a column. In the media library dialog, neither the grid nor the table view show the bundle name, but there's a mandatory filter (the "tabs") so it only ever shows items of one bundle.

So is this about including the bundle name in the checkbox name for every media item?

• Currently these checkboxes are called "Select media-item-label", e.g. "Select green-parrot.jpg".
• If the bundle name is added, the checkboxes would be named something like "Select bundle: media-item-label", e.g. "Select image: green-parrot.jpg"

I'm not sure about this. It arguably adds clarity, but also adds verbosity. Whichever it is, we're getting into very fine detail here. (I'm not even sure we need the word "select" in the checkbox name, because that's implied by the checkbox role and appearance. I think we kept that for consistency with some other listing or operation, but I forget which.)

• I'd think we could treat this as a wait-and-see question, and fix it if problems are reported after the module is marked stable. My hunch is it may amount to excessive hand-holding, but who knows?
• The Berkeley university Web Access team have a screen reader walkthrough test planned (later today, in fact). We could watch how it performs, and/or ask for an opinion on this.
• For triage, I would class this as extra polish, rather than a fundamental part of the design. Nice to have, not major or blocker.

It would be a departure from patterns elsewhere. The part about having to remember the filter choice you made is true everywhere we have filters. We don't keep repeating the entity bundle all the way down the list.

• If you use the content-type filter on admin/content, you have to remember the filter you chose as you tab through links, but we don't use the bundle name on the checkboxes there.
  • However, if you explore the whole table row (not just interactive controls), you will encounter the node bundle name as a column. That kind-of serves as a reminder of the filter you applied, but the main reason it's there is because it shows an unfiltered mixture by default.
• At admin/content/moderated, the situation is similar.
• Under admin/content/comments, there are two separate pagns listing published and unapproved comments. Once you pick one of those pages, you have to remember which page you are on. The approval state isn't mentioned anywhere in the list of comments itself.
  • Aside: these two comment listings have different link names (secondary tabs), but identical page <title>. That's probably a failure of WCAG page title, so I'll file an issue for that.

Based on @andrewmacpherson's comments in #4 from 4 years ago I think the status for this issue should at least be changed to Postponed until Andrew's feedback is addressed.

Hi my name is Ana (@anilu) and we are at Drupalcon Atlanta mentored contribution workshop and are working in documentation for Media core module

wanted to bump 1 more time.