E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 13 (In chronological order)

From: Gijs Veyfeyken
Date: Tue, Dec 04 2018 2:07AM
Subject: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
No previous message | Next message →

Great resource for designers that tries to sum up everything you need to know about color and WCAG on https://webaim.org/articles/contrast/ <https://webaim.org/articles/contrast/>.

The section "Color-only identification of links" explains how difficult it is to come up with color combinations that suffice if links aren't underlined.
If I understand WCAG correctly, this is the case for all user interface components now, if a color change alone is used to indicate a state (hover or focus).

https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html <https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html>
> If a control's indicator of state (e.g., button background) varies only by color this is acceptable if the luminosity contrast ratio between the colors of the states differ by at least 3:1, or if there is another indicator of state.

For example, if a button's background color changes on hover/focus and there's no border change or other visual difference, there are 4 contrast ratio requirements.

1. button text vs background color (4,5)
2. default background color vs surrounding color (3)
3. hover background color vs surrounding color (3)
4. default background color vs hover background color (3)

Perhaps it would be useful to emphasise this in the article?

Kind regards,

Gijs

---
Gijs Veyfeyken
AnySurfer - towards an accessible internet
http://www.anysurfer.be/en
Brussels - Belgium

From: Jared Smith
Date: Tue, Dec 04 2018 12:41PM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | Next message →

>> If a control's indicator of state (e.g., button background)
>> varies only by color this is acceptable if the luminosity
>> contrast ratio between the colors of the states differ by
>> at least 3:1, or if there is another indicator of state.
>
> For example, if a button's background color changes on
> hover/focus and there's no border change or other visual
> difference, there are 4 contrast ratio requirements.

It's important to understand the context for the sentence you quoted
(which is non-normative). It's in relation to "Use of Color" (1.4.1)
or color reliance. So this would only apply if you are indeed only
relying on color to indicate the button - the button looks exactly
like the surrounding non-button text. If the button indeed looks like
a button and is visually differentiated from surrounding content, then
I see no requirement under 1.4.1 for the various states of that button
to have a 3:1 contrast ratio to the default state.

In short, where this paragraph states "If a control's indicator of
state (e.g., button background)..." it is not referring to hover/focus
"states", but instead to the fact that the "state" of this element is
a button rather than something else... I guess. If this is indeed
referring to hover/focus states, then I believe this statement is
incorrect - 1.4.1 does not cover such things. If it covers the various
states of buttons, then it must also cover the various states of
links, so a blue default state would have to be 3:1 from a red hover
state, and that's just not the case.

Now, in the context of 1.4.11 (Non-text Contrast)...

A default <button> provides absolutely no visual change on mouse
hover. This clearly would be exempted because it is a default
component. However, if the author were to make even the slightest of
color differences on hover, this would suggest that this hover color
change must now be at 3:1 from the default color.

Is this really what this success criterion is requiring of authors? I
don't know, but this seems a bit extreme for button hover states when
the user must have manually triggered this state and where the default
and expected behavior is no contrast change at all.

Now, for the keyboard focus state, if there is a visible focus
indicator/outline, as is the default for <button> and links, then this
is sufficient because color changes are no longer "required to
identify" the state. So, if there's a focus indicator no change is
needed, but the hover state must have a contrast ratio of 3:1 from the
default state??? That just doesn't seem right to me.

If, on the other hand, there is NO focus indicator, then I agree that
the 3:1 color change is necessary between the default state and the
focus state. An outline would be better, but this would be sufficient
to meet this success criterion.

This is why we didn't delve into the nuanced and confusing aspects of
this WCAG requirement in our article - it only applies to buttons when
there's no visible focus indicator. And I'm not sure whether this
actually applies to hover states if the user customizes the button
styles - it doesn't make sense to me that it would.

Perhaps someone involved in the authoring of this success criteria
could provide some clarification as to whether hover states for
buttons must indeed present a 3:1 contrast ratio difference from their
default state. If it does, this should probably be clarified.

Thanks,

Jared

From: Jonathan Avila
Date: Tue, Dec 04 2018 1:23PM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | Next message →

There were 2 github issues on the WCAG github repository discussing the question of comparing hover and other states for contrast under SC 1.4.11 non-text contrast. The links are provided below. Based on my understanding the difference between hover and non-hover states do not require 3:1 contrast as there are other indicators provided for hover such as a change in the pointer. Each state alone must have sufficient contrast for text and non-text items if the contrast of those non-text items is the only way of communicating something visually. But you don't need to compare those states to each other.

