Underline inline links

Good afternoon!

Context

In order to fulfill WCAG 2.1 AA requirements, we want to have links that are visible enough from their neighboring text.

So far, links are not underlined in XWiki. This makes it difficult to identify them as links, especially for users with reduced contrast sensitivity (contrast sensitivity typically decreases with age).

This is a mock picture made to highlight the importance of not relying only on color changes to convey information:
inlineLinkLowColor

This was made using the NoCoffee browser extension with a preset to simulate Achromatomaly.
We can see that itā€™s difficult to find links that are inline and not external (because those do get an icon that is easy to spot). There is one inline link besides ā€˜WYSIWYGā€™ in the ā€˜Page Editingā€™ card on the screenshot above. I donā€™t think this link is reasonably easy to notice.

One solution we already discussed to make it easier to spot those links is to ensure thereā€™s enough contrast between them and the surrounding text. We implemented this by making the standard text color darker.

Out of the 441 fails of this WCAG rule found by our automated accessibility tests, this solved only 145.
The others are mostly made of a failure on the color #555555, which is the one in the mixin .text-muted.
Itā€™s not possible to increase contrast between this mixin and links without losing the whole point of this mixin: .text-muted would barely be muted anymore.

Vote proposal

In order to solve those cases, we should provide an additional visual indicator to differentiate the link from its surrounding text. For the sake of consistency, the same rule would apply on all links (even if they are not inside of .text-muted).

I propose to underline inline links by default and add an option to remove all link underlining from the user preferences.

Here is a display of what it would look like:
image
On this second picture I added an orange square around links that do not get underlined, and a light green square around those that do:
image

This is a solution that has been adopted by GitHub recently in their efforts to improve accessibility. @amilica also found out that Obsidian, the french design system, and Notionā€™s blog also use such underlining rule.

I think this is becoming a standard among complex web UIs, and we can leverage its advantages on accessibility without it looking too unusual for users. I think that the experience of a standard user is not meaningfully degraded by those improvements for low vision users.

This is going against a VOTE that was made a few years ago and ended up in links not being underlined in XWiki. @vmassol I remember we looked at it a few months ago when discussing this topic, but I canā€™t figure out how to find anything on the dev mail archive linked in Forums & Mailing Lists - XWiki .

Resources

This change follows the discussion initiated by @amilica about making accessibility features enabled by default.
This forum topic and this PR describe in detail the thought process that led to this proposal.

Note that the specific implementation of the selector used to differentiate inline links from other links is non trivial and will be discussed later on if this vote is not vetoed.


Thank you in advance for your feedback!
Lucas C.

1 Like

+1 100%

Could you explain more precisely the rule since it seems only the links from the content are underlined in the screenshot? How do you decide if a link should be underlined or not?

Could you also explain where do you plan to add this preference in the user profile precisely?

Indeed, but nothing prevents starting a new vote to change that.

The links are broken ATM since markmail has stopped providing its service for XWiki. Iā€™m discussing with the XWiki.org infra team to try to get back the archives we had in the past and that currently are no longer accessible for some reason.

I guess this is the vote. +1 in general (even if I donā€™t like the default look with underlines as I find that is makes the page heavier) but I need to answers to the questions above to understand precisely what weā€™re voting on.

Also, this will need to be in the release notes. All users upgrading their version of XWiki will suddenly see all links underlined.

Thanks

Any link that is inline would be underlined, no matter the position in the DOM or the color of the text surrounding it. On the screenshot, we can see for example that the link forwarding to the profile of the last editor of the page is inline, and underlined. To be honest, most links outside of content are not inline. This change would mostly affect content.

The selector to decide whether it should be underlined or not is based on the nature of the parent. If the parent typically contains text nodes (span, p, ā€¦), then we underline it. I donā€™t yet have the exact selector weā€™ll settle on, but Iā€™m planning on matching the ā€˜inlineā€™ adjective as best as can be done with CSS selectors on XWiki, and donā€™t add any other restriciton.

I plan to add it in the user preferences, under the display preferences, between the display hidden pages and extra accessibility features fields. On the picture below, an orange rectangle is used to highlight this place.
userPreferencesInlineLinks

Okay! Thanks for the help. I wanted to make sure to mention this previous VOTE since thatā€™s the main reason I started a VOTE here instead of a regular proposal :slight_smile:

This is the vote :+1:

Since this is required for WCAG, Iā€™ll leave the type of the ticket about this topic as ā€˜bugā€™, but add a comment so that we donā€™t forget that itā€™s a bug that we should write documentation for :+1:

Thanks for your feedback, I hope my extra explanations made things a bit more clear :slight_smile:
Lucas C.

+1

Thanks for working on this,
Marius

I guess this would be the first version. For the final version, Iā€™d go more towards a section related to accessibility either inside ā€œthe preferencesā€ page itself or as a new tab, and explode the extra accessibility features into several times so that all accessibility options are at the same level.

I remember we discussed this in some thread but I donā€™t remember if itā€™s been decided. If not, I think it would be a good idea to propose it and create a jira for it if agreed. You might even want to go for it directly instead of going through 2 steps, depending on how much extra work this represents. Since itā€™s in the domain of accessibility, I think it would make sense if you could work on this too.

Thanks

PS: Note that ā€œunderlined linksā€ is mentioned in the hint for Extra Accessibility feature already so I think it would make sense to go for it as it seems already included in that config. WDYT?

+1

I donā€™t like the ā€œExtra Accessibilityā€ setting. Users should be able to configure individual accessibility settings based on their needs (e.g. some may want underlined links but not a bigger font).

Thanks,
Marius

2 Likes

:+1:
I started a proposal on this topic a few minutes ago :slight_smile:

The underlining mentionned was applied to all links. I think allowing all link underlining is an option that we donā€™t want to remove. It can make it easier to navigate for some users.
I think the best option would be to join them together in a 3 state select: no underline, underline inline (default) and all underline.

:+1:

Iā€™ll close the vote after 8 days, tomorrow the 27th of October at 6PM UTC+2.

+1 thanks !

+1 thanks

+1 :+1:

Thanks! VOTE passed with at 4 +1 from committers :slight_smile: