material-web
material-web copied to clipboard
Cannot use tab key to focus tab bar in Firefox
Describe the bug When using the tab key to interact with a tab bar in Firefox, the currently active tab does not receive focus. Ironically, using shift+tab works as expected. Testing with Chrome works as expected for both tab and shift+tab.
To Reproduce
- Go to tabs demo in Firefox
- Press tab to try to get to a tab bar, then try to move focus to another tab with arrow keys. This doesn't work because active tab never received focus.
- Try using shift+tab to enter the tab bar instead, and try arrow keys again. This works as expected.
Expected behavior Tabbing to the tab bar should focus the active tab the same as shift+tab.
Browser Version (please complete the following information):
- OS: Windows 10
- Browser Firefox
- Version 100
Additional context ARIA Authoring Practices on tabs
Interesting - Seems to be WAI on Linux (the active tab receives focus when tabing from one tab-bar to another).
Tested the above steps on FF v.100 - Linux mint.
That's interesting. I'm testing with NVDA, but I inspected the browser active element after each tab press and the details tell me the problem is not the screen reader:
- On the first tab key press into the tab list, the active element reported in the console is
<div class="mdc-tab-scroller">, which is quite odd because it does not appear to havetabindexset but it does have a click event listener. - On the next tab key press, the active element correctly becomes the
<button role="tab" tabindex="0" ...>element, but oddly does not trigger NVDA's focus mode as it should. - The next tab key press goes to step 1 on the next tab list.
I would have to look at the component code further, but it's possible this might be a Gecko bug. Do you have the ability to test with JAWS?
Something in the encapsulated styles for mwc-tab-scroller is causing this issue. If I delete that node from the DOM, the problem goes away.
Took one more closer look and it appears Firefox is upset with the CSS rule overflow-y: hidden on that div. At least for the non-scrolling demos, removing that rule fixes the issue. There is probably more to it for the scrolling demos.
Note that the accessibility tree includes a state of "focusable" for that div, which is why tab is stopping there. Toggling off that rule immediately removes the "focusable" state.
Should be fixed in M3