1772375 - With full keyboard access enabled, on macOS 12.5, I can't easily tab through form controls on a website.

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Emilio Cobos Álvarez [:emilio]]

This happens also in 12.4 at least, as per a conversation with :bkardell, which was trying to get links on Firefox on macOS to be tabbable. We make links tabbable only if Full keyboard access is enabled, but it seems the behavior is quite broken with this setting. As soon as you tab around, focus seems to move outside of the page, see screencast.

This makes Firefox pretty unusable with full keyboard access. Also, we should consider adding a setting so that tabbing through links and so on works properly, but that's probably a different issue.

Filing in the a11y component because I suspect there's some accessibility code involved on this behavior, since otherwise the only check we have for full-keyboard access decides what elements are focusable by keyboard: https://searchfox.org/mozilla-central/rev/c8e15e17bc6fd28f558c395c948a6251b38774ff/widget/cocoa/nsLookAndFeel.mm#447

Comment 1

[Emilio Cobos Álvarez [:emilio]]

Attachment: Screen Recording 2022-06-02 at 19.48.31.mov

Comment 2

[Emilio Cobos Álvarez [:emilio]]

For the record, Safari does have a setting to allow tabbing through links / etc. We should consider doing something like that and changing the linked line of code in comment 0 to check a pref in addition to full-keyboard-access.

Comment 3

[James Teh [:Jamie]]

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

it seems the behavior is quite broken with this setting. As soon as you tab around, focus seems to move outside of the page, see screencast.

Would you mind describing the screencast?

Filing in the a11y component because I suspect there's some accessibility code involved on this behavior,

Did you have VoiceOver running when you tested this? If not, I can't think of any way a11y code could be involved here. There's certainly no a11y code that impacts keyboard navigation directly.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

(In reply to James Teh [:Jamie] from comment #3)

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

it seems the behavior is quite broken with this setting. As soon as you tab around, focus seems to move outside of the page, see screencast.

Would you mind describing the screencast?

Sure: I can tab through tabs and other buttons just fine in the parent process, but tabbing on the child process just gets stuck / usually goes back to focus the browser element in the parent process directly.

Did you have VoiceOver running when you tested this? If not, I can't think of any way a11y code could be involved here. There's certainly no a11y code that impacts keyboard navigation directly.

I didn't, but there's definitely some code around that isn't quite in our control at least.

macOS has a custom outline around the focused content that I'm pretty sure isn't drawn by Gecko. I wouldn't be surprised if they used the VoiceOver / AT facilities for this and they were trying to move focus using those.

Comment 5

[James Teh [:Jamie]]

Ah, I wasn't aware of that. It looks like Apple changed what "full keyboard access" meant in Monterey. Now, it seems to be an actual a11y client feature rather than just a setting that widgets/apps respect. What a mess.

Comment 6

[Morgan Reschenberg [:morgan]]

(In reply to James Teh [:Jamie] from comment #5)

Ah, I wasn't aware of that. It looks like Apple changed what "full keyboard access" meant in Monterey. Now, it seems to be an actual a11y client feature rather than just a setting that widgets/apps respect. What a mess.

Huh.. Do we need to support a11y APIs for this?

Comment 7

[Morgan Reschenberg [:morgan]]

FYI -- did some basic telemetry testing, looks like isFullKeyboardAccessEnabled is controlled by both this new preference AND the old/existing keyboard preference. so that's cool.
EDIT: ah, the new feature also enables the old one, but you can manually disable the old one and have just the new one on. The new one does set AXEnhancedUserInterface, though where the old one doesn't. So something like this describes the behaviour:

both enabled -> AXEnhancedUserInterface && isFullKeyboardAccessEnabled
new feature, but not old -> AXEnhancedUserInterface && !isFullKeyboardAccessEnabled
old feature, but not new -> !AXEnhancedUserInterface && isFullKeyboardAccessEnabled

AXEnhancedUserInterface will also be set when VO is enabled, though (among other things), so this isn’t specific enough to know the new feature is on

Comment 8

[Brian Kardell]

Ah I wonder if this explains why different people I talked to see different things?

Comment 9

[Morgan Reschenberg [:morgan]]

It looks like webkit checks a bit in the prefs store to tell if this is activated. Doesn't look like there's a nice accessor though :/

Comment 10

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:Jamie, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

[James Teh [:Jamie]]

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

Sure: I can tab through tabs and other buttons just fine in the parent process, but tabbing on the child process just gets stuck / usually goes back to focus the browser element in the parent process directly.

Just leaving this here for later: I've discovered that Accessible::TakeFocus doesn't work on remote documents if focus isn't already in that document. I thought this worked at some stage, but I could be wrong. This did get fixed for OOP iframes in bug 1556627, but that doesn't seem to apply when the parent process browser element isn't focused at all. That might explain why Mac FKA can't set focus inside content.

Comment 12

[James Teh [:Jamie]]

Now that bug 1898198 is fixed, it's worth checking whether this fixes the new Full Keyboard Access feature based on a11y APIs.

Comment 13

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1772375 - Initial support for MacOS full keyboard access. r?morgan

This feature relies mostly on a search predicate key we did not support.
With that added we at least get some functionality although you encounter
bugs pretty quickly. For example a button after a password field loses focus,
but this seems to be a bug in Safari too. I think the browser support here in general
is pretty underwhelming at this time.

Note: This just works because we now start a11y when a role is retrieved, so
we don't need to sniff out any special FKA settings.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2db3f3293500
Initial support for MacOS full keyboard access. r=morgan

Comment 15

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/2db3f3293500