Links should not be indicated by color only

Setting to needs work because there can be other than just nodes in region-content, thinking this should be set on .region-content rather than node.

Ehh don't we do this in Garland too? Color blind isnt just about the underline, its about ratio's ect t and I am sure work was done on that field.

Checked with Garland, we didn't do it there either. Since the accessibility people never rigorously complained about this one I am going to mark it a feature request. The ratio in terms of contrast. Either way, Bartik was reviewed for accessibility and approved - this is a big visual change very late in the gate? I would say, no.

Fail to see how this is a standard we must meet, millions of sites who are also big on accessibility don't implement this. Including the dutch government :)

@Bojhan

I don't think this is a feature request. It is either a valid or invalid bug report. If Garland has this same issue it is potentially a bug there too.

Can someone explain to me the stylistic differences between the links and plain text?

Stylistically they differ only in color.

From a strictly accessibility perspective, yes this is a bug. From a design perspective this could be a bug also - because in these recolor-able themes its entirely possible to change the color of text and links - so they could be the same, or have insufficient color difference to be discernible even for people withe normal vision. Clearly there is some responsibility born by the site builder to not do this. That said, someone with a color vision impairment might change the colors so the vast majority cannot tell the difference - possible? I am not sure.

I realize this is a very contentious issue, however pushed to make a call on this, yes I think this is a bug.

One final note is, that I have been aware of this issue for a long time, like many others no doubt, and I am guilty of letting it slip under the radar. Sometimes when you just posted 10 other issues, written 8 patches, reviewed 6 others and so on you forget to tackle the most obvious things.

drupal.org is using colors too for links...
So drupal.org and redesign.drupal.org are all using buggy themes?

Agree with the WebAIM article mentioned by @BarisW in #9

@aspilicious

There are a number of significant accessibility issues with Drupal.org and Redesign.drupal.org

Actually, look closer - d.o uses color + bold, the redesign I can't remember.

redesign uses underline while hovering. I like that more than permanent underlining.

@aspilicious

Only using underlining of links on hover:active:focus * may * add to the visual appeal of a page, but it detracts from the overall usability, particularly for users who find it difficult to perceive the links without the underline, or other significant style difference from standard text.

Making links bold (without underline) may improve perceivability for some users. But I recall when I had low vision, not being able to always clearly distinguish bold font from standard font, and attempting to do so would cause strain.

Please note that this is a bug and therefor every attempt should be made to fix it - its a clear failure of WCAG 2.0 level A - http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F73#F73-examples

Setting priority to Major (although I'd argue that any WCAG 2.0 priority A violation is critical).

This only affects links in #block-system-main by adding underlines by default.

This is very simple but needs someone to go through and dig out if there are more instances where we want to remove underlines - I have taken them away from node teaser headings because they are not really needed (compromise) since we have the read more link that is underlined.

Set to major, cross posted with Everett.

I do not get how, it was never an issue before and now suddenly is? Anyway, goodluck making Bartik look like http://www.webrichtlijnen.nl if that is what we want. Don't see how almost every single big site, even ones big on accessibility violate this rule, consider me not convinced.

Anyway I am totally not digging the process of making large visual changes, with 1. no visual designer present, 2. always binary decisions on accessibility, 3. always after the fact (after the design been made) - we seriously need to reconsider our process here, because otherwise you will leave all visual designers very frustrated.

@!bojhan

It is not that this issue wasn't a problem and now suddenly is. It is that we noticed the problem now.

What are you not convinced of, that users with low vision will have difficulty using themes where links do not have a strong enough visual affordance? This would seem to be a rather arbitrary dismissal of the WCAG 2.0 guidelines. I would ask if you have a stronger rationale than simply not liking the idea?

Look, I get that some users might have trouble - my point being, that your process is incredibly frustrating.I find it hard to believe that so many sites that are big on accessibility would break this rule, consider me sold when you explain to me why they don't and we should break this rule? Par example, http://www.bbc.co.uk ?

I don't feel its an arbitrary dismissal at all, after all I don't have a guideline helping me on argumentation why a certain change will make Drupal less beautiful making it an incredible harder thing to argument, but nonetheless equally important. Saying that my argument is about simply not liking it, implies just that misunderstanding of my arguments in the larger sense. This will create a big usability issue, because underlines create a big visual distraction if placed close to each other, as you can see in some of the screenshots - drawing unnecessary attention in the case of dozens of links on a page. Underlines might have been the only affordance in 2001 for indicating a link, most users now do not see it as the only affordance.

Anyway I think its a key design aspect of the Bartik, that we don't have underlines, it was a conscious design decision - I will leave it up to jensimmons to comment, if she thinks its fine - lets move it in.

This isn't going to fly, IMO. We're *well* past UX freeze (hopefully within a few weeks of actual release), and this very dramatically changes the look and feel of our default core theme months after it's gone in.

There are multiple alternative themes in contrib that do use underlines on links if someone with low vision needs them, as well as the "Skip to navigation" link that can get low-vision users to the themes page to enable them.

@WebChick

I can agree that this won't be fixed in D7, but it needs to be called a bug, or we need to redefine Core theme requirements to permit that links be non conforming to WCAG 2.0. Either way I can live with, but let's have a policy and then conform to it.

For D7 can we at least add underline to links on :hover :active and :focus? At least this way if a user thinks a segment of text might be a link they can hover or focus on the link and have a stronger visual affordance revealed.

I'll try to catch up with Jen today at DC and raise this with her - Bojhan is right that we need her input, however this is bug and like I said earlier, a highly contentious one. In my experience Jen has been incredibly supportive of the accessibility requirements and changes we have already made to Bartik - and certainly a Leval A failure is going to need a solution - so lets work for that and not argue about process or timing.

< begin rant > We have been vested with the goal of WCAG 2.0 compliance for D7 - or as close to it as possible. This is not easy in a project that is in constant development, where at every turn either a developer or a designer is crying foul of the recommendations or requirements, where critical issues are blocked based on opinion, where the same old same old arguments are raised as proof this or that standard can be ignored - for example that "this site" is not doing this so why should we - do you not realize how often that tired old line is dragged out in defense of poor accessibility. Let me say this once and hear it - other sites poor accessibility is not a mandate for us to do the same! We either lead or follow - I prefer to lead.

Now, can we please get back on topic! This is not the place to be discussing process or protocols. That is another issue entirely and one we will certainly be addressing in due course. < end rant >

cross post

#27 is a possibility, if it passes design review. That seems like it would allow for accessibility without dramatically affecting the design.

And Everett, would you like to take the lead in establishing a policy, both for core and contrib modules as part of the #D7AX movement? That sounds like it would be valuable.

@WebChick

I would say that the option in #27 does not solve the accessibility issue, but it is a better solution than the current style.

As for a policy, I would say that absolute compliance with WCAG 2.0 priority A and absolute compliance with priority AA unless technically impossible or impractical (performance, etc.).

@Jeff On your rant, I think this is a highly debatable issue - hence my question why we should oblige to this standard. Anyways lets have that discussion elsewhere indeed.

I would say :hover and :focus et al, we can lets get a patch up that does that.

Drupal is not a final product. It is not a website. It is a tool to create websites, with any desirable styling.
I doubt it is a D7/D8/D9/... material. It has nothing to do with Bartik or bugs.
Anyway, one can always try to make a stand-alone "accessibility" theme, which could be included as one of the core/contrib themes. Though we already have such a theme - Stark, with all the default w3c behavior.

@BarisW The new site isn't :) you are right, the current one is. I knew you wanted to pitch that though :P. Your argument on the BBC site is true, then again I doubt you assume that I missed that, its the inconsistency in them applying that I am referring to.

So yhea, lets get a patch up please! For #27

Can we get screenshots?

You can totally screenshot mouseover links :)

Do we need a separate issue for Garland to provide some consistency?

I am gonna mark this RTBC, jensimmons could probably come in later if I am totally wrong :)

Its good, think Jen should have a look to see what she says about the issue before this is committed.

Committed to CVS HEAD.

