RE: Updates to Understanding 1.4.11

John, after re-reading the language of the exception “or where the appearance of the component is determined by the user agent and not modified by the author” you are right that we say “component” and not the state indicator”.   So in the case where the author changes the background color of a button they are changing the component and thus the exception no longer applies.  I’m not sure this was the intention of the group or not.

Jonathan


From: Jonathan Avila
Sent: Monday, June 04, 2018 10:09 AM
To: John Foliot; Andrew Kirkpatrick
Cc: David MacDonald; WCAG
Subject: RE: Updates to Understanding 1.4.11

Hi John,

My assumption was that we were allowing it to pass if they used the default focus ring.  Given the different focus options out there it is difficult to solve cross browser without just turning off the default focus indicator– and do we really want to encourage people to always create their own indicators?    In particular Chrome’s focus can be hard to see in some combinations but that seems more like an issue to be solved in Chrome rather than by all developers.  In fact the indicator on Mac is different from Chrome on Windows.  IE is the only browser that does it correctly by using a dotted xor rectangle where every other dot is inverted and the next is black that way you have automatic contrast with the inversion. Firefox doesn’t do this and just uses black by default.  Seems like user agents should be better about this like VoiceOver is with it’s indicator.

So while I would like to solve the issue of standard focus indicators on a custom background color this may be a more nuanced tasked that we have not considered the impact on all cases.

Jonathan

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Friday, June 01, 2018 11:55 AM
To: Andrew Kirkpatrick
Cc: David MacDonald; WCAG
Subject: Re: Updates to Understanding 1.4.11

Yikes, then I have a significant concern with that.

If the content author modifies the background color(s) of some or all of the content on the screen, then they have a responsibility to also modify all associated foreground colors impacted by that choice/decision, which includes over-riding the browser's native visible tab focus indication. Failing to be explicit about that is a pretty significant issue in my mind.

This needs to be clearly underscored in the Understanding document (given it's likely too late to once again fine-tune the language, unless that is still ongoing, but given' Michael's note to the AC Reps that went out this morning...)

JF

On Fri, Jun 1, 2018 at 10:39 AM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:

> ...except where the appearance of the component is determined by the user agent and not modified by the author.

Hmmm... this might be open to being interpreted as "If you do not specify the visible tab focus, and leave it to the native 'styling' provided by the browser, then black dotted lines around a component situated on a dark background is exempted/acceptable"  ...which is not what we are saying (right?)

I think that we are saying that…

AWK

On Fri, Jun 1, 2018 at 10:01 AM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:
Thanks for looking at this everyone.  Comments within:

"With the exception of inactive components or where the appearance of the component (including it's focus indicator) is determined by the user agent (and not modified by the author), the visual focus indicator for a component must always provide sufficient contrast against the adjacent background when the component is focused.​"​

How about:
The visual focus indicator for a component must have sufficient contrast against the adjacent background when the component is focused, except where the appearance of the component is determined by the user agent and not modified by the author.

I don’t think that we need to mention inactive components since inactive components don’t take focus.

AWK



On Fri, Jun 1, 2018 at 6:26 AM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:
I agree

I put comment inline... Just one thing.

p>In all cases, the visual focus indicator for a component must have sufficient contrast against the adjacent background when the component is focused.</p>
​the SC text has exceptions to "all cases" except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;


How about this?
​"​
In all cases, except for inactive components or where the appearance of the component (including it's focus indicator) is determined by the user agent and not modified by the author; the visual focus indicator for a component must have sufficient contrast against the adjacent background when the component is focused.
​"​


Cheers,
David MacDonald



CanAdapt Solutions Inc.

Tel:  613.235.4902

LinkedIn
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidmacdonald100&data=02%7C01%7Cakirkpat%40adobe.com%7C06c050afb63942845e9e08d5c7c8f28e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634588242668571&sdata=AlrRuZCUwztUx11nPBZl4D0bPFk%2FRXvoLs2skBwiy0E%3D&reserved=0>

twitter.com/davidmacd<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdavidmacd&data=02%7C01%7Cakirkpat%40adobe.com%7C06c050afb63942845e9e08d5c7c8f28e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634588242668571&sdata=gv%2BaTIYLKQNE3pHTv45zn3G0D0X65L9ORuGI6RnrUr4%3D&reserved=0>

GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDavidMacDonald&data=02%7C01%7Cakirkpat%40adobe.com%7C06c050afb63942845e9e08d5c7c8f28e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634588242668571&sdata=UyKm6zXbIImPAQF7SXkoYiqK3S7hleJbzJlQP%2BerYjc%3D&reserved=0>

www.Can-Adapt.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.can-adapt.com%2F&data=02%7C01%7Cakirkpat%40adobe.com%7C06c050afb63942845e9e08d5c7c8f28e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634588242668571&sdata=E1uNNft6QM5VuBXmWvumWqzt7hSLiSAE8NuxNd1%2FgT4%3D&reserved=0>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.davidmacd.com%2Fdisclaimer.html&data=02%7C01%7Cakirkpat%40adobe.com%7C06c050afb63942845e9e08d5c7c8f28e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634588242824824&sdata=7h7rML1JIBQgSIrFOmoxjBY7cinQDactsMI79yuhg6o%3D&reserved=0>

On Thu, May 31, 2018 at 10:39 PM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:
AGWG’ers,
I’ve reviewed the 1.4.11 Understanding document and think that this is a solid start: https://github.com/w3c/wcag21/pull/943/files?utf8=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fpull%2F943%2Ffiles%3Futf8%3D&data=02%7C01%7Cakirkpat%40adobe.com%7C06c050afb63942845e9e08d5c7c8f28e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634588242824824&sdata=foUD4ZC0yOk9Yj7tfG28b4TJSC%2BBNEUMynskwmcBpvQ%3D&reserved=0>✓&diff=split

I expect that we will want to include additional examples and explanations, but think that these changes are aligned with how 1.4.11 reads now.

Thoughts?

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7Cakirkpat%40adobe.com%7C06c050afb63942845e9e08d5c7c8f28e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634588242824824&sdata=WcNMzHP59VCJpk8OrMLNzi8ZrWu7ous%2FSGh7e6FFpEA%3D&reserved=0>




--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion