Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Links (as part of regular text) not distinguishable enough #15304

Closed
patrickhlauke opened this issue Dec 5, 2014 · 17 comments · Fixed by #30389
Closed

Links (as part of regular text) not distinguishable enough #15304

patrickhlauke opened this issue Dec 5, 2014 · 17 comments · Fixed by #30389
Assignees
Projects

Comments

@patrickhlauke
Copy link
Member

For aesthetic reasons, by default Bootstrap links have no underlines, relying instead just on a color difference from surrounding text.

This in itself violates WCAG 2.0 "1.4.1 Use of color" http://www.w3.org/TR/WCAG20/#visual-audio-contrast-without-color

There is a technique suggesting that sufficient difference in color contrast/luminance may be enough in certain conditions, but having some additional cue is preferred http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/G183

There are also situations where links are even less distinguishable.

bootlink2

http://getbootstrap.com/components/#alerts-links - link is of course distinguishable from surrounding text, but the difference between the actionable link and the bold text at the start of the alert ("Well done!" etc) is again only down to a subtle variation in color ... this is confusing for users, as it's not immediately clear what is and isn't a link.

bootlink3

http://getbootstrap.com/components/#navbar-links No distinction at all between inert text and link, unless the user goes on a "let me just hover my mouse over every word" pixel hunt. All sighted users are affected by this (though at least keyboard users will more readily discover these links by virtue of tabbing onto them).

In short: I propose that by default, links should ideally have some subtle additional indication that they're links. Of course, for links in navigation bars etc, this does not apply...the context there is clear enough ("this is a series of actionable things"). But particularly for links that are just part of regular text, we should really do something.

Failing that, this needs to be noted in our accessibility guidance.

/cc @cvrebert

@patrickhlauke
Copy link
Member Author

btw, i'll add here that i'm aware that any change to the default link styling could be seen as breaking backwards compatibility. a risk to weigh up against the out-of-the-box inaccessible experience that a lack of clear links causes...

@cvrebert cvrebert added the css label Dec 5, 2014
@zacechola
Copy link

Re. backwards compat, I can see how some users might take issue with changes, but I think it's pretty draconian to disallow that sort of change. Minor aesthetic changes happen all the time; this is no different. The original text/background contrast has been changed since 3.0.0, for example.

As far as I understand it, this is the test failure:

Check that the relative luminance of the color of the text differs from the relative luminance of the surrounding text by a contrast ratio of at least 3:1.

Of your two examples, the .navbar-link and .navbar-text is the more egregious violation because they are the exact same color. The problem here is that there are no grey variables available that have a 3:1 contrast ratio to #777, other than #000. We have to maintain the text to background ratios as well as the ratio of text surrounding links.

The contrast also fails in alerts, too. The bolded text is technically the same color as the non-bolded text, and thus fails the relative luminance test. Like in the navbar, we also have to worry about the background here as well.

Now, I believe more in practicality than following the notes in the test procedure perfectly, so I think adding a subtle underline to .navbar-link and .alert-link in their default state makes sense and is relatively isolated. A redundant visual cue is useful in these two cases.

@carasmo
Copy link

carasmo commented Dec 5, 2014

+1 I have a deep dislike to not having underlines on links where they are not clearly links.

I find myself adding underlines or globally adding them and then selectively removing them. Right now, I'm using a class "link-underline". Since you have to add a class to alert links anyway -- btw, this is not in the docs -- then I add two "link-underline alert-link".

If the framwork were to add underline as the default link style, it wouldn't be a significant impact to remove them on certain components, such as nav, list-groups, labels, etc. and since they are removed on the components appropriately, the underlined links in body text, alerts, etc., would not break backward compatibility.

@mdo
Copy link
Member

mdo commented Dec 5, 2014

I'm down to restore them I think, especially in v4.

@patrickhlauke If you're willing to explore a PR for it, I'd like to see just how much we'd have to override once more to make this happen. I'm guessing not too much—given we have base classes for buttons, navs, etc—but I'd like a ballpark on the impact.

@carasmo
Copy link

carasmo commented Dec 5, 2014

Here's a kitchen sink (https://jsbin.com/hisah/1/edit?html,css,js,output) of sorts where I have added links and removed them selectively. I don't have much time now, but I can see that the a.list-group-item looks bad with underline but when used without, there's no way of telling upon a glance that there is a link, which is worse, but still it looks shitty so I use :after to add an icon.

