E-mail List Archives

Thread: Firefox visual focus indication

for

Number of posts in this thread: 5 (In chronological order)

From: Schafer, Carmen
Date: Thu, Sep 28 2017 10:22AM
Subject: Firefox visual focus indication
No previous message | Next message →

Are others considering it a violation of 2.4.7 (Focus Visible) when a website doesn't enhance the browser’s default focus indicator since Firefox’s default thin black dotted line focus indicator is difficult to see yet Chrome has a more distinct default focus indicator (solid blue line)?

I just want to be clear what is considered a true violation of 2.4.7.

Thanks,
Carmen

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jonathan Avila
Sent: Friday, November 18, 2016 2:32 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Firefox visual focus indication

> This is a major problem for the user. It is also a problem when testing. We could argue that a digital property is in direct violation of SC 2.4.7 Focus Visible by not providing visual focus indication in Firefox. In my mind, it violates 1.3.1 of UAAG 2.0 because Firefox is not providing "Active keyboard focus" on radio buttons and checkboxes.

I would consider whether the ability to see the focus is because of the technique used or because of how the user agent works in determining conformance. For example, we have run into examples where certain techniques such as floating images in links can cause the visual indication of focus to go away. In other cases use of CSS to create custom radio buttons or the use of CSS over top of standard radio buttons to create a custom look caused the issue. Thus, if the issue occurs on a standard control that hasn't been affected by CSS then it seems like it is not the fault of the author although there are things you can do to overcome the issue. Other times things we do in CSS can cause these problems and authors need to address them or apply visible focus indicators using other techniques to compenstate.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)

Visit us online: Website | Twitter | Facebook | Linkedin | Blog Join SSB at Accessing Higher Ground This Month!

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.


-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Beranek, Nicholas
Sent: Thursday, November 17, 2016 1:02 PM
To: WebAIM Discussion List
Subject: [WebAIM] Firefox visual focus indication

Hi folks,

In Firefox, we are experiencing many issues with visual focus indication. That is, the outline or "focus ring" that is supposed to appear for active elements, in many cases, does not exist or is very difficult to see. This is especially true for radio buttons and checkboxes. For radio buttons, we are unable to determine focus at all. For checkboxes, there is a 1px dotted outline on the right side alone, hardly enough to satisfy for proper visual focus indication. You can test this by tabbing to a radio button or checkbox and check for focus outline.

This is a major problem for the user. It is also a problem when testing. We could argue that a digital property is in direct violation of SC 2.4.7 Focus Visible by not providing visual focus indication in Firefox. In my mind, it violates 1.3.1 of UAAG 2.0 because Firefox is not providing "Active keyboard focus" on radio buttons and checkboxes.

So, my questions are the following:


* Are the folks at Mozilla doing anything to fix this bug?

* Of the bug reports that exist, are we doing anything to ensure Mozilla's engineers fix the focus indication bug? (Link to "radio button focus" search on bugzilla: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=radio+button+focus)

* Have you done anything within your own CSS to compensate for this?

* Could this have something to do with Firefox taking to color property's value as the color for the focus outline?

Thank you so much for your time,

Nick Beranek
Capital One

The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

From: Patrick H. Lauke
Date: Thu, Sep 28 2017 10:30AM
Subject: Re: Firefox visual focus indication
← Previous message | Next message →

On 28/09/2017 17:22, Schafer, Carmen wrote:
> Are others considering it a violation of 2.4.7 (Focus Visible) when a website doesn't enhance the browser’s default focus indicator since Firefox’s default thin black dotted line focus indicator is difficult to see yet Chrome has a more distinct default focus indicator (solid blue line)?
>
> I just want to be clear what is considered a true violation of 2.4.7.

Taking a strict reading of WCAG 2, there's no real requirement for how
"visible" a focus indicator needs to be (as "visible" is not really a
testable adjective).

https://github.com/w3c/wcag/issues/302

So going strictly by WCAG 2, an indicator that's difficult to see is
still "visible", so you'd pass it...but I would definitely note that
although it passes nominally, it's really insufficient and the author
should provide an explicit strong indicator.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Beranek, Nicholas
Date: Thu, Sep 28 2017 10:37AM
Subject: Re: Firefox visual focus indication
← Previous message | Next message →

Using the default browser focus indicator is a sufficient technique: https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G165

It becomes a failure when the focus indicator is suppressed via CSS through means of outline: none, for example (see www.outlinenone.com for more details!).

If you roll your own, you need to ensure that it's "highly visible". WCAG does not define this term, but we have interpreted it to mean that we should strive for a 4.5 to 1 color contrast ratio.

Nick Beranek
Capital One

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Patrick H. Lauke
Sent: Thursday, September 28, 2017 12:31 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Firefox visual focus indication

On 28/09/2017 17:22, Schafer, Carmen wrote:
> Are others considering it a violation of 2.4.7 (Focus Visible) when a website doesn't enhance the browser’s default focus indicator since Firefox’s default thin black dotted line focus indicator is difficult to see yet Chrome has a more distinct default focus indicator (solid blue line)?
>
> I just want to be clear what is considered a true violation of 2.4.7.

Taking a strict reading of WCAG 2, there's no real requirement for how "visible" a focus indicator needs to be (as "visible" is not really a testable adjective).

https://github.com/w3c/wcag/issues/302

So going strictly by WCAG 2, an indicator that's difficult to see is still "visible", so you'd pass it...but I would definitely note that although it passes nominally, it's really insufficient and the author should provide an explicit strong indicator.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

From: John Foliot
Date: Thu, Sep 28 2017 11:15AM
Subject: Re: Firefox visual focus indication
← Previous message | Next message →

Hi All,

FWIW, there is a proposed new Success Criteria being advanced for WCAG 2.1.
-

*Success Criterion 1.4.12 User Interface Component Contrast (Minimum)​
- (Level AA)*
http://rawgit.com/w3c/wcag21/accessible-name-terminology-sync/guidelines/#user-interface-component-contrast-(minimum)

It currently states:


Essential
<http://rawgit.com/w3c/wcag21/accessible-name-terminology-sync/guidelines/#dfn-essential>;
visual
identifiers of user interface components
<http://rawgit.com/w3c/wcag21/accessible-name-terminology-sync/guidelines/#dfn-user-interface-component>;
have
a contrast ratio
<http://rawgit.com/w3c/wcag21/accessible-name-terminology-sync/guidelines/#dfn-contrast-ratio>;
of
at least 4.5:1 against the immediate surrounding color(s), except for the
following situations:
ThickerA contrast ratio of at least 3:1 is required where the minimum width
and height are at least 3 CSS pixels
<http://rawgit.com/w3c/wcag21/accessible-name-terminology-sync/guidelines/#dfn-css-pixel>;,
for the essential visual identifier;InactiveDisabled or otherwise inactive
user interface components;User Agent ControlThe color(s) of the user
interface component and any adjacent color(s) are determined by the user
agent and are not modified by the author.
NOTE

Examples of essential visual identifiers of user interface components may
include (a border, edge, or icon), current value (such as non-text visual
indication of aria-valuenow on a slider) and current state (such as
selection indicator, focus indicator) or other essential visual indication
(which do not rely on color alone).
EDITOR'S NOTE

- Under consideration: simplify this Success Criterion by setting the
minimum color contrast requirement to 3:1 and removing any need for
measuring thickness.
- Under consideration: will review to see if it is possible to combine
with proposed WCAG 2.1 SC 1.4.11 Graphics Contrast.

HTH

JF

On Thu, Sep 28, 2017 at 11:37 AM, Beranek, Nicholas via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:

> Using the default browser focus indicator is a sufficient technique:
> https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G165
>
> It becomes a failure when the focus indicator is suppressed via CSS
> through means of outline: none, for example (see www.outlinenone.com for
> more details!).
>
> If you roll your own, you need to ensure that it's "highly visible". WCAG
> does not define this term, but we have interpreted it to mean that we
> should strive for a 4.5 to 1 color contrast ratio.
>
> Nick Beranek
> Capital One
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Patrick H. Lauke
> Sent: Thursday, September 28, 2017 12:31 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Firefox visual focus indication
>
> On 28/09/2017 17:22, Schafer, Carmen wrote:
> > Are others considering it a violation of 2.4.7 (Focus Visible) when a
> website doesn't enhance the browser’s default focus indicator since
> Firefox’s default thin black dotted line focus indicator is difficult to
> see yet Chrome has a more distinct default focus indicator (solid blue
> line)?
> >
> > I just want to be clear what is considered a true violation of 2.4.7.
>
> Taking a strict reading of WCAG 2, there's no real requirement for how
> "visible" a focus indicator needs to be (as "visible" is not really a
> testable adjective).
>
> https://github.com/w3c/wcag/issues/302
>
> So going strictly by WCAG 2, an indicator that's difficult to see is still
> "visible", so you'd pass it...but I would definitely note that although it
> passes nominally, it's really insufficient and the author should provide an
> explicit strong indicator.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > >
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
> > > > >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
= EMAIL ADDRESS REMOVED =

