Jeff Chandler posted a link in the Post Status Slack yesterday leading to an article complaining about the underlined link requirement for WordPress themes. It’s an interesting read, and it makes some good points about what kinds of link decorations can pass the Web Content Accessibility Guidelines and be fundamentally more interesting than an underline.

If you read Nick Hamze’s article, I recommend doing it on a mobile device; the readability on desktop is more than a little bit iffy.

The fundamental complaint is that the requirements for WordPress themes don’t allow the flexibility that is possible while still passing WCAG (Web Content Accessibility Guidelines) guidelines.

This is only partly true.

WordPress Themes Are Allowed Other Options

The WordPress theme requirements are about defaults. By default WordPress themes have to have underlined links. That doesn’t mean that a theme can’t have alternate styles. Those styles don’t even have to be accessible, although I’d certainly prefer it if they were.

Theme Requirements are about Testability

The rules for WordPress themes are for testing purposes. There is very, very limited bandwidth for testing themes and verifying that they are meeting requirements. It’s manual, and requires a person to actually look at the theme and verify that it meets expectations.

Requiring an underline is very easy to test:

Is there an underline? Yes – it passes. Done.

Let’s look at the testing process for the additional suggested treatments. (These are written in reference to the article, but I’m not quoting the full source. Visit the article for reference.)

Bold + Color with Sufficient contrast.

This requires the tester to verify that the bold links are a different color than bold text, verify that the color contrast difference between the bold text and the links meets color contrast guidelines, and verify that changing colors in the editor doesn’t result in losing this sufficient color contrast.

High Contrast + Hover/Focus underline.

Similar to the previous example, this requires verifying the color difference meets requirements and that it continues to meet this requirement if the color of the text is changed in the editor.

Subtle Border Bottom

This is allowed, so it is irrelevant. The WordPress guidelines don’t stipulate the method you use to add an underline; only that there is an underline.

Background Color Treatment

This also requires extra testing, mostly surrounding color contrast. Layering color contrast always creates a higher testing burden. The background color can’t actually be all that subtle, as the article suggests, because it needs to be able to contrast with at least one of the link color or the background color, while still being sufficiently different from the neighboring colors.

If you want to watch a really thorough talk about the complexity of color contrast testing, watch Jonathan Whiting’s 2023 WP Accessibility Day talk: Understanding Color and Contrast Requirements in WCAG 2.

Icon Indicators

These do provide clear visual cues. They are considerably less obvious; there are complications with the recognition of symbols, what happens if the symbol doesn’t load, or how the icon adjust with font resizing than can require more complex testing.

While this may meet WCAG requirements, it is nonetheless lacking in universal recognition.

Combination Approach

First of all, if one of the included items is an underline, then this will likely pass regardless of the other elements included. So the example given in the article – a solid border with a subtle background and clear focus outline – could pass. (There is an ambiguity here: is it an underline if there’s a border on the bottom, but also on other sides? Maybe…)

What is needed to allow other options?

More people testing themes, with more time available to do it. It’s very simple: the main gap in allowing any additional options is human time. Requiring underlines means that passing can be assessed very quickly; allowing other options makes it time consuming. And there’s nothing stopping developers from adding alternative styles.

But, more importantly, the default should be the most universally recognized indicator that something is a like, and that’s the underline.

One of the author’s criticisms of this is that “Award-winning accessible websites use varied, thoughtful approaches.” Well, that’s fine. But if your aim is building an award-wining accessible website, are you really trying to do that using an out-of-the-box theme? If you win an award using a freely-available theme, then the developer who built the theme deserves that award.

I’m not responsible for the general theme development guidelines; I do have a lot of influence on the accessibility-ready guidelines, which that particular rule is derived from.

In my opinion, theme reviewers should have the latitude to make decisions about whether something passes the principle of a guideline even if it doesn’t pass the literal guidelines as written.

However, I don’t think that theme reviewers should have to spend hours of their time verifying your claims. If you can provide 3rd party verification with detailed explanation of why an exception should be allowed, I’m game to give that due consideration. The guidelines, however, should remain something that can be easily tested by non-experts with a relatively low error threshold.

I’d be happy to allow alternate, WCAG-conforming link designs on themes. But if the cost is hours of theme reviewer time or the acceptance of themes that do not meet accessibility standards, neither of those are acceptable to me.

Note: I was unable to identify the name of the person who wrote the article from their site while writing this. After publishing, I did see this posted on social media and have amended the article to reflect those changes.