User Interface Component Contrast (Minimum)

[allanj-uaag]

Current versions of SC and Definitions

• SC in full draft guideline

Open issues and Surveys

Open issues: SC Status page

• March 14 2017 Survey
  (Links to surveys require W3C Member access)

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

• Examples of essential visual identifiers of user interface components may include (a border, edge, or icon) current value (such as non-text visual indication of aria-valuenow on a slider) and current state (such as selection indicator, focus indicator) or other essential visual indication (which do not rely on color alone).
• Under consideration: simplify this Success Criterion by setting the minimum color contrast requirement to 3:1 and removing any need for measuring thickness.

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.	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.	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

• A disabled submit button that has a closed lock on it indicating that this button is not active yet.

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

• A thin (under 3 CSS pixel width) border on form fields in a university admissions application have a 4.5:1 minimum contrast ratio.
• A thick (3 CSS pixel or wider) border on form fields in a university admission application has a 3:1 minimum contrast ratio.
• Focus indicators on all links in a Web site have a 4.5:1 minimum contrast ratio.

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

• 1 or 2 is true.

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

• 1or 2 is true.

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

• 1or 2 is true.

Testing with current browsers

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

Techniques

Existing Relevant Techniques for 1.4.3

• G17: Ensuring that a contrast ratio of at least 7:1 exists between text (and images of text) and background behind the text
• G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text
• G145: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text
• G174: Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast
• G183: Using a contrast ratio of 4.5:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them

New Techniques

• Using sufficient contrast for images that convey information (Draft)
• Using sufficient contrast for borders (future link)
• Using sufficient contrast for links when they receive keyboard focus (future link)
• Using a double line with sufficient contrast for borders (future link)
• Using a focus indicator that works for all backgrounds (future link)

Related WCAG 2.0 Success Criteria and Techniques (2.4.7)

• 2.4.7 Focus Visible
  • F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received
  • F78: Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator
  • C15: Using CSS to change the presentation of a user interface component when it receives focus (CSS)
  • G195: Using an author-supplied, highly visible focus indicator
  • SCR31: Using script to change the background color or border of the element with focus (Scripting)

Related Information on LVTF wiki

change documentation
diff of WIKI page.

[WilcoFiers]

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

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

• 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.

• Remove () from non-text to make it clear this is only about non-text. This scope must be limited to non-text information, as the usual exceptions that apply to the color contrast rule aren't in this criterion.

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

• Input elements is the wrong word here. I'm guessing this to be similar to what 4.1.2 calls "form elements". Although I'm not a fan of that either. For sure input element excludes textarea and select if you take a narrow interpretation of this. So maybe form control? I'm guessing this applies to buttons too?

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.

• 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 JR comment on Timeouts #555 (a respectful 7.5:1). Now an option is selected, and it gets a background of Aria status role #777 so that it has a 4,5:1 difference to the #FFF bg. The text of JR comment on Timeouts #555 has to change color because on a Aria status role #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.)

• 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?

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]

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

[joshueoconnor]

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]

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

[lauracarlson]

• Survey Results - 22 November 2016
• Minutes - 29 November 2016
• RESOLUTION: Glenda to work on an updated proposal on Disabled Item Success Criteria proposal

[lauracarlson]

Related COGA Proposed SC: Clear controls #36

[jnurthen]

Some comments

• 'in all states' is a little confusing, since disabled is exempted later on
• '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 would prefer to see everything dealing with focus visibility addressed in a separate SC - basically a 'well-quantified' version of the current 2.4.7 that includes contrast, width, etc.
• 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?
• I have absolutely no idea what is meant by the definition of immediate surrounding background: 'a 3px area adjacent to the entire length of the perimeter of the element'. Is that meant to be 9 pixels, from a 3x3 square? And which 3 (or 9) pixels am I supposed to pick for the test??
• the example of the 'wider' text is confusing here since the SC specifically is for non-text

[joshueoconnor]

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

[allanj-uaag]

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

[goodwitch]

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]

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

[mbgower]

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]

@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]

Is there an overlap with Issue #36 and #9

[mraccess77]

Ø Is there an overlap with Issue #36<#36> and #9<#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 GitHub<#10 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFYSMw_upt5vm0D1x__I6lsbR-vTH_Wjks5rTPUkgaJpZM4J-Rwz>.

[goodwitch]

@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]

@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 JR comment on Timeouts #555 (a respectful 7.5:1). Now an option is selected, and it gets a background of Aria status role #777 so that it has a 4,5:1 difference to the #FFF bg. The text of JR comment on Timeouts #555 has to change color because on a Aria status role #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 Graphics Contrast #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? Graphics Contrast #9

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

[goodwitch]

@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]

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]

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.

[mraccess77]

@DavidMacDonald There is a CSS Level 3 outline offset that allows you to position the focus indicator beyond the bounds of the button mitigating the issue with trying to get sufficient ratio between border, background, and page background. I believe It's supported by all browsers but IE.

[goodwitch]

@DavidMacDonald I think your suggested friendly amendment (to simplify this proposed SC to only require 3 to 1) is a pragmatic approach. Looking forward to discussing at the AGWG meeting to see if others support this as well.

[steverep]

All essential visual identifiers that a user interface component is interactive have...

The "all" is implied here (we could put that on every SC). Save yourself 3 characters and a space. Also, saying "identifiers that a" is bad grammar. I don't really see the value in mentioning that UI components are interactive since that's inherent in their definition. So I think the start of the criterion should be simplified to:

Essential visual identifiers of user interface components have...

[mraccess77]

