search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
140 stars 55 forks source link

User Interface Component Contrast (Minimum) #10

Closed allanj-uaag closed 7 years ago

allanj-uaag commented 8 years ago

<!DOCTYPE html>

Current versions of SC and Definitions

Open issues and Surveys

Open issues: SC Status page

SC Shortname

User Interface Component Contrast (Minimum)

SC Text

Essential visual identifiers of user interface components have a contrast ratio of at least 4.5:1 against the immediate surrounding color(s), except for the following situations:

  1. Thicker: A contrast ratio of at least 3:1 is required where the minimum width and height are at least 3 CSS pixels, for the essential visual identifier.
  2. Inactive: Disabled or otherwise inactive user interface components are exempt from this requirement.
  3. User agent control: The color(s) of the user interface component and any adjacent color(s) are determined by the user agent and are not modified by the author.

SC Notes

Suggested Priority Level

Level AA

Related Glossary additions or changes

essential
Uses current WCAG 2.0 definition of "essential"

What Principle and Guideline the SC falls within.

Principle 1, Guideline 1.4

Description

The intent of this success criterion is to apply the contrast requirements to essential visual identifiers related to user interface components in a similar way that it is applied to text in 1.4.3 Contrast (Minimum).

Essential

If essential non-text information is needed to understand the state and/or functionality of the user interface component then it must be perceivable for people with low vision or color blindness.

Thin and Thick

Visual identifiers that are very thin are harder to perceive, therefore have a higher contrast requirement of 4.5:1. Visual identifiers that are thicker or are solid shapes have a lower requirement of 3:1.

The size 3 CSS pixel for 'thick' was selected as it aligns with the large-text requirement of 1.4.3 Contrast (Minimum). See additional information about this concept at on how contrast and thickness were derived.

Sufficient Contrast Examples

For designers developing focus indicators, selection indicators and user interface components that need to be perceived clearly, the following are examples that have sufficient contrast.

@@Additional examples could be added for any native html elements that are interactive and have visual affordances (including: select, radio button, checkbox, details / summary, video and/or audio controls ). @@

