1036966 - Make accessible keyboard navigation of web content default on OSX

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[David Bolter [:davidb] (NeedInfo me for attention)]

For a long time we've respected OSX's keyboard setting[1] for whether we provide accessible keyboard navigation. I think this causes more confusion/harm than good. I propose we default to full keyboard navigation on OSX.

1. http://support.apple.com/kb/PH13833

Comment 1

[Marco Zehe (:MarcoZ)]

I support this!

Comment 2

[Boris Zbarsky [:bzbarsky]]

Have you read the bug that initially implemented following the default OS setting here?  What's changed since then?

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

At the very least I need to re-read them (bug 187508, bug 437296, bug 349357 etc...) -- BZ, thanks for the bug info via IRC.

I wonder why Chrome and (especially) Safari ignore the OS keyboard nav setting here and instead have browser preferences for this functionality... how did we become the odd one out?

Comment 4

[Marco Zehe (:MarcoZ)]

I believe Safari started ignoring the OS keyboard setting with Safari 7 in Mavericks, used to honor the setting before that. I don't know what prompted the change.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Safari 7.0.5 on Mac OS 10.9.4 follows the OS keyboard setting as far as I can tell.

Comment 6

[brianarn]

Using Sauce Labs (as I don't have any Macs with older OSes around) I went and tested Safari functionality. I would agree with Marco - this looks to be a Safari 7 change to respect navigation to links.

Assuming OS X default of only text boxes and lists, using this test page:
http://jsfiddle.net/JPAE4/7/show/

- Safari 6 (unsure specific version or OS version): Focus moves from input to tabindex'd div to input, skipping link
- Safari 7.0.4 on OS X 10.9.3: Focus moves from input to tabindex'd div to link to input
- Safari 7.0.5 on OS X 10.9.4: Focus moves from input to tabindex'd div to link to input

I happened to be an OS update behind, so I tested on both sides of the update, and got the same result.

It could perhaps be something weird about the tabindex'd div, so a more "pure" test might be worthwhile.

I was well aware of the text boxes and lists keyboard option, but genuinely didn't expect it to affect web page navigation. It feels actively hostile (IMO) towards keyboard users to have their navigation restricted.

It's also worth noting that Firefox includes all types of button form elements in keyboard navigation, when they would normally be skipped when that setting is in place ( tested with http://jsfiddle.net/JPAE4/9/ ). As such, adding at least anchor elements as always-navigable elements makes sense, since they're actionable elements on the page.

+1 on enabling full navigation regardless of keyboard setting, or if nothing else, at least adding anchor elements to keyboard navigation.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> - Safari 7.0.5 on OS X 10.9.4: Focus moves from input to tabindex'd div to link to input

That's definitely not what I'm seeing.  I'm seeing it skip the link, in that exact Safari and OS version.

Please do make sure that in your Safari in Advanced preferences you don't have "Press Tab to highlight each item on a webpage" checked?

Comment 8

[brianarn]

That's an option I was not aware of. Turns out, I did have that enabled. If I disable that option, it behaves identically to the behavior I'm seeing in Firefox.

I'm still a fan of having that behavior enabled by default in Firefox, though there's no grounds to stand on in terms of OS consistency now.

Comment 9

[brianarn]

Sorry, I poorly phrased that second paragraph.

I'm still a fan of navigable links by default in Firefox, ignoring the OS setting, though there's no grounds to stand on in terms of OS consistency at this point.

I do feel like it's a confusing behavior at first, but it is consistent with the native browser at this point.

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to On vacation Aug 5-18.  Please do not request review. from comment #2)
> Have you read the bug that initially implemented following the default OS
> setting here?  What's changed since then?

Just heard back from my Apple accessibility contact. Advice is to save ourselves some headaches and just enable full keyboard access. We can revisit if IndieUI picks up content driven setting of keyboard preferences. So I'm back to supporting comment 0.

Comment 15

[Šime Vidas]

I came here from the intent to prototype (https://groups.google.com/a/mozilla.org/g/dev-platform/c/bguStcPFugQ/m/4as3Y3rVAQAJ). I checked in Firefox Nightly’s settings. There is a checkbox “Use the tab key to move focus between form controls and links”, which was disabled for me. I’m confused. I’ve been tabbing through links and buttons for years in Nightly. What additional functionality do I get if I enable this checkbox?

Comment 16

[Morgan Reschenberg [:morgan]]

(In reply to Šime Vidas from comment #15)

I came here from the intent to prototype (https://groups.google.com/a/mozilla.org/g/dev-platform/c/bguStcPFugQ/m/4as3Y3rVAQAJ). I checked in Firefox Nightly’s settings. There is a checkbox “Use the tab key to move focus between form controls and links”, which was disabled for me. I’m confused. I’ve been tabbing through links and buttons for years in Nightly. What additional functionality do I get if I enable this checkbox?

Are you on macOS? Do you have keyboard navigation enabled in System Settings > Keyboard? The Firefox preference defaults to this value when not overridden. I'm not sure why the checkbox would be disabled, I'll have to look into that.

Comment 17

[Šime Vidas]

Yes, macOS, but the previous version (Ventura 13.6.1). Yes, I have keyboard navigation enabled in macOS settings. I tested in Firefox and Firefox Nightly. When the “Use the tab key…” checkbox is not checked, keyboard tab focuses form controls but not links. When the checkbox is checked, it focuses links as well. I guess, that’s the intended behavior.

I’m confused why the ckeckbox was not checked in my Firefox. Maybe I accidentally unchecked it.

Comment 18

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1036966: Create accessibility.focus_links_and_controls, default it to 'on' r?Jamie

Comment 20

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1036966 - Make accessibility.tabfocus default to 7 on macOS too. r=Gijs!,morgan!

I don't see why this wouldn't work? I had to change preferencesBindings
so that unchecking the checkbox actually works instead of setting the
pref to zero.

Comment 21

[Emilio Cobos Álvarez [:emilio]]

(In reply to Šime Vidas from comment #15)

I came here from the intent to prototype (https://groups.google.com/a/mozilla.org/g/dev-platform/c/bguStcPFugQ/m/4as3Y3rVAQAJ). I checked in Firefox Nightly’s settings. There is a checkbox “Use the tab key to move focus between form controls and links”, which was disabled for me. I’m confused. I’ve been tabbing through links and buttons for years in Nightly. What additional functionality do I get if I enable this checkbox?

The checkbox being disabled right now means "follow the system settings", unless you check it and then uncheck it. It's a bit bizarre, see the description in https://phabricator.services.mozilla.com/D208602 as for why.

So yes, if you have the system setting on, the checkbox is pretty confusing. It should be fixed with this bug.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/644738c3ccfe
Make accessibility.tabfocus default to 7 on macOS too. r=morgan,settings-reviewers,mac-reviewers,mstange

Comment 23

[tszentpeteri]

Backed out for causing for causing mochitest failures in test_tabindex.html

• Backout link
• Push with failures
• Failure Log
• Failure line:

[task 2024-05-03T00:56:27.412Z] 00:56:27     INFO - TEST-PASS | dom/svg/test/test_tabindex.html | The active element tabindex is 3 
[task 2024-05-03T00:56:27.412Z] 00:56:27     INFO - Buffered messages finished
[task 2024-05-03T00:56:27.413Z] 00:56:27     INFO - TEST-UNEXPECTED-FAIL | dom/svg/test/test_tabindex.html | The active element tabindex is 6 - got 4, expected 6
[task 2024-05-03T00:56:27.413Z] 00:56:27     INFO -     SimpleTest.is@SimpleTest/SimpleTest.js:509:14
[task 2024-05-03T00:56:27.413Z] 00:56:27     INFO -     main@dom/svg/test/test_tabindex.html?currentTestURL=dom%2Fsvg%2Ftest%2Ftest_tabindex.html&closeWhenDone=1&showTestReport=false&expected=pass:79:9
[task 2024-05-03T00:56:27.413Z] 00:56:27     INFO -     SimpleTest.waitForFocus/<@SimpleTest/SimpleTest.js:1058:13
[task 2024-05-03T00:56:27.413Z] 00:56:27     INFO - Not taking screenshot here: see the one that was previously logged
[task 2024-05-03T00:56:27.414Z] 00:56:27     INFO - TEST-UNEXPECTED-FAIL | dom/svg/test/test_tabindex.html | The active element tabindex is 7 - got 5, expected 7
[task 2024-05-03T00:56:27.414Z] 00:56:27     INFO -     SimpleTest.is@SimpleTest/SimpleTest.js:509:14
[task 2024-05-03T00:56:27.414Z] 00:56:27     INFO -     main@dom/svg/test/test_tabindex.html?currentTestURL=dom%2Fsvg%2Ftest%2Ftest_tabindex.html&closeWhenDone=1&showTestReport=false&expected=pass:87:9
[task 2024-05-03T00:56:27.414Z] 00:56:27     INFO -     SimpleTest.waitForFocus/<@SimpleTest/SimpleTest.js:1058:13
[task 2024-05-03T00:56:27.414Z] 00:56:27     INFO - GECKO(1595) | MEMORY STAT | vsize 6688MB | residentFast 89MB | heapAllocated 8MB
[task 2024-05-03T00:56:27.415Z] 00:56:27     INFO - TEST-OK | dom/svg/test/test_tabindex.html | took 71ms
[task 2024-05-03T00:56:27.415Z] 00:56:27     INFO - TEST-START | dom/svg/test/test_tearoff_with_cc.html

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a0417fcb915e
Make accessibility.tabfocus default to 7 on macOS too. r=morgan,settings-reviewers,mac-reviewers,mstange

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a546ec29a801
Fix browser_tabKeyNav.js too.

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/e82e34aece59
Fix browser_tabKeyNav.js too.

Comment 27

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/a0417fcb915e
https://hg.mozilla.org/mozilla-central/rev/e82e34aece59

Comment 28

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/a546ec29a801

Comment 29

[Pascal Chevrel:pascalc]

This bug has multiple duplicates, is that a change that should be mentioned in our release notes? Thanks

Comment 31

[Emilio Cobos Álvarez [:emilio]]

Release Note Request (optional, but appreciated)
[Why is this notable]: Changed default tab navigation behavior for macOS users.
[Affects Firefox for Android]: no
[Suggested wording]: Links and other focusable elements are now tab-navigable by default on macOS, instead of following macOS' "Keyboard navigation" setting. This is a more accessible default and matches the default in all other platforms. A checkbox in the settings page still allows users to restore the old behavior.
[Links (documentation, blog post, etc)]: this bug is probably enough.

Comment 32

[Neil Deakin]

I agree that the focus-difference-for-XUL thing is weird given we're switching to HTML more and more. Perhaps we can have a follow-up to make that distinction reflect purely whether we're on system principal or privileged about, instead of caring about the node namespace?

What should happen is that the focus behaviour shouldn't be dependent on the flavour of element. It should instead be based on the function of the element, so that textfields, dropdowns and so forth are treated consistently. That said, if we insist of having a separate checkbox in our preferences to handle web page behaviour differently, we should base it on that as well. But that seems confusing to me as to which of the many about pages (preferences, newtab, etc) should be treated as which style.

I trying to understand what this patch is doing though, but it's hard to tell exactly as our Mac tab navigation behaviour seems broken yet again.

From reading the patch and checkin comment, it appears to make tab navigation worse. It seems to remove support for the full keyboard access setting and force you to use some other UI to change this. In addition, the Ctrl+F7 keyboard shortcut can no longer be used to switch full keyboard access off and on, meaning I have to choose either to suffer the tab navigation model other platforms use, or one where I cannot focus all items when I need to, I can't toggle it quickly or use the Option key method as Safari does. (I realize of course that accessibility users would need to navigate between all elements).

But maybe I misinterpreted the intent here?

I would recommend closing this bug as wontfix and implementing a behaviour closer to what Safari has done where Tab can be used to cycle between textboxes and lists (and possibly some other things) and Option+Tab can be used to cycle between all elements. Personally, I would remove the special preference UI and just have that the behaviour for all content and chrome UI and the full keyboard access setting can be used to flip the Tab and Option+Tab behaviour around.

Comment 33

[Pascal Chevrel:pascalc]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #31)

[Suggested wording]: Links and other focusable elements are now tab-navigable by default on macOS, instead of following macOS' "Keyboard navigation" setting. This is a more accessible default and matches the default in all other platforms. A checkbox in the settings page still allows users to restore the old behavior.
[Links (documentation, blog post, etc)]: this bug is probably enough.

Thanks, note added to https://www.mozilla.org/en-US/firefox/127.0a1/releasenotes/

Comment 34

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1896302