Lack of visual cues on hover

[selfthinker]

This issue is from the accessibility audit of the Design System website by DAC in July 2024.

DAC's description

• Page: Home – GOV.UK Design System
• WCAG reference: none (Usability)
• Issue ID: DAC_Visual_Cues_Usability_01 and DAC_Visual_Cues_Usability_02

Users reported issues with the lack of call-to-action functionality when using the mouse on interactive elements. A call-to-action is a prompt on a website that tells the user to take some specified action. It is important as it acts as a signpost that lets the user know what to do next.

Low vision user comments

“The buttons displayed on this platform provide no mouse hover focus upon contact with the mouse pointer. From a low vision users perspective, the lack of adequate vision means that tracking the mouse position together with the target is difficult at best. In my experience, I cannot see both pointer and target and therefore heavily rely on visual focus upon mouse contact. Providing an additional visual cue such as a well-constructed border surrounding the button ensuring contrast minimums are met would also provide good visual focus.”

DAC's proposed solution

We recommend an additional visual cue in the way of the hover state when a user has placed their cursor over an interactive element. The same visual cue provided on focus (the focus indicator on tab) could be used on mouse hover.

Related issues

• https://github.com/alphagov/govuk-design-system-backlog/issues/34#issuecomment-1324954699
• https://github.com/alphagov/govuk-design-system-backlog/issues/64#issuecomment-1932825812

Additional instances

If we are going to fix this, we should audit the hover styling of all other interactive elements. We should also involve the team that works on the potential upcoming work on colours.

Needed roles

Designer

[querkmachine]

I find it interesting that the search field was flagged as part of this, as user agent form controls typically don't provide any sort of hover state and nor do the controls in GOV.UK Frontend (with the exception of small variant radios and checkboxes), which have not been flagged as having this failure.

The user comment thus makes me think that the icon and label style we use for the search field led to the user interpreting it as being a button, thus the confusion.

I would therefore consider the usability issue there to be that the search field perhaps looks too similar to a button, and we should consider altering how it looks. For example, by moving the visible label outside of the input.

[selfthinker]

We recently had an internal discussion about hover states (specifically on form elements) prompted by a support request.

The requester mentioned they found conflicting information, including that too intrusive hover states might cause dizziness and nausea to some users.

@querkmachine mentioned they couldn't find anything academic or research-based. We both looked at a lot of the usual places (including the Accessibility Requirements for People with Low Vision or its latest draft) and couldn't really find anything about this. (It mentions something about losing the cursor/pointer, but nothing about how a hover state might affect that.)

Possible reasons for this that we thought about:

• There are already a couple of assistive technologies that help make it much more visible where the pointer and cursor is. Maybe there is no need to make hover states more visible when low vision users use those kinds of assistive tech?
• Testing is often biased towards either people with no vision or good vision, but rarely people with low vision.
• Is it possible that there is no research because people who thought of researching it have given it a brief look and decided it's a non-issue?