Closed Bug 1284235 Opened 8 years ago Closed 6 months ago

Suggest increasing visibility of default focus ring to improve usability/accessibility for keyboard users

Categories

(Firefox :: Disability Access, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: faulkner.steve, Unassigned)

References

Details

(Keywords: access)

Attachments

(2 files)

Whe a user navigates focusable elements such as links, using the keyboard, the visibility of the element with current focus is important for usability and accessibility. Currently the default focus ring CSS for links in Firefox is:

:-moz-any-link:-moz-focusring {
    outline: 1px dotted;
}

I find this difficult so see and kepp track of when navigating pages using the keyboard.

is it possible to bump the size up to make it easier to see?

example:


:-moz-any-link:-moz-focusring {
    outline: 2px dotted;
}
CC'ing a few people who might be able to help with this. Helen and Yura, you recently worked on the focus visibility stuff in the scope of the dev tools. Were there any talks about increasing visibility overall in Firefox?
Flags: needinfo?(yzenevich)
Flags: needinfo?(hholmes)
(In reply to Marco Zehe (:MarcoZ) from comment #1)
> CC'ing a few people who might be able to help with this. Helen and Yura, you
> recently worked on the focus visibility stuff in the scope of the dev tools.
> Were there any talks about increasing visibility overall in Firefox?

We didn't discuss overall visibility in Firefox. Our devtools journey went like this:

The biggest jumps were made in getting any sort of focus state enabled (devtools had lots of places where there were no focus states at all, and now there are). So that was easy-pickings, nothing > something.

For inputs/textareas, we relied on the prior work that members of the UX team had already completed from here: http://fxos-components.github.io/gaia-components/ (In order for these to work, dom.webcomponents.enabled needs to be set to true.)

For other components, we used the focusring in Comment #0. We never got any further than adding that focus ring.
Flags: needinfo?(hholmes)
Helen, do you think we should bring this up with a broader group? Perhaps you know the right person to point to?

I experimented with the blue box-shadow but it was a bit too intrusive for the markup view.
Flags: needinfo?(yzenevich) → needinfo?(hholmes)
There was also a version with the outline being of a current font color.
(In reply to Yura Zenevich [:yzen] from comment #3)
> Helen, do you think we should bring this up with a broader group? Perhaps
> you know the right person to point to?
> 
> I experimented with the blue box-shadow but it was a bit too intrusive for
> the markup view.

I definitely think we should. I don't know who the right person is exactly, so I think it would be best to bring up in our weekly UX meeting. 

If the answer is that there are no designs/no design thinking as of yet, I'll create a small prototype with some variations and present them to the larger team. I've already invited you to that meeting Yura, in the event thatdesigns aren't already created in which case I'll get those designs started.
Flags: needinfo?(hholmes)
Apple products such as VoiceOver apply a double border with one rectangle black and one white to ensure there is always high contrast on focus no matter what the background color of content is.  This isn't the only solution but I thought I mention this to get the conversation started about providing highly visible indication of focus in situations where you may not know the content behind the focus.  There are other methods such as XOR but that might cause the colors of the focus ring to change which could be confusing.
Any news about the focus ring visibility improvement?
Gijs maybe we could conduct an experiment/study for this?
Flags: needinfo?(gijskruitbosch+bugs)
Priority: -- → P2
(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #8)
> Gijs maybe we could conduct an experiment/study for this?

I'm not sure how to help - are you asking "is it technically feasible to do a study about this?" or "can you organize a study for this" or "how do we get traction here"? :-)

For a SHIELD study you'd need an alternative implementation / styling behind a pref, or an add-on that implemented such a thing.

For other types of user studies I imagine you'd want to talk to user research directly.

Either way I think we effectively need 3 things:
(1) a design with some thinking behind why/how we adjust the styling
(2) a means of measuring both effectiveness for people who are helped by this type of thing (no point doing this if it doesn't help folks who need better focus indicators) and distraction / intrusion feedback (however subtle) relating to the new default appearance clashing with website design from users who don't routinely "use" focus indicators.
(3) some idea about impact on web compat

For (3), websites routinely mess with focus indicators (sometimes for the better, and sometimes not...). Changing how they can expect to mess with it has web compat fallout. I don't know to what degree the web relies on this, and how similar (or not) our implementation is to that of other browsers. It's quite possible that a new design would require more than just changing the CSS outline property, and as a result that would change how websites would (or wouldn't) be able to manipulate this styling, which would make it more difficult to deploy such a change.

Unfortunately, I am likely not the right person to really help with any of these 3 things. UX/design folks can help with (1), user research can potentially help with (2), and some of the more platform-y folks would be better for (3). I hope that helps?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(dbolter)
Thank you! A SHIELD study would be interesting (to me). I'll do a bit of leg work first.

Mike do you have web compat guidance (see comment 9)?
Flags: needinfo?(dbolter) → needinfo?(mitaylor)
(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #10) 
> Mike do you have web compat guidance (see comment 9)?

Generally a good idea is to survey how other browsers behave. If our changes will affect layout (tweaks to just `outline` shouldn't), it would be good to do a focused A/B test of some top sites to see what the real world effects will be. Like Gijs said, it probably depends on the end-result. Doing some work to see how sites commonly modify -moz-focusring would be instructive as well.
Flags: needinfo?(mitaylor)
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Some related things:

WCAG 2.1 Success Criterion 1.4.11: Non-text Contrast
Requires 3:1 contrast for focus indicators
https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

Platform stuff:
- bug 1445482 for :focus-visible / :-moz-focusring
- bug 140562, bug 1113202 and probably more relating to ::-moz-focus-inner

Firefox UX: Photon Design System has a recommended style for focus indicators
(Though I'm not seeing it applied much in Firefox UI...)
https://design.firefox.com/photon/components/buttons.html#default-4
https://design.firefox.com/photon/components/input-fields.html#behaviors

(And anecdotally, for DevTools UI: we're exploring improved focus styles in bug 1502098.)
Attached image chrome focus.png
Looking at proton style guide I get the color #0a84ff.
Transparency is not a good idea because it becomes invisible if the background is dark.
With this and using Chrome as comparation I've got this

box-shadow: 0 0 0 2px #0a84ff;

If you accept this, I can create a patch.
Flags: needinfo?(odvarko)
I like the idea.

When inspecting using the Browser Inspector I found this place, is it related?

--theme-focus-outline: 1px dotted var(--theme-focus-outline-color);
https://searchfox.org/mozilla-central/rev/55895c49f55073d82d977cb74ec1d3a71ae4b25f/devtools/client/themes/variables.css#207

@Matt: what do you think?

Honza
Flags: needinfo?(odvarko) → needinfo?(mcroud)
Just for clarity, this bug is about web content in general, not devtools. See bug 1502098 for the relevant DevTools discussion.

To make progress on this (general focus ring style for web content), as far as I can tell, we might need:
1. A design.
2. Ideally, information on what can be implemented and how.

On the design side:

- Different elements may have different focus styles (links, <input type="text">, <input type="checkbox|radio">, <select>, <video controls>, etc.)
- Different platforms (Windows, macOS, Linux, Android) might require platform-specific styles too, unless we make a case for a more uniform styling.

It would be great to talk with Firefox UX to know if they would like to investigate focus styles for web content, looking at what Firefox and other browsers do on different platforms.

On the implementation side:

- It's likely that either `outline:none` (and perhaps `-moz-appearance:none`) should still remove the default outline, even if that default outline looks like box-shadow; we can't just implement it with box-shadow in resource://gre-resources/ua.css and be done, that would be a major regression on a bunch of sites.

- Some elements use shadow-domy stuff / pseudo-elements for focus styles, especially <button> which has an inner outline (common reset = ::-moz-focus-inner {border: none;}). I think it was a style made to mimick Windows buttons but which is somewhat obselete because Windows moved away from the inner-outline style; maybe that one can be removed.
Yes this is certainly something to be explored. 

It would be beneficial to have people nominate websites/examples where the current focus ring gets lost easily so that design suggestions can built up from there.

A start would be an audit of other browser implementations, do they have a single uniform pattern for focus style regardless of the type of element focused?

It is difficult to judge what is deemed visually intrusive when considering the needs of those who rely on such a feature. Perhaps beyond this scope but the ability to have a more “prominent mode” might be worth exploring.
Flags: needinfo?(mcroud)

Is this different from bug 251198? If so, how?

I believe the first step would be to just make sure the default focus ring meets a 3 to 1 color contrast requirement (based on WCAG 2.1 SC 1.4.11) against the default page background. Then, if a dev or designer changes either the focus ring color or the background color...that dev/designer is responsible.

Or better yet, go with an "oreo" 3 pixel wide focus ring (black 1 px line, white 1 px line, black 1 px line).

It seems to me that currently, there the generic focus ring (i.e. currently, dotted border) and then focus ring of native, unstyled elements (e.g. <button>s, <select>s, etc.).

Dotted border is often hard to see, and looks old in my opinion. I personally like the thick blue border with space around the element, found in e.g. about:preferences and about:addons. It doesn’t seem to work well for some websites were the outline is partly hidden by other elements, but for reference, here’s the CSS code for this (that you can try by using e.g. Stylus):

outline: 2px solid #0a84ff;
outline-offset: 2px;

In Chrome 83, the focus ring was changed (and it’s also what’s used on Edge, Opera and Vivaldi):

Previously, Chromium used a light single color outline to indicate the focused element. However, if the focused element happened to be on a similarly colored background, the ring would be difficult to perceive[.]
[…]
The new focus indicator uses a thick dark ring with a thin white outline, which should improve visibility on both light and dark backgrounds. This is an easy accessibility win that automatically improves the keyboarding experience on a number of sites without developers needing to write any new code.
https://blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html

See also «More accessible controls» in https://blogs.windows.com/msedgedev/2019/10/15/form-controls-microsoft-edge-chromium/

I can’t find how they do the focus ring in CSS though, maybe it’s more involved than that.

Severity: normal → --
See Also: → 1626512

Better than improving the indicator style, I'd like to suggest making the focus indicator a user-customizable feature that isn't exposed to page CSS. I.e., make it unaffected by page styles so it cannot be altered by the page author and is under the complete control of the user.

If that was done, the question of the default styling would be much less of a concern.

There were recently default focus outline changes that :Asa has championed - and I think now Firefox has the best indication across OS and browsers - it is a double outline that uses AccentColor on Mac and Firefox Blue on Windows without any HCM, and on Windows with a High Contrast Mode on the colors are changed to CanvasText that is partially transparent and SelectedItem that is opaque.

Attached is the screenshot of the observations, the Windows HCM used was Night Sky, MacOS accent color set to purple on the test machine.

The current color contrast does provide sufficient color contrast for the white page background (default, color contrast is 5.6:1) as well as black backgrounds (color contrast is 3.7:1) and the focus indication is 2px or more in thickness by default, thus satisfies both WCAG 2.2 Level AAA Success Criterion 2.4.13 Focus Appearance and Level AA SC 1.4.11 Non-text Contrast.

Considering the changes in the default styles, I recommend to close this bug as resolved.

Depends on: 1791024
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: