This repository has been archived by the owner. It is now read-only.

User Interface Component Contrast (Minimum) #10

Closed
allanj-uaag opened this Issue Sep 15, 2016 · 69 comments

Comments

@allanj-uaag
Contributor

allanj-uaag commented Sep 15, 2016

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

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

  • 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

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)

Related Information on LVTF wiki

change documentation
diff of WIKI page.

@joshueoconnor joshueoconnor added the LVTF label Sep 18, 2016

@allanj-uaag allanj-uaag changed the title from Contrast (Minimum) (LV) to Interactive Element Contrast (Minimum) (LV) Nov 17, 2016

@allanj-uaag allanj-uaag changed the title from Interactive Element Contrast (Minimum) (LV) to Interactive Element Contrast (Minimum) (LV) !! ready for review Nov 17, 2016

@WilcoFiers

This comment has been minimized.

Show comment
Hide comment
@WilcoFiers

WilcoFiers Nov 23, 2016

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

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

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

  • 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

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Nov 29, 2016

Contributor

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

Contributor

joshueoconnor commented Nov 29, 2016

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

@joshueoconnor

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Nov 29, 2016

Contributor

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

Contributor

joshueoconnor commented Nov 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Nov 29, 2016

Contributor

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

Contributor

joshueoconnor commented Nov 29, 2016

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

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
Contributor

lauracarlson commented Dec 2, 2016

@jnurthen

This comment has been minimized.

Show comment
Hide comment
@jnurthen

jnurthen Dec 6, 2016

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

jnurthen commented Dec 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Dec 6, 2016

Contributor

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

Contributor

joshueoconnor commented Dec 6, 2016

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

@goodwitch

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Jan 4, 2017

Contributor

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.

Contributor

goodwitch commented Jan 4, 2017

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.

@allanj-uaag allanj-uaag changed the title from Interactive Element Contrast (Minimum) (LV) !! ready for review to Interactive Element Contrast (Minimum) (LV) !! revised 4 Jan 2017 Jan 4, 2017

@moekraft

This comment has been minimized.

Show comment
Hide comment
@moekraft

moekraft Jan 10, 2017

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

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

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 11, 2017

Contributor

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.

Contributor

mbgower commented Jan 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Jan 11, 2017

Contributor

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

Contributor

goodwitch commented Jan 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 17, 2017

Contributor

Is there an overlap with Issue #36 and #9

Contributor

DavidMacDonald commented Jan 17, 2017

Is there an overlap with Issue #36 and #9

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jan 18, 2017

Contributor
Contributor

mraccess77 commented Jan 18, 2017

@goodwitch

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Feb 3, 2017

Contributor

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

goodwitch commented Feb 3, 2017

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

@allanj-uaag allanj-uaag changed the title from Interactive Element Contrast (Minimum) (LV) !! revised 4 Jan 2017 to Interactive Control Contrast (Minimum) (LV) !! revised 3 Feb 2017 Feb 7, 2017

@goodwitch

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Feb 8, 2017

Contributor

@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? #9

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

Contributor

goodwitch commented Feb 8, 2017

@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? #9

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

@goodwitch

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Feb 8, 2017

Contributor

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

goodwitch commented Feb 8, 2017

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

@allanj-uaag allanj-uaag changed the title from Interactive Control Contrast (Minimum) (LV) !! revised 3 Feb 2017 to Interactive Control Contrast (Minimum) (LV) !! revised 8 Feb 2017 Feb 8, 2017

@Ryladog

This comment has been minimized.

Show comment
Hide comment
@Ryladog

Ryladog Feb 9, 2017

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

Ryladog commented Feb 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Feb 10, 2017

Contributor

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.

Contributor

DavidMacDonald commented Feb 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Feb 10, 2017

Contributor
Contributor

goodwitch commented Feb 10, 2017

@jnurthen

This comment has been minimized.

Show comment
Hide comment
@jnurthen

jnurthen Feb 10, 2017

@betabong

This comment has been minimized.

Show comment
Hide comment
@betabong

betabong Feb 10, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Feb 10, 2017

Contributor

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

Contributor

alastc commented Feb 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Feb 11, 2017

