-
Notifications
You must be signed in to change notification settings - Fork 266
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.
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
base: main
Are you sure you want to change the base?
Changes from 18 commits
7fc73e6
6ac58e1
cf5b90d
37d6bda
d8c857e
01db586
d979c4b
de1e9b7
00f06b4
175f5c5
b6e262c
ab1bc2e
dbe48ee
0a08f7c
8b40695
ed9ac55
f5f671b
9cabd44
6f6cbf2
4fae90e
63d2053
de20743
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 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 color text difference (with a contrast difference that is less than 3:1);</li> | ||
mbgower marked this conversation as resolved.
Show resolved
Hide resolved
|
||
<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"> | ||
|
||
|
@@ -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 | ||
|
@@ -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"> | ||
|
@@ -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> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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> | ||
|
||
|
@@ -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> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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"> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.