Accessibility: LocalNav

[cjcenizal]

Problem

The LocalNav (<kbn-top-nav>) has the following issues:

• This menu bar has role="toolbar", but it does not function as an ARIA toolbar. An ARIA toolbar is defined as "A collection of commonly used function buttons represented in compact visual form" (e.g., options in a text editor). The Inbox filtering options are not a toolbar. Options within a toolbar must be navigated with the arrow keys, not the tab key. See https://www.w3.org/TR/wai-aria-practices-1.1/#toolbar for more information on toolbars. This functions more like a "mega menu". For an example of an accessible mega menu (with appropriate ARIA), see https://adobe-accessibility.github.io/Accessible-Mega-Menu/.
• The ARIA labels for the menu provide extraneous information that does not match the text that is presented visually. For example, the "Open" option has aria-label="Load Saved Search". There is no reason for this additional hidden information.
• Selecting a tab ("New, "Save", etc.) opens a subsection (<div class="share-dropdown">) with these issues:
  • Many of the form controls are not labeled. This includes the share tab and most of the form controls in the Reporting section.
  • Text that functions as a heading should be marked up as a heading. For example, in the "Share" submenu.
  • The "close" element (<div class="config-close remove") is inaccessible to keyboard users because it does not receive keyboard focus.
  • The last section in the menu allows users to set a date range. The "Quick/Relative/Absolute" options should be presented as an ARIA tab panel (see https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel) for details.

[cjcenizal]

The ARIA labels for the menu provide extraneous information that does not match the text that is presented visually. For example, the "Open" option has aria-label="Load Saved Search". There is no reason for this additional hidden information.

In this case, I think the context needs to be reinforced in the aria-label because the concept of a saved search isn't very clear in the Discover app. I say this because in a typical CRUD UI you typically start off with a list of existing saved objects and you have the option to "Create a new object" which kicks off the creation flow. But Discover is unique in that you're just dropped into the creation flow by default, and there's no page which lists all of the existing saved searches.

[cjcenizal]

I've crossed out parts of this PR's description which no longer seem to apply.