Publishing Updates to Understanding Documents

Alastair,

> *​*As discussed in multiple the calls and recorded in the surveys, we
didn’t get consensus on failing default-focus-indicators due to background
changes.

This merry-go-round re 1.4.11 interpretation helps nobody. You and I have a
fundamental difference in interpretation, and despite multiple discussions,
we've not reached agreement on this topic. I am happy however to re-open
the issue if you feel this requires even more discussion.

*SC 1.4.11 Non-Text Contrast* states:

The visual presentation of the following have a contrast ratio of at least
3:1 against adjacent color(s):

User Interface Components: Visual information required to identify user
interface components and states, except for inactive components or where
the appearance of the component is determined by the user agent and not
modified by the author;


Contrast is inherently about adjacency (as the text of the SC notes) - one
color next to the other (irrespective of where or how it appears on
screen), and it is clear via SC 2.4.7 and the associated Failure Technique
that if you change the background, *and it has an impact on the visible
focus* (a.k.a. State indication - "this thing's current state is *focused*"),
the author needs to make adjustments there as well, that the default
styling in the browser could very well be insufficient when you make
changes to the background. That is *precisely* what F78 states:

*Failure of Success Criterion 2.4.7
<https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F78>* due to styling
element outlines and borders in a way that removes or renders non-visible
the visual focus indicator

*Description*

This describes a failure condition that occurs when the user agent's
default visual indication of keyboard focus is turned off *or rendered
non-visible by other styling on the pag**e* *without providing an
author-supplied visual focus indicator*.
​[emphasis mine]​
Turning off the focus indicator instructs the user agent not to present the
focus indicator. Other styling may make it difficult to see the focus
indicator even though it is present, such as outlines that look the same as
the focus outline, or thick borders that are the same color as the focus
indicator so it cannot be seen against them.

Failure Example 3: Elements have a border that occludes the focus indicator

The following CSS example creates a border around links that does not have
enough contrast for the focus indicator to be seen when drawn on top of it.
In this case the focus indicator is drawn just ouside the border, but as
both are black and the border is thicker than the focus indicator, it no
longer meets the definition of "visible".​


​You don't want to fail somebody on 1.4.11 because of native browser
default styling? Fine. They still fail on 2.4.7 if the visible tab focus is
rendered in such a way that the focus indicator is not "visible" due to
"...other styling on the page...".


*​​2.4.7 Focus Visible <https://www.w3.org/TR/WCAG21/#focus-visible>:* Any
keyboard operable user interface has a mode of operation where the keyboard
focus indicator is visible. (Level AA)

WCAG 2.0 never defined a measurement for "visible", but I assert that
1.4.11 does (minimum of 3:1).

This has been a long standing problem for some time now, and all
assessments I've ever completed have called out the native "dotted line on
dark background focus indication" as a Failure of 2.4.7 (has anybody not?),
and since WCAG 2.1 is also intended to not "re-interpret" WCAG 2.0 (aka
preserve backward compatibility), Firefox's dotted black lines on a
navy-blue background will fail 2.4.7 - plain and simple, *per Failure
Technique F78:*

Procedure


   1. Set the focus to all focusable elements on a page using the keyboard.

   2. Check that the focus indicator is visible.


Understanding and Techniques documents are non-normative, and unfortunately
the two SC I am referencing are not in complete sync, but that is due to
interpretation: 1.4.11 neither agrees nor disagrees with either of our
interpretations via the normative SC language alone. I argue that state
indication is independent of the component, you want to keep those two
concepts linked. The SC language currently leaves that open to
interpretation.

It is not an accident then that I requested that this Failure Technique be
added to the Understanding Document - it now links these two SC together,
albeit weakly, but linked none-the-less (i.e., I can point to the 3:1
measurement now for help in interpreting "visible" in 2.4.7). It is nowhere
as strong as I wanted it to be, but it gives me enough skin in the game to
conclude & defend my assertion.

As you know, the US is significantly more litigious than the UK, and in a
court of law my argument would (I further assert) stand muster. Your
current interpretation, while perhaps technically defensible, fails the
spirit and intent of WCAG, and I know that I personally will counsel
clients that if you change the background, and it impacts the visible focus
indicator (by making it less than 3:1 contrast) that they will need to
modify that as well: that the "native" defaults DO NOT meet the spirit and
intent of WCAG if other styling - in any fashion - renders visible tab
focus "non-visible".

Ultimately, for any legal challenge, it will need to be brought before a
judge. I assert that by linking this Failure Technique for SC 2.4.7 to the
new SC 1.4.11, it makes the intent clearer to the layman (aka the judge). I
will thus continue to promote my interpretation as the "better safe than
sorry" interpretation, *noting that the experts never really did come to an
agreement on this*, but for technical reasons left it as it stands (with
the linked Failure Technique the stop-gap solution to allow us to move
forward).

Peace out.

JF



On Tue, Jul 17, 2018 at 5:25 PM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi John,
>
>
>
> I think the PR you’re looking for is this one:
>
> https://github.com/w3c/wcag/pull/373/files
>
>
> *​​*
>
> As discussed in multiple the calls and recorded in the surveys, we didn’t
> get consensus on failing default-focus-indicators due to background changes.
>
>
>
> The title, description and examples of F78 refer to the *element*, not
> the background.
>
>
>
> I’ll check why the changes haven’t come through to the published version,
> I thought they had.
>
>
>
> Kind regards,
>
>
>
> -Alastair
>
>
>
>
>
> *From:* John Foliot
>
>
>
> Hi All,
>
>
>
> While I cannot put my hands on the GitHub notification that the
> Understanding document for SC 1.4.11 has been updated, we reached a
> concensus position a few weeks back to add the following Techniques to the
> understanding document for SC 1.4.11:
>
>
>
> Success Technique: https://www.w3.org/WAI/WCAG21/Techniques/general/G195
>
> Description
>
> The objective of this technique is enhance the focus indicator in the
> browser, by creating a highly visible one in the content. The default focus
> indicator in many browsers is a thin,dotted, black line. It can be
> difficult to see the line when it is around a form element which already
> has an outline, when the focused element is inside a table cell, when the
> focused element is very small, or when the background of the page is a
> dark color.
>
> In this technique, when the user places focus on an element, using the
> mouse, tab key, arrow keys, keyboard shortcuts, or any other method, the
> application makes that focus more visible, using a combination of a highly
> contrasting color, a thick line, and other visual indicators such as a glow.
>
> Now... here, "highly visible" (or for that matter "visible") is undefined,
> at least in WCAG 2.0. I assert that 1.4.11 now defines that as a contrast
> minimum, and since this Technique is now attached to the Understanding
> 1.4.11, I further assert this is true and intentional.
>
>
>
> Also:
>
>
>
> Failure Technique: https://www.w3.org/TR/WCAG20-TECHS/F78.html
>
>
>
> Description
>
> This describes a failure condition that occurs when the user agent's
> default visual indication of keyboard focus is turned off or rendered
> non-visible by other styling on the page without providing an
> author-supplied visual focus indicator.
>
> ​
>
>
>
> As noted on today's call, the officially published version of the
> Understanding Document for SC 1.4.11 has not been updated (and I struggle
> to find the Git version to point people to). It is hoped that this update
> can be addressed in a timely fashion.
>
>
>
> Thanks.
>
>
>
> JF
>
> --
>
> John Foliot
>
> Principal Accessibility Strategist
>
> Deque Systems Inc.
>
> john.foliot@deque.com
>
>
>
> Advancing the mission of digital accessibility and inclusion
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion