[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)
Tracking
()
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:
- Start Firefox on a Mac
- Load a page with radio buttons e.g. https://design-system.service.gov.uk/patterns/question-pages/
- Click on a radio button and you will see that there is not a focus state applied to the input
- Tab to the next input and you will see that there is a focus state applied to the input
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.
Comment 1•4 years ago
|
||
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!
Comment 2•4 years ago
|
||
Gijs, here's another focus ring issue.
Comment 3•4 years ago
|
||
Neil, any idea why the :focus
pseudoselector does not match on macOS when it does match on Windows after clicking the radio item?
Assignee | ||
Comment 4•4 years ago
|
||
Does it match on Safari? Mac has a different focus model than windows.
Comment 5•4 years ago
|
||
(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".
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
(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?
Comment 8•4 years ago
|
||
(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...
Assignee | ||
Comment 9•4 years ago
|
||
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?
Reporter | ||
Comment 11•4 years ago
|
||
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.
Comment 12•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 13•3 years ago
|
||
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.
Assignee | ||
Comment 15•3 years ago
|
||
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:
- https://github.com/w3c/csswg-drafts/issues/5885
- https://github.com/web-platform-tests/wpt/pull/27806
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.
Updated•3 years ago
|
Comment 16•3 years ago
|
||
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
Comment 17•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Description
•