-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Content switcher fails WCAG 1.4.11 Non-text Contrast #6745
Comments
@carbon-design-system/design thoughts about adding a stroke to the content switcher so it meets WCAG contrast requirements? |
Version 4 and 5 make sense to me. @jeanservaas @aagonzales can we see those in context of some UIs and confirm which of the designs are preferred |
Thanks for this @mbgower. |
No problem, @mjabbink. As noted at the end of my admittedly long issue:
|
I'm going to add this to our sprint backlog to look at in a future sprint. Stay tuned for an answer. |
I’m partial to as-is with 3:1 divider and option 5 outline |
@aagonzales Option 5 works well to compliment the button switcher on the far right |
@mjabbink so do you think we should darken the divider of the as-is and also add in a new variant for option 5? |
@aagonzales I think we should have one but I mentioned a second choice (5). That said though I leave the choice as 5 as variant to you and Jeannie |
is the unselected background-color supposed to be transparent or |
@emyarod The background color for an unselected section and unselected-disabled section should be |
@aagonzales I recently saw a switcher (forgot where) that had the inside corners of the selected container also rounded like the external radius. This helps identify the selected state with another visual cue. Maybe worth thinking about/investigating? |
@mjabbink Its like that in Sketch. I've seen it else where too. 4px px is pretty subtle but more rounded radius don't look as crispy either. I do think the radius on all side is nice as an additional visual cue as to which one is selected. |
Content switcher fails to provide sufficient contrast for information required to identify the user interface component
1.4.11 Non-text Contrast requires that a minimum 3:1 contrast exists for "visual information required to identify user interface components"
The Content switcher is a complex UI component, made up of at least two tabs that "allow users to toggle between two or more content sections within the same space on screen."
As described on the usage page, the component consists of a selected tab (1) and one or more selectable tabs (2), each with a text label.
Automated testing tool and ruleset
N/A There are no automated test tools that detect failures of 1.4.11
Assistive technology used to verify
Colour contrast analyzer (or any similar tool) can be used to measure the contrast of the visual elements
Detailed description
The contrast failure takes place because the light grey outline of the unselected tab does not achieve a 3:1 contrast against the background. In the version shown on the usage page, the contrast is only 1.1:1
Lacking any visual 'binding' between the selected and unselected tabs, the switcher can easily be mis-identified as a black button. This is especially the case given the 'button' is always present. The problem is especially pronounced in a 2-tab implementation.
In a real-world implementation, the confusion can be shown in the following image from a prototype.
The lower resolution of a conference call this morning rendered the "document" tab as simply a piece of text, resulting in perception of the All tab as a separate black button. Chris Connors asked me to open an issue, based on that discussion.
To understand why some kind of outline around the unselected tab must meet 3:1 contrast, it is helpful to strip the background entirely. This is a recommended test to identify whether any particular visual detail of a UI component is "required to identify" the component.
The default Carbon component is shown at the top of each row of the above image.
Version 1, in each column, strips out all the light grey background (which fails to meet 3:1) on the unselected tabs.
I hope it is clear to anyone viewing versions 1, that the content switcher is not obvious as a component when it is lacking any visual treatment on the unselected tabs.This is especially confusing in a 2-tab implementation.
Version 2 shows the same treatment with the addition of a 1px stroke around the unselected tabs. The component immediately becomes clear as a single component. There are other ways to achieve this minimum contrast, but this seems like the most obvious (especially for demo purposes).
Version 3 shows the same stroke treatment, with all other low contrast info removed. The unified component is still clearly decipherable.
Another piece of visual information which fails 3:1 is the divider between the 2 unselected tabs in the second column. Based on version 3, it is difficult to argue that this divider is required to understand the component or its states. The spacing of the text labels alone provides visual affordance between the 2 unselected tabs.
That said, versions 4 and 5 show there is some benefit to bumping up the contrast of the divider as well.
Version 4 bumps up the contrast of the divider to 3:1.
Version 5, like version 3, shows this clearer divider with the low contrast info removed.
As stated, a case can be made that neither treatment 4 or 5 is required to meet 1.4.11 for this component; however, a better-contrasted divider may be more understandable by some users, and I would recommend doing some user testing with this enhanced divider, especially in an implemented page where other content adds 'noise' to the experience..
Non-text contrast assessments of other Carbon components
I recommend a similar assessment of other Carbon components be carried out (using the procedure of stripping out low-contrast visual features) to determine which visual elements need increased contrast in order for each component to pass 1.4.11 Non-text contrast.
The text was updated successfully, but these errors were encountered: