Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Link hover states are not clear #1417

Closed
Tracked by #2197
NickColley opened this issue May 31, 2019 · 15 comments · Fixed by #2183
Closed
Tracked by #2197

Link hover states are not clear #1417

NickColley opened this issue May 31, 2019 · 15 comments · Fixed by #2183
Assignees
Labels
accessibility audit may 2019 Issues from May 2019 external accessibility audit, before version 3.0.0 design typography
Milestone

Comments

@NickColley
Copy link
Contributor

NickColley commented May 31, 2019

This issue is from a May 2019 external accessibility audit report.

WCAG Reference: Usability feedback only, there is no WCAG related guidelines.
Issue ID: DAC_Issue33
URL: Throughout

Screen Shot

Before hover

On hover

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.

Current Code Ref(s)

$govuk-link-colour #005ea5 $govuk-link-hover-colour #2b8cc4

Low vision user comments

“I had difficulty navigating the links on all pages because little visual feedback was presented when using mouse hover. While they did change to purple, this change was difficult to notice due to the links then looking similar to the regular text on mouse hover.”

Solution

Offer a clearer colour change i.e. similar to that of the keyboard focus, or add/remove an underline when users hover over the links/buttons.

@NickColley NickColley added accessibility audit may 2019 Issues from May 2019 external accessibility audit, before version 3.0.0 awaiting triage Needs triaging by team labels May 31, 2019
@kellylee-gds kellylee-gds added 🕔 hours A well understood issue which we expect to take less than a day to resolve. Priority: low and removed awaiting triage Needs triaging by team 🕔 hours A well understood issue which we expect to take less than a day to resolve. labels Jun 5, 2019
@NickColley
Copy link
Contributor Author

I think it'd good to think about #1205 as well if we did this.

@NickColley
Copy link
Contributor Author

NickColley commented Dec 4, 2019

Hover states in general could do with a review for example:

  • back link
  • breadcrumbs
  • error summary links
  • tabs component

do not have hover states (perhaps more components too).

@timpaul timpaul changed the title Link colour change on hover not clear Link hover states are not clear Jan 28, 2020
@NickColley
Copy link
Contributor Author

NickColley commented Jan 31, 2020

Noticed the NHS seem to have responded to this challenge too (perhaps by DAC as well!).

Main NHS.UK website

No interaction

Hover with a mouse

Focus with a keyboard

I think this approach could potentially be problematic because the hover and the focus style are so similar a user could be confused what they're focused on and accidentally interact with wrong element.

Beta NHS.UK Service Manual

Link with no interaction

Link when hovered

Link when focused

This approach seems to be: 'if there is an underline, remove it. If there is no underline, show one'.

@timpaul timpaul added the design label Feb 4, 2020
@NickColley
Copy link
Contributor Author

NickColley commented Feb 6, 2020

Dave Hunter has shared some of the working notes for this iteration:

First iteration

Hypothesis

  • Current hover and focus styles are too similar.
  • Focus style needs to be more prominent.

If we make the hover style less prominent (by removing the yellow background)
Then users will still be able to detect the link
Because they already know where they are on the page.

Design examples


Link styles before


Link styles after

Link: colour NHS blue with an underline
Hover: colour NHS dark pink with affordance of no underline and pointer cursor
Focus: colour NHS black, background colour NHS yellow and border bottom colour NHS black

User testing

What we were looking to learn:

  • Do the focus styles help users who rely on them
  • Do the focus styles hinder users who don’t rely on them

We recreated pages of the NHS website in a prototype and set the participants tasks, including seeking information (navigating through pages) and filling in a form.

Findings

  • All participants navigated with no problems
  • Participants who didn’t rely on focus styles didn’t notice them
  • Participants who relied on focus styles found them useful

Quotes

“showing me where I am, that’s good”

What next

We have more user testing scheduled in but considering our findings so far and the fact that our work is based predominantly on GOV’s work, we’re confident that the focus styles can go live.

Full document: https://docs.google.com/document/d/11AjdOgWC7ue1bit5AFyaneNwJYiudgLhf8nOxCWbn9M/edit#

A note on how they recruited participants:

At NHS Digital we have something called the Ability Network (it's for employees with a disability, long term condition and carers). We made contact with them and members kindly volunteered for user testing.

@chris-gds
Copy link

chris-gds commented Oct 12, 2020

Related PR raised

@36degrees
Copy link
Contributor

Browser support for text-decoration-thickness has improved since we first started looking at this – technically it's been in Chrome and Edge since v87 and Opera since v73, but there's a bug in Chromium that means it doesn't work unless either text-underline-offset is set to something other than auto or text-decoration-color is set to something other than currentColor.

It looks like that issue should be fixed in Chrome 90, which becomes stable in April. As Edge and Opera are both built on top of Chromium, I'd expect both of those browsers to be updated with the same fix not long after.

Using text-decoration-thickness would allow us to do something like this, if we wanted:

Screen.Recording.2021-01-27.at.09.23.41.mov

It would need to be considered an enhancement as it would not work in IE11, Edge < 90 Early 2021), Chrome < 90 (April 2021), Safari < 12.1 (March 2019), Firefox < 70 (October 2019) – unless we also set the color or offset.

@christopherthomasdesign
Copy link
Member

New link styles and hover states

I've been doing some more work on links, building on Ollie's work above. I'm trying to solve two problems here:

  • link hover states are not clear
  • link text is not easy enough to read – especially when used in long lists or at larger sizes (a problem raised by designers on the GOV.UK team)

The increasing support for a few CSS properties means we can now control more about how links look. I've had a go at making links that:

  • are visually lighter
  • place the underline a decent distance from the baseline of the text (far enough to interfere less with the words, close enough that it's clearly identified with them)
  • have a clearer hover state

It's worth reiterating that these changes should be seen as an enhancement. For browsers that don't support some or all of these properties, the normal underline will still work.

Proposed design

Look at the work in Frontend at #2089. Still some details to iron out, but something like this.

Before:

Screenshot 2021-02-02 at 10 40 49

After:

Screenshot 2021-02-02 at 10 40 56

I've added the following CSS to links:

text-decoration-thickness: 1px;
text-underline-offset: .1em;
text-decoration-color: govuk-colour("light-blue");

It makes all link underlines 1px thick, sits them a bit further below the baseline of the text, and uses a lighter shade of blue to make the line a bit visually lighter.

For the hover state, I made the line thicker and brought back the original link colour to make it stronger:

Screenshot 2021-02-02 at 10 46 07

text-decoration-thickness: unquote("max(2px, .18em)");
text-decoration-color: $govuk-link-colour;

Here's how that scales for different sized text:
Screenshot 2021-02-04 at 16 07 07

Hover:
Screenshot 2021-02-04 at 16 07 13

Considerations

Different coloured links and backgrounds

The use of govuk-colour("light-blue") for underlines works well for blue links on white backgrounds, but obviously wouldn't work on darker backgrounds. Part of the rationale for using thicker underlines for hover states to make them more flexible for different backgrounds because they don't use a colour other than the link colour. So we should see if there's a more flexible way to do the underline colour tint. You can't use SASS tint functions on currentColor, and I don't think you can set an opacity on an inherited underline colour either...

I think we'd want to be fairly confident that any underline colour has at least 3:1 contrast with the background to pass 1.4.11 Non-text Contrast.

If something like that's not possible, we could either:

  • just use the inherited link text colour and lose the (probably small) benefit of a lighter underline
  • add specific underline styling to all the other kinds of links we support (e.g. error summary, green notification banner)

Distance from the baseline

For some reason, every browser's implementation of text-underline-offset is different. Not massively, probably not critically.

On all browsers, the combination of text-underline-offset + text-decoration-thickness together means that when you hover and make the underline thicker, it moves slightly lower down from the text. I don't really see that as a problem but would be interested to hear if others do.

Another thing we could look at doing is making the underline offset on hover the same distance from the baseline as our focus state border. Again, I don't think there are huge gains here but it might look a bit more elegant or less jumpy.

Testing across browsers and versions

I've done a bit of this but it would be good to test a bit more thoroughly on different versions and devices.

@christopherthomasdesign
Copy link
Member

We sent the revised implementation of link styles and hover states to the working group in March 2021.

The group approved the changes, with the following main feedback:

  • consider the hover state for visited links and whether they should change colour
  • make sure the hover underline widths aren’t too heavy, and double-check the width across browsers

We'll need to do a little bit more exploration to address these, covered in alphagov/govuk-design-system#1578

@36degrees 36degrees added epic Epics are used in planning project boards to group related stories and removed needs research 🕔 days labels Apr 8, 2021
36degrees added a commit that referenced this issue Apr 9, 2021
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 <christopher.thomas@digital.cabinet-office.gov.uk>
36degrees added a commit that referenced this issue Apr 9, 2021
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 <christopher.thomas@digital.cabinet-office.gov.uk>
Co-authored-by: Charlotte Downs <charlotte.downs@digital.cabinet-office.gov.uk>
@36degrees 36degrees linked a pull request Apr 19, 2021 that will close this issue
12 tasks
@36degrees 36degrees removed the epic Epics are used in planning project boards to group related stories label Apr 21, 2021
36degrees added a commit that referenced this issue Apr 30, 2021
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 <christopher.thomas@digital.cabinet-office.gov.uk>
Co-authored-by: Charlotte Downs <charlotte.downs@digital.cabinet-office.gov.uk>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility audit may 2019 Issues from May 2019 external accessibility audit, before version 3.0.0 design typography
Projects
Development

Successfully merging a pull request may close this issue.