Visual Focus Indicator Examples
Type Contrast Required Description Examples
Visual Focus Indicator
with 3 CSS pixel stroke		 3 to 1 Visual focus indicator for a link that is a 3 CSS pixel blue outline around the link. The 3 CSS pixel blue outline does provide a sufficient contrast that is equal to 3 to 1. 3 CSS pixel blue visual focus indicator line (#6699cc) against the immediate surrounding color of white (#FFFFFF) has a contrast ratio of exactly 3 to 1. Example of accessible visual focus with 3 CSS pixel stroke
See working examples at Accessible Visual Focus Indicators
Visual Focus Indicator
with 1 CSS pixel stroke		 4.5 to 1 Visual focus indicator for a link that is a 1 CSS pixel black outline around the link. The 1 CSS pixel black outline provides sufficient contrast greater than 4.5 to 1. 1 CSS pixel black visual focus indicator line (#000000) against the immediate surrounding color of white (#FFFFFF) has a contrast ratio of 21 to 1. Example of accessible visual focus with 1 CSS pixel stroke
See working examples at Accessible Visual Focus Indicators
Selection Indicator Contrast Examples
Type Contrast Required Description Examples
Thick Selection Indicator 3 to 1 Selected Tab is visually indicated with a tab background of black (#000000). The black (#000000) background on the selected tab provides a sufficient contrast that is greater than 3 to 1. The black (#000000) tab against the immediate surrounding color of light grey (#eeeeee) has a contrast ratio of 18.1 to 1. The selected tab's color of black (#000000) has a contrast of at least 3 to 1 with the color of the white (#FFFFFF) non-selected tabs The black tab background is larger that 3 CSS pixel wide and 3 CSS pixel high so it is considered "thick" and only has to meet a 3 to 1 color contrast ratio.. See working example at Accessible Contrast for Selection Indicators
Text Input Examples
Type Contrast Required Description Examples
Text Input
with 3 CSS pixel border stroke		 3 to 1 Text Input with a 3 CSS pixel border. The 3 CSS pixel blue outline does provide a sufficient contrast that is equal to 3 to 1. 3 CSS pixel blue border line (#6699cc) against immediate surrounding color of white (#FFFFFF) has a contrast ratio of exactly 3 to 1. See working example at Accessible Contrast for Text Input
Text Input
with 3 CSS pixel border stroke on bottom only		 3 to 1 Text Input with a 3 CSS pixel border on bottom. The 3 CSS pixel blue bottom border does provide a sufficient contrast that is equal to 3 to 1. 3 CSS pixel blue border line (#6699cc) against immediate surrounding color of white (#FFFFFF) has a contrast ratio of exactly 3 to 1. See working example at Accessible Contrast for Text Input
Text Input
with 1 CSS pixel stroke		 4.5 to 1 Text Input with a 1 CSS pixel border. The 1 CSS pixel black outline provides sufficient contrast greater than 4.5 to 1. 1 CSS pixel black line (#000000) against immediate surrounding color of white (#FFFFFF) has a contrast ratio of 21 to 1. See working example at Accessible Contrast for Text Input
Text Input
with 1 CSS pixel border stroke on bottom only		 4.5 to 1 Text Input with a 1 CSS pixel border on bottom. The 1 CSS pixel black bottom border does provide a sufficient contrast that is greater than 4.5 to 1. 1 CSS pixel black border line (#000000) against immediate surrounding color of white (#FFFFFF) has a contrast ratio of 21 to 1. See working example at Accessible Contrast for Text Input
Text Input with no border 3 to 1 Text Input with no border. The white background of the text input does provide sufficient contrast that is equal to 3 to 1. While there is no border, the solid area of the white text input easily meets the minimum 3 css pixel by 3 css pixel requirement to qualify as thick. The white (#FFFFFF) text input against the immediate surrounding color of blue(#6699cc) has a contrast ratio of exactly 3 to 1. See working example at Accessible Contrast for Text Input
Submit Button Examples
Type Contrast Required Description Examples
Transparent Submit Button
with 3 CSS pixel border		 3 to 1 Transparent submit button with a 3 CSS pixel blue border. The 3 CSS pixel blue border does provide a sufficient contrast that is equal to 3 to 1. 3 CSS pixel blue border line (#6699cc) against immediate surrounding color of white (#FFFFFF) has a contrast ratio of exactly 3 to 1. See working examples at Accessible Contrast for Submit Button
Light Grey Submit Button
with 3 CSS pixel border		 3 to 1 Light Grey (#EBEBEB) submit button with a 3 CSS pixel blue border. The 3 CSS pixel blue border does provide a sufficient contrast that is equal to 3 to 1. 3 CSS pixel blue border line (#6699CC) against immediate outer surrounding color of white (#FFFFFF) has a contrast ratio of exactly 3 to 1. The fact that the background of the submit button is a light grey (#EBEBEB) is irrelevant for testing the color contrast of the border line of the button, because this SC only requires the border line to contrast with the immediate outer color. See working examples at Accessible Contrast for Submit Button
Transparent Submit Button
with 1 CSS pixel border		 4.5 to 1 Transparent submit button with a 1 CSS pixel black border. The 1 CSS pixel black border provides sufficient contrast greater than 4.5 to 1. 1 CSS pixel black border line (#000000) against immediate surrounding color of white (#FFFFFF) has a contrast ratio of 21 to 1. See working examples at Accessible Contrast for Submit Button
Blue Submit Button with no border 3 to 1 Blue submit button with no border. The blue button provides sufficient contrast equal to 3 to 1. While there is no border, the solid area of the blue button easily meets the minimum 3 css pixel by 3 css pixel requirement to qualify as thick. The blue (#6699cc) text input against the immediate surrounding color of white (#FFFFFF) has a contrast ratio of exactly 3 to 1. See working examples at Accessible Contrast for Submit Button
Transparent Submit Button
with no border		 4.5 to 1 Transparent submit button with a no border. There is no visual affordance indicating this is a button for any user. This SC does not require the visual affordance to exist, it just requires that if the essential visual affordance (non-text) does exist, that essential visual affordance is accessible to people with low vision too. Note: The proposed SC that does relate to the cognitive usability problem created with a button like this is Issue #36 Clear Controls See working examples at Accessible Contrast for Submit Button

Failure Examples

Submit Button Failure Examples for Color Contrast
Type Contrast Required Description Failure Example
Transparent Submit Button
with very light grey
3 CSS px border
(Failure)		 3 to 1 Failure - Transparent submit button with a 3 CSS px very light grey border. The 3 CSS px very light grey does not meet the minimum contrast requirement of 3 to 1. 3 CSS px very light grey border line (#D2D2D2) against immediate outer surrounding color of white (#FFFFFF) has a contrast ratio of only 1.5 to 1. See working failure examples at Failure Contrast for Submit Button Border

Transparent Submit Button
with 1 CSS px light blue border (Failure)

 4.5 to 1 Failure - Transparent submit button with a 1 CSS px light blue border. The 1 CSS px light blue border does not meet the minimum contrast requirement of 4.5 to 1. 1 CSS px light blue border line (#6699cc) against immediate surrounding color of white (#FFFFFF) only has a contrast ratio of 3 to 1. See working failure examples at Failure Contrast for Submit Button Border

Recommended for Silver or a Future Version of WCAG 2.X

Disabled Interactive Elements

Due to the different needs and preferences of low vision users, the contrast requirements for inactive user interface components (also known as disabled interactive elements) is recommended for inclusion in Silver. RECOMMEND adding an ARIA-status of "disabled" so automated testing tools can ignore. A solution to consider for Silver is to make it a preference to "enhance color contrast for Low Vision AND/OR add a symbol for "disabled interactive elements".'

disabled interactive element
an inactive user interface component that is visible but not currently usable. Example: A submit button at the bottom of a form that is visible but cannot be activated until all the required fields in the form are completed.

Disabled Submit Button Example for Silver

Table Borders

When a data table has visual borders, there are times when it could be argued that those visual borders are essential to being able to read the table. But table borders are not part of an interactive element, so they are not covered by this proposed SC. We propose that the visual affordance of essential table borders be included as a part of the proposed COGA Issue #31 SC Consistent Cues .

Benefits

The intent of this Success Criterion is to provide enough contrast for interactive user interface components, form field borders, focus and selection indicators so they can be perceived by people with moderately low vision (who do not use contrast-enhancing assistive technology).

People with low vision often have difficulty perceiving graphics that have insufficient contrast. This can be exacerbated if the person has a color vision deficiency that lowers the contrast even further. Providing a relative luminance (lightness) difference of 4.5:1 or greater can make these items more distinguishable when the person does not see a full range of colors and does not use assistive technology.

When non-text content is larger, a color contrast of 3:1 or greater can be sufficient for perception by people with moderately low vision.

Examples

Testability

User Interface Component Border

For each user interface component or the essential border of each user interface component,

  1. If there is an essential border defining the edge(s) of the user interface component and the width of the border line is greater than or equal to 3 CSS pixels.
    • Check that the border line has a contrast ratio of at least 3:1 against the immediate surrounding color.
  2. else
    • Check that the edge of the user interface component OR the border line has a contrast ratio of at least 4.5:1 against the immediate surrounding color.

Expected Results

Focus Indicators

For each focus indicator:

  1. If the visual presentation of the focus indicator has a (height consistently greater than or equal to 3 CSS pixels) AND a (width consistently greater than or equal to 3 CSS pixels)
    • Check that the visual presentation of the focus indicator has a contrast ratio of at least 3:1 against the immediate surrounding color(s).
  2. else
    • Check that the visual presentation of the focus indicator has a contrast ratio of at least 4.5:1 against the immediate surrounding color(s).

Expected Results

Selection Indicators

For each selection indicator:

  1. If the visual presentation of the selection indicator has a (height consistently greater than or equal to 3 CSS pixels) AND a (width consistently greater than or equal to 3 CSS pixels)
    • Check that the visual presentation of the selection indicator has a contrast ratio of at least 3:1 against the immediate surrounding color(s).
    • Check that the color of the selection indicator has a contrast ratio of at least 3:1 against the color of the indicator when it is not selected.
  2. else
    • Check that the visual presentation of the selection indicator has a contrast ratio of at least 4.5:1 against the immediate surrounding color(s).
    • Check that the color of the selection indicator has a contrast ratio of at least 4.5:1 against the color of the indicator when it is not selected.

Expected Results

Testing with current browsers

Luminosity Brightness of Enabled/Disabled Form Controls using default browser styling

Techniques

Existing Relevant Techniques for 1.4.3

New Techniques

Related WCAG 2.0 Success Criteria and Techniques (2.4.7)

Related Information on LVTF wiki

change documentation
diff of WIKI page.

WilcoFiers commented 7 years ago

I have a few issues and questions. Hope this helps!

important (non-text) information in an interactive image;

input elements or the border line(s) of input elements;

focus and select indicator(s).

thicker lines: where the minimum width of the line is at least 3px;

I think these criteria should use PT instead of PX. It's a bit of a messy unit. If you have 3px on an LDPI screen, that's the same width as 12px on an XXDPI screen. CSS normalizes these values, calculating them to something like whatever the size would be if the screen was 72 DPI. But that just adds to the confusion. PPK has a great article about why CSS PX isn't the same as pixel width. http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html

3:1 Exceptions: disabled interactive elements;

This may be a personal preference thing, but having low vision, I think it's much more important that there is a clear difference between active and disabled elements, rather than ensure that disabled elements have a strong contrast with their background. To me, this requirement can actually reduce accessibility, as the minimum contrast for disabled elements would mean it will become harder for me to tell them apart from active elements.

disabled interactive element

Should this include 'inactive' links?

Important information information the user may need to complete any action or task including an offline task.

This is a pretty open ended requirement. Not sure how to word it, but I would think this should be limited to actions / tasks that is part of functionality available on the current page, or on a page in a process that the current page is part of.

The term "graphical element" is intended to apply to stand-alone icons such as a print icon...

I'm guessing this is a dated term, as it doesn't show in the success criterion text anymore? Should it be removed?

joshueoconnor commented 7 years ago

@jnurthen Saying that disabled items need a contrast ratio so they look like they are not disabled can cause confusion.

joshueoconnor commented 7 years ago

The WG on call likes the idea from @mraccess77 " how disabled items can be conveyed more effectively. It is valuable information that people with low vision need. There is text, there is other content to help you get it un-dsiabled. We need to think beyond what has always been done."

joshueoconnor commented 7 years ago

Glenda/John to link in with COGA to see if they have SCs for disabled icons for people with Cognitive disabilities.

lauracarlson commented 7 years ago
lauracarlson commented 7 years ago

Related COGA Proposed SC: Clear controls #36

jnurthen commented 7 years ago

Some comments

joshueoconnor commented 7 years ago

To be assigned to Glenda - when she is set up with a GH account

allanj-uaag commented 7 years ago

log of comments https://docs.google.com/spreadsheets/d/17uFopFpjdpCB1yHgkz11fEJ8IGYfPioGsvFUX1Zq96k/edit#gid=0

goodwitch commented 7 years ago

Jim Allan is getting ready to post the first round of changes that are based on the great feedback that has come in on this issue. Here are my notes of the first round of changes:

  1. Changed from proposed Level A to proposed Level AA. (Why: To stay in sync with Issue 9. Suggested by Makoto, Bruce Bailey & AWK. Approved by LVTF.) When: Change made in wiki on 19:51, 7 December 2016‎
  2. Changed "selected indicator" to "selection indicator". (Why: To keep vocabulary consistent with WCAG 2.0. Wording change proposed by AWK and Maureen Kraft.) When: Change made in wiki on 20:56, 28 December 2016
  3. Move disabled element contrast to Silver because it needs preference control. (Why: Approved by LVTF. Action-93. Suggested by Michael Gower, Wilco, jnurthen, Joshue O'Connor and more). The color contrast needs for disabled form controls has conflicting solutions for some low vision users and some users with cognitive issues. Therefore, the color contrast needs for disabled elements needs a preference control and it will be well suited for Silver). When: Change made in wiki on 23:24, 28 December 2016‎ and 23:29, 28 December 2016‎
  4. Removed ( ) from non-text. (Why: For clarity. Suggested by Wilco.) When: Change made in wiki on 23:39, 28 December 2016‎
  5. Changed "input elements" to "user interface components". (Why: For consistency with WCAG 2.0 vocabulary. Suggested by Wilco.) When: Change made in wiki on 23:54, 28 December 2016‎
  6. Changed the term "graphical element" to "interactive image" for consistency with proposed glossary term. (Why: For internal consistency. Suggested by Wilco.) When: Change made in wiki on 00:09, 29 December 2016
  7. Changed "important" to "essential". (Why: To stay in sync with proposed SC Informational Graphic Contrast) Inspired by Alastair Campbell and comments made by Wilco and AWK. When: Change made in wiki on 00:23, 29 December 2016‎
  8. Added "outer" to immediate surrounding background. (Why: For clarity. Per Michael Gower's suggestion. To stay in sync with proposed SC Informational Graphic Contrast) When: 00:47, 29 December 2016‎

Want to see the working draft of these 8 changes...head on over to https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/index.php?title=Contrast_(Minimum)&oldid=2677

Please note that a second round of changes is underway. My brain can only handle so many changes at one time. So, if you've made a comment that has not been addressed yet, rest assured it is on my list of things to review and take positive action on.

moekraft commented 7 years ago

Nice job Glenda and Jim. Thanks for keeping us up to date on the changes.

mbgower commented 7 years ago

Am I correct thinking that someone entirely removing the outline on a text area would PASS this, since there is no visual distinction? I have seen sites remove the border of text inputs before -- leaving just a cursor blinking by a label as the sole indication of the field. I would really like to be able to fail that! That said, I was surprised to see the border of a text input field being used twice in the examples. I would have thought buttons would get the most attention since those are much more commonly failing. That said, can't resist mentioning that this github UI I'm tying this message into itself fails the border requirements with the light-blue outline on this textarea. I don't think that's the browser default, BUT is there any risk of forcing all authors to override crappy user agent defaults to meet this -- resulting in unforeseen complications? I wonder if it might be an idea to consider specificying an exception where the user agent default is not overridden.

goodwitch commented 7 years ago

@mbgower interesting question about the text area. I was initial thinking that it would fail....but that dang blinking cursor may indeed pass. And, yes, we are working on additional examples and will include one for buttons as well. Interesting idea about specifying exception where the user agent default is not overridden. Let me ponder that idea.

DavidMacDonald commented 7 years ago

Is there an overlap with Issue #36 and #9

mraccess77 commented 7 years ago

Ø Is there an overlap with Issue #36https://github.com/w3c/wcag21/issues/36 and #9https://github.com/w3c/wcag21/issues/9

While there appears to be an overlap – the actual requirement for contrast seem different.

36 is really making sure that control has contrast from its surroundings to make it appear as a separate control.

9 is actually focused on the contrast of the actual control itself being discerned to be able to see what it actually is.

While they could be combined I think it would just confuse the situation. Also #36 has other requirements that have nothing to do with #9. I’d recommend keeping them separate.

Jonathan

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/w3c/wcag21/issues/10#issuecomment-273231829, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFYSMw_upt5vm0D1x__I6lsbR-vTH_Wjks5rTPUkgaJpZM4J-Rwz.

goodwitch commented 7 years ago

@jnurthen - I wanted to get back to you on 3 more of your comments.

  1. 'in all states' is a little confusing, since disabled is exempted later on - good point, I'm going to leave that in for now, but I bet it will come out.
  2. 'including when the page is scrolled' - I've not seen that concept before in any other SC - what is the need to specifically call it out? Does this mean as the page is being scrolled or something else. If it does mean this I have no idea how I would test it. - I think there is inconsistency across different experts as to how to test a page where the background changes as your scroll. Imagine after you've scrolled half-way down the page, and you've stopped to read something but the current background does not contrast well with the text...so you can't read it well. I personally think this is something that needs to be addressed at a higher level in WCAG 2.1 (like up at the conformance level). For now, I'm going to leave this in this proposed SC, but I bet it gets pulled...because it should not apply to just this SC.
  3. Since it is preferable that browsers render the focus (unless this is a change from WCAG2?), who is at fault in a web page if the default values of the browser do not meet this criteria? - excellent question. We are proposing that visual focus become a WCAG 2.1 responsibility of the developer. We can also encourage the browser vendors to work on this.
goodwitch commented 7 years ago

@WilcoFiers

I wanted to get back with you about about some more of your comments on this proposed SC:

Your comments (and my responses)

  1. Wilco said "On "focus and select indicator(s)." - This seems strange to me, select indicators are often done with a background color. Does this mean the background color has to have a contrast of 4.5:1 to the non-selected parts? That seems wrong to me. For thick stroke you allow 3:1, but backgrounds still require 4,5:1? I would think a background change is at least as clear as a thick border."
    • Glenda's response: "No. I meant that any indicator that is larger that 3 css px by 3 css px only needs to meet a 3 to 1 ratio with the immediate surrounding color. If search this page for the words 'Selection Indicator Contrast Examples" you will find a table with info/examples." Does that help?
    • You also ask if the selection color should contrast with the non-selection color. You are SOOOOO right. And I have not made that clear in the SC Text. I had not thought about that until the last day or so. So...I have included it in the example (because that was relatively easy to do)...and I even included it in Testability. But my brain wasn't ready to try and verbalize this in the SC itself. So...please (when this goes to survey)...hit me with this comment again..because I must add that detail to the SC text.
  2. Wilco said "Additionally, this 4,5:1 requirement almost forces you to invert the text color on selected items. If you have a select element for example, the BG is #FFF and the text is #555 (a respectful 7.5:1). Now an option is selected, and it gets a background of #777 so that it has a 4,5:1 difference to the #FFF bg. The text of #555 has to change color because on a #777 bg it no longer meets 4.5:1. If you do not actually want to change the text color when you select (which you may not want because that can be a little jarring), the actual color contrast requirement becomes 9:1! (Reminder 12:1 is the difference between black and white.)"
    • Glenda's response: I'm thinking we need the color contrast between selected and not selected to have at least a 3 to 1 ratio. Otherwise...wouldn't we be hurting everyone who is low vision and everyone who is color blind? Imagine if a radio button "selected" vs "not selected" did not have a contrast of 3 to 1. I think it is worth putting forth as a proposal. If there is significant pushback from the design community (and it really is too painful for designers and makes designs bad for everyone...then we may have to push this "selection" vs "non-selection" color contrast piece to WCAG 2.2...or Silver. But for now, i think it makes sense to leave it in :)
  3. Wilco said "On "input elements or the border line(s) of input elements;" I don't think border should be mentioned separately. This implies that the other 2 bullets wouldn't pass if they were done through border"
    • Glenda's response - can you take a look at my examples at http://www.glendathegood.com/a11y/lvtf/textinputborder.html ? I don't feel I can just say "input element"...I feel like I have to be really specific about what I mean. So...in many cases...an "input element" like a radio button, a text input or a checkbox...really is defined by a line. But in other cases...the text input might not have any lines...but the text input might be white...and the entire background could be blue (see examples on my site). So that is why I said it the way I did. I agree it probably could be said better...but I'm not sure how to say it. Now that you look at my examples...do you have any additional ideas for how I could say it better?
  4. Wilco said "Many browsers have a default dotted border. Am I right in guessing that as long as that dotted line has a color of 4,5:1 it meets this?"
    • Glenda's response: Yes.
  5. Wilco said "I think the scope of this should be changed. It makes sense for me that if you have an interactive bar graph, that the color contrast requirement there is different from that of a static image. But the way this criterion is formulated it's already applicable if this static image was part of a link. This feels pretty arbitrary. Not sure how to properly describe this, but I would exclude things like plain image links from this."
    • Glenda's response: Anything related to essential information in a Graphic has moved over to issue #9 (the one Alastair is handling). So based on how that one is reading now...do we need to share this comment with Alastair, or has it been addressed in other changes that have been made to it? https://github.com/w3c/wcag21/issues/9

Thanks for your brilliance. I deeply appreciate your attention to detail, depth of knowledge and all around awesomeness.

goodwitch commented 7 years ago

@awkawk I wanted to respond to 3 of your comments (that I did not have a chance to address yet). All 3 comments were from the original survey on this proposed SC with results posted here: https://www.w3.org/2002/09/wbs/35422/NewSC_20161122/results#xq1

  1. AWK asked "Border line - could a single line, only on the left of a field be sufficient?"
    • Glenda's response: If the design for all users is a single line to the left of the field, then yes, technically, I think that would be sufficient (from a simple color contrast perspective).
  2. AWK asked "What issues does the scrolling aspect of this SC try to address?"
    • Glenda's response: Some web pages meet color contrast requirements when the page first loads, but as a person scrolls down a page with a gradient background, essential data could be missed because at that state of the page (scrolled) the color contrast could be less than 3 to 1. Perhaps this could just be a side note. Or we could add an over arching assumption to WCAG 2.1 for clarity...so that we could get more consistent results from experts.
  3. AWK asked "We need to be clear about what "in all states" means"
    • Glenda's response: I agree. This is similar to the scrolling situation. Perhaps it does not belong in a specific SC...but at the higher level of WCAG 2.1. The point was to clarify that color contrast requirements exist when a user interface component is in an active / usable state. Examples of active / usable states include: checked (true/false), expanded (true/false), invalid (true/false), pressed (true/false), selected (true/false), grabbed (true/false), hover (true/false), focus (true/false). Examples of inactive / non-essential states include: disabled (true), hidden (true). I think busy (true) would fall in the inactive state...but perhaps I should sleep on that.
Ryladog commented 7 years ago

This is getting soooooo good!!

One comment on Glenda's response to AWK on this... "1.AWK asked "Border line - could a single line, only on the left of a field be sufficient?" ◦Glenda's response: If the design for all users is a single line to the left of the field, then yes, technically, I think that would be sufficient (from a simple color contrast perspective)."

I do not agree with this Glenda and Andrew. I think we need to be careful, for low vision reasons, as well as various directional-language low vision reasons NOT to specify or allow a colored line on only one side (to the left or right, nor top or bottom), as it may not all be in the viewport of a low vision user. We need to keep the surrounding the component of this really good proposed SC......

DavidMacDonald commented 7 years ago

hmmm The focus indicator has to maintain sufficient contrast... It sounds like it will have to be a double line, one light, one dark. Because otherwise it will pass on some and not on others if their are different colours of buttons. I guess the author could also put custom outline for focus ring on every interactive control based on its colour...

big ask.. but I support it.

goodwitch commented 7 years ago

Katie, good thought. Thanks for the feedback on the single line on the left indicating a text field. I agree, it would be odd for anyone to even try and design it that way. So, I'm certainly open to changes.

David, on focus indicators...yep, the easiest solution will be an Mac like focus indicator (like we see in VoiceOver) that is a double line with light and dark. Jim Allan helped me understand a super simple way to make it happen to. I've posted an example at http://www.glendathegood.com/a11y/lvtf/submitbuttonborder.html (currently living on my site, only because I'm not sure where to store it on W3C).

Onwards! G

glenda sims | team a11y lead | deque.com | 512.963.3773

web for everyone. web on everything. - w3 goals

On Thu, Feb 9, 2017 at 8:14 PM, David MacDonald notifications@github.com wrote:

hmmm The focus indicator has to maintain sufficient contrast... It sounds like it will have to be a double line, one light, one dark. Because otherwise it will pass on some and not on others if their are different colours of buttons. I guess the author could also put custom outline for focus ring on every interactive control based on its colour...

big ask.. but I support it.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/10#issuecomment-278838604, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0uWiDDjlvgHufgIV3m5FFTXeHsE68tks5ra8gKgaJpZM4J-Rwz .

jnurthen commented 7 years ago

So this would make the focus indicator in google's material design ( https://material.io/guidelines/components/text-fields.html#text-fields-input ) non conformant.

(Not stating an opinion on whether this is a good thing or not - just stating a fact)

On Feb 9, 2017, at 18:48, Glenda Sims notifications@github.com wrote:

Katie, good thought. Thanks for the feedback on the single line on the left indicating a text field. I agree, it would be odd for anyone to even try and design it that way. So, I'm certainly open to changes.

David, on focus indicators...yep, the easiest solution will be an Mac like focus indicator (like we see in VoiceOver) that is a double line with light and dark. Jim Allan helped me understand a super simple way to make it happen to. I've posted an example at http://www.glendathegood.com/a11y/lvtf/submitbuttonborder.html (currently living on my site, only because I'm not sure where to store it on W3C).

Onwards! G

glenda sims | team a11y lead | deque.com | 512.963.3773

web for everyone. web on everything. - w3 goals

On Thu, Feb 9, 2017 at 8:14 PM, David MacDonald notifications@github.com wrote:

hmmm The focus indicator has to maintain sufficient contrast... It sounds like it will have to be a double line, one light, one dark. Because otherwise it will pass on some and not on others if their are different colours of buttons. I guess the author could also put custom outline for focus ring on every interactive control based on its colour...

big ask.. but I support it.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/10#issuecomment-278838604, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0uWiDDjlvgHufgIV3m5FFTXeHsE68tks5ra8gKgaJpZM4J-Rwz .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

betabong commented 7 years ago

Google Material design is non conformant for other reasons already, lacking enough contrast in non focus mode. Still I'd find it wrong to specify too much, like that a component needs to be surrounded by borders. There are sufficiently good examples of text inputs that wouldn't pass. Also I'm very much opposed to restricting design too much, preventing potentially better solutions. The spec should define the minimal conditions that have to be met (it can still give advice on how to achieve this).

I also find the proposed minimal contrast ratios too high: 4.5:1 is the same as for small text, and that's for reading whereas a control border should help to recognise a simple shape. Many many standard OS controls would fail, as would many many websites that so far were considered good examples.

Also while I appreciate that this gap in spec will be filled we should pay attention that it doesn't open new uncertainties: I've attached an example where two of the three examples would probably not meet the criteria, although they provide sufficient visual contrast (IMHO).

contrast-and-buttons

alastc commented 7 years ago

The 'thicker' exception allows 3:1, so any button with text will be larger than 3px squared.

Therefore, if the button background contrasts 3:1 against the surroundings, that should pass.

If the surroundings of example C were #959595 or darker, it would pass. (Although logically, the 3px has to be on both sides of the dividing line, so the shade 1px might need to be darker, so that the pixels that are 3px away from the button are dark enough.)

The examples made me wonder about links in text, do they count as interactive controls?

Under the SC text:

essential graphical objects for user interface component(s) or a border line thereof...

I don't think so because they are text with no "graphical object", but what about a menu (list of links)? How about a nav element?

I think those aspects can be defined in the understanding (ideally with examples).

joshueoconnor commented 7 years ago

@goodwitch You mentioned this is ready for review? Is there PR? Let me know if so and we will get into this weeks survey (Feb14th). Thanks

goodwitch commented 7 years ago

Josh c: Jim Allan

I think Issue #10 is ready as is. Jim Allan made the changes. If the text is just the way we want it at https://github.com/w3c/wcag21/issues/10 then is that enough? Or...do I need to fork then commit then make a pull request?

G

glenda sims | team a11y lead | deque.com | 512.963.3773

web for everyone. web on everything. - w3 goals

On Sat, Feb 11, 2017 at 8:57 AM, joshueoconnor notifications@github.com wrote:

@goodwitch https://github.com/goodwitch You mentioned this is ready for review? Is there PR? Let me know if so and we will get into this weeks survey (Feb14th). Thanks

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/10#issuecomment-279149287, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0uWgnFmWG_ZCoY1TUbn8bsKPD9SPINks5rbcxCgaJpZM4J-Rwz .

allanj-uaag commented 7 years ago

closed. see Issue #128

betabong commented 7 years ago

I hope this is the right place to add my concerns. While I very much agree with the contrast criterias for text, I think that this one goes too far (with the required contrast) and is misleading: we want to make sure that people recognize UI elements as such, but we should not define this has to happen via borders. If it would say that "The defining graphical elements of a UI control need to have at least 3:1 contrast when the minimum area covers 3 pixels or 4.5:1 if it covers less", I'd go with it. But this way you'll render a lot of good and accessible websites "unsuccessful".

I'm adding another example to illustrate the problem. The graphic shows 4 controls elements (A to D) and all of them are probably not accessible (although may be the ones without any border at all are?) And I'm sorry to say so: that's just wrong.

wcag2 1-inputs

So I hope you'll reconsider. I'm both designer and frontend developer and I love to create accessible websites and I want to continue doing so.

goodwitch commented 7 years ago

@betabong So...look back at the proposed SC text and notice that it says "The visual presentation of essential graphical objects for user interface component(s) OR a border line ". So only essential border lines need to have the color contrast.

In your examples above, I can see that item A offers good contrast (for both the text and the downward facing triangle). For item C, that blue (#4C93DE) text (and left point arrow) against a white background is only a 3.2 to 1 color contrast ratio...so I'd have to get down to measuring the "thickness" of the blue line that forms the left facing arrow to see if it is at least 3 css pixels (thicker).

I'm going to add a testability section for this exact use case...so hopefully that will clarify that non-essential borders are NOT required to meet color contrast (which also means that a border that is non-essential can be left off the design entirely).

mraccess77 commented 7 years ago

@goodwitch when is a border essential and when is it not essential? I assume an input field's border is essential? What about text that acts as a button?

goodwitch commented 7 years ago

Based on feedback from survey and AGWG meeting, I changed the wording of this proposed SC to what was suggested by @michael-n-cooper . I also applied Greg's suggestion to move the list of things it applies to into a glossary entry for essential graphical objects for user interface components.

DavidMacDonald commented 7 years ago

The visual presentation of all essential graphical objects for user interface components has a contrast ratio of at least 3:1 against the immediate surrounding color(s), unless it is disabled or otherwise inactive. Propose simplification and also address focus:

The visual presentation of all essential graphical objects for user interface components and their focus indicators, has a contrast ratio of at least 3:1 against the immediate surrounding color(s), unless it is disabled or otherwise inactive.

CityMouse commented 7 years ago

I would think focus indicator would handle this, just to ensure they are viewable in contrast to the page content.

goodwitch commented 7 years ago

@mraccess77 you asked "when is a border essential and when is it not essential? I assume an input field's border is essential?" The test? If there is a visual border for the input field as original designed, then the border should meet color contrast requirements. If there is no visual border for the input field, then it is equally ambiguous to all users. Same goes for text that acts as a button. I am assuming there is no other visual affordance to indicate that the button is indeed a button.

goodwitch commented 7 years ago

@DavidMacDonald I don't think we can just add "focus indicators" because then people will ask about "selection indicators". I've taken one more stab at clarifying this SC by adding a note. Can you look at the updated text at the top of this issue?

mraccess77 commented 7 years ago

@goodwitch If there is no visual border for the input field, then it is equally ambiguous to all users. Same goes for text that acts as a button. I am assuming there is no other visual affordance to indicate that the button is indeed a button.

This is a whole other topic. It seems that people with cognitive disabilities could be at a disadvantage in this situation. Also mouse users will get a clue when they hover, A keyboard user would as well but it would require more effort to get their. Sometimes when an input field has no border it isn't clear if the field is above or below the label and whitespace may be the only indicator. It makes it more complicated when there is placeholder text in the input field and a label. https://www.gofundme.com/send-a-random-girl-to-cna-school/donate. For example, in the example from go fund me when viewed in Chrome there is no borders -- first name is a place holder but email address is a label.

But back to the main question -- if the button does have a border but it's faint then it becomes an accessibility issue as the border communicates that it's not just text but a button. So if there is no border it's not a violation of this SC -- but perhaps another -- but if there is a border and no other way to know that the text is actionable and if the border doesn't have sufficient contrast then it's a violation of this SC IMO.

goodwitch commented 7 years ago

@mraccess77 Agreed!

awkawk commented 7 years ago

Looking back at the original problem statement: "The intent of this Success Criterion is to provide enough contrast for interactive user interface components, form field borders, focus and selection indicators so they can be perceived by people with moderately low vision (who do not use contrast-enhancing assistive technology).".

I wonder whether we are getting too focused on things like borders. Ultimately, I think that we want to say "people need to be able to tell what is an interactive control" - is that right?

Here's a few examples: 1) http://bilderphoto.com - the main heading and the "view collections" text are interactive. They are actually both part of the same link. 2) https://18f.gsa.gov - there is a "get in touch" button (actually a button within a link) that is purple, and has no border. It does have >7:1 contrast between the button background and the area it is in front of though. It seems that we would want to have this looked at under this SC, but wouldn't if it was just looking at borders. 3) Flat buttons in Material UI http://www.material-ui.com/#/components/flat-button - these have text and the same background color as the surrounding background, and no border. Pass or fail? I can see the argument that they need to do more than they do because if these were links we would expect that they have an underline or something to differentiate them from regular text. What if a flat button had an underline like a link?

I think that we need to think about our position on control type and interaction. If I had a web page and made all of my links have a full border around them, I don't think that we would fail any SC currently. Conversely, what are we expecting from buttons and other controls?

DavidMacDonald commented 7 years ago

@goodwitch the note would have to be a definition for the normative glossary rather than a note

@awkawk said "people need to be able to tell what is an interactive control" which @betabong said also, https://github.com/w3c/wcag21/issues/10#issuecomment-287120439 Also, I don't think we need "against immediately surrounding colors". We didn't say that in 1.4.3. What about this for the SC?

All essential visual identifiers of user interface components have a contrast ratio of at least 3:1, except when the component is inactive.

Definition of visual identifiers of User Interface Components: A visual indication that the component is interactive. This may be a border, icon, or other visual indication (which doesn't rely on color alone). Focus and selection indicators represent separate states of the interface component which also require these contrast minimums.

If we want the 2 tier contrast 4.5:1 and 3:1 we could still use the same language for the first sentence.

All essential visual identifiers of user interface components have a contrast ratio of at least 4.5:1, except for the following situations:

alastc commented 7 years ago

I certainly like "essential visual identifiers of user interface components", it neatly calls out the specific things we’re looking for without being overly specific in the SC.

That concept may also be useful for the Clear Controls SC as well? #36

Regarding the need to say immediate surrounding colours, text has an advantage because you are talking about it's foreground and background, e.g. in the understanding the first sentence includes "enough contrast between text and its background".

For graphics (#9), they may not have a background. They are much more likely to have different colors next to each other, e.g. in a pie chart. I don't think we can assume they have 'a' background.

For this one (interactive controls), hmm, it's somewhere in the middle. They are less likely to be adjacent to multiple colours, but still more common than text.

DavidMacDonald commented 7 years ago

@alastc I'm fine to leave "against immediately surrounding colours" if it serves a purpose.

I'm still struggling with the focus indicator issue. If a black focus indicator hits a button with a black border, it has sufficient contrast with the background, but is it visually distinct from other controls? Our current language would pass that. Wouldn't it?

alastc commented 7 years ago

If it is under author control, the focus indicator can be different for different elements, so it should be visually distinct from it's previous state (not focused), and from EITHER the element or the surroundings.

Or, the focus indicator should be a change of background, shape, size, font-style... doesn't have to be a border.

I do have a wider question about states: Do WCAG guidelines apply in all states by default? My thinking it a bit of a patchwork on this, and I think the answer is in ancillary info somewhere.

Examples:

Is a different state an alternative way of passing in general?

DavidMacDonald commented 7 years ago

Do WCAG guidelines apply in all states by default?

Probably yes, but in practise probably not well enforced.

goodwitch commented 7 years ago

@awkawk great questions posted by you on March 29. My responses:

Overarching thoughts...

Now on to your specific questions

  1. Links on http://bilderphoto.com/ would be covered under WCAG 2.0 SC 1.4.3 Contrast (Minimum) and 1.4.1 Use of Color
  2. "get in touch" button on https://18f.gsa.gov does pass this proposed SC...see the example listed above "Blue Submit Button with no border" and see it in action at http://www.glendathegood.com/a11y/lvtf/submitbuttonborder.html Also see the section where I've defined how to test for this...it is called "User Interface Component Border" under Testability.
  3. Flat buttons (http://www.material-ui.com/#/components/flat-button) don't have borders in the default state...this SC does not REQUIRE anything be added...if someone designs something that has zero visual clues that it is a button...well...that is their design choice. This SC is about when a visual affordance is only available to people who can see things with low color contrast. (and yes, I'm pulling the failure example about a button with no border failing this SC. I think this SC should stick to...if an essential visual affordance exists...it needs to have proper color contrast. The question on "does a button need an edge/border"...can be tackled from a different SC..that I would bet comes from COGA. Make sense?)
  4. Clear Controls - questions like "is this thing even recognizable as a button?" belong in a different SC. I look to Issue #36 Clear Controls and Issue #49 Familiar Design for that. Let's keep this SC 100% focused on color contrast for essential non-text information.
goodwitch commented 7 years ago

@DavidMacDonald you said "I'm still struggling with the focus indicator issue. If a black focus indicator hits a button with a black border, it has sufficient contrast with the background, but is it visually distinct from other controls? Our current language would pass that. Wouldn't it?"

And, of course, I'm thinking oreo as a "simple" solution. Or, as Alastair said, different focus indicators could be created for different situations on a site.

Thanks for the reaching out to ask if we can have more control on the css double style outline.

goodwitch commented 7 years ago

@DavidMacDonald and @alastc I do believe WCAG should apply to all active states.

mraccess77 commented 7 years ago

As an FYI - in my experience when the background is used to be a focus indicator this information can be lost in high contrast mode. HCM may restore the normal system focus indicator. So this is something we need to carefully consider if we recommend that strategy.

DavidMacDonald commented 7 years ago

The proposal to the CSS working group I made to introduce multiple outline colours as an option for focus indicators has been accepted. This will allow focus indicators to be visible regardless of the colour of the interactive element.

This clears the way for us to require contrast on focus indicators without worrying about there being many colours of buttons. https://github.com/w3c/csswg-drafts/issues/1172

goodwitch commented 7 years ago

LVTF voted to add the following exception to this proposed SC (inspired by Target Size #60 )

User agent control: The color(s) of the user interface component and any adjacent color(s) are determined by the user agent and are not modified by the author.

DavidMacDonald commented 7 years ago

I would like to make a friendly amendment:

All essential visual identifiers that a user interface component is interactive have a contrast ratio of at least 3:1 against the immediate surrounding color(s), except for the following situations:

  • Inactive: Disabled or otherwise inactive user interface components are exempt from this requirement.
  • User agent control: The color(s) of the user interface component and any adjacent color(s) are determined by the user agent and are not modified by the author.

The rationale is that text requires more detail to process than an affordance. Also, we have focus indicators in the mix. When the focus indicator is on a button it would need a 4.5:1 contrast with the button border, which requires an additional 4.5:1 with the background. This narrows the pallet for buttons significantly. 3:1 improves that. Alternatively something can be done about the double contrast requirement when a focus indicator hits the button. No sure how that language would look. Perhaps making it explicit that the focus indicator only needs contrast on one side of the line??