Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes to 1.4.1 Use of Color understanding #1788

Open
wants to merge 22 commits into
base: main
Choose a base branch
from
Open

Changes to 1.4.1 Use of Color understanding #1788

Changes from 20 commits
Commits
Show all changes
22 commits
Select commit Hold shift + click to select a range
7fc73e6
Amend benefits
patrickhlauke May 9, 2021
6ac58e1
Examples of use of color to denote pressed and focused controls
patrickhlauke May 9, 2021
cf5b90d
Reword first examples so they don't sound like instructions/descriptions
patrickhlauke May 9, 2021
37d6bda
Further rework of examples
patrickhlauke May 9, 2021
d8c857e
Tweak focus example, move and change note about other criteria
patrickhlauke May 10, 2021
01db586
Merge branch 'main' into patrickhlauke-understanding-useofcolor
patrickhlauke Jun 28, 2023
d979c4b
Merge branch 'main' into patrickhlauke-understanding-useofcolor
patrickhlauke Mar 9, 2024
de1e9b7
Update understanding/20/use-of-color.html
patrickhlauke May 6, 2024
00f06b4
Update understanding/20/use-of-color.html
patrickhlauke May 6, 2024
175f5c5
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
b6e262c
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
ab1bc2e
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
dbe48ee
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
0a08f7c
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
8b40695
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
ed9ac55
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
f5f671b
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
9cabd44
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
6f6cbf2
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
4fae90e
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
63d2053
Update understanding/20/use-of-color.html
mbgower Jun 12, 2024
de20743
Merge branch 'main' into patrickhlauke-understanding-useofcolor
patrickhlauke Jun 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
114 changes: 68 additions & 46 deletions understanding/20/use-of-color.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,13 +38,28 @@ <h2>Intent of Use of Color</h2>
only in color.
</p>

<p>Examples of information conveyed by color differences: “required fields are red",
“error is shown in red", and “Mary's sales are in red, Tom's are in blue". Examples
of indications of an action include: using color to indicate that a link will open
in a new window or that a database entry has been updated successfully. An example
of prompting a response would be: using highlighting on form fields to indicate that
a required field had been left blank.
</p>
<p>Examples of common failures include:</p>
<ul>
<li>
<strong>Information conveyed by color differences:</strong>
<ul>
<li>required fields are only identified by changing their existing border to a red color;</li>
<li>the type of transaction is only visually distinguished by using different foreground colors: red for debits and green for credits;</li>
<li>subway lines are visually distinguished solely by employing various filled colors.</li>
mbgower marked this conversation as resolved.
Show resolved Hide resolved
</ul>
</li>
<li>using color alone to indicate
that a link will open in a new window or that a database entry has been updated successfully.</li>
<li>using subtle color highlighting on form fields to prompt for a response on
bruce-usab marked this conversation as resolved.
Show resolved Hide resolved
required fields that have been left blank.</li>
<li><strong>Distinguishing a visual element:</strong>
<ul>
<li>text links are only distinguished from surrounding text using a subtle text color difference (with a contrast difference that is less than 3:1);</li>
<li>for a series of toggle buttons, the pressed and unpressed buttons are only visually indicated by a subtle difference in color;</li>
<li>the interactive element that currently has focus is only distinguished by changing the color of the element's existing background or border.</li>
bruce-usab marked this conversation as resolved.
Show resolved Hide resolved
</ul>
</li>
<p>However, particularly in the case of state/focus indication, note that if the visual indicator was not previously present, this does not count as a change in color. For instance, if a focused element has a new border, or a new solid background shape, that was not there in its unfocused state, this does not count as a change of color alone, since the indicator was not present to begin with.</p>
bruce-usab marked this conversation as resolved.
Show resolved Hide resolved

<div class="note">

Expand Down Expand Up @@ -82,7 +97,7 @@ <h2>Intent of Use of Color</h2>

</div>

<div class="note">
<div class="note">

<p>This criterion does not directly address the needs of users with assistive technologies.
It aims to ensure that sighted users who cannot distinguish between some colors can still
Expand All @@ -99,30 +114,34 @@ <h2>Intent of Use of Color</h2>
criterion requires a visible alternative to color.
</p>

</div>

<div class="note">

<p>Most user agents provide users with a color-only cue that a link has been previously activated by them ("visited"). However, several technical constraints result in authors having very limited control over these color-only indications of visited links. The technical constraints are as follows:</p>

<ol>
<li>
User agents constrain the exposure of a link's visited state due to <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector">privacy concerns</a>. Author queries to user agents will indicate all links have not been visited.
</li>
<li>
Any available information on the visited state of a link would be inaccurate since it is both user and browser-dependent. Even if an author could accurately get information on previously activated links by a certain user, the author would be constrained to the current browser's preserved history, and would be unable to determine if the user had visited the page using a different browser (or if the history was not preserved, either from cache clearing or use of private sessions).
</li>
<li>
Authors can <em>only</em> use color to modify the <code>:visited</code> CSS pseudoclass style. The technology constrains any non-color styling. Due to palette limitations, an author cannot use color alone to achieve 3:1 contrast between link and non-link text as well as between visited and unvisited links while also achieving 4.5:1 contrast for all link and non-link text.
</li>
<li>
Authors also cannot set the visited state of links. The anchor element does not include a "visited" attribute; therefore the author has no ability to alter the state through an attribute setting. As such, authors cannot achieve <a href="info-and-relationships">1.3.1 Info and Relationships</a> or
<a href="name-role-value">4.1.2 Name, Role, Value</a> in regard to visited links.
</li>
</ol>
</div>

<div class="note">
bruce-usab marked this conversation as resolved.
Show resolved Hide resolved
<p>Note that particularly in the case of focus indication, this criterion is likely to overlap with
other, more specific criteria, such as
<a href="focus-appearance">2.4.11 Focus Appearance</a> (new in WCAG 2.2).
</p>
</div>

<div class="note">
<p>Most user agents provide users with a color-only cue that a link has been previously activated by them ("visited"). However, several technical constraints result in authors having very limited control over these color-only indications of visited links. The technical constraints are as follows:</p>
<ul>
<li>
User agents constrain the exposure of a link's visited state due to <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector">privacy concerns</a>. Author queries to user agents will indicate all links have not been visited.
</li>
<li>
Any available information on the visited state of a link would be inaccurate since it is both user and browser-dependent. Even if an author could accurately get information on previously activated links by a certain user, the author would be constrained to the current browser's preserved history, and would be unable to determine if the user had visited the page using a different browser (or if the history was not preserved, either from cache clearing or use of private sessions).
</li>
<li>
Authors can <em>only</em> use color to modify the <code>:visited</code> CSS pseudoclass style. The technology constrains any non-color styling. Due to palette limitations, an author cannot use color alone to achieve 3:1 contrast between link and non-link text as well as between visited and unvisited links while also achieving 4.5:1 contrast for all link and non-link text.
</li>
<li>
Authors also cannot set the visited state of links. The anchor element does not include a "visited" attribute; therefore the author has no ability to alter the state through an attribute setting. As such, authors cannot achieve <a href="info-and-relationships">1.3.1 Info and Relationships</a> or
<a href="name-role-value">4.1.2 Name, Role, Value</a> in regard to visited links.
</li>
</ul>
<p>For these reasons, setting or conveying a link's visited status is not an author responsibility. Where color alone distinguishes between visited and unvisited links, it does not result in a failure of this Success Criterion, even where the contrast between the two link colors is below 3:1. Note that authors must continue to ensure that all text links meet contrast minimums against the page background (SC 1.4.3).</p>
</div>
</div>

</section>
<section id="benefits">
Expand All @@ -139,13 +158,7 @@ <h2>Benefits of Use of Color</h2>
in other visual ways.
</li>

<li>People using limited color monochrome displays may be unable to access
color-dependent information.
</li>

<li>Users who have problems distinguishing between colors can look or listen for text
cues.
</li>
<li>Users who have problems distinguishing between colors can look for other visual cues.</li>
Copy link
Contributor

@giacomo-petri giacomo-petri May 6, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with the edit.

Not a problem, but in points 1 and 2, we delineate the beneficiaries of a proper implementation. In points 3 and 4, alongside identifying the beneficiaries, we also clarify that they will reap the benefits if other visual cues are present (although this may not be necessary). Should we stay consistent?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think with the first two the only thing you could then say is a platitude/truism a la ", so not relying on color alone will help them". in a sense, the first three bullets all get to the same point and could even be combined.


</ul>

Expand All @@ -157,18 +170,27 @@ <h2>Examples of Use of Color</h2>
<dl>
<dt>A form that uses color and text to indicate required fields</dt>
<dd>A form contains both required and optional fields. Instructions at the top of the
form explain that required fields are labeled with red text and also with an icon.
Users who cannot perceive the difference between the optional field labels and the
red labels for the required fields will still be able to see the icon next to the
red labels.</dd>
form explain that required fields are labeled with red text and also with an icon.
Users who cannot perceive the difference between the optional field labels and the
red labels for the required fields will still be able to see the icon next to the
red labels.</dd>
<dt>An examination</dt>
<dd>Students view an SVG image of a chemical compound and identify the chemical elements
present based <strong>both</strong> on the colors used, as well as numbers next to each
element. A legend shows the color and number for each type of element. Sighted users who
cannot perceive all the color differences can still understand the image by relying on
the numbers.</dd>
present based <strong>both</strong> on the colors used, as well as numbers next to each
element. A legend shows the color and number for each type of element. Sighted users who
cannot perceive all the color differences can still understand the image by relying on
the numbers.</dd>
<dt>A series of toggle buttons</dt>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the state of toggle buttons, I also think we're on thin ground. Again, it helps to think about these visuals all being carried out in black and white, and gray. I point again to the creation of Non-text Contrast as proof that Use of Color was considered inadequate to fail subtle state changes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again, non-text contrast can't compare things that aren't visually adjacent. use of color, on the other hand, can

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the point of this example was the "also styled to appear pressed" and the alternative use of icon, just to make sure it's more than just a change of background colour alone (below 3:1) that distinguishes toggles that are on and toggles that are off. without those, you're relying purely on the user's ability to be able to tell the difference between the two shades, which fails use of color (and can't fail non-text contrast because they're not adjacent, unless the toggles all butt up with each other with no dividing line or anything)

<dd>Users are presented with a series of toggle buttons that can be turned on or off. Visually,
when a toggle button is turned on, it not only has a different background color, but is
also styled to appear "pressed", with a distinctive inner shadow. Alternatively, toggles that
patrickhlauke marked this conversation as resolved.
Show resolved Hide resolved
are turned on could have an extra "ticked" icon to distinguish them from toggles that are
turned off.</dd>
<dt>Focus indication</dt>
Copy link
Contributor

@mbgower mbgower Jun 12, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinnest ice of all. The WG introduced Non-text Contrast in 2.1, it can be argued, because a 'background color change' especially from white to something else, passed Focus Visible. Then the working group introduced Focus Appearance in 2.2, because the wording in Non-Text Contrast was not deemed as sufficient to cover several situations. A 10% gray fill replacing a white fill in a text input does not fail Non-text Contrast. Any two visible non-text contrast visualizations of state that both achieved 3:1 against adjacent colors but not against each other likewise do not fail Non-Text Contrast.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but unarguably you're just relying on color here to convey something. so while non-text contrast can't compare two different states that are not adjacent, use of color can (because if the change is less than 3:1 it counts as only a change in color, which is a use of color)

Copy link
Contributor

@mbgower mbgower Jun 12, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but unarguably you're just relying on color here to convey something

Not unarguable, since that's exactly what I'm challenging! I think it is clear that a transition from nothing (blank white page) to any content was not intended to be caught by Use of Color. By that definition, EVERYTHING added to or removed from a page is a failure of use of color, since the text, the symbols, the shadows, etc., is simply a use of color. Color alone is forming the letters (even if they're black). Color alone is forming the shapes. Color alone is forming the fills. Everything ever added to a page would fail this SC.

Clearly, Contrast (Minimum) was intended to specifically assess the contrast between text and its background. And Non-text Contrast was added to assess contrast between any non-text visually present feature and its adjacent color (typically the page background).

In the example, if toggle buttons showed for their pressed state with only a less than 3:1 inner shadow (i.e., no use of the 'tick') that would still pass Use of Color. Not saying it would be good design, but especially in the days before Non-text Contrast (which introduced the idea of 3:1) no one would have argued using a shadow is an example of Use of Color.

I'm not trying to split hairs here. Your final note identifies the exact same problem.

However, particularly in the case of state/focus indication, note that if the visual indicator was not previously present, this does not count as a change in color. For instance, if a focused element has a new border, or a new solid background shape, that was not there in its unfocused state, this does not count as a change of color alone, since the indicator was not present to begin with.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getting lost between resolved comments, your myriad of tiny changes (could really do with doing them with proper git and pushing up a single commit, rather than piecemeal) etc. thought this comment was still about toggles, but i see it's the next one. and in this case, this was an example where it's not JUST a use of color change, and it's the additional outline that absolves the example from being a FAIL.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if anything, it's the whole angle of these (existing) examples (which i then added to) ... even the existing ones aren't examples of failures, but examples of "this would fail, were it not for..."

<dd>When an interactive control (like a button, toggle, or checkbox) receives focus, its background color
changes. In addition to this, an extra outline (which was not present in the control's unfocused state)
appears around the control.</dd>
</dl>

</section>

<section id="resources">
Expand Down