1799153 - No focus is set after opening preferences and scrolling with openPreferences

Status: ASSIGNED

(Firefox :: Settings UI, defect, P2)

Description

[Henry Wilkes (they/them) [:henry-x]]

Steps to reproduce

This would be a general problem with most calls to openPreferences (https://searchfox.org/mozilla-central/search?q=openPreferences).

For example

1. Go to "about:logins".
2. Navigate to and open the menu next to "Sign in to sync".
3. Select "Preferences".

Expect

After the privacy settings are opened and "Logins and Passwords" is scrolled into view, the first input ("Ask to save logins and passwords for website") should be focused. This should allow you to immediately change the settings with a keyboard, and make the experience on a screen reader similar to the visual experience.

Actual

The focus remains on the "Find in Settings" search bar. This means there is no indication for a screen reader user where the relevant setting is and they would have to find it themselves. Depending on the context of what called openPreferences this can also be disorienting. Moreover, any keyboard user would not be able to immediately change the preferences.

Note

I think the practice of opening the preferences and dropping the user in the middle of them has the potential to be disorienting regardless of if the focus is also moved. But whilst openPreferences is still used it would be nice if it also moved focus.

Comment 1

[Henry Wilkes (they/them) [:henry-x]]

Maybe openPreferences could accept the id of the element to focus as another parameter? Or it could find the first focusable element automatically.

Comment 2

[Pier Angelo Vendrame]

I think that adding an attribute with the id of the element to focus in conjunction with data-subcategory would be a great idea, too.

Comment 3

[:Gijs (he/him)]

(In reply to Pier Angelo Vendrame from comment #2)

I think that adding an attribute with the id of the element to focus in conjunction with data-subcategory would be a great idea, too.

Why? The only callers of this method are inside Firefox and we don't seem to need this. It's not exposed to extensions. I don't see why the API needs extending.

Comment 4

[:Gijs (he/him)]

Attachment: Bug 1799153 - move focus when switching to a specific portion (subcategory) of the settings UI based on the URL, r#settings-reviewers

I decided not to do this when we leave the page scrolled to the top (ie when only
loading a toplevel category, no subcategory), because the search input is still
useful (and consistent) and a single [tab] keypress will focus the initial control
anyway.

Comment 5

[Henry Wilkes (they/them) [:henry-x]]

Thanks for putting a patch together so soon. The current patch would also focus any "Learn More" links if it appears before a form input. For example openPreferences("privacy-sitedata"), which is used in firefox.

Just to add some context to why I opened the bug, in tor browser we have additional calls to openPreferences and one of them would also include a "Learn More" link.

I feel like there are two possible approaches:

1. Expect immediate user input. In this case we want to focus the first form element. A link would not be considered a form element.
2. Expect user to read the heading and introductory text. In this case we want to focus the element's heading.

After thinking about this, I think option 2 is better for screen reader users and is a safer fall back.

One way to do this would be to make the scrolled to groupbox focusable without making it part of the Tab sequence by setting tabindex to -1. You can even move focus and then make it non-focusable again. E.g. you could do

  header.setAttribute("tabindex", "-1");
  header.focus();
  header.removeAttribute("tabindex");

This will move focus for a screen reader to the top of the group and place the screen reader in a browsing mode and from here pressing Tab once will take you to the "Learn More" link or the form input.

Or maybe there is a more privileged accessibility or focus tool that can do the same sort of thing.

Comment 6

[:Gijs (he/him)]

(In reply to Henry Wilkes (they/them) [:henry-x] from comment #5)

Thanks for putting a patch together so soon. The current patch would also focus any "Learn More" links if it appears before a form input. For example openPreferences("privacy-sitedata"), which is used in firefox.

Just to add some context to why I opened the bug, in tor browser we have additional calls to openPreferences and one of them would also include a "Learn More" link.

I feel like there are two possible approaches:

1. Expect immediate user input. In this case we want to focus the first form element. A link would not be considered a form element.

I don't really think it follows that we expect immediate user input - I just think we want to ensure that if the user is tab navigating, focus doesn't end up somewhere useless and it's impossible to get back to the scrolled-into-view section.

Links are focusable on the web so I don't think it's a bad thing to focus a link.

2. Expect user to read the heading and introductory text. In this case we want to focus the element's heading.

After thinking about this, I think option 2 is better for screen reader users and is a safer fall back.

I'm not convinced that making a non-focusable, non-clickable/actionable thing focusable, focusing it, and then removing the focusable state is all that good for screen reader users. Or at least, I don't see why it's better than focusing something that is already focusable - even if that is a "learn more" link. The example in comment 0 focuses the first checkbox in the section, which seems fine.

Jamie, can you chime in?

Comment 7

[Henry Wilkes (they/them) [:henry-x]]

I'm not convinced that making a non-focusable, non-clickable/actionable thing focusable, focusing it, and then removing the focusable state is all that good for screen reader users. Or at least, I don't see why it's better than focusing something that is already focusable - even if that is a "learn more" link.

This was based on testing the patch with Orca. The screen reader has two main modes: browse mode and focus mode. In browse mode the screen reader's position can be anywhere on the page. This is more useful for reading a page. But it is harder to direct the screen reader's browse position (as far as I know, in an unprivileged context). Adding tabindex="-1" is one way to do this.

The example in comment 0 focuses the first checkbox in the section, which seems fine.

In that case, it would be ok. But another would be this caller https://searchfox.org/mozilla-central/rev/185db4a5f794fa6afbbd446944bdeaf640ba7d72/browser/base/content/browser.js#1005 . For a screen reader user it would go like

1. Get a notification about the cache being larger than 5GB.
2. Activate the "Open Settings" button.

Then the screen reader output would be something like "Settings page, tab, 2 of 2. Learn More, Link. Finished loading page ...". So the user would be dropped at the end of a paragraph with very little context, and they would likely still have to do some work to orient themselves. I thought that at least if we drop them at the top of the section and put them in a browsing mode it would be a little less disorientating.

But I would like to hear some more input from Jamie as well.

Comment 8

[Henry Wilkes (they/them) [:henry-x]]

Note, here is the latest version of the patch we have been using in Tor Browser: Tor Browser commit. I've tested it with NVDA, and it seems to be working.

Comment 9

[James Teh [:Jamie]]

Sorry for the... ridiculous delay in responding.

(In reply to :Gijs (he/him) from comment #6)

I'm not convinced that making a non-focusable, non-clickable/actionable thing focusable, focusing it, and then removing the focusable state is all that good for screen reader users.

More on the focus bit below, but it's worth noting that removing tabindex after focusing might be risky. If you switch apps after you do this, some screen readers might lose their position when they return to the app. I'm not certain without explicit testing though. Granted, that's an obscure edge case.

(In reply to Henry Wilkes (they/them) [:henry-x] from comment #7)

This was based on testing the patch with Orca. The screen reader has two main modes: browse mode and focus mode. In browse mode the screen reader's position can be anywhere on the page. This is more useful for reading a page. But it is harder to direct the screen reader's browse position (as far as I know, in an unprivileged context). Adding tabindex="-1" is one way to do this.

An alternative (and theoretically more "correct") way to do this is to use named anchors; e.g. <h3 id="someHeading">Some Heading</h3. There are a few gotchas here, though:

1. Firefox already uses named anchors in about:preferences to jump to pref pages. Can we also use them for specific parts of a page without breaking a bunch of things?
2. Focus will override a named anchor. So, we must not focus the search box if we're specifying a named anchor for a particular part of a page.
3. Screen reader handling of anchor jumping works fairly well across the board if a user activates a link to jump to an anchor on the same page. The story when a page opens at a particular anchor is a bit less consistent. It usually works in NVDA and JAWS, and there are probably things I could do to improve that. In VoiceOver, it just doesn't work at all, though we're looking into how to work around that. I'm not sure about Orca. But these are all issues that really need to be fixed for the benefit of the entire web anyway.

The most pragmatic solution here if we want to be sure of best support across the board "right now" is probably to go with the focus hack, as much as it pains me. The more correct solution is to use named anchors and fix issues associated with those, but that might mean relying on AT vendors to fix things.

I don't know how hard it would be to write the named anchor patch or at least a prototype of it. If it's not a lot of work, I'd be interested to see how it works in practice.