Warning -- these links are provided as the open discussion of the issue and the discussion may be confusing to some -- so I only recommend them for those who really want to dig into the theoretical discussion -- although proposed responses are provided at the end. One issue was closed while the other open -- so I would assume further clarification of the response from the Accessibility Guidelines Working group in the form of updates to the understanding document will be forthcoming.
https://github.com/w3c/wcag/issues/400
https://github.com/w3c/wcag21/issues/913

Use of contrast as the only differentiator for the focused and non-focused state is a separate issue and under discussion.

Jonathan

Jonathan Avila, CPWA
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office

Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog

Looking to boost your accessibility knowledge? Check out our free 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: Alastair Campbell
Date: Tue, Dec 04 2018 3:40PM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | Next message →

Jared Smith wrote:
> It's important to understand the context for the sentence you quoted
> (which is non-normative). It's in relation to "Use of Color" (1.4.1)
> or color reliance.

Yes, however, the paragraph was intended to say that you could use a
change of contrast as a method of showing a change of state. Not the
only method, but a method.

> I see no requirement under 1.4.1 for the various states of that button
> to have a 3:1 contrast ratio to the default state.

Not under 1.4.1, but that SC was referenced as a potential method for
meeting 1.4.11, not a requirement.

> A default <button> provides absolutely no visual change on mouse
> hover.

That might depend on your browser, I see a subtle background change
from grey to light blue in FF & Edge on windows, but it isn't
particularly noticeable.

This key thing for 1.4.11 is that you can perceive the control in any
state (as you suggested), then with 2.4.7 Focus styles, there is a
combined requirement for a visible focus indicator (now better defined
with 1.4.11). Mike Gower put it well here:
"one must perceive the difference between focused and unfocused state
in order to meet 2.4.7 Focus Visible, so the two states must meet the
minimum contrast requirements of 3:1. In other words, having
established this minimum contrast for non-text contrast, I think it is
both logical and consistent that "visible" in the sense of 2.4.7 must
be a differentiation between the focused and non-focused states."
https://github.com/w3c/wcag/issues/541#issuecomment-443749529

There are multiple ways to provide an indicator, a *change* of colour
of something already there would need to meet the contrast ratio, but
an additional element / change of the component shape is another way.

A contrasting change (like in the Understanding doc) works, as does an
outline. I put together a little scratch page to show some different
methods specifically for buttons:
https://alastairc.ac/tests/wcag21-examples/ntc-focus-styles.html

That was the starting point to a technique that is basically about
"changing the shape of the component". Talking about the adjacent
colours is difficult when you've multiple sides for things, and adding
a dark outline around a dark border does have good visibility. When
you get down to it, shapes are made of contrasting colours, so it
should be a useful distinction. See examples 4 & 5, where 5 uses a
colour that contrasts with the dark border, but not the background.


> whether hover states for buttons must indeed present a 3:1
> contrast ratio difference from their default state.

There are a remarkable number of states, especially for links [1], so
differentiating all states from each other is not feasible. The
intended scope was that the component is perceivable in all it's
states, including the things that define what that component is:
"Visual information required to identify user interface components and
states". For example, the toggle in a toggle button. The other aspect
was focus state, where it was intended to build on top of 2.4.7.

Hope that helps, thanks to JF for the nudge, I don't get to follow
email lists much these days!

-Alastair

1] http://blog.selfthinker.org/2011/07/10/trick-question-how-many-link-states-can-be-defined-in-css/

From: Jared Smith
Date: Tue, Dec 04 2018 10:05PM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | Next message →

Thank you Jonathan and Alistair for your thoughts and resources. The
Github threads were helpful, but seem to have ended without a clear
resolution to this question.

If I understand you both correctly, you are stating that hover state
is not required to have a 3:1 contrast ratio difference from the
default state. This is my understanding as well. Again, it would be
odd to say that no or very subtle change (depending on the browser) on
hover is perfectly fine, but a subtle author-specified color/contrast
change on hover is a WCAG failure that can be remedied only by making
it a rather significant 3:1 contrast ratio change.

I believe this can be better clarified and explained in the
Understanding document for this SC, especially if one infers the
discussion of "states" to apply to more than the visibility of the
focus indicator (which is really covered by 2.4.7 anyway - this SC
just helps to define what "visible" means).

