Underline Links in Text Blocks Public Beta

[dipree]

Links should be easily distinguishable from surrounding text, not solely by color but also by styling. Thus, we've introduced a new accessibility setting to underline links within text blocks. You can now toggle this setting to either "show" or "hide" underlines for such links, ensuring clear visibility and differentiation. Per default, the setting is set to underline!

If you come across any links within text blocks that aren't underlined even when the setting is enabled, please let us know here.

[paulshryock]

Making links more accessible is a good thing. Links are the most basic of fundamental aspects of the web. I shouldn't need to opt-in to an accessible experience. The baseline experience should be fully accessible. With that in mind, please make this the default; not a hidden setting.

[NiklasBr]

Thank you for underlining links by default @dipree! Even for someone like me who technically does not need it to distinguish links from other text it is a clear improvement!

[o0101]

Sometimes the old ways are the best.

[piotrpoliwoda]

Thanks so much for making this a customisable setting. I understand that when it comes to colourblindness underlines are a great way to distinguish what is or isn't a link. Though I literally disabled it in 2 seconds for myself since it makes the UI look too noisy and cluttered for me 🙂 win-win. Then again, the old links changed on hover so there was a way to distinguish them visually when using a mouse.

[johnswolter]

Needs some contrasting colors. I'm partly sight limited.

[jaggli]

It clutters up the text. This should be a browser setting like Dark-Mode or Contrast, then you should be able to use it with media queries prefers-underlines or similar. But cluttering up the text for everyone by default... I don't know. At least we can turn it off.

[DNin01]

I found that commit descriptions and titles don't have underlined links (the blue ones) yet.

[dipree]

Thank you, can you please post a screenshot or a url so we can reproduce this?

[DNin01]

Sure! Here's an example.

So yeah, links still need to be underlined on the commit history and commit details pages.

[dipree]

Links in commit details are underlined now. The links in the list of commits in the commit history are bold while text is regular and therefore, they are not underlined.

[DNin01]

By links in the commit history, I actually meant in the commit descriptions inside the history, which can be shown by clicking the three dots next to a commit.

[mtsknn]

A very welcome setting. 👍 Not having hover styles feels somewhat jarring. 🤔

[jfrost-mo]

The increased line thickness (the posted CSS) is a style I stole from the GOV.UK design guide, so is tested for accessability. I'm not sure if a small snippet like that is copyrightable, but if so, it is under the MIT licence.

[mtsknn]

Removing the underline on hover unfortunately defeats the purpose of this feature and makes it less accessible which we want to avoid.

I did not propose removing the underline on hover. I personally dislike that some sites do it and I agree that it wouldn't be a good solution.

Another option: changing the text color on hover (with or without increased underline thickness).

[jfrost-mo]

Having hover styles, such as mentioned above, would be a really nice useability improvement. It could also be a nice improvement to increase the spacing between the text and its underline.

[krystof-k]

Hover, please. Please! 🙏

[github-account1111]

Removing the underline on hover unfortunately defeats the purpose of this feature and makes it less accessible which we want to avoid.

Could you elaborate? The idea behind this change is to make it possible for colorblind people to distinguish links from text. Once you start hovering your mouse over a link, you obviously already know it's a link. What exactly is defeated?

[jfrost-mo]

The GitHub blog doesn't seem to respect this setting. (It may be out of scope however.)

For example, the announcement post for this feature:

I'm on Firefox ESR on Linux.

[dipree]

You are right, the blog isn't covered by this feature yet. However, we've noted your feedback and will look into options.

[thibaudcolas]

A welcome change, though I’m really surprised this is configurable and even more so that it’s opt-in. It’d be great to be able to use "Markdown in GitHub" as the one and only published version of a project’s documentation, be it within the repository or a wiki, without having to compromise on such a basic accessibility need.

---

Aside from this – I’m surprised this also applies to headings. Here’s an example (example source if it helps):

Those headings are authored without links – the links come from GitHub’s automated creation of anchor links, so effectively all headings in GitHub would become underlined. I thought it worth flagging. Not really sure what to think of it myself. On one hand the consistency makes sense, on the other all the headings are links no matter what so not sure it’s needed.

[dipree]

Headings aren't underlined any longer.

[GuySartorelli]

Headings aren't underlined any longer.

I haven't tested this but I assume that if you make the heading explicitly be a link (e.g. # [my heading](some-url)) then it will be underlined?

[paulshryock]

Headings aren't underlined any longer.

I haven't tested this but I assume that if you make the heading explicitly be a link (e.g. # my heading) then it will be underlined?

Right, this is what my comment above in this thread was getting at. Hopefully links which are not simply anchors will still be underlined.