Using a "light" underline is not a good plan on the navbar-nav as that light underline is a border and that, because of the padding, will not appear in the correct place.

@carasmo
Copy link

carasmo commented Dec 5, 2014

Updated .btn-link should have underline. https://jsbin.com/hisah/2/edit

@patrickhlauke
Copy link
Member Author

@mdo will do, boss :)

@carasmo thanks for making a start with that kitchen sink. personally, i think the "list groups" ones are ok without additional indication, provided that the text/context that they're being used is clear (same reason that for, say, nav pills it's not necessary to provide extra visual hints that they're links, as it's clear/inferred from how they're used). i may still explore some possibilities, though.

@zacechola beyond the two explicit examples, i was also after the "main" links in general page content, which are just blue with no underline. that's probably the one change that would be most impactful...but then, if authors upgrade to v4 and don't like it, they can easily override the underline i guess.

The bolded text is technically the same color as the non-bolded text, and thus fails the relative luminance test

but, as long as nothing else is bold (which is the problem with having the "Well done!" etc bits), it would be sufficient indication that that text is different from the static text around it (though yes, having an extra underline would be better/clearer).

anyway, i'll see what i can do in the next few days.

@carasmo
Copy link

carasmo commented Dec 6, 2014

Cool. I just want main body text links, for the the most part, to be underlined, color alone doesn't do it for me and bold doesn't either. I agree on the other points, that was a quick example.

@patrickhlauke
Copy link
Member Author

I may have missed a few edge cases, but this #15316 seems mostly complete to me (for the specific scope I had in mind, mainly reintroducing link underlines for main body and a few extra cases).

bs-link1

bs-link2

bs-link3

@patrickhlauke
Copy link
Member Author

@mdo once we stop suppressing the underline for basic a elements, there's actually little need to add extra overrides etc. in fact i'd say this even simplifies some of the less files a bit.

@saas786
Copy link
Contributor

saas786 commented Dec 17, 2014

@patrickhlauke @carasmo @mdo

+1

I myself would like to see some more significant indication of links in header (navbar-link), or in body, or in footer (links inside text like copyright etc etc).

And like you are suggesting for alerts etc, I would like to do it as well.

But,

I am working on new project, and this thing is bothering me as well, as I myself wanted to have same distinction for links on different areas of page.

So I started reviewing top brands (Dell, Intel, Microsoft, Macdonald and so on, about top 50 brands), and also I reviewed top themes on few market places and I was disappointed to see that none of them have some standard pattern in such regard.

But I found few sites, which has done it with some quality, but they didn't underlined any links by default, but instead on hover for all links excluding nav / navigation / menu links.

And they distinguish the links by using different colors for default text & links but I didn't saw contrast in them as of 3:1 ration, but it hinted the difference somewhat.

I would like to review your solutions in this regard.

@mdo I sent you a PM on twitter few days ago but haven't heard back yet. I am eager to review the v4.0, so I can contribute or learn which way Bootstrap is going in near future and plan my projects on same terms.

@carasmo
Copy link

carasmo commented Dec 20, 2014

In all articles, my links have underlines and in the navigation and places where it's evident by the text I don't use it unless it's not really clear. When the type is too thin and there's a color, it's particularly hard to tell. Links should have the ability to have some better looking styles besides having to use borders or dots or something more elegant.

@mdo
Copy link
Member

mdo commented Dec 21, 2014

Per #15316, we're punting this to v4.

@saas786 There's nothing to share publicly yet. You'll get the alpha the same time as everyone else ;).

@mdo mdo closed this as completed Dec 21, 2014
@saas786
Copy link
Contributor

saas786 commented Dec 24, 2014

@mdo Thanks. Hopefully soon I see the alpha release 👍

@xi
Copy link
Contributor

xi commented Jun 1, 2018

Somehow this never landed in v4, Can this issue be reopend or should I file a new one?

@patrickhlauke
Copy link
Member Author

oh, well spotted @xi ... forgot all about this. will see if i can re-PR for v4

@mdo
Copy link
Member

mdo commented Mar 12, 2020

See #30389 :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
v5
  
Shipped
Development

Successfully merging a pull request may close this issue.

9 participants