Identify purpose of vertical tabs in MediaLibraryWidget dialog for assistive tech users.

Initially just separating this from #3035331: Improve keyboard focus behaviour of vertical tabs in MediaLibraryWidget. Will review later.

Having a navigation landmark region inside a dialog sounds a bit strange to me, because we'd be dynamically changing the list of landmark regions when the dialog opens and closes. I'm going to ask about this one in the wider accessibility community.

I'm also not sure that a list of tabs amounts to navigation. In this case it's actually behaving more like an exposed filter for the view. Under the hood, it's a Views contextual filter, but the tabs have effectively put a UI on it. So it's more like we have our exposed filters in two different places in the dialog.

Whatever the case, our current Form API '#type' => 'vertical_tabs' does NOT have a navigation landmark. Instead the list is preceded by visually-hidden text saying they are vertical tabs.

There is an ARIA pattern for tabs, but we don't currently use it in Drupal core, but there's a note about it in #2893640: Modernize ARIA usage, in line with ARIA 1.1 and the ARIA Authoring Practices guide.. However the ARIA tabs pattern is a bit controversial - the main worry is that many users are not familiar with it, and some user studies have been published where sighted keyboard users were confused by them. So I don't want to rush into using those until they have broader consensus in the accessibility community.

Updated (2019-06-18): fixed a broken issue link in this comment.

Let's put aside the tabs pattern from the WAI-ARIA Authoring Practices for now. That's a red herring in this issue. In any case, our current Form API vertical tabs component doesn't use that pattern, and for the time being I'd like to avoid having two components that both look like vertical tabs behave in two different ways. (Eventually, I'd like to use the ARIA tabs pattern for both of these. Just not today.)

In #3, I said I'd ask around in the wider accessibility community, about whether a navigation landmark region made sense inside a dialog. I chatted with Scott O'Hara from Paciello Group, and described the dialog. We agreed that having landmarks inside of a dialog was serious overkill; if a dialog needs landmark regions, then you need to simplify the dialog. We noted that the media library is a rather complex dialog, but thought it would still be best to avoid using landmark regions inside a dialog. The main reason is that conceptually a dialog isn't really part of the page; in native desktop apps it's actually a separate window. However in web pages the screenreader landmarks tool will show all of the landmarks for the parent document. (That may improve in the future if/when the inert attribute gains support.)

For now, the problem that needs to be addressed is this part of comment #3:

I'm also not sure that a list of tabs amounts to navigation. In this case it's actually behaving more like an exposed filter for the view. Under the hood, it's a Views contextual filter, but the tabs have effectively put a UI on it. So it's more like we have our exposed filters in two different places in the dialog.

What needs to be conveyed is that these controls behave as a filter. The action is "click this control to show image media items".

Here's the markup we currently have from MediaLibraryUiBuilder::buildMediaTypeMenu():

<ul class="media-library-menu js-media-library-menu">
  <li class="media-library-menu-audio">
    <a href="/media-library?" class="media-library-menu__link active">
      Audio
      <span class="active-tab visually-hidden"> (active tab)</span>
    </a>
  </li>
  <li class="media-library-menu-document"> ... </li>
  <li class="media-library-menu-image"> ... </li>
  <li class="media-library-menu-remote-video"> ... </li>
  <li class="media-library-menu-video"> ... </li>
</ul>

Good parts:

• There is a grouping element (the <ul>).
• The currently-selected media type is indicated (the visually-hidden "active tab" text).

Bad parts:

1. The behaviour semantics are misleading. The tabs are link elements, but they don't behave as hyperlinks for navigation.
2. The purpose of the control is unclear. A link says "Document", but it isn't clear that pressing it will cause the dialog content to switch to listing document media entities.
3. The visually-hidden "active tab" text is a bit misleading. I've witnessed screen reader users become confused when they hear the word tab, but the control doesn't behave like a ARIA tablist.
4. Clicking the control causes content to change elsewhere in the dialog, but focus remains on the tab so it isn't clear that something has happened. The invisible "active tab" text goes some way to convey this, but I think it would benefit from a more explicit "something happened!" message.

TO FIX:

1. Don't use links. Replace them with AJAX-enabled buttons.
2. Include text which conveys the filter behaviour. The simplest idea may be something like <button type="button"><span class="visually-hidden">Show </span>Image<span class="visually-hidden"> media</span></button>. Take care to address WCAG SC 2.5.3 Label In Name. There should be no invisible text inside the visible label. It's okay to have visible text sandwiched between two hidden spans.
3. Change the visually-hidden "(active tab)" to "(selected)", so it doesn't mislead screen reader users into thinking it behaves like an ARIA tablist.
4. Use an AJAX AnnounceCommand to inform the user about what changed: "Showing Image media."