Advancing the mission of digital accessibility and inclusion

From: Schafer, Carmen
Date: Thu, Sep 28 2017 11:49AM
Subject: Re: Firefox visual focus indication
← Previous message | No next message

Thanks for all the useful feedback!

Carmen

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of John Foliot
Sent: Thursday, September 28, 2017 12:16 PM
To: Beranek, Nicholas < = EMAIL ADDRESS REMOVED = >; WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Firefox visual focus indication

Hi All,

FWIW, there is a proposed new Success Criteria being advanced for WCAG 2.1.
-

*Success Criterion 1.4.12 User Interface Component Contrast (Minimum)​
- (Level AA)*
http://rawgit.com/w3c/wcag21/accessible-name-terminology-sync/guidelines/#user-interface-component-contrast-(minimum)

It currently states:


Essential
<http://rawgit.com/w3c/wcag21/accessible-name-terminology-sync/guidelines/#dfn-essential>;
visual
identifiers of user interface components <http://rawgit.com/w3c/wcag21/accessible-name-terminology-sync/guidelines/#dfn-user-interface-component>;
have
a contrast ratio
<http://rawgit.com/w3c/wcag21/accessible-name-terminology-sync/guidelines/#dfn-contrast-ratio>;
of
at least 4.5:1 against the immediate surrounding color(s), except for the following situations:
ThickerA contrast ratio of at least 3:1 is required where the minimum width and height are at least 3 CSS pixels <http://rawgit.com/w3c/wcag21/accessible-name-terminology-sync/guidelines/#dfn-css-pixel>;,
for the essential visual identifier;InactiveDisabled or otherwise inactive user interface components;User Agent ControlThe color(s) of the user interface component and any adjacent color(s) are determined by the user agent and are not modified by the author.
NOTE

Examples of essential visual identifiers of user interface components may include (a border, edge, or icon), current value (such as non-text visual indication of aria-valuenow on a slider) and current state (such as selection indicator, focus indicator) or other essential visual indication (which do not rely on color alone).
EDITOR'S NOTE

- Under consideration: simplify this Success Criterion by setting the
minimum color contrast requirement to 3:1 and removing any need for
measuring thickness.
- Under consideration: will review to see if it is possible to combine
with proposed WCAG 2.1 SC 1.4.11 Graphics Contrast.

HTH

JF

On Thu, Sep 28, 2017 at 11:37 AM, Beranek, Nicholas via WebAIM-Forum < = EMAIL ADDRESS REMOVED = > wrote:

> Using the default browser focus indicator is a sufficient technique:
> https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G165
>
> It becomes a failure when the focus indicator is suppressed via CSS
> through means of outline: none, for example (see www.outlinenone.com
> for more details!).
>
> If you roll your own, you need to ensure that it's "highly visible".
> WCAG does not define this term, but we have interpreted it to mean
> that we should strive for a 4.5 to 1 color contrast ratio.
>
> Nick Beranek
> Capital One
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Patrick H. Lauke
> Sent: Thursday, September 28, 2017 12:31 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Firefox visual focus indication
>
> On 28/09/2017 17:22, Schafer, Carmen wrote:
> > Are others considering it a violation of 2.4.7 (Focus Visible) when
> > a
> website doesn't enhance the browser’s default focus indicator since
> Firefox’s default thin black dotted line focus indicator is difficult
> to see yet Chrome has a more distinct default focus indicator (solid
> blue line)?
> >
> > I just want to be clear what is considered a true violation of 2.4.7.
>
> Taking a strict reading of WCAG 2, there's no real requirement for how
> "visible" a focus indicator needs to be (as "visible" is not really a
> testable adjective).
>
> https://github.com/w3c/wcag/issues/302
>
> So going strictly by WCAG 2, an indicator that's difficult to see is
> still "visible", so you'd pass it...but I would definitely note that
> although it passes nominally, it's really insufficient and the author
> should provide an explicit strong indicator.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > >
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The
> information transmitted herewith is intended only for use by the
> individual or entity to which it is addressed. If the reader of this
> message is not the intended recipient, you are hereby notified that
> any review, retransmission, dissemination, distribution, copying or
> other use of, or taking of any action in reliance upon this
> information is strictly prohibited. If you have received this
> communication in error, please contact the sender and delete the material from your computer.
> > > archives at http://webaim.org/discussion/archives
> >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
= EMAIL ADDRESS REMOVED =

Advancing the mission of digital accessibility and inclusion