Closed Bug 1614658 Opened 4 years ago Closed 3 years ago

[MacOS] consider making accessibility.mouse_focuses_formcontrol true by default (was: form controls do not match `:focus` pseudo-selectors when you click on an input, but do when you tab to it.)

Categories

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

73 Branch
All
macOS
defect

Tracking

()

RESOLVED FIXED
88 Branch
Tracking Status
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox88 --- fixed

People

(Reporter: rich, Assigned: emilio)

References

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36

Steps to reproduce:

Actual results:

Click on the input and it has no focus indicator such as the default outline you would expect to see in other versions of Firefox (e.g Windows 10 Firefox).

Expected results:

Clicking on an input should show that the input has focus, normally by showing an outline. Tabbing to the input does show the input focus indicator.

Using Firefox on a windows machine will show the focus indicator. The only way to resolve this is by going to the about:config and explicitly setting the accessibility.mouse_focuses_formcontrol to true. This is currently making life harder for users.

Hi rich,
I can reproduce this on MacOS 10.15 and MacOS 10.13 on all the latest Firefox version. On Windows10 the focus ring will appear correctly.
There are several bugs submitted for focus but nothing specific for MacOS. Moving it over to Graphics, this may be moved to Cocoa if its a better place to treat this issue as MacOS specific.
Thanks for the report!

Status: UNCONFIRMED → NEW
Component: Untriaged → Graphics
Ever confirmed: true
OS: Unspecified → macOS
Product: Firefox → Core
Hardware: Unspecified → All
Summary: Firefox does not honor focus when you click on an input, but does when you tab to it. → [MacOS] Firefox does not honor focus when you click on an input, but does when you tab to it.

Gijs, here's another focus ring issue.

Flags: needinfo?(gijskruitbosch+bugs)

Neil, any idea why the :focus pseudoselector does not match on macOS when it does match on Windows after clicking the radio item?

Component: Graphics → Layout: Form Controls
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(enndeakin)
Summary: [MacOS] Firefox does not honor focus when you click on an input, but does when you tab to it. → [MacOS] form controls do not match `:focus` pseudo-selectors when you click on an input, but do when you tab to it.

Does it match on Safari? Mac has a different focus model than windows.

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

Does it match on Safari?

It does not. Chrome on macOS does do so, however...

Mac has a different focus model than windows.

Right - perhaps the question I should have asked is:

(In reply to rich from comment #0)

The only way to resolve this is by going to the about:config and explicitly setting the accessibility.mouse_focuses_formcontrol to true. This is currently making life harder for users.

Can you elaborate? What prompted this report? If I'm a mouse user, do I really care which element is focused, when it's not a text input field or similar (which doesn't seem to have this problem, I think)? Apple seems to claim the answer to that question is "no, you don't care, so we don't indicate focus".

Flags: needinfo?(rich)

Richard Cooley <rich@dxw.com>
2:21 PM (1 minute ago)
to Bugzilla@Mozilla

Hey,

So I was doing some accessibility work for the Department for Education in the UK. As part of the testing I noticed the on Windows devices and MacOS Chome, that when you click on an input you get a focus state. This is very useful for visually impaired users as we can do more to highlight where they are and what they have clicked one. Its especially useful if they need to go away from the screen or tab for a moment to check some information. It struck me as unusual that it would honor the focus state if a user tabbed to an element but not if they clicked on it.

As we assuming that all mouse users have no visual impairments or that all keyboard users do have visual impairments?

I'm really questioning if Firefox is providing a consistent, accessible and best behaviour? Personally I think Firefox should honor the focus state when clicking on inputs, especially as the convention to do so is already set on Windows. I think Mac OS has it wrong and I wanted to rasie that so we can make life better for those people that would required it, or be forced to change browser (as that is in my humble opinion, easier for people than amending the config which is pretty hidden away)

I've put a link below to the Governement Design System radio button section so that you can see what I'm talking about.

https://design-system.service.gov.uk/components/radios/

Please let me know if I can be for further help.

Thanks,
Rich

Flags: needinfo?(rich)

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

Does it match on Safari? Mac has a different focus model than windows.

Yeah, I think Mac does have a different focus model. So I guess I'm asking is that right as we are assuming that all mouse users have no visual impairments or that all keyboard users do have visual impairments?

Personally I think it should honour focus when you click and as its something that improves life for people who need it, and its just a flag, and changing it could make Mac Firefox more consistent with other browsers then maybe that should be the default behaviour?

(In reply to rich from comment #7)

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

Does it match on Safari? Mac has a different focus model than windows.

Yeah, I think Mac does have a different focus model. So I guess I'm asking is that right as we are assuming that all mouse users have no visual impairments or that all keyboard users do have visual impairments?

I don't think we're making any assumptions about visual impairments - even with 20/20 vision you cannot see what is focused when using the mouse on macOS, so I don't think it's related to visual impairments.

The assumption is that, if you're navigating with a keyboard, focus is important and you want a focus indicator in order to see what element will be focused next if you press [tab] or [shift-tab]. If you navigate with a mouse, you click the next thing you want to click, and which element was focused previously is not important to how you interact with the page, unless you're going to be directing keyboard input to that field (like typing in an input field) - and we do match :focus for input fields after clicking them, as far as I can tell.

changing it could make Mac Firefox more consistent with other browsers

More consistent with Chrome, less consistent with Safari...

I'm personally +1 to make focus work more consistently across platforms in Firefox, but I think historically we generally try to respect the platform conventions and settings for focus and such.

Anyhow that's probably not my decision to make, but Neil's, Olli's, or the UX team even.

Olli, do you know who's call should this be?

Component: Layout: Form Controls → DOM: UI Events & Focus Handling
Summary: [MacOS] form controls do not match `:focus` pseudo-selectors when you click on an input, but do when you tab to it. → [MacOS] consider making accessibility.mouse_focuses_formcontrol true by default (was: form controls do not match `:focus` pseudo-selectors when you click on an input, but do when you tab to it.)

ni? for the above (mid-aired with Gijs :))

Flags: needinfo?(bugs)

I don't think we're making any assumptions about visual impairments - even with 20/20 vision you cannot see what is focused when using the mouse on macOS, so I don't think it's related to visual impairments.

I think that it may be wrong that we are not showing focus with mouse events. Someone has decided that when clicking you don't need that reminder as to where you are an what you have clicked on. By doing that I think we are unintentionally deciding that it is not important for mouse users. Also if we are making it hard to see what is clicked then I struggle to see how that can not be detrimental to people with visual impairments.

If this wasn't important then why have a focus state at all? There is a reason why the people at GDS have put in the time and effort to code up the focus states and visually change the inputs.

The assumption is that, if you're navigating with a keyboard, focus is important and you want a focus indicator in order to see what element will be focused next if you press [tab] or [shift-tab]. If you navigate with a mouse, you click the next thing you want to click, and which element was focused previously is not important to how you interact with the page, unless you're going to be directing keyboard input to that field (like typing in an input field) - and we do match :focus for input fields after clicking them, as far as I can tell.

Sorry I fail to see how that addresses the situation of a user changing tab/looking at something on their computer and then coming back and trying to find out where they currently are on a form. Accessibility users could be people with visual, motor or cognitive impairments and currently when using Firefox on a Mac and trying to navigate back to a form and answer something requires a higher cognitive load than doing it on Windows Firefox.

I do not think that just because "that's how it is currently" is a valid reason for not considering changing something.

changing it could make Mac Firefox more consistent with other browsers

More consistent with Chrome, less consistent with Safari...

Putting aside the OS differences, there is a question here as to which browser better serves users and which one we should be trying to be consistent with.

Because buttons, checkboxes and the like don't get focused on Mac when you click on them.

Focus rings are used to indicate which control accepts keyboard input. In the mac focus model, it is expected that users that are using a mouse to click on a checkbox are not going to then interact with it with the keyboard, so it would be counterproductive to move the focus there. On Windows, the assumption is different and that the focus follows what the mouse is clicked on. Neither model is particularly more correct than the other, so we favour using the platform convention.

A bug making a suggestion to change this comes up every now and again, but we've generally favoured not changing the behaviour.

Flags: needinfo?(enndeakin)
Priority: -- → P3

A bug making a suggestion to change this comes up every now and again, but we've generally favoured not changing the behaviour.

Recent support for :focus-visible might be a good occasion to revisit.

If the spirit of that interaction pattern in macOS/Safari was “showing an outline on a clicked button can be confusing, making it look like a pressed state”, this can be addressed today by styling buttons with :focus-visible styles instead of :focus styles.

This aligns Mac's focus model with other platforms. Matches Chromium, but not
Safari.

Reasons why I think it's worth making this change:

  • Consistency with all other platforms.
  • Makes the :focus-visible implementation more useful.
  • Fixes focus navigation after e.g. clicking a button.
  • Shouldn't cause a lot more outlines to show up (at least not by default).

An example of the second point:

data:text/html,<button onclick="this.nextElementSibling.focus()">Click</button><button>Imagine I'm a dialog close button or something</button>

In non-macOS platforms, we won't show an outline for the button in that case,
which matches the developer expectations (links below). We don't show the
outline because the focus comes from an element that has been focused by mouse
(and thus didn't show an outline). But on macOS that doesn't work, because the
button is not focused.

For completeness, the actual heuristics for :focus-visible may change a bit as
a result of the discussions in:

But it's not clear to me how to best define this so it works on the macOS focus
model.

An example of the third point:

data:text/html,<input type=text><input type=submit><input type=text>

On Safari and Chrome (and Firefox on non-macOS platforms), clicking the button,
then pressing tab, goes to the input on the right. In Firefox on macOS it
doesn't because the button doesn't gain focus nor is selectable.

Assignee: nobody → emilio
Status: NEW → ASSIGNED
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/836a840bffc6
Enable accessibility.mouse_focuses_formcontrol by default. r=mac-reviewers,bradwerth,mstange
Regressions: 1699324
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
Blocks: 1699570
Regressions: 1713739
See Also: → 1843669
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: