2

I've got a basic understanding of accessibility and how it applies to visual elements of your product and I'm keen to apply guidelines as best as I can.

My question is does the hover state button text also need to comply with accessibility guidelines as well as the normal state?

  • Can you add some example images of the normal and hover state? – jazZRo Jul 17 '19 at 12:30
  • Hey D Smith, welcome! I think the usual approach is, whenever possible, ensure that your designs pass accessibility, including different states of elements. You don't want anything to be unreadable (especially if they tab ~ usually hover states match :focus states in tabbing) – Majo0od Jul 17 '19 at 15:51
  • @Majo0od well that was my thoughts - I just wanted to ensure I was correct in my thinking as I'm anticipating I will be challenged by stakeholders on this. – D Smith Jul 18 '19 at 8:29
2

Yes off-course. WCAG 2.0 version 1.4.3 has not mentioned anything specific regarding color change for button text on hover/focus states. It is safe to assume that the button text on hover/focus states should maintain a contrast ratio of 4.5:1 or more to pass AA conformance level of WCAG 2.0. more info can be found here: https://webaim.org/articles/contrast/

If you are looking for accessibility guidelines for content on focus/hover states in general. They are clearly explained in the latest version of WCAG 2.1 2018 version in Success criterion 1.4.13 https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

2

First off, hopefully your hover state is also indicated with keyboard focus too. (Just use :hover and :focus in the same style definition).

Whether the button has focus or hovered or not, the text on the button must have a sufficient contrast with its background color. If it didn't, then the text might disappear when it receives focus/hover and then you wouldn't know if you should select the button because you can't see the text.

Note, however, that 1.4.11 says that the focus color or hover color does not need sufficient contrast with the default state. That is, if your button's background changes slightly between hover and default state, that color difference does not have a contrast requirement.

2

Let's take the example of a table row that is highlighted on mouse hover. As mentioned by Sooraj MV, WCAG enforces a contrast ratio of 4.5:1 minimum for AA level of accessibility.

OK but you can argue that the color contrast is good when not hovering / focusing the element. The problem is that some people with low vision will use a screen magnifier, and for example to read the table row, their mouse will necessarily be on hover. That means everytime they will read a row, they will trigger the hover interaction, making a good color contrast becomes mandatory in this case.

For the contrast of a focused element, the problem seems less obvious, but users generally focus on an element (i.e. button) just before they trigger the interaction. If they can't read what is focused, how are they supposed to know what the action is? They would need to go back and forth. Obviously this is not a good user experience.

Remember that accessibility guidelines are here to help you design accessible websites. In the end, the only thing that tells if it is accessible or not is a user test. And you can provide a very bad user exeprience while respecting WCAG AA ... Prioritize user feedback over guidelines

1

Yes it does. Hover state is just one of the states of a UI control, so every requirement is applicable.

Only disabled (inactive) state is exempt from colour contrast requirements.

See Success Criterion 1.4.3 Contrasstrong textt (Minimum) Incidental

1

You describe a way of thinking about accessibility that is quite common.

Lets assume it is for a contact form and ask those questions:

  1. Does the hover state need to be accessible or the whole button?
  2. Does the button need to be accessible or the way the form is send?
  3. Does the form need to be accessible or just the fact that people are able to contact you?

You might be struggling to make a contact form accessible for disabled people, and then find out that they prefer to make a call. Just by adding a phone number on the page makes it a lot more accessible for those people to contact you. While this is just an example, I hope it makes a point clear. Are all users able to understand what the button does and how it behaves in the context of the form?

Focus on the button in it's entirety, not just the hover state, and see if and how the hover state improves or decreases the accessibility of the button.

Does the hover state of the button communicate some crucial information? Provide this information in a different way. If the hover state has the same function as the focus state for keyboard users, it should be made accessible.

-1

there are many states of buttons, sometimes I meet with the situation that it is worth blocking a given button until certain conditions are not met (eg entering variables)

Depends on hover, You can changing this attributes: enter image description here

enter image description here]2

Credit for Nathan Curtis for the pictures.

-1

This issue filed on WCAG Github may answer your question

1.4.11 hover state clarification #849 [https://github.com/w3c/wcag/issues/849#issuecomment-518747778]

  • 1
    Hi Laurence, welcome to the UX StackExchange community. We recommend adding an excerpt or a screenshot of the relevant portion of the URL in the answer so that it doesn't become irrelevant if the URL becomes inactive – Shreyas Tripathy Aug 13 '19 at 9:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.