1231014 - accessibility.tabfocus should probably also be 7 on OS X by default just like on other platforms

Status: RESOLVED DUPLICATE of bug 1036966

(Core :: Widget: Cocoa, defect, P3)

Description

[Xidorn Quan [:xidorn] UTC+11]

Currently we make accessibility.tabfocus unset by default on OS X, and uses the system preference for what behavior should we take. But this doesn't match either Chrome or Safari.

Chrome simply allows tabbing to any focusable element on OS X as well, just like what we do for all other platforms.

Safari, on the other hand, behaves like us by default, but it has a separate shortcut Option-Tab to tab on every element, which we don't have. In addition, Safari doesn't use the system preference at all -- it has its own pref for this single behavior.

So I think we probably should just follow the Chrome path and make all elements accessible via Tab by default.

One thing which might need concern is accessibility.tabfocus_applies_to_xul, which is enabled by default on OS X. We probably still want to use the system preference for XUL elements, because they are part of the UI rather than web content.

Comment 1

[Julien Wajsberg [:julienw]]

I found this problem today while working on accessibility for perf.html. I believe we should follow Chrome as well.

What would be the next step? Just set "accessibility.tabfocus" to 7 on MacOS X in [1]? What is the good path to handle `tabfocus_applies_to_xul`, would we need to change some actual code to support having the value "7" for content but still have the system preference apply to XUL? Also what does it look like now that we replace XUL by HTML, should it rather be chrome vs content?

[1] https://searchfox.org/mozilla-central/rev/3160ddc1f0ab55d230c595366662c62950e5c785/modules/libpref/init/all.js#960-971

Comment 2

[Dustin Y]

I ran across this bug today while attending an MDN Documentation Hackathon at the AccessU Conference and playing with skip navigation on MDN itself. I found https://stackoverflow.com/questions/11704828/how-to-allow-keyboard-focus-of-links-in-firefox which helped me solve the problem - adding accessibility.tabfocus and setting it to 7 fixed the problem. It feels like the lack discoverability of this makes it feel like a bug that needs addressing.

Setting accessibility.tabfocus to 7 by default would be ideal, but simply having this available as a Preferences pane option would also be very useful for helping Firefox work out of the box.

Comment 3

[Julien Wajsberg [:julienw]]

Hey Stephen, what's the right path in this issue in your opinion? I see people being confused by this behavior all the time, there are numerous questions and blog posts about this too [1] [2].

[1] https://www.scottohara.me/blog/2014/10/03/link-tabbing-firefox-osx.html
[2] https://marieguillaumet.com/activer-la-prise-de-focus-dans-firefox-sur-macos/
[3] https://stackoverflow.com/questions/11704828/how-to-allow-keyboard-focus-of-links-in-firefox/11713537#11713537

Thanks!

Comment 4

[Stephen A Pohl [:spohl]]

Having parity with Chrome and Safari seems like a good thing. Unfortunately, I can't give a specific recommendation right now regarding tabfocus_applies_to_xul without spending time testing this. And I may not have time to do so for a while.

Comment 5

[Julien Wajsberg [:julienw]]

Is this the only place where tabfocus_applies_to_xul is used ? https://searchfox.org/mozilla-central/rev/a887c90ea9c19a0b5529a1f5fa351929944887ba/dom/xul/nsXULElement.cpp#457

I feel like we could remove all the related code if we don't obey the MacOS X System setting. TBH this setting sounds problematic because we have links in our chrome now (about:preferences has some XUL-based links (I think that's <label>) but other html-based panels like about:debugging have real links.