@steverep I don't agree that UI components are inherently interactive. A separator, label, and icons can all be non-interactive.

[steverep]

@mraccess77, I'll yield to WCAG 2.0 veterans on what the original intent was, but if they can be non-interactive then the existing definition, which says it must be perceived as a control for a function, needs work. If it can be controlled, it's interactive. All criteria where it is used imply interaction as well: contrast exception for inactive UI components, 3.2.2 saying they have a setting, and several things about 4.1.2. If a separator is a UI component, how do you give it a name to pass 4.1.2?

[goodwitch]

@DavidMacDonald thanks for your friendly amendment on June 1. I've added a note to this proposed SC User Interface Component Contrast (Minimum) saying we are considering simplifying the requirement to just 3:1 with no requirement to measure thickness. I don't feel comfortable completely removing the 4.5:1 option at this time, since the LVTF and Low Vision Researchers (including Aries Arditi and Gordon Legg) agree that 'In fact, one could make the argument that poor contrast can be a greater problem for form controls than for text.'

We believe it is worthwhile to let this proposed SC be reviewed by the public. Are you in agreement? (now that we have added an note to indicate that simplifying to 3:1 is under consideration)?

[goodwitch]

@steverep Thanks for your suggestion on simplifying the language of this SC. I've removed the words "All" and "interactive". See the latest version of this proposed SC User Interface Component Contrast (Minimum)

[DavidMacDonald]

@goodwitch I can live with it at 4.5:1.

But would like to see discussion of the different states and their contrast levels. It's going to be a pretty significant ask of devs.

[allanj-uaag]

Excellent.

…

On Fri, Jun 16, 2017 at 1:42 PM, David MacDonald ***@***.***> wrote: @goodwitch <https://github.com/goodwitch> I can live with it at 4.5:1 — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG_WL7plukRjVDno8upCR6OHoSt1UtBBks5sEsyggaJpZM4J-Rwz> .

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964

[PhuongHoang1182]

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".'

RECOMMEND adding aria-describedby or the new aria-errormessage with aria-disabled to make it clear.
I been waiting for this, can't wait to see this completed.

Thanks you allanj-uaag

[guyhickling]

Would it be possible to amend the example of the Selection Indicator, currently shown in the Sufficient Contrast Examples of the draft Understanding document? It features a set of tabs, which is a good example to use as it is something different from the other examples, and a very popular component as well. But while the selected tab is a nicely contrasting black, the other tabs have no contrast at all, so as it stands it isn't a good example for the SC.

In detail, the light grey border round the tabs has a colour of #d9d9d9, which has a contrast of only 1.2 to 1 against the #eeeeee grey background outside them (and only a contrast of only 1.4 to 1 against the white tabs themselves). They are only recognisable as tabs by the characteristically shaped borders round them (plus their positional arrangement in a row), so it seems to me the border is one of the main visual identifiers and needs the full 4.5 contrast.

I'm concerned that if it is published like this developers will use it as an example of how tabs can look, and they will quote the SC to support all their barely visible designs!

[guyhickling]

Regarding "immediate surrounding colors", it might be good to incorporate either a definition in this SC, or some examples of what exactly this term means, as it could be ambiguous to some people in some circumstances (and the WCAG is already ambiguous enough as it is!)

For instance the border round a button: most would view that as a box and understand everything outside it to be surrounding, but not what is inside it. Others might view the border as 4 lines, and developers especially are quite used to that in the CSS. Border-top, border-right and so on are CSS properties, and developers can specify different values for them. A line is surrounded on both sides, so on that basis the button colour and the background around the button both "surround" the line that is one side of the border.

Perhaps the SC's Understanding document could include something like:

"To clarify what is meant by "immediate surrounding color(s)" in the case of something like a rectangular button with a border, the button's border color must have the specified contrast with the color of the content that surrounds the button, but the amount of contrast between the border and the button's fill color is not important for this SC to be satisfied."

[goodwitch]

@guyhickling I love your suggestion about clarifying what is meant by "immediate surrounding color(s)". I've just added it exactly as your wrote it. Check it out at Understanding User Interface Component Contrast.

[mbgower]

I've just added it exactly as your wrote it.

@goodwitch, this was discussed somewhere else already. i remember commenting on it many months back. I think it was in the context of #9 and some of the related material.

I think Guy's wording can work to make it clear we're talking about the external surrounding colour, but I just want to make sure that if we constrain it to that, then internal colour contrast is covered by existing minimum text contrast. In other words, if my border colour on a button is the same as or similar to the fill colour on the button, that doesn't matter, so long as:

1. the contrast between the fill colour and the text colour is sufficient (measured via 1.4.3)
2. the contrast between the border and the page background colour is sufficient (measured by this new SC)

I've actually used a 'bump up' in the border colour to get around an existing design where the colour pallette failed (but where I couldn't get traction to alter the entire pallette).

[goodwitch]

@guyhickling I also agree with your suggestion (on July 26) where you asked if I could darken the light grey border around the tabs to meet 4.5 to 1. So, I've just changed that example. Take a look at Accessible Contrast for Selection Indicators and see if you like it now.

[goodwitch]

@mbgower you are correct, the WCAG 2.0 SC 1.4.3 Contrast (Minimum) is still fully in play, so text contrast requirements are unchanged. This new proposed SC is to address non-text items that need color contrast.

[guyhickling]

Yes, that tabs example looks much better. Thank you.

[mgifford]

I understand this issue is closed, but would be nice to have the initial links in this work, rather than go to 404 pages.

[goodwitch]

Great idea! Done!