Alistair, there are still some statements you made that muddy the
waters for me...

> There are a remarkable number of states, especially for links [1], so
> differentiating all states from each other is not feasible. The
> intended scope was that the component is perceivable in all it's states

Right, so regardless of the state, the component itself needs to be
perceivable with 3:1 contrast to its surroundings, and there's no
requirement that the individual states themselves have 3:1 contrast
from each other. Gotcha!

> For example, the toggle in a toggle button.

Wait, now I'm confused again! If you mean that in both states (on and
off) that the button itself needs to be perceivable, then I agree.

But if you are instead stating that the two states (on and off) have
to be differentiable *from each other* with a 3:1 contrast ratio
(assuming no other visual or text changes), then this conflicts with
your previous statements. How are the on/off states covered, but the
hover state not covered? The SC doesn't make a differentiation of
types of states.

See how this quickly gets confusing? Authors (and accessibility folks
like me) really need clear guidance on this - the supporting materials
can't say that some states are covered and others not without clear
descriptions of which are which - and explanations of how that aligns
with the normative text.

Thanks,

Jared

From: Alastair Campbell
Date: Wed, Dec 05 2018 2:37AM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | Next message →

Jared Smith wrote:
> But if you are instead stating that the two states (on and off) have
> to be differentiable *from each other* with a 3:1 contrast ratio
> (assuming no other visual or text changes), then this conflicts with
> your previous statements. How are the on/off states covered, but the
> hover state not covered?

I think the confusion is assuming that a 'colour change' is the only
differentiator, the requirement here is that *if* you rely only on a
contrast change. This SC focuses on using contrast, but that isn't the
only method.

Take this Android toggle button example:
https://androidician.files.wordpress.com/2014/09/output_potdse.gif
(animation warning)

Let's assume for the sake of discussion that the blue 'on' indicator
contrasted with the grey background, and that the dark grey fill of
the 'off' state also had contrast with the background. Neither do, but
it's the example I could find in a few seconds of googling.

You go from a right-hand contrasting area to a left-hand one - it changes shape.

The grey doesn't have to contrast with the blue.
(Of course, there might be an issue with knowing that right is on and
left is off, but that's a different issue.)

If you go in thinking "this component needs to have contrast so you
can see it", that generally works for radio buttons, toggles,
checkboxes etc. We did some analysis of examples, including from some
of the common pattarn libraries:
https://alastairc.ac/tests/wcag21-examples/non-text-contrast.html

So the things that determine 'this thing is a control' need to be
discernable. For links that might be an underline (but then there's a
separate requirment for focus indicator), for a checkbox the box and
the tick are needed. For an input it might be a border, a single line,
a different background, we can't just list these things because there
is too much flexibility.

That's why the understanding doc says:
"any visual information provided that is necessary for a user to
identify that a control exists and how to operate it must have
sufficient contrast with the adjacent background."


> See how this quickly gets confusing? Authors (and accessibility folks
> like me) really need clear guidance on this - the supporting materials
> can't say that some states are covered and others not without clear
> descriptions of which are which - and explanations of how that aligns
> with the normative text.

Indeed, I'm afraid we have a slight backlog of issues in this area:
https://github.com/w3c/wcag/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+1.4.11

I think once we've worked through those it should be clearer, we're
also trying to get techniques done which should help, but can't do
everything at once. If anyone can join up and pitch in, it would be
most appreciated [1].

Cheers,

-Alastair

1] https://www.w3.org/WAI/GL/participation.php

From: Jared Smith
Date: Wed, Dec 05 2018 8:05AM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | Next message →

Alastair Campbell wrote:

> Take this Android toggle button example:
> https://androidician.files.wordpress.com/2014/09/output_potdse.gif
> (animation warning)
>
> The grey doesn't have to contrast with the blue.

Of course not, because there are several other visual indicators of
state change. But what if color/contrast was the ONLY indication of
state, particularly hover state?

I put together the following page to demonstrate this, and to show
that, if 1.4.11 requires 3:1 contrast between states, this could be
considered rather constraining to button design:

https://webaim.org/temp/1-4-11examples.htm

I'd be happy to hear your opinions on the "Pass or Fail?" scenarios.
It's still not clear to me what WCAG requires here.

