Re: Publishing Updates to Understanding Documents

> 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
>