Components: tabs: When the selectedIndex is changed, if focus is on a tab, focus should move to the now-selected tab

[ghost]

Bug, feature request, or proposal:

When the selectedIndex property of an MdTabGroup is changed so that another tab is opened, if the focus is on a tab within the MdTabGroup's tab header, focus should move to the now-selected tab.

Alternatively, I would like the MdTabGroup's tab header child component to be exposed so that I could update the focusIndex.

What is the current behavior?

Currently, when the selectedIndex is changed to open a different tab while the focus is on one of the tabs, focus remains on the tab.

What are the steps to reproduce?

Please see this Plunker: http://plnkr.co/edit/xNUO08jgFcFCsdWDzCRZ

In this Plunker, I integrated a Material Design tabs component with routing, so that clicking on a tab changes the URL, and visiting a certain tab's URL will cause the tab to be opened.

1. Run the Plunker that I linked to. Click the "Launch the preview in a separate window" button to see the changing URLs.
2. When you see the tabs rendered, click on "Tab 3" to open the third tab.
3. Right click on "Tab 3" and select "Back" from the context menu (in Firefox, the "back" menu item is just an arrow icon).
4. The blue tab underline will move to "Tab 1" and the first tab will be opened; however, the focus is still on "Tab 3".

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

I would like to be able to move the focus to the now-selected tab.

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

Angular 2.3.1, Angular Material 2.0.0-beta.1

I have tested Safari 10.0.3, Firefox 51.0.1 (64-bit), and Chrome 56.0.2924.87 (64-bit).

Is there anything else we should know?

See this thread on JavaRanch for some background: https://coderanch.com/t/675876/access-grandchild-component-Angular

[antonmoiseev]

A picture is worth a thousand words 😉

[jrood]

Yes, I've found that if I bind selectedIndex to a property on my component, if I change the value of that property (say, from 2 to 3) sometimes the change is reflected in the ui, but other times not. Sometimes I can overcome this issue by setting that property to null (which animates back to the first tab) and then setting it to the tab that I actually want to go to. It seems like it might be a change detector issue.

[jrood]

I'm not sure if what I have observed falls under this issue or not. Let me know if I should open a separate bug.

[ghost]

@jrood Is what you are describing similar to issue #687?

[jrood]

@dtrebbien oh yeah, that's exactly the bug I'm seeing.

[finalxcode]

+1 i have same issue

[amcdnl]

Repo Steps

1. Create a tab set with multiple tabs.
2. Click a tab.
3. Have something external (timeout/browser navigation) select a new tab using the selectedIndex property on the tabset without actually clicking the page.
4. Note the previously selected tab still has focus.

Conclusion

I spoke with @jelbourn regarding this issue, this is considered working as designed.

The reasoning behind this is that for a11y, if the focus state of the page is changing unexpectedly its not considered good UX. Additionally, if there is multiple tab sets on the page it would reset it n* times which could result in the screenreader jumping to the last tabset vs where it was currently.

Generally speaking, the focus should be managed at the application layer rather than individual controls. For more information, check out this link: https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_generalnav