Make changes to links and hover states based on working group feedback #1578
Comments
Update on design workWorking on this draft PR: alphagov/govuk-frontend#2089 I changed the hover underline thicknesses to stop them crashing into the text below at larger sizes – increasing the min width to 3px and decreasing the max to 0.12em. It’s a bit close with 16px I lean towards not applying a colour change on hover too, for the sake of consistency and simplicity. From what I remember, our previous experiments found that there wasn’t really a good way to apply a ‘universal tint’ that could apply the same darkening effect to any colour consistently. Something about not being able to darken white… If there’s no colour change, it also means you don’t have to worry about colour contrast of hover states so long as the text itself has enough contrast. If we take that approach, 14% of users won’t see a visual change on hover other than the pointer cursor. Text-decroration-thickness is not supported by IE11, Samsung Internet (mobile), Firefox for Android (mobile), Opera Mobile (mobile), as well as older versions of the more common browsers. Some questions in this area:
I’ve updated the listed components to be consistent with the link styles. Someone more skilled than me should probably look in detail at how the CSS actually works for all of these. A couple of things to note on these components:
|
Switching to 'Usage relative' on caniuse gives us a better idea of where that 14% lies:
It's mostly Samsung Internet and older versions of Chrome, with a little IE11, and older iOS and Firefox in the mix.
I'm wondering if it’d be easier and safer to just keep the existing colour changes on hover ‘for now’ whilst we’re still aiming to support IE11 as a 'compliant' browser, and look at removing them and simplifying the hover styles later when IE11 has dropped off of our support matrix entirely, and once more users have updated to the latest versions of evergreen browsers. I don't think we'd be introducing any 'new' inconsistency? It just makes it perhaps a little more obvious.
Yep, agreed. I think I've got this working fine, but because it's slightly 'special' I haven't yet found a way to do this without duplicating the underline styles in the component.
All sounds good. We'll need to do a little bit of work to make the underline width 'customisable' but that's OK. Is the offset the same?
I think the menu is technically a button rather than a link… but yes, this might be a can of worms we don't want to open just yet. I think we'll also need to work out what to do with the footer as there's a bug in Chromium (affecting Chrome, Edge and Opera) when We might need to remove the offset for the footer only, and create an issue to undo that once the bug's been fixed and usage of the affected versions of Chrome drops off? It does mean those links look subtly different to the others, but it sort of works, I think, because they’re already different enough being black rather than blue? |
Yeah this seems a sensible compromise. Let's do this.
Yep sounds good |
|
Have checked the links in legacy mode – the underlines all seem to work ok for me, just using the old colours. |
Are we happy to keep the colour change for visited links as well? That was called out by the working group – although it's existing behaviour, it is possibly slightly more noticeable with the underline? |
|
Just revisiting the links without underlines guidance. I think it broadly still stands. We could be stronger on it, and say you should really only remove underlines for things like navigation. I think part of making the underlines lighter is to reduce the chance of "the number or placement of links mak(ing) them difficult to scan or interact with the element they’re part of"... If we removed that bit it could read more like: Links without underlinesOnly remove underlines from links if it’s clear to the user from the context that they’re links, even without the underline. For example, links in a header or side navigation won’t necessarily need underlines. Users will understand that they’re links because of their position on the page and how they persist across different pages. —— Someone who can actually write could tighten that up but hopefully you get the idea! Would be interested to hear what you think about this @CharlotteDowns @timpaul |
I think let's keep it – makes it consistent with our approach with the other kinds of links. Like with those, we can revisit it when browser support is better and when if we decide to stop IE11 one day. |
We have a long-standing issue (#1417) [1] from an audit in May 2019 about the link hover state not being clear: > The colour change when a user hovers over a link is not clear and this was especially difficult for low vision users to determine. > > Ensuring that the state change is distinctive would benefit low vision users in particular, while benefiting all mouse users in general. This was raised as a usability issue rather than a WCAG failure. We’ve been keeping an eye on browser support for the `text-decoration-thickness` property, and its introduction into Chrome 87 means that all evergreen browsers now support it. We can therefore use `text-decoration-thickess` as a way to differentiate the link on hover. Some of the rationale for this is included in a comment around the time of the previous working group review [2]. The broad intention is that the thicker underline is a state change that can work across any combination of text colour and background colour, as long as the link has enough contrast in its default state. We set the underline to a minimum width to 3px with a max to 0.12em. The aim is to make the state change clear whilst avoiding the underline crashing into the text below at larger sizes. A minimum 3px width ensures at least a 2px change from the default 1px thickness. It’s a bit close with 16px body-s text, but if you set the minimum width too low, the hover thickness at 19px stays too thin. [3] We're retaining the existing colour change on hover, as without the colour change there would be no state change in browsers that don't support `text-decoration-thickness`, including IE11. We can revisit this decision as and when our browser support requirements change. [4] [1]: #1417 [2]: #1417 (comment) [3]: alphagov/govuk-design-system#1578 (comment) [4]: alphagov/govuk-design-system#1578 (comment) Co-authored-by: Chris Thomas <[email protected]>
We have a long-standing issue (#1417) [1] from an audit in May 2019 about the link hover state not being clear: > The colour change when a user hovers over a link is not clear and this was especially difficult for low vision users to determine. > > Ensuring that the state change is distinctive would benefit low vision users in particular, while benefiting all mouse users in general. This was raised as a usability issue rather than a WCAG failure. We’ve been keeping an eye on browser support for the `text-decoration-thickness` property, and its introduction into Chrome 87 means that all evergreen browsers now support it. We can therefore use `text-decoration-thickess` as a way to differentiate the link on hover. Some of the rationale for this is included in a comment around the time of the previous working group review [2]. The broad intention is that the thicker underline is a state change that can work across any combination of text colour and background colour, as long as the link has enough contrast in its default state. We set the underline to a minimum width to 3px with a max to 0.12em. The aim is to make the state change clear whilst avoiding the underline crashing into the text below at larger sizes. A minimum 3px width ensures at least a 2px change from the default 1px thickness. It’s a bit close with 16px body-s text, but if you set the minimum width too low, the hover thickness at 19px stays too thin. [3] We're retaining the existing colour change on hover, as without the colour change there would be no state change in browsers that don't support `text-decoration-thickness`, including IE11. We can revisit this decision as and when our browser support requirements change. [4] [1]: #1417 [2]: #1417 (comment) [3]: alphagov/govuk-design-system#1578 (comment) [4]: alphagov/govuk-design-system#1578 (comment) Co-authored-by: Chris Thomas <[email protected]> Co-authored-by: Charlotte Downs <[email protected]>
We have a long-standing issue (#1417) [1] from an audit in May 2019 about the link hover state not being clear: > The colour change when a user hovers over a link is not clear and this was especially difficult for low vision users to determine. > > Ensuring that the state change is distinctive would benefit low vision users in particular, while benefiting all mouse users in general. This was raised as a usability issue rather than a WCAG failure. We’ve been keeping an eye on browser support for the `text-decoration-thickness` property, and its introduction into Chrome 87 means that all evergreen browsers now support it. We can therefore use `text-decoration-thickess` as a way to differentiate the link on hover. Some of the rationale for this is included in a comment around the time of the previous working group review [2]. The broad intention is that the thicker underline is a state change that can work across any combination of text colour and background colour, as long as the link has enough contrast in its default state. We set the underline to a minimum width to 3px with a max to 0.12em. The aim is to make the state change clear whilst avoiding the underline crashing into the text below at larger sizes. A minimum 3px width ensures at least a 2px change from the default 1px thickness. It’s a bit close with 16px body-s text, but if you set the minimum width too low, the hover thickness at 19px stays too thin. [3] We're retaining the existing colour change on hover, as without the colour change there would be no state change in browsers that don't support `text-decoration-thickness`, including IE11. We can revisit this decision as and when our browser support requirements change. [4] [1]: #1417 [2]: #1417 (comment) [3]: alphagov/govuk-design-system#1578 (comment) [4]: alphagov/govuk-design-system#1578 (comment) Co-authored-by: Chris Thomas <[email protected]> Co-authored-by: Charlotte Downs <[email protected]>
What
Make final design decisions and tweaks to links and hover states after the working group review. List of things to do below.
Why
So we can ship the changes!
Who needs to know about this
Designer, developer
Further detail
Summary of working group review
Done when
Directly related:
Review components that contain links that are treated differently and decide if they need to change at all:
Broader scope but also worth doing:
The text was updated successfully, but these errors were encountered: