Accessibility: Plugin Single Use of Color Failures

[amberhinds]

On the plugin single page (Gutenberg plugin test page), there are several instances where links are indicated only by a change of color and do not have any other way to indicate that they are links. This is a failure of WCAG 1.4.1 Use of Color (A).

Here are the instances I found:

1. "See all 56" - referring to languages in plugin meta:

2. The Advanced View link:

3. All of the rating links (both the number of stars "5 stars" and the count "821"):

4. Contributors & Developer links:

Links need a second way, aside from color to indicate that they are links and actionable. Traditionally this is done with underlines, but arrows or other icons can also be used as an alternative.

[ryelle]

I thought that only applies to links inside content? That these links, like the navigation links, were understood to be links by the context around them (being in the sidebar as "meta" info — the exception might be example 4). They also have underlines on hover, to help clarify.

For example, this pattern exists on Learn and Showcase, no underlines in the sidebar content until hover.

[amberhinds]

It applies to links where you cannot clearly differentiate that it is a link. In the first example, maybe those are okay because they are all links and are a different weight from the text on the left. But in the second example that you posted, if you couldn't differentiate between the color blue and black, how would you know that "Business" is a link but "United States" is not?

[amberhinds]

Essentially, people shouldn't have to hover over something to know that it's a link. Sometimes, positioning is enough to make it stand out as a link. But having some elements in a "table" (I know those are not tables, they just look like them) that are linked and others that are not, it's not sufficient to only use color to indicate which are links and which are not.

[ryelle]

Okay, then I'll tag in @WordPress/meta-design since it sounds like we might need to revisit link styles across the entire redesign 😬

[StevenDufresne]

I'm not pushing back against this but interested in learning more.

For example, from the link you shared

WCAG 1.4.1 Use of Color (A).

The left-hand menu seems to also violate the rule based on the explanation.

Those are all links that are only discoverable after hover.

[amberhinds]

The difference there is the context.

It's under a heading of "Table of Contents" which in and of itself may communicate to people (in a web scenario) that the items below the heading are all clickable. I think that communicates to people an expectation of functionality.

Also, every single thing in that list, styled that way is a link. There's not a mix of links and non-links that share the same styles in that list.

What I was getting at with my first comment is that it might be OK in some scenarios not to underline or have an icon if there's some other visual distinction between the link and adjacent text. While I don't love this, it might get a "pass" from some testers because everything on the right is a link and the links have a lower font-weight than the text at the left.

It's most problematic in scenarios like this where it's not clear if something is a link or not:

People might expect to be able to click on the author name or country. Or vice versa, if the first couple are not links and I can't distinguish the blue from the black, I wouldn't expect that I could click on the category or flavor.

[ndiego]

Thanks for flagging this issue and the additional context 🙏

While we should definitely investigate and look into a design solution asap, I personally don't think it should block launching the new Plugins design since the link behavior is the same in the current theme (and elsewhere on the the site).

[fcoveram]

It could be a solution adding context to the area rather than modifying the font weight or adding an underline style? Given that the WCAG documentation example meets the requirement by clarifying the section purpose through a heading, we could include one in this section noting the meta content.

[joedolson]

It's pretty much entirely about whether a link is mixed with non-linked content. Even with a heading, the case with Author/Country/Category/Flavor/Published/Site tags posted above would fail, because some of those strings are linked and others aren't, and there's no way to distinguish between them.

The use of color criteria is about differentiating items: in this case, is it possible to differentiate a link from a non-link?

In the Table of Contents example from the W3C, there are several indicators that those are links: the heading 'Table of Contents', the background color that sets the content off from neighboring content, etc.,

If some of the text following the Table of Contents heading was linked and some of it wasn't, there would definitely be a problem there.

Following that logic, the example from Learn can pass; but the example from Showcase can't. It might be better if the Learn example had underlines, but I wouldn't actually call it a WCAG failure; being an accessibility problem and being a WCAG failure are two different things.