RE: Updates to Understanding 1.4.11 part 2

> Even when setting the background to the same as the default (in most cases white), presumably that counts as setting it?
> Well, to me setting = setting, so yes. It is an explicit, conscious decision (at some level, by somebody) to dictate a style.
> That it is redundantly setting the background to white more often than not is, in many ways, a "guarantee" that the
> background color will be white, and so I say, "OK, then guarantee that color contrast is always maintained."

I’d add that we also have a failure of not setting background when foreground is set and vice versa.  So we are very much requiring that if one is set both are set.  F24 (https://www.w3.org/TR/WCAG20-TECHS/F24.html)

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access
jon.avila@levelaccess.com
703.637.8957 office

Visit us online:
Website<http://www.levelaccess.com/> | Twitter<https://twitter.com/LevelAccessA11y> | Facebook<https://www.facebook.com/LevelAccessA11y/> | LinkedIn<https://www.linkedin.com/company/level-access> | Blog<http://www.levelaccess.com/blog/>

Looking to boost your accessibility knowledge? Check out our free webinars!<https://www.levelaccess.com/compliance-resources/webinars/>

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

From: John Foliot <john.foliot@deque.com>
Sent: Thursday, June 14, 2018 10:18 AM
To: David MacDonald <david100@sympatico.ca>
Cc: Alastair Campbell <acampbell@nomensa.com>; Laura Carlson <laura.lee.carlson@gmail.com>; WCAG group <w3c-wai-gl@w3.org>; LVTF - low-vision-a11y <public-low-vision-a11y-tf@w3.org>
Subject: Re: Updates to Understanding 1.4.11 part 2

Alastair wrote:

>> I can agree with that half-way: as long as the author has not modified the background, then yes, the native foreground is a User Agent problem.
>>
> As I’ve said, that virtually never happens because people set the background on the page, without thinking about the individual links on the page.

While this may be something of a norm today, I don't believe we should be encouraging bad practices. "Not thinking" about things like setting background colors but not adjusting foreground colors is not something we should be rewarding or excusing. Developers used to use stylesheet resets that completely stripped away visible focus states - should we have let that slide 10 years ago when we published WCAG 2.0 with SC 2.4.7 Focus Visible? (see: https://meyerweb.com/eric/thoughts/2011/01/03/reset-revisited/, and http://www.outlinenone.com)


> Even when setting the background to the same as the default (in most cases white), presumably that counts as setting it?

Well, to me setting = setting, so yes. It is an explicit, conscious decision (at some level, by somebody) to dictate a style. That it is redundantly setting the background to white more often than not is, in many ways, a "guarantee" that the background color will be white, and so I say, "OK, then guarantee that color contrast is always maintained."


> > Even in the extreme edge-case of a style sheet with body {background-color: #FFF;}, yet still allowing the native focus color…

> This is not an ‘edge’ case at all, in just the sample we looked at it affects Github, WAI, Adobe, & Facebook. Not for all links, but some.

I think you've just argued against yourself Alastair: those sites *did* make color contrast changes at least some of the time, so if they can do it (say) 65% of the time, is it really unreasonable to ask for 100% of the time? This is an education problem, not a technical hurdle that requires a lot of complex hoop navigation. (Additionally, this new SC will not have any real "force of law" for at least a year, and likely much longer than that globally, so it's time we put devs and designers on notice now, IMHO)


> > in that instance to remain unstyled, is a conscious [sic] decision to stay with defaults that are known to be inaccessible

> Especially in big teams, people working on components are often not the same people who set the background of the page. Also, if you set the page to white, suddenly you would fail even though it is the same as the browser default!

Well, it is unfortunate that one or more browsers on a platform currently fail this SC, but that alone is not, in my opinion, a reason to walk away from this. We know that Safari's defaults today fail this SC. Page authors and designers now have a choice: fix Safari's shortcomings by explicitly setting background and foreground colors, or ship content that knowingly fails on at least one platform/browser combination, shrug and say "not my circus, not my monkeys - blame Apple". I  believe everyone knows which way I'm leaning.


> As Eric mentioned, the default Mac focus styles are much more obvious to most people in most cases, mainly because they are thicker. (See example 17, there are 5 images from different browsers under ‘focus’, and the most obvious one to me is the 4th, at 1.7:1.)

As I recall, we discussed "thickness" as part of this SC previously, and as I further recall, in the end we side-stepped that whole decision as being too complex. The "thicker" default Mac focus styles *may* be thick enough, or may not be. Do we have any data on how thick is "thick enough"?

Additionally, the native Mac indication also has something of a 'blur' to it - what (if any) is the impact of that blurring for low-vision users?

Have we proposed an algorithm that measures both thickness and luminescence and contrast so that when one of those values "slides" below a threshold, it could be made up by increasing another value? What if, instead of "baby blue" as used by Safari today, it was instead "baby pink" at the same thickness - would you pass that because it was "thicker"? Where, exactly, do you propose to draw the line? At a browser default known today to not meet our SC, but because it's the platform and browser of choice by many tech pros, oh well, we'll let that one slide? Sorry, I can't.


> Github (and others) even copy that style manually because people think/assume it is a good setting.

Yep, and I've been on the web long enough to remember when sites "copied" the dev practice of using tables for grid layout, because back then "...people thought/assumed it is (was) a good setting". More recently, we've likely all seen sites that use the @placeholder value as the visible label for a form input, even though HTML 5 explicitly and specifically says not to<https://www.w3.org/TR/html5/sec-forms.html#the-placeholder-attribute> (but to the point where screen readers are now going off spec and none-the-less using that value when nothing else is provided) - again all because developers today "...copy that [practice] because people think/assume it is a good setting."

I cannot accept that Alastair, sorry. The overall effort to correct or manage this issue is not so burdensome as to be a show-stopper: if you change one value, you need to ensure all related values remain in compliance. You can "assume" they are, or you can "guarantee" they are - those are the 2 choices before any developer/designer today. Let's teach them to make the right choice.

JF

On Thu, Jun 14, 2018 at 7:34 AM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:
I can live with that.


Cheers,
David MacDonald



CanAdapt Solutions Inc.

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://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 Thu, Jun 14, 2018 at 5:12 AM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
> I'm nervous about requiring momentary transient states to pass. Its new territory for WCAG. It hard on testers and hard on developers, for little good.

It is also quite rare to find, you’ll see from the examples that only the default (un-styled) link and a quiz had ‘active’ states.
The default button does have an active state, but does not rely on colour: The text moves down-right to create a 3d effect.

As soon as you give a link a default colour, the ‘active’ and visited states disappear (unless you set :active :visited, or only use a:link). In general people use things like:
a {color:blue;}

So those states disappear, and aren’t really missed.

Given that the intent is: “If you provide meaningful information via states then make sure people can discern them”, I don’t have a problem with adding something like what you proposed, how about:

"momentary transition states such as 'active' are hard to register visually for all users and are generally not considered to convey information required for that component."

I added ‘generally’ because there could be niche cases like the quiz where it does try to convey information in that state.

But for the very accessibility/usability-aware, I don’t really want to punish people who provide hints with :visited, conveying that in a way other than using purple is not often recognised.

-Alastair




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