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!

Sometimes the old ways are the best.

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.

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

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.

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

Sure! Here's an example.

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

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.

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.

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.

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).

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.

Hover, please. Please! 🙏

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?

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

Headings aren't underlined any longer.

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?

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. */
}

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...

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.

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.

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.

@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.

@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?

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.

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.

@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.

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

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.

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

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

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

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

@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 🌻

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.

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.

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.

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.)

Well, I am stating those pesky facts and science....

1.4.3 was a typo; I was referring to 1.4.1. Should have said 1.4.x. Overall point was that WCAG is the reference. Not my personal opinion.

I understand the difference between hue and lightness. Contrast between text (hyperlink or otherwise) needs a minimum contrast with the background color. Obviously, if that is not met, that should be fixed.

That doesn't take away from the fact that color shouldn't be the only means of differentiating hyperlinks, according to the WCAG.

We disagree, and that's fine. I think we both want to learn and grow as engineers, and both want to do what's right for users.

I'm glad to see a small step forward toward a more accessible GitHub UI. Hopefully, we'll see many more steps in that direction, including better color contrast (in lightness, not just hue).

...color shouldn't be the only means of differentiating hyperlinks, according to the WCAG....

The actual SC is:

• ...Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

WCAG is very clear defining color as in hue and saturation as separate from luminance or lightness (contrasts) in the understanding document which continues with:

• ...If content is conveyed through the use of colors that differ not only in their hue, but that also have a significant difference in lightness, then this counts as an additional visual distinction...

In light mode, text should be black. This also means that making a link literally any saturated color will by default also make the link lighter. Color + lightness difference = two things, and the SC is satisfied. (It states 3:1 for contrast which may be insufficient, or may be more than enough, but that's a separate matter).

Going back to your original statement, you said:

...Hyperlink text should have appropriate color contrast and color should not be the only visual means of distinguishing it from other text....

And I have just shown you that your statement is incorrect in the face of what WCAG actually states.

...That's why underlined hyperlinks are good...

Logical fallacy reciting facts not in evidence, and a non sequitur. WCAG makes no statements that any particular identifier is better than another, saying:

• ...Check that each link in the page that is identifiable by color (hue) is visually identifiable via some other means (e.g., underlined, bolded, italicized, sufficient difference in lightness, etc).

That being one of the rare times underlines are even mentioned.

...They are also a well-established convention with decades of precedent....

You mean from back in 1989 when people were still using matrix text monochrome displays? That's hardly relevant. The WWW wasn't really a "thing" to the public till 1997 to 2000 ish. So in the distant past there was a decade and a half. Google dropped underlines in 2014, so now we've had about a decade of "occasionally-established non-convention" with a number of other options and methods.

Moreover, peer reviewed research shows that underlines are not always the best solution here, as they cause other functional problems. Best practice is a case-by-case basis, related to use cases and intent, and underlines should not in any case be slapped on everything across the board.

...We disagree, and that's fine...

If it's an opinion of mine, sure, I recognize that sort of disagreement. But the parts I am talking about are verifiable facts in terms of how WCAG2 is actually written. It is a public document anyone can read.

And I'm not saying I always agree with WCAG either: I've been on record since April 2019 about how WCAG 2 is deficient in areas such as contrast, and I am on the teams that are working to change these problems.

TLDR

But my underlying point is there is much too much of people "reading into WCAG what they want to see" and this leads to further misunderstandings, misunderstandings cause distrust, and distrust hurts accessibility overall.

Thank you for reading.

    Too Long is typically not the reason that caused Didn't Read:
    Poor hierarchy and arrangement (therefore bad segmentation and problematic parsing) are.

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

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...

    “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.

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...

    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.

    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.

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

    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.

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.

    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.

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

    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... ]

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.

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

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.

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:

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.