feat(tab): Give focus to tab when activated

[patrickrodee]

Closes #3163

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (feat/tabs/tabs@51ae758). Click here to learn what that means.
The diff coverage is 100%.

@@                Coverage Diff                @@
##             feat/tabs/tabs    #3164   +/-   ##
=================================================
  Coverage                  ?   98.42%           
=================================================
  Files                     ?      113           
  Lines                     ?     4821           
  Branches                  ?      600           
=================================================
  Hits                      ?     4745           
  Misses                    ?       76           
  Partials                  ?        0

Impacted Files	Coverage Δ
packages/mdc-tab/foundation.js	100% <100%> (ø)
packages/mdc-tab/index.js	100% <100%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 51ae758...addb0dc. Read the comment docs.

[kfranqueiro]

Are we sure we want to do this in all cases? Couldn't this be really confusing if you're focused e.g. on a part of the page unaffected by tabs, then a tab is activated programmatically and grabs the user's focus?

[patrickrodee]

If the tab is programmatically activated, then the content will change and I’d think the user would want to be aware that something changed via a focus adjustment. Focusing on activation via keyboard navigation is part of the W3 spec for accessible tabs. That was my goal here: to add support for keyboard navigable Tabs. https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html

…

On Mon, Jul 23, 2018 at 6:54 AM Kenneth G. Franqueiro < ***@***.***> wrote: ***@***.**** commented on this pull request. Are we sure we want to do this in all cases? Couldn't this be really confusing if you're focused e.g. on a part of the page unaffected by tabs, then a tab is activated programmatically and grabs the user's focus? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3164 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFqhdpo9CfDRY9Dk8YHn2W1ji_odQyoAks5uJdWygaJpZM4VZaso> .

[kfranqueiro]

I realize this is about keyboard a11y, but that example seems to be showing almost the reverse of what this is doing: the example activates a tab when it receives focus. This PR focuses a tab when it's activated.

There's also another WAI-ARIA example that shows tabs not being activated until space/enter is pressed when they have focus. Our design article seems to show focus states for both activated and unactivated tabs, and our earlier Tabs implementation doesn't activate on focus. Have we talked to a designer about which interaction behavior is intended for Material tabs? I don't see clear guidance on keyboard navigation.

Either way, this PR seems potentially backwards - should we be manipulating focus when arrow keys are used in the tab bar and activating based on focus or space/enter, instead of driving activation off of arrow keys?

[patrickrodee]

I haven’t talked with design yet about interaction behavior but I can schedule some time to do that. With regards to tab activation on focus, that’s not quite how it works since inactive Tabs all have a tabindex of -1 so they can’t manually receive focus via the tab key. The only way Tabs can receive focus is by activation through clicking or keyboard navigation. They function similar to lists in that case where you can’t use the tab key to navigate through them but instead use the tab key to get to the current active Tab then use arrow keys to navigate through them. I’ll see if I can get some info from the GAR folks about how they expect Tabs to work with keyboard navigation.

…

On Mon, Jul 23, 2018 at 8:19 AM Kenneth G. Franqueiro < ***@***.***> wrote: I realize this is about keyboard a11y, but that example seems to be showing almost the reverse of what this is doing: the example activates a tab when it receives focus. This PR focuses a tab when it's activated. There's also another WAI-ARIA example that shows tabs not being activated until space/enter is pressed when they have focus. Our design article seems to show focus states for both activated and unactivated tabs, and our earlier Tabs implementation doesn't activate on focus. Have we talked to a designer about which interaction behavior is intended for Material tabs? I don't see clear guidance on keyboard navigation. Either way, this PR seems potentially backwards - should we be manipulating focus when arrow keys are used in the tab bar and activating based on focus or space/enter, instead of driving activation off of arrow keys? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFqhdqnnrO5uV5G7LNsfC1r_HrzIXNXqks5uJemTgaJpZM4VZaso> .

[kfranqueiro]

Approving for now in the interest of unblocking tab bar, but my reservations stand and we should check with design on what the intended behavior is.

[mathiasschopmans]

tl;dr: Can this behaviour be optional/configurable please?

---

I am implementing MDC components on a onepage website and (mis)using the tabs as a navigation element in a fixed header, which will scroll the user to some sections of the page.

Additionally, I'm using something like Bootstrap's scrollspy-script to detect whenever the user scrolls to a new section of the page and use instance.activateTab() to mark the current visible section's link (tab) … and this is causing an issue when I'm trying to use the page by keaboard only:

Example:

• Tabbing: Focus on the tabs. ✔️
• Tabbing again: Focus is inside a input-element: ✔️
• Tabbing again: Focus is inside a input element within the next section below the fold
  • Browser scrolls focused element into viewport ✔️
  • Scrollspy script will activate second tab via .activateTab(1) ✔️
  • Focus isn't inside the input-element anymore. Instead tab has focus. ❌

I thought this behaviour could be somehow related to the useAutomaticActivation property, should'nt it, @kfranqueiro? Any help / suggestion would be appreciated. 🙇

[kfranqueiro]

useAutomaticActivation was added in #3303 and is false by default, in which case focusing on tabs shouldn't immediately activate them.

However, it sounds like you have the reverse issue - you're programmatically activating a tab, which gives it focus automatically.

Can you log a separate issue for this? We should probably check with our interaction designers on it.

[mathiasschopmans]

Ah, I see. You're right. In this case useAutomaticActivation shouldn't be used.

However, it sounds like you have the reverse issue - you're programmatically activating a tab, which gives it focus automatically.

Jup, that's my issue. :(

Can you log a separate issue for this?

I will.