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

> I can live with that.
>
> 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 Thu, Jun 14, 2018 at 5:12 AM, Alastair Campbell <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

Advancing the mission of digital accessibility and inclusion