Its a difficult issue because the Bartik design does not "work" with the visual distraction of underlines (or bold for that matter). Bartik is meant to be a very clean, simple design and such changes certainly distract from that goal - in fact it does look rather ugly and to accommodate such a change really entails a redesign - sorry but I'm not really sure I can back that, nor do I really want to suddenly change the design now we have shipped (in such drastic ways).

I'm not sure we'll ever reach a compromise that's acceptable to everyone. We reached something of a compromise and I think that's about all we're going to get on this issue.

Yes, the @webaxe arguments definitely make sense to me as I read them earlier this week (original article) http://www.webaxe.org/keep-the-underline-text-links/

I wonder if it's possible to do something now with the hover & focus elements?

Jeff, would a color background or dotted/dashed line be easier to incorporate?

I don't know if it has to be a traditional link.

This is not subject to feature freeze.

Actually can we control the height between the text and the underline?

#56: 890362-56-underline-links-bartik.patch queued for re-testing.

There are a few ways to do it:

http://alistapart.com/article/customunderlines
http://stackoverflow.com/questions/1734618/css-underline-possible-to-inc...

@Bojhan let us know what you'd like. We can even play with something on http://jsfiddle.net/ to get the right mix if that helps.

Animated underlines, hah.

I think this works, we just need to find styling that blends well, sadly I am not in a position to do this atm. Perhaps others can try some different approaches (e.g. more vertical padding, different colors, etc.).

Ok, here's an initial crack at this. There are definitely faster ways to do this, but why not bring in thousands of lines of CSS to be there in case we wanted to test different Drupal-like situations.

Please fork:
http://jsfiddle.net/mgifford/pwj2q/

Adding link to meta #2034915: [meta] Track progress in WCAG 2.0 conformance

#56: 890362-56-underline-links-bartik.patch queued for re-testing.

#56: 890362-56-underline-links-bartik.patch queued for re-testing.

I'm going to mark this RTBC. This is a big accessibility/usability win.

There are more options for look/feel than proposed in #62, even more in #1993574: Add focus styling to all interactive elements but this is pretty modest so probably the right place to start.

Meh, there is no tweak it later.

Why are we doing this so inconsistently - I see a whole group of elements this isn't applied to. I see no big usability win.

No, but atleast we should be doing something for the other elements that we are only using color on too.

Yup, lets discuss! I understand your point now, its a bit hard to track this issue.

tagging

Added an issue summary.

This looks good :) I'd consider this RTBC, it does raise the criticality of the other issue somewhat, because when we push this in the sidebar kinda looks ugly.

The question that appears first - aren't the "My Account" and "Logout" not links? (at the very top).

yes they are, and I believe they should also be patched

This is a big step for accessibility. Woo Hoo!

The patch in #76 looks good, but it's only for the Bartik theme. What about Seven?

Yes.

The patch in #76 is RTBC.

https://drupal.org/files/after_117.png

Hm. Really? Why are some links underlined (the ones in the sidebar and body) but not others (the ones in the header). This creates a really inconsistent experience.

https://drupal.org/node/890362#comment-7909999

@webchick From my understanding is this universally applied. See the W3C.org website, when links are obviously links (like menu items) they don't have an underline. When this isn't clear it is underlined. We have things underlined in the block, because of a element that isn't in core yet.

Hm. If W3C.org is the bar, their site is a complete mess of inconsistency regarding what's underlined and not.

Though after staring at it for 10 minutes, I guess the overall pattern is "if it's in content, underline it, if it's a heading or navigation element, don't."

That would make the patch more-or-less correct, except that the links in the "Tools" menu (and probably all other menus) should not be underlined.

I'm curious also if the accessibility issue here for colour-blind people could be resolved by picking a different colour of blue that didn't have contrast issues with the black, rather than causing visual dissonance all over the place for 100% of people.

@webchick As stated in #89 and #80, the links in menu are underlined because of a bug.

I don't think we can choose a color that would be distinguishable enough, as far as I know are black and white on far ends of the spectrum. Getting far enough from either to pass WCAG 2.0 sounds rather impossible (remember we don't just have to be far from the black text, also the white background), especially if we want it to still look nice (this color is connected to much more than just the links).

I think you meant #77, but yes, I see that now. So does that mean this would look weird until #1912516: Markup for menus is done? Or is there a smaller, more targeted issue to just add nav wrappers on menu blocks?

Ha, #80, not #90. I can read. :)

So my initial inclination is to postpone this issue until #1912516: Markup for menus is done, so that the solution that is proposed here is what ends up actually getting done. I'm sensitive to the fact though that this will not be perceived as very nice, given this issue got postponed to D8 during the D7 cycle due to how late it was proposed. OTOH, we are not currently in any danger of freezing markup until we hit RC, afaik, and we are 150-some issues away from that atm.

What say you?

@webchick Yhea, my thought was that we are still far from UI freeze so we can get the menu issue in - it is true that this is dependant on that getting in. Whatever you feel is the right strategy, I thought the right way to just raise the priority of that issue.

I still think its kinda ugly, hah. I am not so sure about applying this to the Seven theme, where it will look more out of context. It's sad we can't move to Source Sans typeface, that's much better with underlines.

Also, a small note - when writing this I notice that even d.o doesn't comply to this standard and probably won't.

@webchick Even if we changed the color contrast of links significantly, this would still be an accessibility problem because we need more than one design element to differentiate links, not just color. That's why color AND underline works so well. We can take away the underline, but then we need another design element that conveys the information "this is obviously a link."

The placement of links can convey this information, which is why links in menus and teaser headings don't need underlines.

Issue summary and comment #78 written by meichr.

76: 890362-76-underline-links-bartik.patch queued for re-testing.

I ran across the Knowability site recently and liked how they displayed link underlines. Much more subtle just using bottom border.

.bodyLink:link, .bodyLink:visited {
    background: none repeat scroll 0 0 rgba(0, 0, 0, 0);
    border-bottom: 1px solid #C6D6E4;
    color: #205988;
    padding: 0.2em 0.2em 0;
    text-decoration: none;
}

Adding related issue too.

Oh, nice!

Changing status to needs work.

Re-roll with new underline styling.

1. +++ b/core/themes/bartik/css/style.css
   @@ -9,17 +9,38 @@ body {
   +h2 > a:visited,
   

   Do we need the child selector here? Seems odd.

2. +++ b/core/themes/bartik/css/style.css
   @@ -9,17 +9,38 @@ body {
   +  background: none repeat scroll 0 0 rgba(0, 0, 0, 0);
   

   none is sufficient.

3. +++ b/core/themes/bartik/css/style.css
   @@ -9,17 +9,38 @@ body {
   +  border-bottom: 1px solid #C6D6E4;
   

   Lowercase?

Uploading screenshot with 3 links and one with focus.

The patch fails, once its green I will tinker with it a bit I am not 100% pleased with the vertical spacing.

106: 890362-106-underline-links-bartik.patch queued for re-testing.

I don't see how this would be releated to the css changes:
Undefined index: base Notice color.module 485 _color_rewrite_stylesheet()

+++ b/core/themes/bartik/css/style.css
@@ -12,15 +12,21 @@ body {
+  border-bottom: 1px solid #c6d6e4;

Colors should be in colors.css (for color module re-writing), I haven't looked at the test but it might be seeing that this one does not change?

I applied the patch and its too generic, breaks quite a bit of stuff like toolbar, contextual links, user pictures, the "About text formats" link and probably others so most likely needs to shift back to being pretty targeted.

I opened #2149783: Toolbar CSS styles are too weak; common theme styles unintentionally distort it on the basis of the patch #107 also, toolbar should not break this easily.

I get that the border bottom is pushed down by the padding required by the hover/focus style, I question if we need the hover/focus styles that loud, especially with the text shadow they kind of pop, I would personally prefer something more flat, or even just an outline type hover/focus (and change of color for the text and border). Then we could shift the border a bit closer. Just my two cents on the actual style, please don't take this the wrong way but the styles are a bit old school for me.

Yhea, I am not a big fan of the hover styles either - we should just go with highlighting the border. That is 1) a11y compliant, because it can be a significant enough change, 2) not jarring because it doesn't change the whole visual look.

It would probably make sense to keep the focus/hover discussion on #1993574: Add focus styling to all interactive elements

I like it myself, but it's a pretty big change and would need buy-in on the UX side.

Also, I don't get which colors should be in colors.css and which not, as there are a LOT of colors already defined in style.css.

Because the border color needs to "shift" when the user changes the color scheme. E.g. change to the Plum color scheme and #427bab shifts to #A06D6D.

Anything defined in style.css is grey or white or some rgba version of black or white etc, all pretty much neutral. There should be no colors that need to be under control of color module in that file.

Personally I would much prefer if the border simply inherited the link color, rather than adding another color to the default state of links - you are making this very nearly into a tritone theme which is hell to get right in color module unless you explicitly declare color settings for it and lock it down (don't use shift) and I would be against adding a setting just for link borders.

Something like this would be very easy, simple and looks pretty good (and shouldn't even need to touch colors.css):

a {
  color: #0071b3;
  border-bottom: 1px solid inherit;
}
a:hover,
a:focus {
  color: #018fe2;
  border-color: inherit;
}
a:active {
  color: #23aeff;
  border-color: inherit;
}

Apologies for the incremental comments and general bitching.

Ok, I've given this another shot...

I went and also border-bottom: none; into border-bottom: 0; as it wasn't consistent, but I figure that should go in another issue anyways.

I wish that one could just do something like border-color: rgba(inherit, inherit, inherit, 0.5); as I think that would be the best (if the color was defined in RGB.. I don't think that's possible.

I believe the reason for introducing a border color previously though was to produce something that was diminished or less intensive than a single border. I applied what you had suggested Jeff and it seemed just too heavy. I couldn't inherit the border-color mind you as that was black. Believe it isn't defined in the color.css file.

Although ideally there would be underlines under all of the links, the biggest area of priority is in the main content areas, so I figured I'd focus there. The header/footer folks assume is going to be largely links and styled differently. It is the main body of the page where there is the most confusion about what is and is not a link generally.

So I went back to the dotted lines. However, on hover/focus they go back to normal underlines. This gives what I see as a nice additional visual change.

In anycase, there are no changes to the color.css with this patch.

Not a bad idea Mike, that has become a quite common design pattern.

Note wee can't use rgba because color module does not (as yet) support rgb. By setting no color on the border declaration the border color is inherited from the link color.

Not sure I see the design benefit in using border for one state and text-decoration for the others, how about using border for both?

I rejigged this a bit to apply the style globally and then selectively remove borders, I know this can be a slight pita but we can avoid using an ID which ramps up specificity a helluvalot, can't say I like using an ID (if we are to constrain these border styles to main-wraper only), since Bartik is trying to be more of a base theme and using an ID is bad karma for those wishing to modify it.

I've "removed" the styles from the site banner, node header titles, some headings, feed icon and field type image links, but let them flow into the footer stuff and of course other regions. This is generally contrary to CSS standards for core, but it's also not much code and easy to extend for sub-themers etc.

I've also been nice to toolbar and contextual links and removed them there also, even those both those modules need isolate their styles themselves.

By using !important and not explicitly declaring :link and :visited pseudo styles we save quite a few lines of code.

I'm marking this RTBC. This seems like a good compromise. It only applies to Bartik at the moment, but think we should open up discussions about Seven in a new issue.

So in #94 @webchick suggested postponing this on #1912516: Markup for menus - is that no longer necessary?

True enough. That was a long time ago and I'd forgotten. Marking it postponed.

It's worth nothing that the last comment was on November 17, 2013 at 4:55am and nobody is assigned to address this issue.

My assumption at the time that @webchick wrote that in October that it was at a time when it looked like we were closer to a resolution.

Probably too late to incorporate into this issue, but here’s a new technique for adding underlines: https://medium.com/p/7c03a9274f9

I couldn't see much to pull from the Medium article. At least until it goes live.

I tried to play with some of the ideas expressed in it and put it here http://jsfiddle.net/mgifford/DrPBn/

Essentially on of the takeaways is to use either background images or CSS gradients

a {
    text-decoration: none;
    /* The old syntax, deprecated, but still needed, prefixed, for WebKit-based and old browsers */
    background: -prefix-linear-gradient(top, white 98%, rgba(0, 0, 255, 0.9));
    /* The new syntax needed by standard-compliant browsers (Opera 12.1, IE 10, Fx 16 onwards), without prefix */
    background: linear-gradient(to bottom, white 98%, rgba(0, 0, 255, 0.9));
}
a:hover, a:focus {
    /* The old syntax, deprecated, but still needed, prefixed, for WebKit-based and old browsers */
    background: -prefix-linear-gradient(top, white, white 80%, rgba(0, 0, 255, 0.4));
    /* The new syntax needed by standard-compliant browsers (Opera 12.1, IE 10, Fx 16 onwards), without prefix */
    background: linear-gradient(to bottom, white, white 80%, rgba(0, 0, 255, 0.4));
}

As far as @webchick's concerns with #94. Although still valid. Can't we simply exclude the menus and focus just on the text in the main section of the site?

76: 890362-76-underline-links-bartik.patch queued for re-testing.

I was going to mark #122 as RTBC again, as I don't think menus are getting getting completed. Then figured that because this patch applies to Bartik we should have it reviewed there first.

#128, yes I agree, in content links are not menu links, they're different things altogether and require different solutions. Forge ahead, the menu markup issue might not complete for several months in any case.

Re the gradient idea - not really liking that idea very much, seems very bespoke, i.e. need to adjust the background-position if you change the font size, i.e. too complicated and not intuitive for marginal differences, just a bad TX imo. Can it.

So do we just need @Bojhan's approval before #122 can be marked RTBC? He marked it RTBC back in August of 2010, so maybe not....

This visual approach has my RTBC.

Thanks Bojhan.

I'll mark this RTBC then as the CSS is pretty simple.

Committed/pushed to 8.x, thanks!

Hooray!!! A personal thanks to everyone who persisted through this four year long issue, well done people. D7 anyone?

Hey, I noticed that dropbutton elements now look a bit weird in Bartik, a lot of them tend to use anchor elements, so they appear with borders at the bottom.

Breadcrumbs also look a bit weird, I don't seem any prior mentioned of breadcrumbs in this issue?

Well, a drop button issue could be an issue for dropbutton.css, critical form navigation elements shouldn't really be disturbed by a theme wanting to set an underline/border etc on anchors, but still not be onerous in terms of resetting every possible declaration or using highly specific selectors. Setting plausible declarations however I think is a different story and this may be a case for doing so, i.e. border: 0; in drop button.css

I think you're talking about the kind of buttons used in views, e.g. /admin/structure/views which is an admin page, not a front end page, but Bartik is a front end theme, so there's also some issue there - I always went with the concept of an "MVP" when Bartik is set as Admin theme. i.e. it may not look ideal but its not broken to the extent you cannot use it.

Breadcrumbs don't look weird to me - browser issue?

One place I have seen something I didn't notice before and I'm not entirely happy with is the tips link.

I suppose we could fix the tips link (if deemed necessary, personally I am not happy with it), and the breadcrumb issue (pending screenshot etc), but the drop button one feels like a followup (to figure out if this a theme issue or a core issue, i.e. should we let it break and force themes to fix and repair, or not) requiring some discussion. We may have a precedence on this already because of Toolbar CSS needing similar reinforcement (isolation, there is an issue open on this already) because doing things like this is not sustainable:

.field-type-image a, h1 a, h2 a, [role*="banner"] a, .feed-icon, .contextual-links a, .toolbar a {
    border-bottom: medium none !important;
}

@LewisNyman see #2256915: Pager link underlinings do not display properly

I created one for filter tips link: #2271327: Tips link border bottom not looking great

Add for drop buttons: #2271341: Drop button anchors easily broken by common theme styles

Can we agree to close this issue again and deal with stuff in followups? Setting to active for now.

That works for me.

Sounds good, let's keep moving forward.