Re: Publishing Updates to Understanding Documents

​I totally agree we move to have visible focus in 2.1as much as possible,
but I think this particular failure can only apply where the background and
the focus ring colour are identical or where the ring has been removed.​
Unless we update it for 2.1.

For better or worse, WCAG 2.0 intentionally decided to leave out focus ring
contrast, and only require it be visible, as in, *a different color*. Ugly,
hard to see focus rings that have 1.5:1 ratios pass WCAG 2.0.

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 6:17 PM, Steve Faulkner <faulkner.steve@gmail.com>
wrote:

> I have been following this discussion with interest as I firmly believe
> that default focus indicators are a major blight to the accessibility of
> web UIs for keyboard users.
>
> Therefore I add a hearty +1 in favour of John’s argument and consider the
> inclusion of the failure technique a worthwile attempt to provide some
> mechanism whereby accessibility advocates can have a referencable source to
> add some much needed ‘visibilty’ and clarity to this issue.
>
>
> On Friday, 20 July 2018, 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
>>
>
>
> --
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>
>
>