A11y: Continuous text hyperlinks are marked by colour only and therefore not accessible

[daniellekirkwood]

Continuous text links (examples marked red) are only marked by a colored highlight.
There is no additional symbol, underlining or boldface. The required contrast ratio of at least 3:1 to the rest of the text is not met with a value of 1.7:1.

Since the perception of color is required to identify the continuous text links, they are
difficult or impossible to recognise for visually impaired users if the contrast is too
weak. This is also present elsewhere.

The contrast ratios in the alternative displays "dark" and "high contrast" also do not meet the minimum requirements.

[daniellekirkwood]

@janogarcia similarly, we need your guidance here on how we plan on changing and addressing hyperlinks in the future as a part of compound. Assigning you.

[janogarcia]

@germain-gg @daniellekirkwood

I'll be referring to contrast values for Compound, as applied in the Colour pass Germain recently implemented:

• Blue links in messages: Accessible (3.2:1). Don't need an underline.
• Green links elsewhere: Accessible (3.18:1). Don't need an underline.

So, consider it solved with Compound.

[janogarcia]

Should I close the issue already or wait for the Colour pass to be released?

[daniellekirkwood]

@janogarcia thanks for the response but the issue here is that the links are only seen to be links denoted by colour which is not accessible. It's not the colour itself that's the problem

[daniellekirkwood]

if we want to use colour alone for hyperlinks then it must match this criteria: https://www.w3.org/TR/WCAG20-TECHS/G183.html

[janogarcia]

The links I provided above demonstrate why we don't need to show an underline by default. That is, the contrast against surrounding text is > 3:1 when using Compound colors.

On top of that, only thing that needs to happen is showing an underline on hover or alternative decoration on focus, but the color part for the links when in the default state is already sorted out by Compound colors.

[daniellekirkwood]

in that case this can be closed as the compound colours handle it. You agree, @janogarcia ?

[janogarcia]

@daniellekirkwood The concern regarding 3:1 contrast against surrounding text is definitely handled by Compound. That said, we may have some instances in the legacy codebase where those links don't get an underline when hovered (e.g., links in supporting text in Settings > Help & About).

Maybe we want to keep this issue open to track those improvements to the legacy codebase? /cc @germain-gg

[daniellekirkwood]

Here's our first example. Hovering over this does not show an underline but as to your colour comments @janogarcia this is the new colours and I didn't spot that it was a link for a while. I think that we need to be really careful here especially as we can't rely on someone using their mouse to hover over random text hoping that it'll underline.

[daniellekirkwood]

the links in the labs and help&about section are blue and much much clearer

[daniellekirkwood]

[daniellekirkwood]

@janogarcia How would you proceed from here? Please update :)

[daniellekirkwood]

@janogarcia polite reminder...

[janogarcia]

@daniellekirkwood Apologies, I got your previous messages while I was away (for 3 weeks) and it seems I didn't notice them when I caught up with stuff.

Yeah, thanks for those examples.

So, the safe contrast ratios I shared above are true when non-underlined links are combined with the primary text color, but they will fail when combined with the lower contrast secondary text color.

• Blue + Secondary Text
• Green + Secondary Text

For those cases we should underline the links by default.

[janogarcia]

Alternatively, we could show underlines by default only in the high-contrast theme. That's still a perfectly valid way to handle accessibility issues/enhancements. /cc @nadonomy

https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=143#contrast-minimum

For example, Twitter will underline links when enabling the high-contrast mode on iOS system-wide ("Increase Contrast" setting in iOS Accessiblity settings) or switching on the "Increase color contrast" preference on Web.

[janogarcia]

Also, the Security Disclosure Policy example you shared would still be valid/accessible, as it's using a icon to indicate the link and not relying exclusively on color.

[janogarcia]

Update on the high-contrast theme.

We basically need to underline the links by default on the high-contrast theme. Otherwise the contrast for links against surrounding text will be low even for the primary text color.

https://contrast-triangle.com/?linkColor=%230543a7&textColor=%231a1c21&underlines=false

[daniellekirkwood]

Thanks for your comments. Is that the only action that's needed here? To add an underline when in high-contrast mode?
Are we comfortable having the difference between modes?

[daniellekirkwood]

FYI @janogarcia this report shows that we should have the underline everywhere...

[daniellekirkwood]

@janogarcia polite reminder that we're waiting for your response to move this forward.

[janogarcia]

Thanks for pinging, @daniellekirkwood.

I'm not sure if the report is accurate in that detail. Links in running text can be accessible, even if the only difference is in color, as long as that the relative contrast between links and surrounding text is 3:1.

That said, for the case of links in running text:

• on desktop, we still need an underline (or alternative accessible indication) when hovering the link;
• it fails when the surrounding text is set to the secondary text color (gray instead of almost black); and,
• it fails when in the high-contrast theme, since the link color will also be darker and thus won't meet the minimum 3:1 contrast against surrounding text

Given there are so many scenarios where non-underlined links in running text can fail to meet the accessibility guidelines, I think we basically have two possible directions:

• Option A — Providing a setting to enable link underlines (e.g., GitHub), or just enabling it automatically for the high-contrast theme (ala Twitter).
• Option B — Just render underlines by default for links in running text.

→ I'd say Option B, given that Option A makes the default experience less accessible (even if it's still compliant by providing a setting).

Standalone links (e.g., menus, footers... see footer element on GitHub screenshot) are not affected by this rule, you just need the text to be 4.5:1 against the background.

---

Refer to the currently introduced setting on GitHub and their accessibility guidelines for links.

They use a CSS selector (link--inTextBlock) for targeting links in running text.

[daniellekirkwood]

@janogarcia please confirm: You're now advising that we underline all hyperlinks on web?

[daniellekirkwood]

And should we be going for blue or green ? It's clear the standard across the internet is blue. I think we should have our hyperlinks in blue and underlined. @janogarcia please confirm this is reflected in the design system.

[janogarcia]

You're now advising that we underline all hyperlinks on web?

In running text we should always render the underline. Example on GitHub:

Standalone links are not required to be underlined. From an accessibility point of view, those are optional. We render an underline for most of them for the new UIs we're working on, but we may also omit it for low priority elements that should have lower visual weight (e.g. page footers). Example on GitHub:

And should we be going for blue or green?

At the design-system level we use mostly black, but use blue for external or user-generated links (e.g., links in user-generated content in the timeline). Similar example on GitHub:

[janogarcia]

Additional note on the colors used for links in the design system vs. legacy Element Web.

We don't need to hunt down every link in the legacy Element Web app and map it to either black or blue. For now it's OK to just make sure we're showing the underline where needed.

So, in the following example we'd just make sure the green link shows an underline, but we don't need to change it to black or blue just yet.

As we redesign the different areas of Element Web we'll make sure to update those elements as needed. For now consider it being a first pass where we just make sure we show the underline where needed.

[daniellekirkwood]

I need to confirm with the customer whether Jano's statement above is true or not. Assigning to me to do that.

@gaelledel assigning to you because: Can you confirm that the compound rules and guidance has been updated in all the necessary places to ensure that hyperlinks everywhere are shown appropriately given the above discussion?

[gaelledel]

Yes, the compound design system is using underlines under text based components

[nadonomy]

I need to confirm with the customer whether Jano's statement above is true or not. Assigning to me to do that.

@gaelledel assigning to you because: Can you confirm that the compound rules and guidance has been updated in all the necessary places to ensure that hyperlinks everywhere are shown appropriately given the above discussion?

Added this issue to track adding a blue external text link issue variant in Compound: element-hq/compound#286

Not clear when we pick this up though (design, engineering) - probably best for us to discuss in the next web leads sync.

[daniellekirkwood]

Great. As we now have that issue to track this update, I don't think we need this one anymore so I propose we close it. Thoughts?

[gaelledel]

I think it's good to be closed