Contributor

@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

Contributor

joshueoconnor commented Feb 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Feb 13, 2017

Contributor
Contributor

goodwitch commented Feb 13, 2017

@allanj-uaag

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Feb 13, 2017

Contributor

closed. see Issue #128

Contributor

allanj-uaag commented Feb 13, 2017

closed. see Issue #128

@goodwitch goodwitch reopened this Mar 16, 2017

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Mar 30, 2017

Contributor

Do WCAG guidelines apply in all states by default?

Probably yes, but in practise probably not well enforced.

Contributor

DavidMacDonald commented Mar 30, 2017

Do WCAG guidelines apply in all states by default?

Probably yes, but in practise probably not well enforced.

@goodwitch

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Apr 6, 2017

Contributor

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

Overarching thoughts...

  • Non-text - this SC is for NON-TEXT things that are interactive. Anything that is just a plain ole link (link text) will fall under WCAG 2.0 SC 1.4.3 Contrast (Minimum) and 1.4.1 Use of Color.
  • Border/Edges - Borders are not just lines...borders can be contrast in colors of edges of things...see answer to 2) below

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

goodwitch commented Apr 6, 2017

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

Overarching thoughts...

  • Non-text - this SC is for NON-TEXT things that are interactive. Anything that is just a plain ole link (link text) will fall under WCAG 2.0 SC 1.4.3 Contrast (Minimum) and 1.4.1 Use of Color.
  • Border/Edges - Borders are not just lines...borders can be contrast in colors of edges of things...see answer to 2) below

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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Apr 6, 2017

Contributor

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

Contributor

goodwitch commented Apr 6, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Apr 6, 2017

Contributor

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

Contributor

goodwitch commented Apr 6, 2017

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

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Apr 8, 2017

Contributor

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.

Contributor

mraccess77 commented Apr 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Apr 20, 2017

Contributor

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. w3c/csswg-drafts#1172

Contributor

DavidMacDonald commented Apr 20, 2017

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. w3c/csswg-drafts#1172

@goodwitch

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Jun 1, 2017

Contributor

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.

Contributor

goodwitch commented Jun 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jun 1, 2017

Contributor

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

Contributor

DavidMacDonald commented Jun 1, 2017

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

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jun 2, 2017

Contributor

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

Contributor

mraccess77 commented Jun 2, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Jun 6, 2017

Contributor

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

Contributor

goodwitch commented Jun 6, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Jun 15, 2017

Member

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

Member

steverep commented Jun 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jun 15, 2017

Contributor

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

Contributor

mraccess77 commented Jun 15, 2017

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

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Jun 15, 2017

Member

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

Member

steverep commented Jun 15, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Jun 16, 2017

Contributor

@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)?

Contributor

goodwitch commented Jun 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Jun 16, 2017

Contributor

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

Contributor

goodwitch commented Jun 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jun 16, 2017

Contributor

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

Contributor

DavidMacDonald commented Jun 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@allanj-uaag

allanj-uaag Jun 20, 2017

Contributor
Contributor

allanj-uaag commented Jun 20, 2017

@PhuongHoang1182

This comment has been minimized.

Show comment
Hide comment
@PhuongHoang1182

PhuongHoang1182 Jul 17, 2017

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

PhuongHoang1182 commented Jul 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@guyhickling

guyhickling Jul 25, 2017

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!

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

This comment has been minimized.

Show comment
Hide comment
@guyhickling

guyhickling Jul 26, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Jul 27, 2017

Contributor

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

Contributor

goodwitch commented Jul 27, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jul 27, 2017

Contributor

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

Contributor

mbgower commented Jul 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Jul 28, 2017

Contributor

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

Contributor

goodwitch commented Jul 28, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Jul 28, 2017

Contributor

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

Contributor

goodwitch commented Jul 28, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@guyhickling

guyhickling Jul 28, 2017

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

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

@mgifford

This comment has been minimized.

Show comment
Hide comment
@mgifford

mgifford Sep 4, 2017

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

mgifford commented Sep 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Sep 5, 2017

Contributor

Great idea! Done!

Contributor

goodwitch commented Sep 5, 2017

Great idea! Done!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.