fix(tabs): unable to tab to tab content

[crisbeto]

Currently the tab's content doesn't have a tabindex which means that if it doesn't have any focusable elements, users with assistive technology will skip over the content completely. These changes add a tabindex to the content of the currently-selected tab, based on the example of accessible tabs from the ARIA best practices.

[andrewseguin]

LGTM

[mmalerba]

So it seems there's a team in google3 that is placing an empty tab in one of their test apps which they run accessibility tests against. Because the tab is empty, mat-tab-body has 0 height, resulting in this error:

Warning: AX_FOCUS_01 (These elements are focusable but either invisible or obscured by another element) failed on the following element:
#mat-tab-content-0-0

I'm not sure if this is something we should bother addressing, or just consider it an error on the user's part if they do this in a real app. @jelbourn thoughts?

[jelbourn]

It sounds like a problem in their app rather than the tabs itself

[jelbourn]

I actually double-checked this against the internal examples built by Google's a11y people and they don't put tabindex on the content. This aligns with my understanding that only interactive elements should be tab stops, and that screen-reader users will navigate to static content via the screen-reader shortcuts (not tab).

I have my next a11y sync next Monday, so I'll double check.

[crisbeto]

For future reference, this is based on the following example from the W3C: https://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-2/tabs.html

[jelbourn]

@crisbeto I confirmed that we shouldn't make the content tabbable by default. However, when the content is scrollable and it doesn't contain any interactive elements, making the content a tab stop is the only way for users to scroll the content with the keyboard. It seems like the best thing here,then, would be to document what people should do in that case rather than trying to figure it out at the library level.

[andrewseguin]

@crisbeto Should this PR be closed in favor of adding better documentation for adding a tabstop when the content is scrollable?

[crisbeto]

I think we should close it in favor of not doing anything. We have a similar pattern to this in the stepper and there's a pending PR to remove it since it ends up being more annoying than useful.

[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.}