Highlight box colour contrast too low for WCAG AA

[maxf]

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

[sanjaypoyzer]

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.

[gemmaleigh]

Two examples spring to mind:

1. The GOV.UK Bank Holidays page https://www.gov.uk/bank-holidays
2. The "Confirmation page" pattern http://govuk-prototype-kit.herokuapp.com/examples/confirmation-page

Both use #28a197, or $turquoise.

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 Text failed at level AAA

Large text passed at level AA Large text failed at level AAA

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.

[sanjaypoyzer]

Ah, sorry I misunderstood - I thought we were talking about $highlight-colour.

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.

[edwardhorsford]

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.

[sanjaypoyzer]

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

[joelanman]

there's something to be said for the green tinge being associated with success, on transaction complete screens, which is important

[markhurrell]

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?

[joelanman]

@markhurrell start buttons are green no? You think they should be the start button green instead of turquoise?

[sanjaypoyzer]

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

[edwardhorsford]

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.

[sanjaypoyzer]

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?

[edwardhorsford]

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.

[markhurrell]

@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

[cjforms]

I am much happier with this version than with the current reversed-polarity one. Reversed-polarity worries me because:

1. What happens when the user elects to reverse the polarity or tune the basic colour scheme? Does it reverse again? If so, can the person actually read it if they need a different colour scheme in the first place?
2. I've seen lots of instances where reversed-polarity elements work excellently as graphic elements in the page (in this case 'something big happened') but where the reversed-polarity seems to have the ability to suck the content out of the element, as if it became a pure graphic with no content in it.

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

[markhurrell]

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

[edwardhorsford]

I've seen the existing boxes work very well in user research.

(also - it's Tim's idea - just sharing for discussion)

[cjforms]

@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'. The problem I'm trying to articulate is that I've observed that users can fail to understand and act on the content that sits within the element. For example, they may grasp the message 'the computer dealt with the thing I just completed' (signified by the big change in layout) but fail to see that there's an important reference number placed on the box.

[stephenjoe1]

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.

[joelanman]

+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

[cjforms]

@stephenjoe1 That's good. Have you tried it with anyone who needs to use a reversed colour scheme because of reading difficulties such as dyslexia? Do you know why some / any participants didn't note the reference number?

[sanjaypoyzer]

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 points rather than pixels. There is a notion that 1 point = 1.33 pixels, which means when AA wants 18pt, we should be using 24px.

(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 #28A197, we have to use at least 24px, or 19px bold.

Right now the example on smaller screens:

.bold-large (24px bold) - passes AA p (16px) - fail .heading-medium (18px bold) - almost passes, should 1px bigger

If we increase the .heading-medium by 1px, and also use it on the p we have:

Arguably that makes the header disappear though, so we could bump that up to .heading-xlarge:

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.

[joelanman]

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?

[sanjaypoyzer]

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

[markhurrell]

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 against both black and white

Mark Hurrell Head of Design for GOV.UK Government Digital Service

On 18 May 2016 at 12:42, Sanjay Poyzer notifications@github.com wrote:

Yeah, I think a darker green needs to be investigated. I found a tool to help find alternatives http://contrast-finder.tanaguru.com/result.html?foreground=%23FFFFFF&background=%2328A197&algo=Rgb&ratio=4.5&isBackgroundTested=true but the suggestions it gives are quite dull. 😞

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/alphagov/govuk_elements/issues/200#issuecomment-220001679

[sanjaypoyzer]

@markhurrell What are your thoughts on the bigger and bolder text?

[markhurrell]

i like the bigger, bolder text

wonder what the average ref number length is. could we make that bit bigger

Mark Hurrell Head of Design for GOV.UK Government Digital Service

On 18 May 2016 at 13:45, Sanjay Poyzer notifications@github.com wrote:

@markhurrell https://github.com/markhurrell What are your thoughts on the bigger and bolder text?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/alphagov/govuk_elements/issues/200#issuecomment-220014801

[sanjaypoyzer]

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 .heading-medium at 18px rather than bumping it up 1px as I'm sure that will have much more far reaching effects.

[edwardhorsford]

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: I'm wary of relying on specific guidance about font weights and sizes - I would anticipate in many cases services will just pick what seems suitable to them.

[joelanman]

The pattern was originally designed for very little content. We should definitely collect examples of use, but also assess whether, if there is more content, that's a thing we should endorse or advise against.

[cjforms]

+1 to @joelanman on collecting examples.

Quick reminder: I still haven't had an answer to my question about how this box behaves for people who elect to reverse foreground and background. Does it stay the same, reverse, or disappear?

[joelanman]

@cjforms on OSX, this is close to "invert colours" set in system preferences:

(I had to edit the colours by hand as taking a screenshot doesn't work - it takes a screenshot of the non-inverted colours)

[robinwhittleton]

@edwardhorsford @joelanman what was the action out of this then? Was it to specifically recommend only using bold text on http://govuk-elements.herokuapp.com/colour/#examples ? Do we want to specifically darken the turquoise to cope with whatever fonts the consuming developer chooses to use?

[edwardhorsford]

I think no clear action as yet. In the short term we can recommend bold and larger font sizes.

Should gather together some options and discuss. I've spoken with @timpaul before about setting up some kind of 'board' to make decisions on awkward things like these.

[selfthinker]

To fully answer @cjforms' question. For people who don't fully invert the screen but change colours via either browser settings or Windows system settings, the box completely disappears. I'm not sure if that's a big problem, though, as they will be used to it and it probably still looks different enough to stand out.

I tested with changing colours in Firefox and switching to the first Windows 'High Contrast' colour scheme and looked in Edge. Both look nearly identical which is why I only attach one screenshot:

I guess it could be fixed in a similar way we fixed buttons, by giving the box an invisible outline. When you do that, it looks like this (and would be invisible otherwise):

[accessiblewebuk]

Just to clarify that from a WCAG point of view, we only need to consider the colour contrast in a typical setup - not with changes by assistive technology (e.g. Zoomtext) or changes to browser or OS colour settings. To quote from https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html :

Note 6: WCAG conformance should be evaluated for colour pairs specified in the content that an author would expect to appear adjacent in typical presentation. Authors need not consider unusual presentations, such as colour changes made by the user agent, except where caused by authors' code.

[accessiblewebuk]

If we want the highlighting colour to be bright then we can't use white or very pale text, unless we do things like outlining the text with a dark colour. The existing turqoise would work fine with darker text - the only question is whether that gives the same impact?

[accessiblewebuk]

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:

[robinwhittleton]

You could do it with text-stroke in Webkit / Blink and recent Firefox / Edge. Alternatively you could use text-shadow which would look somewhat different but might work just as well: that’s well supported (we’d only be not showing it for IE8/9 and that’s probably acceptable at this point).

[alextea]

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.

[accessiblewebuk]

This example has text-stroke for the date and text-shadow for the rest of the text:

[joelanman]

Is there a problem with @gemmaleigh 's suggestion? It sounds good to me:

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.

[accessiblewebuk]

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

[joelanman]

@accessiblewebuk sorry - missed it, so that sounds like something we could consider recommending? 19px bold or 24px standard at minimum

[accessiblewebuk]

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

[joelanman]

Looks good to me

[sanjaypoyzer]

lol that's exactly what i posted on the 18th May last year 😉

[joelanman]

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.

[sanjaypoyzer]

But then as Alex has said above, the pattern could/should dictate what kind of text is used in it.

[edwardhorsford]

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 $govuk-blue.

If there is semantic meaning, how about a stronger green?

[joelanman]

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.