Re: Updates to Understanding 1.4.11

+1 Jon, that is *exactly* my concern.

Perhaps we can have this added to the agenda for Tuesday? (Chairs?)

JF

On Mon, Jun 4, 2018 at 9:29 AM, Jonathan Avila <jon.avila@levelaccess.com>
wrote:

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



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

Advancing the mission of digital accessibility and inclusion