- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Fri, 20 Jul 2018 23:17:29 +0100
- To: John Foliot <john.foliot@deque.com>
- Cc: Alastair Campbell <acampbell@nomensa.com>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CA+ri+V=hgA_3oSwT-GjjAr3daoBeW=ETw4hrnePqGMHhUh_uLA@mail.gmail.com>
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/>
Received on Friday, 20 July 2018 22:17:54 UTC