Explicit tab index on anchor elements ignored on macOS
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
People
(Reporter: krinkle, Unassigned)
References
Details
(Keywords: parity-chrome, parity-safari)
Test case: https://codepen.io/Krinkle/full/eYvygWo
<h2>With <code>tabindex="0"</code></h2>
<ul>
<li><a tabindex="0" href="/foo">Foo</a></li>
<li><a tabindex="0" href="/bar">Bar</a></li>
<li><a tabindex="0" href="/baz">Baz</a></li>
</ul>
<h2>Plain</h2>
<ul>
<li><a href="/lorem">Lorem</a></li>
<li><a href="/ipsum">Ipsum</a></li>
<li><a href="/dolor">Dolor</a></li>
</ul>
Browser interop:
- Firefox 88 on Mac: None of the links are focusable.
- Chrome 91 on Mac: All links focusable.
- Safari 14 on Mac: All links focusable.
- Firefox 88 on Windows: Al links focusable.
- Chrome 91 on Windows: All links focusable.
- Edge 90 on Windows: All links focusable.
I am aware of the legacy Netscape decision not to enable focus on links by default on OSX. [1] And I am aware that this is user-configurable. [2] I do think it is time to reconsider this unusual default. But.. this bug report isn't about that.
This bug report is about an explicit tabindex="0" being ignored as well. I expect web authors to have the ability to override this. If there is a alternative uncompromising way to achieve this in HTML, I would be happy to hear that and have this closed as invalid.
[1] 20 year old bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=170833.
[2] http://kb.mozillazine.org/Accessibility.tabfocus
(In reply to Timo Tijhof from comment #0)
Test case: https://codepen.io/Krinkle/full/eYvygWo
<h2>With <code>tabindex="0"</code></h2> <ul> <li><a tabindex="0" href="/foo">Foo</a></li> <li><a tabindex="0" href="/bar">Bar</a></li> <li><a tabindex="0" href="/baz">Baz</a></li> </ul> <h2>Plain</h2> <ul> <li><a href="/lorem">Lorem</a></li> <li><a href="/ipsum">Ipsum</a></li> <li><a href="/dolor">Dolor</a></li> </ul>Browser interop:
- Firefox 88 on Mac: None of the links are focusable.
- Chrome 91 on Mac: All links focusable.
- Safari 14 on Mac: All links focusable.
- Firefox 88 on Windows: Al links focusable.
- Chrome 91 on Windows: All links focusable.
- Edge 90 on Windows: All links focusable.
I am aware of the legacy Netscape decision not to enable focus on links by default on OSX. [1] And I am aware that this is user-configurable. [2] I do think it is time to reconsider this unusual default. But.. this bug report isn't about that.
Without being very familiar with the topic, it's seems reasonable to reconsider the default and to follow Chrome's and Safari's behavior.
This would require comparing the focusability of all elements (text fields, form elements and links) for Chrome and Safari too.
Then, I guess the desired tabindex="0" functionality becomes less important.
Masayuki: any concerns about this?
This bug report is about an explicit tabindex="0" being ignored as well. I expect web authors to have the ability to override this. If there is a alternative uncompromising way to achieve this in HTML, I would be happy to hear that and have this closed as invalid.
[1] 20 year old bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=170833.
[2] http://kb.mozillazine.org/Accessibility.tabfocus
|
||
Comment 2•5 years ago
|
||
No, I agree with changing our behavior for following the other browsers'.
Enn, how about you?
|
||
Comment 3•5 years ago
|
||
Are you referring to clicking on the links or tabbing through them? Can you clarify what behaviour you are expecting to change?
We focus the links when clicking them as far as I can tell, but we don't draw focus rings to avoid distraction. The is the same behaviour as Chrome.
We don't put them in the tab order when the Keyboard Navigation preference is off, the same as Safari. With the Keyboard Navigation preference on however, we put links in the normal tab order, however Safari lets one navigate through links with Option+Tab regardless of the system setting. I personally find the Safari behaviour more rational.
I don't see any difference between the way we treat links with tabindex="0" versus no tabindex assigned. Safari does seem to show a focus ring on tabindex="0" links when clicked however.
|
Reporter | |
Comment 4•5 years ago
|
||
(In reply to Neil Deakin from comment #3)
Can you clarify what behaviour you are expecting to change?
For my particular web app, I'd like the elements in question to always be reachable by keyboard navigation on all platforms by default. I don't mind if there's a way users can disable this, but I'd like it to work this way by default for everyone for these particular links in my particular web app.
My example is live at https://treasure21.timotijhof.net/drive/INDEX.html
In all mentioned browsers/platforms, the icons in question were reacheable through keyboard/tab navigation, except Firefox on macOS. And, setting tabindex="0" did not appear to change anything, as I had hoped/expected. They were still not reachable by tab navigation.
To be explicit: the idea above was to set the default value of accessibility.tabfocus to 7 on macOS.
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 7•2 years ago
|
||
@emilio I don't think this is a duplicate. Whether links are by default included in tab navigation is a coincidence. I mentioned this 20y related issue in comment 0.
Firefox is currently explicitly an element with tabindex enabled from the tab order, presumably because it is indiscriminately removing anchor tags due to the accessibility setting, without realising that elements can have tabindex elements that enable it disable this on a per element basis, regardless of the browser or OS config.
If and when Firefox changes the default tabfocus setting, it merely changes this bug from affecting all anchor elements for all users, to affecting users that favour today's config by default, and might even break the inverse of setting tabindex -1 on an anchor element to exclude it.
|
|
||
Comment 8•2 years ago
|
||
Okay, I see, apologies!
Relevant code is here, should be a reasonably straight-forward tweak.
Description
•