> We did some analysis of examples, including from some
> of the common pattarn libraries:
> https://alastairc.ac/tests/wcag21-examples/non-text-contrast.html

I don't think anything here examines the specific scenarios I'm
discussing - where color/contrast alone is changed on hover. Your
suggestion that the change in cursor on hover is sufficient to meet
1.4.11 is interesting. This alone suggests that you believe 1.4.11
must provide state differentiation. Cursor change, however, would not
be applicable to buttons which do not (and, arguably, should not) do
so on hover.

> Indeed, I'm afraid we have a slight backlog of issues in this area:
> https://github.com/w3c/wcag/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+1.4.11
>
> I think once we've worked through those it should be clearer, we're
> also trying to get techniques done which should help, but can't do
> everything at once.

When I have some time, I'll add these scenarios and my thoughts to the
logged bugs. I do hope that corrections to the mistakes and ambiguity
in the already-published WCAG materials would be given priority
treatment - I think giving incorrect or ambiguous guidance is more
detrimental than not giving guidance at all.

Thanks!

Jared

From: Alastair Campbell
Date: Wed, Dec 05 2018 5:57PM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | Next message →

Jared Smith wrote:
> But what if color/contrast was the ONLY indication of
> state, particularly hover state?

I'm compiling the issues to make one update, and found we have
discussed this aspect already:
https://github.com/w3c/wcag21/issues/913#issuecomment-393975067

In that compilation, I gathered together this set of updates to make
to the understand docs, just bullets to use at this stage.

