Blog October 19, 2026 · 12 min read

Underline Links for Accessibility: When to Keep Them

Designer reviewing underlined links on a webpage

Underline your links. WCAG does not literally say “every link must be underlined,” but links inside text that rely on color alone to stand out fail Success Criterion 1.4.1 (Use of Color), and an underline is the simplest, most widely understood way to fix that. If you remove underlines, you take on specific design obligations: a 3:1 contrast ratio against the surrounding text, plus a non-color cue on hover and keyboard focus.

This guide explains the rule, shows when removing underlines is defensible, and gives you CSS and a test routine you can use today. It is written for site owners, designers, and developers who want links that every visitor can find and use.

AccessWiser

Find Link Accessibility Issues

AccessWiser scans websites against WCAG 2.2 AA, identifying code-level issues and providing plain-language guidance for fixes in your site's own code.

Explore AccessWiser

TL;DR

Color alone must not be the only way to show that text is a link. Underlines plus a distinct color are the commonly accepted best practice, per Section508.gov.
If you drop underlines on inline links, the link color needs at least 3:1 contrast against surrounding text, and a non-color indicator must appear on both hover and focus (technique G183).
Navigation menus, buttons, and footers are different from links in paragraphs. Context can make them obvious without underlines, but inline links almost never have that context.
Underlines do not fix vague wording. Link text still has to describe its purpose (SC 2.4.4).
Test with a grayscale view, the Tab key, and a scan that checks each link in the code.

What the rule actually says
Why color alone fails real readers
Where underlines are needed and where they are not
If you remove underlines, here is what you owe
Hover and focus are not the same thing
Common styling traps
Underlines do not fix unclear link text
How to check your own site in ten minutes
Our perspective: make the fix permanent
Catch link problems automatically
Frequently asked questions
Sources

What the rule actually says

The requirement comes from WCAG 1.4.1, Use of Color. It says color cannot be the only visual means of conveying information, which includes the information that a word is clickable. The W3C’s failure technique F73 describes the problem plainly: people who cannot perceive color differences cannot identify links when color is the only signal. It states that link underlines or another non-color distinction are required when the links are discernible to people with color vision. You can read that on the F73 technique page.

The same page makes a useful distinction. Some links are evident from page design and context, such as a row of navigation links. Links buried inside a paragraph are not. A reader scanning a sentence has nothing else to go on.

There are two ways to pass:

Add a non-color cue by default. An underline is the classic choice. Bold weight or a border can work, but underlines carry decades of user expectation.
Keep color as the only default cue, but meet G183. The link color must contrast at least 3:1 with the surrounding non-link text, and the link must show a non-color indicator when it receives hover and focus.

The first option is easier to defend, easier to test, and kinder to readers.

Why color alone fails real readers

Color perception varies widely. Section508.gov’s guidance on descriptive links and hypertext points to color blindness as a reason to provide redundant visual cues, so every user can tell interactive elements from static content. Low vision, glare on a phone outdoors, a washed-out monitor, and grayscale or high-contrast modes produce the same result for people without any diagnosed condition.

Here is a quick way to see it. Take a paragraph with light-blue links in dark-gray text. Switch the page to grayscale. If the links disappear into the sentence, a meaningful share of your visitors are having that experience in some form.

For more on design decisions that hold up for color-blind users, see our guide to stopping color blind failures with WCAG fixes, tokens, and CI.

Where underlines are needed and where they are not

Not every link needs the same treatment. Use this as a working guide.

Link type	Underline by default?	Why
Links inside paragraphs, lists, and table cells	Yes	Nothing but color separates them from text
Links inside a bulleted list of resources	Yes, unless the whole list is clearly a link list	Context is weaker than it looks
Primary navigation bar	Not required	Position and layout signal that these are links
Footer link columns	Not required, but be consistent	Grouped, labeled, and repeated across pages
Buttons styled as links	Not required	Shape, padding, and borders signal interactivity; check non-text contrast
Card titles and logo links	Not required, if the card is clearly interactive	Visual affordance comes from the component

The pattern is simple. If a link sits among words that are not links, underline it. If it sits in a component whose design makes the click target obvious, you have freedom.

One caution. Navigation that is obvious to you, the designer, may not be obvious to a visitor who has never seen the site. Test with someone who has not seen the design.

If you remove underlines, here is what you owe

Some brand systems insist on non-underlined links. That is workable, but only when you meet the conditions in technique G183:

3:1 against the surrounding text. This is the contrast between the link color and the body text color, not between the link and the background. People often miss this. A link can pass 4.5:1 against a white background and still fail 3:1 against dark-gray body text.
A non-color indicator on hover and focus. An underline appearing, bolding, or a background change all count.
The link must still meet text contrast against the background. That is a separate requirement under 1.4.3.

The math is demanding. Using a dark body text and a link color that is distinguishable at 3:1 from it, and also readable on the background, leaves a narrow window of colors.

A second limitation: the hover cue helps only people with a pointer. Someone using a touch screen never hovers, so on touch devices the default state does the work. This is another reason underlines are the safer default.

Hover and focus are not the same thing

A frequent mistake is styling a:hover and forgetting a:focus. Section508.gov’s guide to accessible web design and development stresses that accessibility is device-independent. A visual change must be available to someone using a mouse and to someone tabbing through the page. If hover works and focus does not, keyboard-only users are left out.

Pair every hover rule with a matching focus rule. Better, use :focus-visible for the focus ring and keep the underline change on both states.

Hover and keyboard focus link states compared

/* Default: underlined, readable, distinct from body text */
.content a {
  color: #0b57d0;
  text-decoration: underline;
  text-decoration-thickness: 0.08em;
  text-underline-offset: 0.15em;
}

/* Hover and focus get the same treatment, plus a visible focus ring */
.content a:hover,
.content a:focus-visible {
  text-decoration-thickness: 0.15em;
}

.content a:focus-visible {
  outline: 3px solid #0b57d0;
  outline-offset: 2px;
}

This keeps the underline in every state, thickens it on interaction, and adds an outline for keyboard users. The color values here are examples. Check yours against your actual background. For focus ring size and contrast, see our walkthrough of WCAG 2.4.13 focus state requirements.

If your design really requires no underline

Use an underline that appears only at the right moments and meet G183 by default:

.content a {
  color: #0b57d0;        /* 3:1 or better against body text */
  text-decoration: none;
  font-weight: 600;      /* extra cue, not a substitute for the checks */
}

.content a:hover,
.content a:focus-visible {
  text-decoration: underline;
}

Then measure. Use a contrast checker on the link color against the body text color, and again against the background. Both numbers have to pass.

Common styling traps

These are the problems that most often turn up when we review link styles.

Global reset removes underlines. A CSS reset sets text-decoration: none on all anchors, and nobody adds it back inside article content.
Underlining things that are not links. This is not a WCAG failure, but it misleads people. If you underline emphasis, links lose their meaning. Use italics or bold instead.
Custom elements posing as links. Unlike a native <a> element, a clickable div or span has no default underline, no pointer cursor, and no keyboard behavior. Section508.gov notes these need manual CSS and keyboard support. Use a real <a href> whenever the element goes somewhere.
Links that change only in hue on hover. A slightly darker blue is not a non-color cue.
Visited links with no distinction. Not required by WCAG, but a distinct visited color helps people retrace their steps.
Dark mode surprises. Link colors that pass on a white page can fail on a dark theme. Test each theme separately. Our piece on high contrast CSS patterns covers this.
Text spacing and zoom. Underlines that collide with descenders or clip when line height is overridden make links harder to read. See our text spacing guide.

Underlines do not fix unclear link text

A perfectly styled link can still fail if its words say nothing. WCAG 2.2 Success Criterion 2.4.4 requires that the purpose of each link can be determined from its text, or from the text together with its programmatic context. Section508.gov explains why this matters: screen reader users may listen to a list of links, and in that case the reader may speak only the link text, without the sentence around it.

Compare:

Weak: “Click here to read our policy.”
Better: “Read our returns policy.”
Weak: “Read more” repeated under five blog teasers.
Better: “Read more about keyboard testing” or a visible title that is itself the link.

Section508.gov’s guidance for content authors lists “click here,” “read more,” and “more” among phrases to avoid. A practical tip: if you pulled every link out of the page and read them as a list, would each one make sense? If you serve readers in more than one language, the same rule applies in each.

How to check your own site in ten minutes

Grayscale test. Use your browser’s rendering emulation or an OS grayscale filter. Find the links in a paragraph without color.
Tab test. Press Tab from the top of the page. Every link should show a visible change when it is focused. Our keyboard accessibility steps walk through this in detail.
Hover versus focus. Compare the two states. They should both carry a non-color cue.
Measure contrast. If any inline link has no underline, measure link versus body text. You want 3:1 or higher.
List the links. Use a screen reader’s links list, or a browser extension that lists them, and read for meaning.
Check each template. Blog posts, product pages, checkout, footers, and email-style content blocks often use different CSS.
Re-check after releases. Link styles regress when a theme updates or a plugin injects its own stylesheet.

Steps 1 through 6 are one-time work. Step 7 is what keeps the result.

Our perspective: make the fix permanent

We look at link styling as a code problem with a code solution. A runtime overlay can add underlines to a page after it loads, but the underlying stylesheet still says the links are unmarked, and the next template change can undo the effect. We would rather you fix the CSS once, in your own theme, and verify it.

There is a second reason we favor underlines. Automated checks detect a substantial subset of accessibility barriers, not all of them. Whether link text reads clearly in context, or whether a navigation cluster is obvious to a first-time visitor, still calls for human judgment. A default underline removes the guesswork. It is a decision that does not depend on someone later measuring contrast ratios on every release.

Finally, we encourage teams to keep dated records. When you fix link styles, note the date, the template, and the criterion it addresses (1.4.1, and where relevant 2.4.4). That documentation shows a good-faith program and makes the next audit faster. Accessibility is a commitment to every visitor, and small, steady decisions like this one break down digital barriers.

— The AccessWiser Team

Catch link problems automatically

CSS rules are easy to write and easy to break. AccessWiser scans your site against WCAG 2.2 AA, ties each finding to the specific element and criterion it affects, and gives plain-language guidance for fixing it in your own code. Scheduled re-checks flag regressions when a theme or plugin changes your link styles, and dated records of scans and fixes support your documentation.

Plans start at $24 per month for Starter, with Basic at $49 per month and Pro at $119 per month. Business is a custom plan without a published price. Every subscription starts with a 7-day free trial. See the pricing page to compare plans, or browse accessibility solutions for every website.

Frequently asked questions

Should hyperlinks be underlined for accessibility?

In running text, yes. Color cannot be the only cue that something is a link, and an underline is the most recognized alternative. Section508.gov calls an underline plus a different color the commonly accepted best practice.

Is it a WCAG failure to remove link underlines?

Not automatically. You can pass by giving the link at least 3:1 contrast against the surrounding text and adding a non-color indicator on hover and focus, as described in technique G183. If links also rely on color with no other cue and fail that ratio, 1.4.1 is not met.

How do I make a text link without an underline?

Set text-decoration: none on the anchor in CSS, then add a second cue so the link is still identifiable. At minimum, meet the 3:1 link-to-text contrast and restore an underline on :hover and :focus-visible. Test with the Tab key to confirm keyboard users see the change.

Not necessarily. Links in a clearly grouped menu, footer, or button component are identified by layout and context, which F73 recognizes for navigational links. Inline links inside sentences lack that context and should be underlined.

Does underlining non-link text cause a failure?

It is not a barrier that WCAG sets a rule against, but it confuses readers who expect underlined text to be clickable. Use bold or italics for emphasis and keep underlines for links.