fix(tabs) dummy tabs should not have acccessibilty roles

[clshortfuse]

• Remove role="tab" from dummy tabs

Fixes #9450

[clshortfuse]

I'm not understanding why the spec tests are actively checking for md-dummy-tab to have a role='tab'.

[crisbeto]

I'm not sure either. It could have something to do with them forwarding focus to the real tabs, but I'm just guessing.

[topherfangio]

@clshortfuse Can you do some testing by removing the role from the non-dummy tabs and see if keyboard accessibility still works?

[clshortfuse]

@topherfangio I wouldn't say it works properly because I found a keyboard bug with dynamic heights in master where you can't navigating while the animation is running, but yes, keyboard works like master.

Travis Fails because of a spec test is expecting a dummy tab to have a role. I'm not sure why this would be expected behavior. I'll need some clarification about this.

material/src/components/tabs/tabs.spec.js

Line 357 in 8758488

expect(tabItem.attr('role')).toBe('tab');

[topherfangio]

@clshortfuse Is the dynamic height bug you mentioned fixed by the dummy tabs having the role?

[clshortfuse]

@topherfangio I discovered that keyboard events aren't processed while a tab is in a transition phase and dynamic height is on. In other words, go to demo and spam right, enter and right, enter. It's unrelated to this PR, just something I found.

I'm going to just remove the role check in dummy tabs and add a spec test that ensures dummy tabs do not have role attribute.

I will say, there is another way to solve the issue, which is to set a dummy tab with a hidden attribute. Technically, dummy tabs are hidden and it may be a better solution, but it creates a lot more problems than just removing the role attribute.

[clshortfuse]

Spec tests added. OK with ChromeVox.
Needs to be tested:

JAWS (Windows)

• Chrome
• IE
• Edge
• FireFox

NVDA (Windows)

• Chrome
• IE
• Edge
• FireFox

VoiceOver (Mac)

• Safari
• Chrome
• Safari Mobile

TalkBack (Android)

• Chrome