NOTE: Very draft, still to be approved.
-------------------
From 1.4.11:
- Components must continue to have contrast in different states
("required to identify").
- Where a state indicates functionality of the component (e.g. a check
in a checkbox), that aspect must have sufficient contrast ("required
to identify … states"). However, it does not create a requirement to
differentiate states by color internally (e.g. between default and
hover, visited link, visited + hover etc.). A better term than
"functionality" would be useful there.

In combination with Focus Visible (2.4.7) & Use of Color (1.4.1):
- if the focus indicator relies on color alone (so all three SCs!),
that must provide contrast compared to the non-focused state. (E.g.
changing the background color of a button.)
- if the focus indicator adds/removes parts of the component, or
changes the shape of the component, that change must have contrast.
(e.g. adding thickness to a border that has contrast, or adding a
separate outline.) However, it doesn't have to contrast with itself if
it changes the shape.

Not in scope:
- Boundaries for links / buttons.
- Default (untouched) focus indicators.
- Measurement is against adjacent colors of the component, not
different states within the component (except when color-change-only
is used for focus state).
- Hover / visited state (except that the component must continue to
have contrast). Whilst desirable that a component would indicate hover
state in a perceivable way, it is not required by 1.4.11.
------------------

> I'd be happy to hear your opinions on the "Pass or Fail?" scenarios.
> It's still not clear to me what WCAG requires here.

As per the above, differentiating hover isn't required, but I was
hesitant to say that because you asked:

> ... Cursor change would not be applicable to buttons which do not
> (and, arguably, should not) do so on hover.

What's the argument about not having a pointer change on hover? I had
thought adding `cursor: pointer` (or whatever the CSS is) would be an
easy thing to do. All the 'buttons' in the Gmail interface I'm using
do that.

There might have been an assumption that hover would generally change,
and I'm not sure that was realised when that aspect was discussed, as
we were talking about links initially. Overall I think requiring a
hover state is problematic, and therefore requiring contrast for it is
also problematic. Let me come back about that.

> I do hope that corrections to the mistakes and ambiguity
> in the already-published WCAG materials would be given priority
> treatment - I think giving incorrect or ambiguous guidance is more
> detrimental than not giving guidance at all.

We did spend many hours on it, and go through hundreds of examples,
the problem is distilling that. It helps to have conversations like
these to iterate that distillation.

Do the above notes help? I'll try to get that into the understanding
docs soon, via the working group process.

-Alastair

From: Jared Smith
Date: Wed, Dec 05 2018 9:03PM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | Next message →

Alastair Campbell wrote:

> In that compilation, I gathered together this set of updates to make
> to the understand docs, just bullets to use at this stage.

Thank you for compiling these. This is very helpful.

> However, it does not create a requirement to
> differentiate states by color internally (e.g. between default and
> hover, visited link, visited + hover etc.). A better term than
> "functionality" would be useful there.

This aligns with my thoughts. I think it's useful to recommend visual
changes on hover for many interactive components to reinforce that
they are interactive, but a 3:1 contrast ratio requirement for those
changes would be constraining to many designs and could result in a
less accessible experience.

> What's the argument about not having a pointer change on hover? I had
> thought adding `cursor: pointer` (or whatever the CSS is) would be an
> easy thing to do. All the 'buttons' in the Gmail interface I'm using
> do that.

I'm not sure Gmail should be considered a model for optimal user experience. :-)

Adam Silver provides a comprehensive analysis of this topic at
https://medium.com/simple-human/buttons-shouldnt-have-a-hand-cursor-b11e99ca374b
As a quick summary, Microsoft
(https://docs.microsoft.com/en-us/windows/desktop/uxguide/inter-mouse#hand-pointers),
Apple (https://developer.apple.com/design/human-interface-guidelines/macos/user-interaction/mouse-and-trackpad/),
and the CSS specification
(https://www.w3.org/TR/CSS21/ui.html#propdef-cursor) all specify that
the hand/pointer cursor is only for links - elements that will take
the user somewhere else. Buttons, text boxes, checkboxes, sliders,
select menus, etc., etc., do not have this functionality and thus
should not provide this visual affordance.

While changing the cursor to the pointer for buttons is easy to do,
it's a violation of at least the spirit of CSS, even though it is
commonly done (e.g., Gmail).

> > I do hope that corrections to the mistakes and ambiguity
> > in the already-published WCAG materials would be given priority
> > treatment - I think giving incorrect or ambiguous guidance is more
> > detrimental than not giving guidance at all.
>
> We did spend many hours on it, and go through hundreds of examples,
> the problem is distilling that. It helps to have conversations like
> these to iterate that distillation.'

Indeed. This has been helpful for me to explore this topic more fully.
These things are not easy to define or explain - and I applaud all of
you that do the hard work to put this into guidelines and supporting
materials. I'd be happy to review and provide feedback on an updated
Understanding document for this success criterion.

Thanks again for your effort on this.

Jared

From: Detlev Fischer
Date: Wed, Dec 05 2018 11:07PM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | Next message →

I think this is a very good summary of adequate requirements - especially differentiating between ‚functional states‘ (‚states to convey critical affordances‘) and the host of other states. I agree not to extend the focus indication requirement to hover states - the simple reason that the cursor / finger/ stylus is right there over the element should suffice, at a minimum level.
This thing is just that it *is* complex to delineate the requirement exactly, so I fear it will remain not easy to grasp / communicate what is required. Cheers, Detlev

Sent from phone

> Am 06.12.2018 um 01:57 schrieb Alastair Campbell < = EMAIL ADDRESS REMOVED = >:
>
> Jared Smith wrote:
>> But what if color/contrast was the ONLY indication of
>> state, particularly hover state?
>
> I'm compiling the issues to make one update, and found we have
> discussed this aspect already:
> https://github.com/w3c/wcag21/issues/913#issuecomment-393975067
>
> In that compilation, I gathered together this set of updates to make
> to the understand docs, just bullets to use at this stage.
>
> NOTE: Very draft, still to be approved.
> -------------------
> From 1.4.11:
> - Components must continue to have contrast in different states
> ("required to identify").
> - Where a state indicates functionality of the component (e.g. a check
> in a checkbox), that aspect must have sufficient contrast ("required
> to identify … states"). However, it does not create a requirement to
> differentiate states by color internally (e.g. between default and
> hover, visited link, visited + hover etc.). A better term than
> "functionality" would be useful there.
>
> In combination with Focus Visible (2.4.7) & Use of Color (1.4.1):
> - if the focus indicator relies on color alone (so all three SCs!),
> that must provide contrast compared to the non-focused state. (E.g.
> changing the background color of a button.)
> - if the focus indicator adds/removes parts of the component, or
> changes the shape of the component, that change must have contrast.
> (e.g. adding thickness to a border that has contrast, or adding a
> separate outline.) However, it doesn't have to contrast with itself if
> it changes the shape.
>
> Not in scope:
> - Boundaries for links / buttons.
> - Default (untouched) focus indicators.
> - Measurement is against adjacent colors of the component, not
> different states within the component (except when color-change-only
> is used for focus state).
> - Hover / visited state (except that the component must continue to
> have contrast). Whilst desirable that a component would indicate hover
> state in a perceivable way, it is not required by 1.4.11.
> ------------------
>
>> I'd be happy to hear your opinions on the "Pass or Fail?" scenarios.
>> It's still not clear to me what WCAG requires here.
>
> As per the above, differentiating hover isn't required, but I was
> hesitant to say that because you asked:
>
>> ... Cursor change would not be applicable to buttons which do not
>> (and, arguably, should not) do so on hover.
>
> What's the argument about not having a pointer change on hover? I had
> thought adding `cursor: pointer` (or whatever the CSS is) would be an
> easy thing to do. All the 'buttons' in the Gmail interface I'm using
> do that.
>
> There might have been an assumption that hover would generally change,
> and I'm not sure that was realised when that aspect was discussed, as
> we were talking about links initially. Overall I think requiring a
> hover state is problematic, and therefore requiring contrast for it is
> also problematic. Let me come back about that.
>
>> I do hope that corrections to the mistakes and ambiguity
>> in the already-published WCAG materials would be given priority
>> treatment - I think giving incorrect or ambiguous guidance is more
>> detrimental than not giving guidance at all.
>
> We did spend many hours on it, and go through hundreds of examples,
> the problem is distilling that. It helps to have conversations like
> these to iterate that distillation.
>
> Do the above notes help? I'll try to get that into the understanding
> docs soon, via the working group process.
>
> -Alastair
> > > >

From: Alastair Campbell
Date: Thu, Dec 06 2018 6:00AM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | Next message →

Jared Smith wrote:
> I'd be happy to review and provide feedback on an updated
> Understanding document for this success criterion.

Great, I've made some updates and created a summary here:
https://github.com/w3c/wcag/pull/550

That will go to the AGWG shortly, but it would be great to get other
people reviewing it as well.

-Alastair

From: Gijs Veyfeyken
Date: Thu, Dec 06 2018 8:59AM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | Next message →

That was a lot of information to digest. The two types of information that were most helpful to get my mind in order:

* The decision tree of pass/fail and the assumptions below that Alastair wrote at https://alastairc.ac/tests/wcag21-examples/non-text-contrast.html <https://alastairc.ac/tests/wcag21-examples/non-text-contrast.html>.
* Examples with a detailed explanation in clear language that lead to the conclusion of pass or fail, like some of the examples Jared shows at https://webaim.org/temp/1-4-11examples.htm <https://webaim.org/temp/1-4-11examples.htm>.

Both of these are currently missing in the Understanding document in my humble opinion.
I appreciate the current update (https://github.com/w3c/wcag/pull/550/ <https://github.com/w3c/wcag/pull/550/>) and I understand it's awfully hard to write such a document.
But it's not realistic for an average designer to spend as much time as we do to grasp what is required for WCAG compliance.
Perhaps it's useful to focus on these points and a bigger update of the current page?
I'll try to pitch in.

Kind regards,

Gijs

From: Alastair Campbell
Date: Sat, Dec 08 2018 6:25PM
Subject: Re: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements
← Previous message | No next message

> * The decision tree of pass/fail and the assumptions below that Alastair wrote at https://alastairc.ac/tests/wcag21-examples/non-text-contrast.html <https://alastairc.ac/tests/wcag21-examples/non-text-contrast.html>.

There's a version of that under the "Testing principles" in the
understanding document. It probably needs an update, but hopefully
that meets the same purpose.

> * Examples with a detailed explanation in clear language that lead to the conclusion of pass or fail, like some of the examples Jared shows at https://webaim.org/temp/1-4-11examples.htm <https://webaim.org/temp/1-4-11examples.htm>.

That certainly helps, but to do that with reasonable coverage of all
the different component types (considering that was just for buttons &
hover states), is a huge undertaking!

The top of the Understanding doc now has plenty of examples [1], and I
think we (the working group) need to focus on making sure the core
explanations and advice are as clear and complete as we can. With that
in place, it is a lot easier for others (like the good folk at Webaim
and the Education & Outreach group) to provide focused tutorial
material that is easier to digest.

Having said that, we obviously will try to improve the understanding
documents, so thank you for pitching in :-)

-Alastair

1] temporary link for the updated document:
http://htmlpreview.github.io/?https://github.com/w3c/wcag/blob/non-text-contrast-updates/understanding/21/non-text-contrast.html
When that disappears it should be published on the official location soon after:
https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html