Problem/Motivation
WCAG 2.1AA requires certain minimum contrast for icons which convey information (SC 1.4.11 Non-text contrast). Also sites with a dark theme will require a light icon.
Proposed resolution
The current sprite needs to be changed to adjust the color of the icon. Light icons also need to be added to the sprite.
Alternatively we create an svg for each of the icons. Possibly declaring the code in the css. Which would allow css override for the colour.
Additional information on SVG accessibility:
https://developer.paciellogroup.com/blog/2013/12/using-aria-enhance-svg-...
Original report by [miwayha]
We're using this module on sites that must comply with WCAG 2.0 AA, which includes minimum contrast requirements. The pngs included in this module are slightly too light to meet the minimum requirements on a white background. When I use the mac color meter, it looks like they are RGB (135, 135, 135). Anything RGB (105, 105, 105) or darker would meet this requirement.
Is that something you could consider?
Thanks!
Comment | File | Size | Author |
---|---|---|---|
#44 | Icon on dark area.png | 21.9 KB | brucedarby |
#44 | Icon on light area.png | 45.94 KB | brucedarby |
#42 | 2811293-42.patch | 12.26 KB | elachlan |
| |||
#39 | 2811293-39.patch | 11.81 KB | elachlan |
| |||
#37 | 2811293-37.patch | 10.42 KB | elachlan |
Comments
Comment #2
elachlan CreditAttribution: elachlan commentedIf you submit a patch with the changed images I would be happy to review/add it.
Also is the inverse true? if we change them to be darker is the contrast going to be bad with a darker background?
Comment #3
miwayha CreditAttribution: miwayha as a volunteer commentedThanks for your reply!
This patch is a binary one, so be sure to test by using
git apply --diff
rather than justgit apply
. This darkens things to about RGB(111,111,111), which has a contrast ratio a bit over 5:1 against a solid white background.Re: reducing contrast on darker things: it's a really good point. A darker image would show less contrast on a darker background. But given that you can't have a solution that will work in all cases, I would suggest that you focus on what you think is the default use case and focus on that. I assume that most of the text this module applies to would have a white or light gray background, but if that's not a reasonable assumption, feel free to reject the patch.
Building something that could be more flexible — maybe a few options depending on the background color, or using an icon that could be applied through CSS — would be a heavier lift, but perhaps worth considering. But I think it's unavoidable that some users area going to have to create their own image files overwrite your own CSS with theirs no matter what solution you come up with.
Cheers, and thank you for the really helpful module!
Comment #4
elachlan CreditAttribution: elachlan commentedI think there was talk about having a light/dark theme in another issue. If you can put together light/dark versions we might be able to combine the issues.
Comment #5
elachlan CreditAttribution: elachlan commentedAre you able to put together some lighter icons as well?
Comment #6
elachlan CreditAttribution: elachlan commentedComment #7
elachlan CreditAttribution: elachlan commentedAttaching the lighter version of the icons from #2465503: Light version of icon.
This is so all changes are done in one issue.
They should probably be added to the one sprite file and maybe even changed to a svg?
Changing to 8.x as all changes should be made here first.
Comment #8
elachlan CreditAttribution: elachlan commentedComment #9
elachlan CreditAttribution: elachlan commentedComment #10
mgiffordThis tool is good for finding better color contrast options http://contrast-finder.tanaguru.com/
Comment #11
elachlan CreditAttribution: elachlan commentedComment #12
elachlan CreditAttribution: elachlan commentedThese are the svg images I found.
https://thenounproject.com/search/?q=link&creator=15063&i=497066
https://thenounproject.com/search/?q=mail%20to&creator=15063&i=497064
Here is an example codepen.
https://codepen.io/anon/pen/KedZbp
I think the javascript would either store the svg definition, or it would read the file contents and then output an svg tag for the external links.
Comment #13
elachlan CreditAttribution: elachlan commentedComment #14
elachlan CreditAttribution: elachlan commentedThis is my attempt. It will need some tweaking and the tests need to be updated.
Comment #16
elachlan CreditAttribution: elachlan commentedComment #18
elachlan CreditAttribution: elachlan commentedComment #20
elachlan CreditAttribution: elachlan commentedComment #21
elachlan CreditAttribution: elachlan commentedComment #23
elachlan CreditAttribution: elachlan commentedComment #25
elachlan CreditAttribution: elachlan commentedComment #27
elachlan CreditAttribution: elachlan commentedComment #28
elachlan CreditAttribution: elachlan commentedComment #29
elachlan CreditAttribution: elachlan commentedComment #30
elachlan CreditAttribution: elachlan commentedComment #31
elachlan CreditAttribution: elachlan commentedHere is the test example of external links using the svg.
https://dispatcher.drupalci.org/job/drupal8_contrib_patches/30816/artifa...
Comment #32
mgiffordOne challenge comes down to the id's within the SVG file. Glad you involve the title, and link to the title with an id. But id's still need to be unique in a page, so if we know there might be two images on a page then
id="title"
is going to be a problem.What's the best way to make this identifier unique?
Comment #33
elachlan CreditAttribution: elachlan commentedCould we use aria-label since we are using an aria role?
Comment #34
cboyden CreditAttribution: cboyden commentedIt looks like the latest patch already uses aria-labelledby? In a case where the label text is not visible on the screen, it's fine to use aria-label instead.
Comment #35
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedre: #32 - the duplicate ID issue is indeed a problem. As well as being a HTML validation problem, when they are references for
aria-labelledby
then it causes a problem for calculating the accessible name. In this case, the FIRST element withid="title"
will be used as the accessible name for all elements witharia-labelledby="title"
.For example, a page can have an external link icon AND a mailto link icon. In this case they both have different text in the SVG
<title id="title">
element, but the first one will be used as the label for both icons.I made a simple demo page for this: Duplicate IDs with aria-labelledby. I tested it with IE, Chrome and FIrefox using NVDA.
How about removing them instead?
aria-label
will be better, because it doesn't need IDREFs. The duplicate ID attributes can be removed:Comment #36
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedThe WCAG 2.0 success criterion 1.4.3 Contrast (minimum) only applies to text. However WCAG 2.1 has introduced SC 1.4.11 Non-text contrast, which will apply to these icons.
Comment #37
elachlan CreditAttribution: elachlan commentedChanged to use aria-label. Unsure on exactly what is needed for contrast. But people should now be able to override it in their themes.
Comment #39
elachlan CreditAttribution: elachlan commentedComment #40
brucedarby CreditAttribution: brucedarby at The University of Edinburgh commentedPicking this up at #uoecontributionday2018
Comment #41
brucedarby CreditAttribution: brucedarby at The University of Edinburgh commentedI hope I’m picking this up correctly. The icons for external links should have a contrast ratio 3:1 to comply with WCAG 2.1 Non-text Contrast.
Do we have the exact hex codes for the colours? If so we can check the contrast using https://webaim.org/resources/contrastchecker/
In this patch are there 2 different coloured icons - one for the light background and one for the dark background? Sorry if I'm picking this up wrong.
If so I’m wondering if the icons are the wrong way round? The icon next to the ‘User Guide’ link on the default homepage is lighter than the icon next to the ‘Drupal’ link? If they were the other way round the contrast would pass the WCAG 2.1 Non-text Contrast for both a light background and a dark background. It’s the icon next to the ‘Drupal’ link which fails in the current set up.
‘User Guide’ icon should be #6E6E6E and a background of white #FFFFFF which is 5.10:1 which is a pass.
Rather than what it is currently is at #727272 and #FFFFFF which is still a pass at 4.81:1.
But the ‘Drupal’ icon in footer should be #727272 with background of #292929 so the ratio would be 3.02:1 which would be a pass.
Rather than what it is currently at #6E6E6E and #292929 which fails at 2.85:1
Comment #42
elachlan CreditAttribution: elachlan commented@brucedarby, thanks for your help on this.
Attached is the amended patch.
Comment #43
brucedarby CreditAttribution: brucedarby at The University of Edinburgh commentedPicking this up at #uoe-d8-contribution
Comment #44
brucedarby CreditAttribution: brucedarby at The University of Edinburgh commentedYep that's worked. The difference is subtle but it does now pass. I've applied and checked the patch for the icon and the colour contrast for the dark panel and that will pass the WCAG 2.1 guidelines. Just adding a couple of screen shots for clarity (they are in the files for this issue).
The new icon fill colour in the dark panel is #727272 and the panel colour is #292929.
Using Webaim colour checker at https://webaim.org/resources/contrastchecker/ returns a ratio of 3.02:1 which is a pass for not text items.
Comment #45
brucedarby CreditAttribution: brucedarby at The University of Edinburgh commentedComment #47
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedThanks for the review.
Minor update to issue summary to clarify which WCAG SC is being addressed.
Comment #49
elachlan CreditAttribution: elachlan commentedThanks for everyone's work on this!