Is removing a link underline on hover not WCAG compliant? - accessibility

Question

I'm trying to find a definitive answer to this accessibility question. If I set the underline on all links by default...
a {
text-decoration: underline;
}
...and remove the underline on hover...
a:hover {
text-decoration: none;
}
...is this no longer WCAG 2.0 compliant?
There's a bit of gray area with the W3C's Success Criterion. Per "Failure of Success Criterion 1.4.1 due to creating links that are not visually evident without color vision":
Link underlines or some other non-color visual distinction are required (when the links are discernible to those with color vision).
We know that a link with default styling that doesn't include an underline fails the success criterion even if the underline is applied on hover. Because as stated above, "other non-color visual distinction are required". Is the same true in reverse?
I've seen a few accessibility tools (e.g., SiteImprove) flag the lack of underline on hover even when it's present for default styling. Does anyone know definitively what the answer is?

Answer 1

#graham is spot on but a few other things to consider that can't fit into a comment area.
Bear in mind that you don't have to underline links. You just have to make them visually identifiable with something other than just colour.
You don't necessarily have to distinguish with more than color if the links are all by themselves. It's usually only a problem if you have links embedded in a paragraph with plain text. Then you need to make sure the links look different from other text besides using just color.
Likewise with your comment:
We know that a link with default styling that doesn't include an underline fails the success criterion even if the underline is applied on hover.
We actually don't know that it fails the success criterion. It depends on the context and design as I'll explain below.
An important part of accessibility with regards to WCAG is to understand that documentation/specs can be normative or non-normative (the latter is also called informative).
Normative is required for conformance and non-normative/informative is not. However, non-normative is usually pretty good advice (best practice) so it's often a good idea to follow it, but not following it doesn't mean you're not conformant to WCAG.
See "5.1 Interpreting Normative Requirements":
The main content of WCAG 2.1 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.
As an example, the intro section of WCAG says it's non-normative.
The failure you quoted, F73, is non-normative. Even if you have that pattern, "links that are not visually evident without color vision", that doesn't mean you necessarily fail WCAG. It goes back to my first comment about links by themselves. F73 even mentions that:
While some links may be visually evident from page design and context, such as navigational links, links within text are often visually understood only from their own display attributes.
In other words, it depends on the design.
As an example, look at https://webaim.org/. The paragraph text color is black. "The results of WebAIM's...".
There's a link below the text that is blue and underlined which is a typical practice but ignore that link for now. Just note that the paragraph text is black.
Near the top of the page is a list of navigation links. They are black too.
So now there is plain text that is black and links that are black and when looking at just color, you can't tell the difference. However, the design of the page makes it apparent that the text at the top are links so it wouldn't fail 1.4.1 or F73.
Even though this doesn't fail, WebAIM still has a hover and focus state that changes the color of the link and they have a slight shadow when hovered and focused. That makes for a better user experience but isn't necessarily needed for WCAG.
All that being said, you are ok if you remove the underline upon hover with regards to WCAG conformance but you should still ask yourself is it's a good user experience.

Answer 2

I am afraid you are unlikely to find a definitive "you can do that" or "can't do that".
However in this scenario where the link is identifiable in text without hovering due to the underline, I cannot think of any success criterion you would fail by removing that underline on hover.
I am making the assumption that there is a visible focus indicator if some focuses links of course.
I am also assuming that you don't change the cursor behaviour and there will be a cursor: pointer when you hover the links.
Bear in mind that you don't have to underline links. You just have to make them visually identifiable with something other than just colour.
This could be making the text bold, italicised, larger etc.
If you are at all worried then making them bold as well as underlined (or even just bold when hovered and remove the underline on hover) would make sure the link will always have some visual distinction in all states.
The only other thing to consider...link state can be identified by colour alone (visited and active for example) so I would consider hover to just be another state.
The only other final "argument" I have is that of expected functionality. It is one of the largest aspects of accessibility. Would a user expect the underline to be removed on hover? Could that cause confusion or unsettle someone with an anxiety disorder?
I would say it is fine but that might be one for user testing to get a definitive answer!
I am aware this answer has ended up as "opinion", but it is at least educated opinion and the short answer is "it passes WCAG given the information provided"...I just wanted to explain some considerations I would have if I were assessing this for accessibility.

Answer 3

The first answer is, the link you provided is to a completely obsolete very early working draft from 2008. And be careful at the W3 site, it's a a bit of a mess and unfortunately fairly easy to get stuck on the wrong document.
Disclaimer: As an Invited Expert of the W3C my statements in this post are mine alone and do not necessarily reflect the official views of the W3C or AGWG. 😇
Second is to read the current pages. Unless you have a specific need to, don't use WCAG 2.0, use the current recommendation, 2.1, or the current draft moving toward consensus 2.2.
Here is the correct page in the actual 2.0
Here is that page in the current 2.1
Here is that page in the pending 2.2
Third if I haven't annoyed you yet, you might be interested in the Advanced Readability Forum at the github for APCA, and this post in particular:
A Discussion of Inline Links (Theory and Practice)
It's the start of a thread and there's a lot of other similar topics, comments of course are welcome.
Note: the link is to a discussion, and is not part of a normative standard yet.