Highlight box colour contrast too low for WCAG AA #200
Comments
|
Isn't this only an issue if the colour is used directly on a white background? Is there an example (apart from the swatch) where this is done? For the swatch, we should probably be putting a border around the element as with the white swatch. |
|
Two examples spring to mind:
Both use Both examples use white text on the turquoise background. Since it passes AAA for large text and the smallest font size for the text on this colour on the Bank Holiday page is 18px (for smaller viewports) and 24px (for wider viewports), I'd be keen to keep the background colour the same and add guidance to ensure that text used on this background colour isn't ever smaller than 18px or 14px bold. Foreground: #FFFFFF - Background: #28A197 The contrast ratio is: 3.17:1 Text failed at level AA Large text passed at level AA 1.4.3 Contrast (Minimum): Text (and images of text) have a contrast ratio of at least 4.5:1, except if the text is pure decoration. Larger scale text (at least 18 point or 14 point bold) or images of text can have a contrast ratio of 3:1. (Level AA) 1.4.6 Contrast (Enhanced): Text (and images of text) have a contrast ratio of at least 7:1, except if the text is pure decoration. Larger scale text (at least 18 point or 14 point bold) or images of text can have a contrast ratio of 4.5:1. (Level AAA) Note: Fonts that are extraordinarily thin or decorative are harder to read at lower contrast levels. |
|
Ah, sorry I misunderstood - I thought we were talking about In the case of the turquoise boxes, I agree that if it passes AAA with large text, we should make that clear in the guidance. |
Fixes the problem discussed in issue alphagov#200.
|
I wonder whether those highlight boxes could be done with $govuk-blue instead - is there a reason it should be turquoise? The blue gives a contrast of 6.68:1. cc @joelanman @markhurrell $govuk-blue is also used by some services for introduction walk-throughs (verify, passports, notify), but I don't know if it's necessary for it to be different.
|
|
@edwardhorsford I think there is value in using a different colour here. It gives a sense of "something different is happening now" which could help people feel certain they've reached the end of the interaction. Keen to hear what other people think though. |
|
there's something to be said for the green tinge being associated with success, on transaction complete screens, which is important |
|
I'd like to rationalise this to blue for information highlighting (eg, bank holidays, verify and passports etc) and turquoise for completion states (matching the start buttons?) probably good to look at the typography we use on them too - only 16px+ sizes, and maybe only bold too? |
|
@markhurrell start buttons are green no? You think they should be the start button green instead of turquoise? |
|
@markhurrell Yep, added guidance around font size in the above PR. The idea of turquoise == completion is interesting. In this prototype that Harry's working on, he shows the user the result of the last bit of the transaction (finding the licence) using the turquoise box, before sending them onto the next bit of the transaction (updating their details). Do you think this is a good example of a box that should be blue, because the user hasn't finished what they were trying to do? Or is it okay to use the completion colour to mark completion of a bit?
|
|
In general I think I'm seeing too much of the turquoise box. I'm seeing it used in other contexts like notifications too, which I think we could have a different pattern for. |
|
Yeah, in the guidance it's called a "highlight box" which is pretty generic. If we called it a "success box" or something, then we could constrain the usage a bit more. Then we could add new patterns for those uses. I'm guessing at this point we just have to swallow the fact that there are services out there already which will then not be following the new patterns? |
|
Playing with an idea @timpaul had. I don't know if I like it, but that might be because it looks so different to me. This uses a slightly darker turquoise for the non-bold text, and regular turquoise for everything else. |
|
@edwardhorsford yeah I'm not sure about that one. feels like it would have way less impact (especially on mobile) tbh I'd prefer if we thought about this a bit more systematically. we should be thinking about how coloured boxes work across verify and passports too, and what colours we use for what purpose |
|
I am much happier with this version than with the current reversed-polarity one. Reversed-polarity worries me because:
I like this version because it has Big Important Text with the standard polarity. (I'm not quite so keen on the box part. I suspect it might suffer from the 'boxed warning' problem that's been discovered in testing of patient information leaflets, the compulsory leaflets that come with medicines. The counter-intuitive finding is that boxed warnings are actually less likely to be read than the ordinary text that doesn't have a box around it; it seems to be a similar problem to the banner-blindness and ad-blindness phenomena that we know about on the web). |
|
@cjforms hey caroline - if we have it as ed's idea without the box, it's pretty much just normal text on the page. the big boxes for that type of information work effectively, I don't think there's a reason for ditching them. we just need to make sure we aren't causing any contrast issues (and probably consider making them a bit more consistent) |
|
I've seen the existing boxes work very well in user research. (also - it's Tim's idea - just sharing for discussion) |
|
@markhurrell, not exactly. It's giant centred text in a distinctive colour and layout that's different to what's happened before. But I admit it's only a slight feeling of unease; I'd definitely love to try it. @edwardhorsford yes, I've seen these reversed-polarity elements work very well as graphic elements to signal 'something different has happening here'. |
|
I would be sceptical about changing the current confirmation page layout with the big turquoise block at the top. During pay user research this page has tested very well. Pretty much every participant has noted the message and reference number. If we make the turquoise colour slightly darker for better contrast that's fine but I don't think we need to do anything else. |
|
+1 to making the turquoise (or similar colour) box specifically "transaction success messaging", and making the tick part of that pattern, to not rely on colour so much |
|
@stephenjoe1 |
|
Me and Richard Morton had a bit of chat about this yesterday, and unstuck it a little bit. Something that makes it quite difficult is that the AA guidelines specify font size in (How this 1pt / 1.33px conversion translates to smaller screens, which are often held closer to the face, is unclear... But unless we do our own research to work that out, or W3C come out with guidelines that work better for a world of various screens, AA is the best guidelines we have.) So if we stick with Right now the example on smaller screens:
If we increase the
Arguably that makes the header disappear though, so we could bump that up to
And on a bigger screen:
Should probably be played with a little bit more, but I think if we don't want to change the colour and we want to pass AA, then we need to be heading in this direction. Keen to hear what people think. |
|
It looks nice, but I'd worry that, especially with a longer service name or smaller screen, this larger design is more likely to take over the whole screen. This might make it more likely for people to think that's all there is, and not know to scroll. Is another alternative to investigate a darker green? |
|
Yeah, I think a darker green needs to be investigated. I found a tool to help find alternatives but the suggestions it gives are quite dull. 😞 |
|
I'd like to find a better solution than just using dull colours there's only a very narrow bandwidth of colour that passes colour contrast Mark Hurrell On 18 May 2016 at 12:42, Sanjay Poyzer [email protected] wrote:
|
|
@markhurrell What are your thoughts on the bigger and bolder text? |
|
i like the bigger, bolder text wonder what the average ref number length is. could we make that bit bigger Mark Hurrell On 18 May 2016 at 13:45, Sanjay Poyzer [email protected] wrote:
|
|
Sure -
If we're happy with that, I can do a PR for it and include some text about making sure text is big when using that colour. I'll think I'll leave |
|
Would be good to keep in mind that some services have quite a bit more text in this box. We're currently only testing with the simplest case. Perhaps collect some examples of summary boxes? For the proposed solution: |
|
Example of what I meant about outlining the text (but I don't know how well this is supported cross browser or for older browsers: |
|
You could do it with |
|
Personally I think the pattern should dictate the font weight and size. We don't want it to be used for body copy. The purpose for the pattern is to highlight confirmation. |
|
This example has text-stroke for the date and text-shadow for the rest of the text:
|
|
Is there a problem with @gemmaleigh 's suggestion? It sounds good to me:
|
|
@joelanman this has come up earlier in the discussion: The WCAG guidelines are for 14pt bold text and 18pt standard text - it is generally agreed that the conversion factor between pt and px for these purposes should be one and a third so the minimum size to be classed as large text is 19px bold or 24px standard text. There is further detail in https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html : Note 1: When evaluating this success criterion, the font size in points should be obtained from the user agent or calculated on font metrics in the way that user agents do. Point sizes are based on the CSS pt size as defined in CSS3 Values. The ratio between sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt and 18pt are equivalent to approximately 18.5px and 24px. Note 2: Because different image editing applications default to different pixel densities (e.g. 72 PPI or 96 PPI), specifying point sizes for fonts from within an image editing application can be unreliable when it comes to presenting text at a specific size. When creating images of large-scale text, authors should ensure that the text in the resulting image is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text. For example, for a 72 PPI image, an author would need to use approximately 19 pt and 24 pt font sizes in order to successfully present images of large-scale text to a user. |
|
@accessiblewebuk sorry - missed it, so that sounds like something we could consider recommending? 19px bold or 24px standard at minimum |
|
@joelanman those sizes would pass - if that is the simplest way of getting this resolved then I am all for it - it may well depend on other factors though like how much text might be needed. Interestingly the Bank Hol example I posted is already 24px for the smaller text size. The application complete example isn't though so here is a before and after:
|
|
Looks good to me |
|
lol that's exactly what i posted on the 18th May last year 😉 |
|
Oh yeah and there's relevant discussion on that point too, about whether people would just use a smaller font anyway, and about gathering examples of usage. I think this is more evidence we could do with more people/time to look at patterns. |
|
But then as Alex has said above, the pattern could/should dictate what kind of text is used in it. |
|
We should aim for a solution that has 4.5:1 contrast and doesn't rely on teams getting it right. We aim for that everywhere else - why is this any different? We can try to dictate what kind of text is used, but in practice teams can and will modify it. Aiming for 4.5:1 means we're good no matter what. I'm not clear why the pattern is using turquoise - or the significance of it. If there is no semantic meaning, I suggest going with If there is semantic meaning, how about a stronger green? |
|
The semantic meaning here is success, and in my experience the turquoise box has always tested well. I think we'd have to test the blue and green to make sure it's ok, and the green could possibly clash with a button on the same page. |
|
Bank holiday is different - being just information. Maybe that would work just as blue, the same as our 'intro slides' pattern. |
|
@joelanman Surely there shouldn't be any buttons on such a page? |
|
@sanjaypoyzer don't see why not, if there's a common action to do next having finished that one. Maybe it's common to make a second application, or another service? |
|
Having a button on the page is a common pattern. It might be to do something else, or to return to GOV.UK or to give feedback. With that said, I'd be really surprised if moving to a greener green caused any issues. |
|
Who can make a decision on the way forward with this? |
|
@markhurrell can make that decision. And because this has been going back and forth for so long, I'd suggest he should do that. |
|
@selfthinker 👌🏼 for the moment, we should just recommend only using 19px and larger on these boxes looking at the bank holidays page etc is part of the GOV.UK template consolidation team's work, so the design might end up being iterated pretty soon anyway. i'll add this to the design considerations of that work If/when we do update the bank holiday page design, we should look at incorporating those changes to the confirmation page pattern |
|
apparently it's 19px bold or 24px standard to pass standards |
|
To compare options 1) as it currently is (fail):
|
|
Thanks all for the detailed discussion and to @selfthinker and @accessiblewebuk for reminding us to resolve this. The simplest solution seems to me to increase the size of the text (hat tip to @sanjaypoyzer). I've increased the size of the text over in #451, @markhurrell has approved it. Thanks everyone! |
19px text has a contrast too low against turquoise for WCAG AA. Use bold font to increase contrast and fix aXe warning. See lengthy discussion here: alphagov/govuk_elements#200
Highlight boxes (as visible at the bottom of https://govuk-elements.herokuapp.com/colour/ ) have a too low colour contrast (3.17) to comply with WCAG2 level AA.
Offending line is:
https://github.com/alphagov/govuk_elements/blob/master/public/sass/elements/_components.scss#L7
Suggest: #0c857b as the nearest colour that satisfies the requirement
The text was updated successfully, but these errors were encountered: