Re: Publishing Updates to Understanding Documents

Hi David,

You are correct, in that WCAG 2.0 never defined what was meant by
"visible".
​

Let me ask you this: Do you agree that b
lack dotted lines on a dark blue background are, for some (many?) users
​ effectivley​
​"in
visible
​"
​?​
(Specifically low-vision users, or
​potentially ​
users with color-blindness concerns.) Since we have no definition in WCAG
2.0 for what "visible
​/invisible​
" means, it is open to interpretation.

And while you may have been there for the original discussions
​ over a decade ago​
, nowhere do I see a note (Normative or otherwise) that backs up your claim
that SC 2.4.7 "*... never intended to fail hard-to-see focus indicators,
just invisible ones*".
​
(Do we have a definition of what "hard-to-see" means? Can that be measured?
At what point do things stop being hard-to-see for you? For me? For our
colleague Jon Avila? Would you agree that there are potentially 3 different
answers there?)​
​
For some users, black lines on dark blue *ARE* invisible
​ - it's contextual (user & user-needs) as well as situationa
l
​ (Desktop versus outdoors on a mobile device on a very sunny day).​

The Understanding document for SC 2.4.7 has the following *Intent *text:


The purpose of this success criterion is to help a person know which
element has the keyboard focus.
​
(*That seems pretty unconditional to me - JF*)


The purpose of this success criterion is to help a person know which
element among multiple elements has the keyboard focus. If there is only
one keyboard actionable control on the screen, the success criterion would
be met because the visual design presents only one keyboard actionable item.

Note that a keyboard focus indicator can take different forms. One common
way is a caret within the text field to indicate that the text field has
the keyboard focus. Another is a visual change to a button to indicate that
that button has the keyboard focus.

​(source: https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html)​


​I don't see any mention there of "hard-to-see". Can you point me to any
other reference that would back up your claim?​


One of the reasons why I asked for these 2.4.7 Techniques to be linked to
the 1.4.11 Understanding document is that it weakly associates the 3:1
measurement back to the WCAG 2.0 SC (
​for some ​
clarity
​, or at a minimum a 'hint'​
), but does not re-write SC 2.4.7.

At the end of the day, it comes down to interpretation, and I remain quite
comfortable with my reading. T
​​
here may not be a direct line between
​SC ​
2.4.7 and
​a ​
3:1 contrast ratio, but
​ I assert​
there are enough dots to connect together and glean a larger understanding
​ and intent. Likewise, while t
​
here may not be a direct line between
​ ​
SC 1.4.11 and SC 2.4.7, when I look at SC 1.4.11 AND SC 2.4.7​ together
holistically, I can make some fairly safe assumptions and assertions (to
whit: "visible = 3:1 color contrast"), *and that no matter what*, because
of SC 2.4.7 the page author is responsible to ensure that the visible tab
focus always remains, well, "visible".

​As I noted previously to Alastair, if you want to stand in front of the
judge and explain​
​ that a thin dotted black lines on a dark-blue background is "visible" to
a low-vision user, I will wish you good luck.

This WG *did* agree to add both the Techniques to the Understanding 1.4.11
document, and I will use those weak associations going forward to defend my
position, as well as to explain and educate clients.​

You
​, and others,​
are welcome to interpret either of these SC in your own way however.

Cheers!

JF


On Fri, Jul 20, 2018 at 3:46 PM, David MacDonald <david100@sympatico.ca>
wrote:

> > renders non-visible the visual focus indicator
>
> The failure doesn't say "renders the visual focus indicator to less than
> 3:1 contrast"
>
> This failure about the focus being identical to the background so that
> there is no visible indication of focus. So if it is *really* hard to see,
> it still passes.  The technique says:
>
> "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." The title is says "renders non-visible"
>
> WCAG 2.0 never failed low contrast focus indicators. And as a person
> involved in all of those discussions back in the day, I can say it was
> never intended to fail hard to see focus indicators, just invisible ones.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
> On Fri, Jul 20, 2018 at 4:08 PM, John Foliot <john.foliot@deque.com>
> wrote:
>
>> 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
>>
>
>


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

Advancing the mission of digital accessibility and inclusion