A11y keyboard focus control in the Toolbar Component

[DaveBest99]

Bug, feature request, or proposal:

Bug:
The Toolbar component is not in the page focus order, and has no interactive child elements for testing.

What is the expected behavior?

Tab key should move focus to the Toolbar and arrow keys move between the child elements.

What is the current behavior?

Currently the Toolbar is not in the focus order and has no buttons.

What are the steps to reproduce?

See below.

Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: https://goo.gl/DlHd6U

What is the use-case or motivation for changing an existing behavior?

To create a usable component.

Which versions of Angular, Material, OS, browsers are affected?

Using screen reader JAWS17 with browsers Firefox, Internet Explorer 11, and Google Chrome.

Is there anything else we should know?

Screen reader user experience follows:

1. Press Tab key to move focus to the Toolbar example component.
   The screen reader focus skips over the Toolbar example and lands on the "Learn Angular" in the page footer.
   The MD-TOOLBAR module has role=toolbar, but has no focusable child elements.
   The MD-TOOLBAR-ROW module has 6 image elements, each having a text label (aria-label=verified_user) and "role=img" to identify the image, but they are not in the focus order.
   The Toolbar component cannot be tested with the screen reader, as there are no interactive Toolbar Buttons.

2. Keyboard Toolbar handling.
   Typically a toolbar is a container for grouping a set of controls, like buttons.
   The keyboard Tab sequence should stop on the toolbar (focus is set on the first control that is not disabled), and arrow keys used to move focus among the controls in the toolbar.

Resources: WAI-ARIA Authoring Practices 1.1
2.22 Toolbar
https://www.w3.org/TR/wai-aria-practices-1.1/#menu#h-toolbar

[devversion]

We already had a similar issue for this #2909.

I'm not sure whether the md-toolbar should be responsible for keyboard focus control, I initially thought that the md-toolbar is just a wrapper and doesn't really do anything except the styling.

[mmalerba]

Here's the relevant excerpt from the w3c doc for convenience:

To optimize the benefit of toolbar widgets:

1. Implement focus management so the keyboard tab sequence includes one stop for the toolbar and arrow keys move focus among the controls in the toolbar.
2. Avoid including controls that require arrow keys to operate, such as textbox or radio group. If unavoidable, include only one such control and make it the last element .
3. Use toolbar as a grouping element only if the group contains 3 or more controls.

@jelbourn is this something we want to tackle in md-toolbar or leave it up to the user? Maybe we could make a directive that users can put on any container to turn the tab stops into arrow-key managed activedescendants?

[jelbourn]

I'm wondering here is what we call a "toolbar" is the same thing that the WAI-ARIA considers a toolbar. Our md-toolbar primarily serves as a styled header region, which typically contains a title and a couple of buttons. My interpretation of the WAI-ARIA is that the role is meant more for a more comprehensive set of actions, such as the editor controls in Google docs.

We should check with internal a11y eng for clarification.

[devversion]

@jelbourn Any updates on this?

[jelbourn]

I think the resolution here is to add an Accessibility section to the docs similar what I've done for cards in #4781. The gist is that md-toolbar provides only a colored header region and the user should:

• Apply role="toolbar" and related attributes if they're using the component as an actual toolbar as described by the W3C.
• Use appropriate headers or roles in the md-toolbar content otherwise

[devversion]

The a11y section has been added in 1b6b270#diff-bffb761b9b560b8ea8a59421fa247316

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}