Open ckrina opened 6 years ago
The following feedback comes from here: https://www.drupal.org/project/drupal/issues/2904243#comment-12353721
(We may have improved / fixed some of the following already)
I will start a v3 of the Styleguide PDF to tackle specific items where the styleguide makes good sense to lay it out and then update the issue here accordingly.
Thank you Andrew Macpherson!
.visually-hidden
to the search form submit button. For a sighted keyboard user the button will be operable, but not perceivable. Could also cause difficulty for touch screen users, speech control, or users who input text with something other than a keyboard. A visible button is safer.@markconroy asked me to prioritize the a11y issues, so we can tackle them in order I guess.
I'm not sure how to manage this list, github issues don't have a body vs. comments aspect like d.o issue summaries. Would it be OK to track these on a d.o [meta] issue? The individual issues can still be on github if you like.
Anyway, the ones I'd prioritize now are:
Regarding my comments about icons and WCAG 2.1:
The latest (hopefully last) working draft of WCAG has merged two of the new success criteria. User Interface Component Contrast has been merged into SC 1.4.11 Graphics Contrast.
Notably, the nitty-gritty about line thickness and different contrast thresholds was deemed too complex, so they've simplified it (this was hiinted at months ago, now they've done it). The required contrast for icons is now 3:1, which gives us much more leeway. Obviously, it would be better if we can get vibrant colours that are comfortably over that threshold, towards the 4.5:1 contrast that text uses, but it unblocks some of our palette.
The 3:1 threshold also applies to things like button focus outlines, main-menu active/hover styles, etc.
I added an a11y plan to the menu JS issue, #130
The mobile menu button is currently just an icon. An icon + visible text label ("menu") would be clearer, and help speech control users (pressing buttons is hard if you don't know what they are called... "click 3-line thingy").
Not actually a WCAG 2.0 requirement AFAIK, but I think it might relate to one of the new WCAG 2.1 criteria, will look into it.
Likewise for the search icon at mobile breakpoint.
Apologies, I owed this thread an update from my 'accessibility-quick-wins' branch merge done earlier this week. So this all should be in dev branch now. e.g.: https://master-7rqtwti-acn64pnrbyo7q.eu.platform.sh/articles/sun-peaks-okanagan-wine-festival
The magnifiying glass icon for the top search looks about the same height as regular text, but portland orange on white is just 3:1 contrast ratio. Since it's acting as the visible form label, I'd interpret this as failing the new Graphics Contrast SC in WCAG 2.1 In v1 of the styleguide the magnifiying glass was Pine Green which has contrast 4.5:1 on white.
The newly designed search dialogue that's work in progress addresses this by switching to the cerise colour.
H5 and H6 are indistinguishable visually
These have been split into two different sizes. Let me know if we need more differentiation
Link styles need work, for consistency and clarity. I'm not keen on the dotted link underline. A solid underline is a clearer indication of a link; dotted underlines are variously used for , , keywords, and who knows what else. The difference between dotted underline and solid underline my be lost on users with blurry vision, which in turn makes the focus style a borderline failure of use of colour. I should file an issue for this in Bartik too.
These now have solid underline and a hover background colour. What do you think?
In the styleguide, I'd like to see examples of links in all of the specimen blocks of text. Example: blockquotes have a beige background. What if a block quote has a link inside, will it have sufficient contrast? Likewise links inside photo credits, recipe steps, etc.
The block quote links have been given similar treatment with a different colour set.
Still need focus styles for buttons, currently rely on colour change only. (Can't recall whether the styles sheets are suppressing user agent defaults or not.)
Work has started on this with possibly too great a hover/focus change. Might want to wind this one in and keep the green/white but have a darker border. Or if folks like this (and I'm having second thoughts) then great.
A text input focus style would be nice, e.g for the search form block.
@tomphippen and I started experimenting with this today
The message status (error, warning, info) are currently distinguished by colour alone. Icons would be the easiest solution here. I really like the full-width background, that could help draw attention to the message area.
@thamas has done some work on this and simultaneously I did similar work but using the same link styles as the body area with colour variations. I need to re-implement my work for the links only since they conflicted on merge
Awesome progress, loom forward to reviewing in detail.
I've tried drumming up contributors from the #a11y slack channel. Comparing your latest work against my older reviews would be a good way to get on board.
I've tested a few of these changes from @kjays last comment. Tested by installing a copy today and adding content to a recipe node. I'm not sure where style guide referenced above is located:
H5 and H6 are indistinguishable visually These have been split into two different sizes. Let me know if we need more differentiation
H5 and H6 are fine now however in body content h3 and h4 are the same size (screenshot below). I have: h2 1.77rem h3 1.33rem h4 1.33rem h5 1.125rem h6 1rem
Suggestion: change h3 to 1.5 or 1.6rem. Tested this on a few pages and couldn't find a style issue with either size option.
Link styles need work, for consistency and clarity. I'm not keen on the dotted link underline. A solid underline is a clearer indication of a link; dotted underlines are variously used for , , keywords, and who knows what else. The difference between dotted underline and solid underline my be lost on users with blurry vision, which in turn makes the focus style a borderline failure of use of colour. I should file an issue for this in Bartik too.
These now have solid underline and a hover background colour. What do you think?
By adding a background colour and changing the text colour you are still using colour alone to distinguish the links, so it's still an issue for colour blind people. I didn't check if there is a hue change but I doubt it. The best remedy is if on hover you remove the underline text decoration - text-decoration: none; therefore you have colour and the removal of the underline on hover as your visual cues.
Suggestion: Remove underline text decoration on hover for links in body, breadcrumbs, and tags
In the styleguide, I'd like to see examples of links in all of the specimen blocks of text. Example: blockquotes have a beige background. What if a block quote has a link inside, will it have sufficient contrast? Likewise links inside photo credits, recipe steps, etc.
The block quote links have been given similar treatment with a different colour set.
With the current style of the quote box background and recipe background #F4F2E9 and greenish link colour #00836D colours do not pass WCAG AA for normal text.
The orange as a link #cc2a00 with the #F4F2E9 background passes.
The greenish link colour #00836D and white #fff does pass contrast so if the hover state is #00836D text, #ff background and text-decoration:none; it will pass.
Suggestion: For quote and recipe box area, where background is #F4F2E9 make the link colour #cc2a00. On hover make the link colour #00836D, background #fff, and remove underline.
Link to contrast checker for link and background pallette of quote box https://accessibility.oit.ncsu.edu/tools/color-contrast/accessible-color-palette.php?&colors=00836D,F4F2E9,cc2a00,fff&main=F4F2E9&level=AA
thanks for making some updates @lyndsey to the accessibility efforts! in order for things to not "go missing" I will break your comments into some new tickets.
@fuzzbomb if everything else on this ticket is either complete or in separate sub tickets, is it possible to close this giant one?
We got some accessibility review on slack from Andrew Macpherson. I suggest to add all related feedback here and create small and actionable related issues to fix or discuss each of them.