<h2><a href="https://www.example.com">My heading that is a hyperlink</a></h2> <!-- Should be underlined -->
<h2><a href="#my-heading-that-is-an-anchor">My heading that is an achor</a></h2> <!-- Should not be underlined -->

Something like:

a:not([href^="#"]) {
  /* Underline styles. */
}

[himdel]

Looks like this was fixed everywhere except the wikis?

Given a bunch of headings like

## Automation Content
### Namespaces
### Collections
### [Execution Environments](./Hub-Execution-Environments)
### Signature Keys

I would expect only the penultimate one to be blue and underlined.

Currently, they become indistinguishable...

[TheDiscordian]

In regards to what @paulshryock said I don't believe this has been changed actually. For example my repository has a table of contents which looks a bit cluttered to me now: https://github.com/TheDiscordian/onebot#table-of-contents

I believe this use is what they're talking about (and I hope the example helps).

Edit: On second look I think you're right, however I still don't like how my ToC looks now lol.

[janmaarten-a11y]

This is fantastic, thank you. Please consider making "show underlines" the default.

[whisperity]

It looks like this has been implemented. As I was posting an issue I reloaded the page and suddenly, without changing anything in my configuration or my browser, suddenly things were underlined. It took me a while to get here and to figure out that this is some intended change... I was thinking something broke with my browser or my connection was being hijacked or I installed something I should not have.

It would have been worthwhile to show a banner to alert users to the fact that this is a deliberate change and offer guidance as to where it can be reverted should they wish.

[TokisanGames]

This default is not desired by many. It should be opt-in, not forced on. Instead temporarily show a banner letting people know they can enable it. That styling was popular in 1995, but it is too busy on wikis and pages with heavy documentation and many links.

[joshkimux]

@whisperity I got a banner alert on this which made it easy to jump to my settings. That being said, it was at the top right corner of my screen, so it may not have been too visible. Love the idea of making that more easily noticeable and maybe providing some plain language explanation why it benefits alot of folk functionally.

[rjgotten]

@joshkimux
I got a banner alert for this as well, but it was more of a pain to dig back out this setting due to it being paired also with the new (crappy) navigation update and the account accessibility settings being generally a mess.

Github staff should have a critical look at the current situation where each and every separate section has its own [save these settings] button. It's a completely unusable experience. If you change anything else without first hitting that button for that one section, it does a page refresh and resets everything else.

Pardon my French, but which blathering idiot designed that?

[xamidi]

These forced-in underlines are just another symptom of Microsoft ruining GitHub in an attempt to appear politically correct by favoring tiny minorities (only around 1 in 30000 people have achromatopsia!) rather than favoring preferences of the large majority.
By decreasing the average perceived value of your platform, you make it objectively worse and drive away many users in the long run. All because a political ideology gave you some nonsensical understanding of how to be politically correct.

[Myndex]

Underlines can be good, but too many can create a distracting chaos that is ultimately harder to read. We are doing some work on this, here's an early draft in the discussion area: Myndex/SAPC-APCA#65

If you are going to provide underlines, it would be ideal for users to have some control over not only the underlines, but also the line spacing.

If content is crowded with links, then line spacing needs to be increased to improve readability.

Also, the "built in" underlines in many font families are often less than idea, often too thick and too close to the glyphs.

All that said, having underlines selectively available is a good think.

At the moment, due to GitHub's poor color schemes, I find I always bold and italicize at least the important links, so they are visible and readable.

[GuySartorelli]

Yeah, totally agree on this. I turned the underline off because the spacing was too tight, which meant underlines were making it harder to read the content.

[Myndex]

@GuySartorelli

Yes exactly, you can't just add underlines without also adjusting leading (line spacing) and the offset of the underline itself.

Example, without underlined links:

p {
  font-size: 1rem;
  font-weight: normal;
  line-height: 1.3;
}

a:link {
 font-weight: bold;
 text-decoration: none; 
}

But with underlined links, especially a large density, more like:

p {
  font-size: 1rem;
  font-weight: normal;
  line-height: 1.55;
}

a:link {
  font-weight: normal;
  text-decoration-line: underline;
  text-decoration-thickness: 1px;
  text-underline-offset: 0.33em;
}

Keeping the underline thin, and offsetting it from the text slightly, improves readability.
But it is also necessarry to increase line spacing to reduce crowding.

[jfrost-mo]

Here are some other missing underlines I've seen.

Protip at bottom of pages:

About links at bottom of page:

Load hidden conversations:

View reviewed changes after approving a PR:

[jfrost-mo]

In fact none of the links in the merging box are underlined.

[dipree]

Most of them should be fixed now. Some aren't in a text block or already different in style and therefore not underlined. We'll be making this more consistent in the future though.

[jfrost-mo]

It is really inconsistent how the command line instructions are underlined, but the link to GitHub Desktop is not.

[adito4354]

Tautan harus mudah dibedakan dari teks di sekitarnya, tidak hanya berdasarkan warna tetapi juga gaya. Oleh karena itu, kami telah memperkenalkan pengaturan aksesibilitas baru untuk menggarisbawahi tautan dalam blok teks. Anda sekarang dapat mengalihkan pengaturan ini ke "tampilkan" atau "sembunyikan" garis bawah untuk tautan tersebut, memastikan visibilitas dan diferensiasi yang jelas.

Jika Anda menemukan tautan apa pun dalam blok teks yang tidak digarisbawahi meskipun pengaturannya diaktifkan, beri tahu kami di sini.

[ghostinhershell]

Thank you for providing a translation and making this accessible for our native Indonesian speakers @adito4354

[TokisanGames]

As an option, it's great. But the changed default is unattractive and should be opt-in. Documentation already has a lot of links and are already bright blue. The extra lines all over make pages too busy and harder to read. It should be off unless the user specifically desires it and changes the setting.

The recent change to make header links blue instead of black in my wiki is also unattractive and I've been wishing for a setting to control css or revert back.

This change has reduced readability of documentation as the eye is now much more distracted by links instead of content:

---

[TokisanGames]

I feel like a couple seconds worth of flipping the switch is a light cost to revert back to a well-known usability principle.

Just as easy for those who need it to turn it on. Seat up or seat down? Forced global utilization is not the well-known usability principle. Using it where needed is.

I also wonder if this change may, in the future, encourage folk to design with that default in mind

Yes, actually. The only reason I'm paying for github is to use the wiki. This is now the second global CSS change that has reduced readability and attractiveness in only a month or two. And the blue isn't even an attractive blue. It's almost the default 1995 web blue. So I'm much more inclined to move my wiki & documentation elsewhere to a site that has attractive design and stop paying github. @dipree

[nelsonaloysio]

The recent change to make header links blue instead of black in my wiki is also unattractive and I've been wishing for a setting to control css or revert back.

Regarding your wish, this workaround may be helpful. @TokisanGames

[joshkimux]

@ayuhito sorry for the delay on a reply friend 🌻

I want my documentation to be accessible and easy to read for everyone regardless of their chosen styling, but this change seems to have fragmented the community. What are your thoughts on this?

I agree with you here, and it's hard to have thoughts without fuller context to the team's decision making. Without knowing the context, I think the rollout of this could have been done more gracefully (and less suddenly) with community feedback. I understand why it feels fragmenting when it occurs out of the blue. I respect the community's thoughts here, and wish there could have been a softer way to introduce this as a default down the road.

I do think the majority of users prefer aesthetics over function which is why it is considered the default on most of the web. This is why I think it should be an opt-in feature due to majority preference.

I respect this thought, but I might add on to it by examining the notion of majorities vs. minorities. How do we measure if a majority prefers one or the other? How do we measure that in context to how the web has privileged people who haven't historically needed these features? How might that impact who is centered (and decentered) over time? Considering the larger context makes me feel that taking the time to undo a setting isn't too bad, especially considering how inequitable the rest of the web can be.

I actually would like tools to see how my content written looks in all sort of environments, e.g. with underlines and without so I can format it accordingly.

I love this, and agree with you whole-heartedly. Considering all those contexts will only help to inform decision making better 💙

But it already exists and may sometimes be necessary in some cases. Pushing the blame onto the userbase doesn't help if this is an existing precedent.

This is a fair point. I empathize with folk who were caught off guard by this. Again, I wonder if there are more graceful, softer ways to ease into a change in defaults (or if better solutions exist that meet the needs of both sides). I love some of the feedback that explores how to improve the readability of underlines without fully sacrificing it.

This is only going to fragment the community more in my opinion. Opinionated defaults lead to much less bikeshedding and complaints in the long run.

Agree, I tried to hint at that in my comment. There will be consequences that again, to your point, should be mapped out, considered, and planned for before a decision is made.

---

smol appreciation note, thanks for having dialogue with me 🌻

[rjgotten]

I respect this thought, but I might add on to it by examining the notion of majorities vs. minorities. How do we measure if a majority prefers one or the other? How do we measure that in context to how the web has privileged people who haven't historically needed these features?

You start by not conflating the issue of majority preference with the issue of privilege vis-a-vis needing or not needing certain features.
If you want to measure majority preference between an existing solution and a new solution, then you stick with the old solution and you notify users that they can, if they want, opt in to the new solution. If users feel the new solution may add value and they're interested- then they can enable it and try it out. And make a judgement to stick with it; or return to the old. So you measure how many users make the shift, and you measure how many of those make the shift back. And you judge from those two numbers.

You do not enable the new solution for everyone and inform them they can disable it again somewhere in their settings.
Because even if users do not prefer the new solution; they might still tolerate it just enough to stick with it and not bother changing it. Or maybe they missed the message about being able to change it back? Or maybe they reason that at some point the old way is going to go the way of the dinosaur anyway, so they might as well take their pain now and get used to the new way?

By making the act of choosing the new solution and the act of opting back out of the new solution BOTH a conscious choice on the part of the users, you eliminate these types of unknowns from the majority.

[Julian-Dumitrascu]

In this case it's not enough to press a button, so I write that I find such attitudes useful.
I am willing to build a dialogue with you and to help spread such practices.

[teabroker]

Accessibility should be adaptive and based on the client preferences. Now it ignores those who required lower contrast. To satisfy this requirement underlines should be less visible for clients with low contrast preferences and more visible to those who requires higher contrast.

Example:

a {
  text-decoration: underline;
  text-decoration-color: rgba(0, 0, 0, 0.35);

  @media (prefers-contrast: more) {
    & {  
      text-decoration-color: rgba(0, 0, 0, 1);
    }
  }

  @media (prefers-contrast: less) {
    & {
      text-decoration-color: rgba(0, 0, 0, 0.2);
    }
  }
}

[Myndex]

I require higher contrast. The only scheme here that is even remotely viewable for me is the high contrast dark mode.

But needing high contrast does not mean I want nor need underlines.

Underlines are not an accessibility feature, especially if done using the default much-too-close underline. Underlines cause crowding, clutter, and impact readability.

[JacksonChen666]

Does not respect browser preferences, though. So if the user disabled link underlines in their browser for some reason (not sure in Chromium based, search "Manage Colors" in settings for Firefox based), links will still be underlined on GitHub.

[rjgotten]

This is something of a shortcoming in CSS.
Disabling default underlines modifies the user agent base stylesheet to not have underlines on links / anchor elements anymore.

But there's no way currently to surface that preference to authors to apply to their authored sites' stylesheets.
You'd need something like prefers-underlines CSS media feature which would default be true but would become false where the user has configured their browser to disable the default underlines on anchors. (Actually; the user agent stylesheet itself could then also work via that media feature.)

[zeux]

Something that I would consider as a tweak to "enabled" setting, whether or not it's the default, is to distinguish between links that the author of the text intended to be a link, from links that GitHub automatically inserts, most notably @-names for user accounts (I'm not sure how #-links to issues should be treated).

While @-mention is indeed a link to the user's profile, and a reader may click it to see the background/repositories/contributions/etc. of the said user, the default intent isn't to click - it's merely to address the user. The downside of course is that underlines for the @-mentions break the visual flow of reading the regular text.

[MasterInQuestion]

    More practical proposed GFM (GitHub Flavored Markdown) change:
    https://github.com/orgs/community/discussions/68734#discussioncomment-7347910

[Myndex]

Hi @MasterInQuestion

I didn't see your earlier post before, thanks for pointing it out.

|*| `[Text] (URI)` (no underline)
|*| `[Text]_(URI)` (underline)

What is |*| ? a checkbox?

But otherwise I like this:

[Text]_(URI) (underline)
[Text] (URI) (no underline)

Seems much better than the *_link_* I was suggesting, though the space for explicit "no" feels uncomfortable... Playing on the idea, what about:

[Text]-(URI) or [Text]-[1] (no underline)
[Text]_(URI) or [Text]_[1] (underline)
[Text](URI) or [Text][1] (system/site/user default)

• Understanding:
  • The hyphen (-) explicitly removes (subtracts) underlines
  • The underscore (_) explicitly adds underlines
  • No white space ]( or ][ acts as it does now, following the system setting, and this should prevent any breakage...

[MasterInQuestion]

    “What is "|*|"? a checkbox?”
<^>    Much a bullet point, comparable to HTML "<ul>".
    As you noticed, I use a Plain Text interoperable scheme for writing.

    “The hyphen ("-") explicitly removes (subtracts) underlines”
<^>    Visually too similar to "_" (notably during scrolling) and perhaps suboptimal.

    [ Quote:
    No white space "](" [1]; or "][" acts as it does now: following the system setting.
    And this should prevent any breakage...
[1] No extension to the "](" type. ]
<^>    Probably introduces new breakage...
    Too risky, and conflicts established habits.

[Myndex]

a bullet point, comparable to HTML "

". As you noticed, I use a Plain Text interoperable scheme for writing.

But Github will parse * or - into actual bullets if you wanted...?

    “The hyphen ("-") ...Visually too similar to "_" (notably during scrolling) and perhaps suboptimal.

Yea, I thought about that... it's a common problem with a simicolon and colon... Here's a better:

[Text]^(URI) or [Text]^[1] (no underline)

  No extension to the "](" type. ] <^>    Probably introduces new breakage...     Too risky, and conflicts established habits.

I might not be explaining myself, the third type is identical to the current syntax, and as such it behaves no differently. So [Text](URI) is not replaced, just added to...

[MasterInQuestion]

    Plain Text interoperability matters more to me.
    And I'm actually trying to circumvent such over-interpretations of the system.

    "`[Text]^(URI)` or `[Text]^[URI]` (no underline)"
<^>    Looks a bit strange. And the "^" generally has special meaning.
    (e.g. "1,024^2", "2^( n - 1 )" alike)

    "I might not be explaining myself, ..."
<^>    I see.
    Exactly what I mean: "`[Text](URI)` is not replaced"
    .
    The risk is new syntax may cause unexpected change of old content.

[Myndex]

From a study:

Underlined links seem to substantially decrease the reading performance on Web pages and may add to the reasons why users don’t like to read on the Web.

The study:

Comparing Link Marker Visualization Techniques – Changes in Reading Behavior

Some studies indicate that underlines are okay for navigation sections, but bad for text blocks.

I lean very much on the side of "it's the users preference", and it is a preference that is case by case, use case related, and should not in any case be forced on users as a part of posturing  accessibility.

[MasterInQuestion]

    Not entirely personal, nor entirely true [1].

[ [1]
    "their whole premise was that hyperlinks should have a solid background instead of an underline" in particular.
    "No mention of accessibility anywhere in the paper." unsure.
    .
    Too hard to parse. I dislike PDF. ]

    ----

    I think the conclusion would be more related with writing habit, rather than actual underlining.

[paulshryock]

It does help to actually read the PDF and know what it says before sharing a cherry-picked quote.

[MasterInQuestion]

    Adequate amount of context analyzed: enough to prove the "hyperlinks should have a solid background instead of an underline" statement cherry-picked.
    The rest, I have no objection.

[paulshryock]

Out of the two studies, yes, the entire point of the first one was to compare a background color (referred to as an overlay) versus underlines.

[MasterInQuestion]

    Such may not be considered the "whole premise", and the conclusion was not found.

    "Translucent overlays did not only avoid the disadvantages of underlined links in our study, they also offer many advantages such as being more flexible, applicable to graphics and ready for future requirements like those that will be introduced by the W3C's XML linking standard and other rich hypermedia concepts." [1]
<.>    This statement may somewhat contribute to your conclusion, but not conclusive.

    "We believe that further research is needed in this area, as ..."
<.>    This is the conclusion.

[ [1]
    Translucent overlay, or background color indeed partly avoid the disadvantages of underlining.
    They seem to also introduce other problems:
    |1| Potentially impaired readability (poor contrast if inappropriate color) for highlighted texts. [2]
    |2| Over-contrast caused by highlighting. (potentially distracting) [2]
    |3| Block highlighting may conflict with the typical scheme used by Search, Selection alike.
    .
    And the claimed advantages seem invalid. ]

[2] Same problems with mere text coloring, with/without underlining.

[xamidi]

Achromatopsia frequency, according to various easily googleable sources, is around 1 in 30000. So this ugly 'feature' should really be disabled by default. People that need accessibility settings will look for it. Others will just assume that GitHub is getting uglier. And for all users that are not logged in, it is uglier when defaulted to underlines. Also it reduces readability as pointed out in another comment.

[xv]

This. I've seen README pages full of underlined links and it's a total eye-straining visual mess.

[Myndex]

Achromatopsia

Achromatopsia frequency,... is around 1 in 30000.

• Rod only achromatopsia is about 1 in 33,000 to 40,000 (rough estimate).
• Blue cone monochromacy is about 1 in 100,000. Much like rod only, but they have S cones as well.

In both cases they:

• Have severe photophobia
  • Must wear sunglasses or dark tinted contacts
  • (70% tint for one of our study subjects)
• Have low visual acuity
  • 20/100 (aka 6/30 or 2/10, or LogMAR 0.7 for one of our study subjects)
• See monochrome (true color blind)
  • Mostly capable of seeing the GREEN primary of a display, and
  • very limited perception of the red or blue primaries.
• Mode: dark was preferred.
  • Subject preferred black bg #000000, and
  • letters that were visible all had substantial green #00bb00
    • This makes sense as rods are mainly sensitive in the range we'd call teal.
  • Worse red perception than protanopia.

Due to the co-morbid conditions, they need assistive technologies, at a minimum very dark sunglasses, text must be large, and good luminance contrast (good luminance contrast requires much green, as green is the primary component of luminance.)

We have not tested with underlines, but I'd venture that if he prefered underlines it not due to color issues but due to the low vision issues.

On the color issues: in Dark mode, the pure blue that GitHub is using for links is utterly inaccessible. In his case, so dark it would not matter if there were an underline because it would not be perceived just as the text would not be readable.

In light mode, he'd "probably" want an underline because the blue and black would be difficult to distinguish.

Just to get an idea of what an achromatope sees, here is a plot of normalized rod (and cone) responses, The dotted teal curve is the rod response (sensitivity relative to spectrum).

As a result, even sRGB red is not seen at all. In the following charts, showing a dark mode and a light mode for standard vision (top) and rod only achromatopsia (bottom).

So a few things to point out here;

1. The low vision and photophobia is a significant part of this impairment.
   • The LowVis/Photophobia is more debilitating than the hue insensitivity.
   • The need for underlines is more related to this low vision component.
2. Notice the dark blue "3" of the top row of standard, and notice how it just vanishes?
   • The implication is that achromats need links NOT in blue, but JUST underlined.

I am going to repeat:

3. The BLUE Github is using for link COLOR is TOO DARK in dark mode.
4. WCAG 2.x can not be used to calculate dark mode.
   • That "link color triangle" isn't meaningful because the underlying assumptions are flawed.
   • APCA or Bridge PCA far exceed WCAG for dark mode (all modes actually, but that's another issue)
   • This is still a problem on GitHub for dark modes.
   • The only mode I personally can use here is Dark High Contrast, as it's the "not as bad as the others" choice.

Over Kill Bill

Let's examine some thinking here and illuminate some considerations regarding links.

CONSIDER:

Right now for regular dark mode, there is white non-link text and dark blue link text, and with underline this means that from the normal text to the link text you have:

Markings in Dark Mode

a) LUV saturation from near null 0.09 way up to 1.97 (chroma 8 to 108)
b) Near null hue from #e3edf3 to the dark blue #3181f7 (hue 255°)
c) CIE Lightness L* 93 down to an L* of 55
d) Luminance 84 Y down to 23 Y
e) Against a #131723 BG, perceptually uniform contrast is $Lc\ -94$ (too high¹) down to below fluent-text cut-off at $Lc\ -36$
f) The WCAG2 is 15:1 to 4.77:1 (non-uniform and therefore lacking meaning²)
g) An underline is added.
h) Bonus: in my Github documents, I often make links bold, or italic, or bold & italic.
i) Double bonus round: other ways are with a "reference icon" like wikipedia, or ref number, or using a different font family for the link text, or changing the letter aspect ratio or spacing, changing shadow, changing/adding a color overlay, or alternate bg etc.

The Objective:

To differentiate the link text from the non-link text, with minimal interfereance to other tasks.

This is actually a pretty low bar. Even significant impairments exhibit significant sensitivity to and ability to discriminate small variations in adjacent elements. This is different than the contrast level needed for reading, and letter and word recognition in the VWFA/lexical processing³.

Looking at the above list, except ignore (i) to keep it simple.

1. ab — a strong color difference from desaturated to saturated blue.
2. cdef — a very big change in lightness, luminance, or lightness/luminance contrast.
3. g — an underline of some sort.
4. h — bolding/italicizing the link text (all of which affect visual contrast)

That is four distinctly different things. Do we need all four? No, of course not. Do we need three? Also no, yet when you turn on underlines here, you are getting the first three. All three of 'em.

The more things you have in a layout, the more cluttered the layout becomes. Link marking and readability need to be balanced for the given use case and intended purpose. The prominence needed for signaling any given link is an important design choice. And it is a design choice for the author to consider, as part of creating the visual hierarchy for guiding the user through the given content. Blanket "let's stick underlines because retro" is not per se accessible.

---

Summary

This entire thread has been very useful reading. In particular, responding to this thread has helped to exercise and focus my own thoughts on the matter.

It also caused me to examine critically some of the things GitHub is doing in the name of accessibility. I have concerns, some of which I presented earlier. But it is clear that GitHub is genuinely working to improve accessibility.

But how to do so in a field that is still young and emerging, with continuing research? While some lay persons might lazily point at WCAG and say "use that", WCAG does not adequately promote actual accessibility. It is a low-bar minimum, much like a safety net. Considering the work GitHub has done thus far toward building an accessible UI, I'd like to extend an offer of a zoom call with the relevant interested parties (no fee) to discuss some of the current science and developing guidance, including ways to exceed WCAG 2.x and promote visual accessibility for all.

Thank you for reading,

Andy

Andrew Somers
_{Director of Research}
^{Inclusive Reading Technologies, Inc.}
_{W3C WAI AGWG Invited Expert}
^{WCAG 3 and Low Vision Task Force}

Footnotes
¹ _{We are evaluating dark mode maximum contrasts, with $Lc\ -90$ for small text, $Lc\ -85$ for medium and $Lc\ -75$ for >36px bold.
      We do not find a max contrast for light mode on SDR displays, though we are working on max luminance for some scenarios.}
² _{WCAG 2 substantially overstates contrast with dark colors, in this case the blue 4.77 is overstated at over 200% .}
³ _{Despite WCAG2 slapping the ol' 3:1 on whatever SC is tangentially related to vision, 3:1 is not well supported by science,
      particularly for high spatial resolution elements like small text and thin lines.}

[MasterInQuestion]

    Informative, but a bit of... lost?
    Better summary perhaps?

    Thanks for the effort anyway.

    ----

    Quick Summary:
    |1| [
    The colorization for links is problematic under certain themes: suboptimal color used, Dark Mode notably.
    Reportedly even unreadable with underline..?
    More info: https://github.com/orgs/community/discussions/68734#discussioncomment-7332612 ]
    .
    |2| Colorization with underlining may cause over-contrast thus distracting. [1]
    |3| How to improve the accessibility of things overall, generally? [2]

[ [1]
    The real issue is probably not over-contrast, but that underlining itself actually decreases readability (by the interference) thus must be used with caution in order to improve readability (via the contrast):
    [ E.g. https://github.com/MasterInQuestion/Honorificabilitudinitatibus#index ]
    The very reason we don't see underlining on this page's navigation panel, and clickable text description of buttons. (sheer meaningless and counter-productive) ]

[ [2]
    For the record, I also have various accessibility feedback (on various aspects) posted before:
    https://github.com/orgs/community/discussions?discussions_q=involves:MasterInQuestion
    .
    Significant portion of them matters much more than the "petty" underline issue.
    GitHub seems to just politely archived them without any follow-up... ]

[Myndex]

Hi @MasterInQuestion

Informative, but a bit of... lost? Better summary perhaps?

While I do joke about my apparent prolixity, the fact is (and for those of you following along at home, please note), this is part of my process. The "boiling down" and eventual distilling things to the irreducible minima happens later.

My present work is being conducted in the open, and therefore as a matter of "open and live working notes," I am aware it may garner some criticism or questioning from time to time.

Thank you for reading.

[MasterInQuestion]

    Apparently alright.
    Though I don't tend to post draft outright.

[alexwlchan]

Not a link without styles, but I did spot some inconsistent link styles at the bottom of an issue:

Here's the relevant bits of HTML:

<div data-view-component="true" class="text-small color-fg-muted mt-3 mt-md-2 mb-2">
  <svg aria-hidden="true" …>
  Remember, contributions to this repository should follow its
  <a style="text-decoration: underline" class="Link--inTextBlock" href="/urllib3/urllib3/blob/f7cd7f3f632cf5224f627536f02c2abf7e4146d1/docs/contributing.rst">contributing guidelines</a>,
  <a style="text-decoration: underline" styleclass="Link--inTextBlock" href="/urllib3/urllib3/blob/f7cd7f3f632cf5224f627536f02c2abf7e4146d1/.github/SECURITY.md">security policy</a>, and
  <a style="text-decoration: underline" class="Link--inTextBlock" href="/urllib3/urllib3/blob/f7cd7f3f632cf5224f627536f02c2abf7e4146d1/CODE_OF_CONDUCT.md">code of conduct</a>.
</div>

Notice that links #​1 and #​3 have a class="Link--inTextBlock attribute, but link #​2 has a styleclass="Link--inTextBlock" attribute.

[franckDev21]

Okay !

[whisperity]

On pull request pages (right now I found it on llvm/llvm-project#71912) when having my profile set to "no underlines", some of the links are still underlined. All blue things otherwise are appropriately links.

[AlexanderYastrebov]

Autolinked labels are underscored which is not consistent with label rendering in other parts of the page

[Ahmedalrabahi]

تم اغلاق حسابي عن طريق الخطأ الرجاء إعادة النظر لتنشيط الحساب الموقوف وشكرا في الأربعاء، ٦ ديسمبر ٢٠٢٣, ٢:٤٨ ص Alexander Yastrebov < ***@***.***> كتب:

…

Autolinked labels <https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls#labels> are underscored which is not consistent with label rendering in other parts of the page Screenshot.from.2023-12-06.00-45-52.png (view on web) <https://github.com/community/community/assets/697976/b4bdf441-d5f7-4557-94e7-35f94f8ae949> — Reply to this email directly, view it on GitHub <#68734 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDF46LB3QVCQZXIN3WULWV3YH6XF5AVCNFSM6AAAAAA5ME4RJOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TONZQGA3TG> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[ghostinhershell]

Hi @Ahmedalrabahi , thanks for participating!

We take our Code of Conduct very seriously and want to help ensure that everyone has a good experience free of antagonism and harassment. Unfortunately, we don’t currently have moderators for languages other than English. Until that changes, we need to ask that everyone use English here in the GitHub Community when posting.

[Myndex]

FWIW it translates to:

My account was closed by mistake. Please reconsider to activate the suspended account. Thank you

On Wednesday, December 6, 2023, 2:48 AM Alexander Yastrebov <
@.***> wrote:

[edamamez]

Links on Github pages aren't underlined

Hello, when I put a link in markdown for a github page, e.g. [https://github.com](https://github.com), it only shows up as a different color (blue). Is it possible to have these links underlined? I tried adding <ins> tags and that did not work either.

[Marcono1234]

Would be useful to underline (or otherwise highlight) <details> ... </details> blocks in Markdown as well. They are quite useful to collapse additional verbose data by default, but users not familiar with them might not be aware that you can expand them.

Here is an example:

You can click me

some additional verbose information

For reference, here is how this is currently displayed (screenshot):

There is no indication at all that you can click it; you might just assume it is regular text with some uncommon looking bullet point.

[xamidi]

Would be better to use <u> and </u> to underline, and leave those alone who do not wish their README's to look like crap. Including for hyperlinks. Leave accessibility (and if/how they prefer to carry it out) to the actual owners of projects.

[gmifflen]

An underline appears on the whitespace that follows an <img /> tag and its surrounding </a> tags.
It can be reproduced with the following md/HTML snippet:

Click to show code

<a href="https://www.java.com">
  <img src="https://raw.githubusercontent.com/devicons/../../../java/java-original.svg"/>
</a>
<a href="https://www.rust-lang.org">
  <img src="https://raw.githubusercontent.com/devicons/../../../rust/rust-original.svg"/>
</a>

---

A workaround can be done by removing any whitespace between the and the tags, but it hurts readability(and my soul) to format HTML this:

Click to show code

<a href="https://www.java.com" target="_blank" rel="noreferrer">
  <img src="https://raw.githubusercontent.com/devicons/../../../java/java-original.svg"
/></a>
<a href="https://www.rust-lang.org" target="_blank" rel="noreferrer">
  <img src="https://raw.githubusercontent.com/devicons/../../../rust/rust-original.svg"
/></a>

---

It seems to be that the whitespace -- in this case the \n and 4   -- within the <a></a> tags is being targeted by CSS for text content, resulting in an underline.

While this may be an intended feature, I find it annoying enough to write this post about it.

---

The workaround looks even worse in my use case since I have the <img> tag wrapped in a <code></code> tags for a faux drop-shadow:

Click to show code

<a href="https://www.java.com" target="_blank" rel="noreferrer">
  <code><img
           src="https://raw.githubusercontent.com/devicons/../../../java/java-original.svg"
           alt="java"
           height="40"
  /></code
></a>
<a href="https://www.rust-lang.org" target="_blank" rel="noreferrer">
  <code><img 
           src="https://raw.githubusercontent.com/devicons/../../../rust/rust-original.svg" 
           alt="rust"
           height="40" 
  /></code
></a>

---

Sorry for the long post, have a cookie :)

Click for cookie

_{^{Thanks to @Marcono1234 for mentioning the <details> tag in their post; I didn't know it was a thing.}}

[bartandrews]

As mentioned in this thread https://github.com/orgs/community/discussions/113792 , the contents of code blocks are being incorrectly underlined in rst files. For example, my bibtex code block has recently lost all syntax highlighting and is now underlined: https://github.com/HofstadterTools/HofstadterTools?tab=readme-ov-file#how-to-cite A fix would be much appreciated 🙏

[v0lta]

Yes, I am observing the same problem in my RST files.

[KSR-Yasuda]

Aren't there some code blocks whole underlined?

Likely to see this for syntax highlighted blocks in .rst files.

[WaterSwallow]

Links should be easily distinguishable from surrounding text, not solely by color but also by styling. Thus, we've introduced a new accessibility setting to underline links within text blocks. You can now toggle this setting to either "show" or "hide" underlines for such links, ensuring clear visibility and differentiation. Per default, the setting is set to underline!

If you come across any links within text blocks that aren't underlined even when the setting is enabled, please let us know here.

This is indeed a great move towards improving accessibility on the platform. Making links easily distinguishable not only by color but also by styling can greatly enhance the user experience, especially for visually impaired users. The decision to underline links within text blocks by default is particularly commendable as this would significantly boost readability and navigation.

The introduction of a toggle feature to 'show' or 'hide' underlines provides users with greater control over their visual experience on the platform. This allows for a more personalized, user-friendly interface that caters to individual preferences.

On the off chance that users encounter links which aren't underlined despite the setting being enabled, it's a good call to action to urge them to report it. This can help the team in promptly addressing such oversights, further enhancing the platform's accessibility.

It's clear that these steps exhibit GitHub's commitment towards fostering inclusivity and it's heartening to see the efforts being put in to ensure that the platform is accessible to all users.

[MasterInQuestion]

https://github.com/orgs/community/discussions/68734#discussioncomment-7487371