Twenty Fifteen: Underline menu links & post links in the archive on hover so it is clear they are links

[KatherineMancuso]

For visually impaired users who have difficulties with color or contrast perception, it is currently unclear that the menu links and the post links in the archive in Twenty Fifteen are links. The change in color on hover/keyboard focus is quite subtle.

Adding an underline on hover/focus would make it much clearer that these are links.

[morganestes]

style.css

[morganestes]

Added a rule that will add underlines to anchors on :hover and :focus, then a more-specific one to remove the underline from links inside the post content, since those are already underlined regardless of state and we don't want a double underline.

Only issue I can see with this so far is there is a slight jank with underlines for text next to an icon, as seen in the screenshot.

[morganestes]

Underlined link on hover with icon next to it.

[morganestes]

Corrects the janky underlines in icons and adjusts links inside the post to visually alter links on hover.

[morganestes]

Note: second diff from inside the src folder.

[GrahamArmfield]

I have tested this and it appears to mostly have fixed the issue. Everything seems ok except for the edit link which still seems to have the 'janky' underline.

[GrahamArmfield]

Screenshot of edit link with funny underline.

[morganestes]

Remove underline from Genericon-prefixed links on hover and focus.

[morganestes]

Thanks for catching that GrahamArmfield.

I've made another pass at it. This one specifically targets the links listed in the Genericons list (Section 2.0 in the CSS) and removes the underline from them on :hover and :focus.

I would like to mention that I would really like to see the source Sass files in future theme releases, partly to see the intention of the author, and partly to avoid the massive typing (or copy/paste) of these types of specific selectors.

[iamtakashi]

If we are going for this, we also need to remove border from hover and focus states for entry-summary a, page-content a, and comment-content a.

[morganestes]

Updates page and entry content rules, and updates customizer rule for elements that have the border removed on hover/focus.

[morganestes]

Replying to iamtakashi:

If we are going for this, we also need to remove border from hover and focus states for entry-summary a, page-content a, and comment-content a.

I updated that ruleset to remove the border from the CSS, and from the customizer CSS since border-color isn't needed on an element that doesn't have the border.

After discussion with other core devs, I went back to diffing from the root of develop, rather than inside src. Sorry I keep going back and forth, but this'll be the last time. :)

[morganestes]

Edit comments underline fix

[morganestes]

Customizer with menu underlined

[iamtakashi]

I had a look 30108.3.diff but there are still few issues.

1. The border rule needs to stay there in customizer.php for border color for blockquote. There are already secondary text color rules for those selectors just above.

2. If you specify border:none; in L: 1763, do we need border-bottom: none; in the big chunk of changes in style.css?

3. Then we can remove the.entry-content a:focus and .entry-content a:hover from the chunk.

[iamtakashi]

I'm not sure how to solve this but when a menu item has description, looks quite bad.

[morganestes]

Replying to iamtakashi:

I had a look 30108.3.diff but there are still few issues.

1. The border rule needs to stay there in customizer.php for border color for blockquote. There are already secondary text color rules for those selectors just above.

2. If you specify border:none; in L: 1763, do we need border-bottom: none; in the big chunk of changes in style.css?

3. Then we can remove the.entry-content a:focus and .entry-content a:hover from the chunk.

1. I pulled out just the :hover and :focus rules in the customizer, since they're not relevant any more, so it's just down to blockquote in that ruleset.
2. Right, that's just duplicated needlessly. I tried to keep that ruleset instead of duplicating selectors, but it doesn't make much sense to have border: none in that line. I removed it from that selector and re-grouped all the a11y changes to the selectors in section 7.0.
3. I vote for leaving the color changes in L:1769 (in new patch) since those are strictly style changes, and moving the border styles into the a11y section 7.0 in the stylesheet.

I'm adding a new patch, 30108.4.diff with these changes. It also fixes a selector error I missed before, and change the selector order to alphabetical so it's easier for me to read.

[iamtakashi]

Thanks for the update.

However more I look this, I don't like more and more the whole underline idea. It just looks bad - the underline touches letters and for some letters it overlaps. This is the reason I use bottom border in the content area in the first place.

I get the idea of visual feedback that doesn't rely on color but nothing else can be done?

[iamtakashi]

As you can see the screenshot of the menu description, the underline significantly impacts legibility. Again I understand the value of non-color visual feedback but if that makes unreadable because of poor legibility, it's creating issues than helping, IMO.

[joedolson]

I'm personally not convinced that underlines are required in a menu context, where all text is linked in a structured manner. Links embedded in content benefit from this hugely, but I think it clutters menus.

[iamtakashi]

Replying to joedolson:

I'm personally not convinced that underlines are required in a menu context, where all text is linked in a structured manner. Links embedded in content benefit from this hugely, but I think it clutters menus.

I agree. Also anything in entry-footer and list type widgets are always links. The only thing I can think it's hugely beneficial is links in text widget. But we can do the same as content (bottom border, not underline).

[morganestes]

Replying to iamtakashi:

Replying to joedolson:

I'm personally not convinced that underlines are required in a menu context, where all text is linked in a structured manner. Links embedded in content benefit from this hugely, but I think it clutters menus.

I agree. Also anything in entry-footer and list type widgets are always links. The only thing I can think it's hugely beneficial is links in text widget. But we can do the same as content (bottom border, not underline).

The ​WCAG guideline I was working from says to 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).

Underlines were my first thought, but I really do like the border-bottom in the main entry content.
I think we should do something to differentiate beyond the subtle color change/fade but I'm open to what that something is.

[joedolson]

I like the border; that's just fine. Agree that hover/focus needs something more. I like adding/subtracting borders/underlines in those situations.

For the main menu, while they are links, their application and appearance is more button-like, so I don't feel that an underline is beneficial.

I'm avoiding specifics because I'm boarding my flight in a few minutes, so I can't check details...

[afercia]

Replying to iamtakashi:

the underline touches letters and for some letters it overlaps. This is the reason I use bottom border in the content area in the first place.

My personal opinion:
Twenty Fifteen is a theme with a strong focus on accessibility and I'm totally happy with this, having been involved in accessibility projects since more than 10 years, but still is a theme for a general audience. Twenty Fifteen should not be compared to sites that are strongly targeted to users who need a very high level of accessibility like for example webaim.org, paciellogroup.com, deque.com, etc.

It would be great to have the maximum reasonable level of accessibility without sacrificing the beautiful typography @iamtakashi and others carefully crafted. That's a great value for readability (readability = better accessibility). Not to mention aesthetics.
Like @joedolson, I'm for practicality :)

Menu links are perceivable by context. It's a navigation menu, has links, everyone gets that. No need of underlines. Navigational links are different from links within body content:

​http://www.w3.org/TR/WCAG20-TECHS/F73.html
...
While some links may be visually evident from page design and context, such as navigational links, links within text are often visually understood only from their own display attributes. Removing the underline and leaving only the color difference for such links would be a failure because there would be no other visual indication (besides color) that it is a link.

​http://webaim.org/techniques/hypertext/link_text#underlining
...
Although users are accustomed to seeing links in the main content underlined, they are also accustomed to seeing tabs and main navigational features (oftentimes created as graphics rather than text) without underlining. In these cases, the linked items should be designed so it is apparent that the user can click on them to perform an action.

​http://www.nngroup.com/articles/guidelines-for-visualizing-links/
Nielsen (2004, a bit outdated and Nielsen is known for being a bit... radical :))
...
There are two main cases in which you can safely eliminate underlines: navigation menus and other lists of links. However, this is true only when the page design clearly indicates the area's function.
...
Exception: underlined links are important for low-vision users' accessibility, so retain underlines if accessibility is a priority for your site or you have many users with low vision.

Recap:

• navigation menus are a no-issue for me
• border bottom is totally fine for links within post content
• I agree with @joedolson: better focus, everywhere
• focus style could be like in the WordPress admin (à la Webkit) or even something stronger like on deque.com outline: 3px solid #0079c1;
• post meta, comments meta, links in the footer and other secondary links may benefit from a border-bottom just on hover, that's one of the points suggested by @KatherineMancuso and I totally agree
• widgets that have links within some kind of text block (for sure the text widget) need same bottom border as main content

If you think at all this, not so much would be changed in the visual appearance of this beautiful theme and at the same time links would have some nice improvements on hover/focus.

[iamtakashi]

Replying to afercia:

Thanks for the thoughtful comment, afercia. I like your balanced way that's not sacrificing the typography and the ascetics. I'll make a patch.

[iamtakashi]

Add/remove bottom borders to/from links on hover/focus.

[iamtakashi]

Scratch 30108.5.diff. We need better focus style. Working on a new patch.

[iamtakashi]

Adjust focus and hover style for better accessibility.

[iamtakashi]

Some examples of this change.

Post meta (Hover)

Post meta (Focus)

A link in text widget:

A link in text widget (Focus)

[afercia]

Thanks very much takashi, super nice to have custom focus style for alternate color schemes :)

Please check following screenshots for some details that need attention, especially checkboxes, radio buttons and selects, they need focus style.

The other ones are very subtle details and, as I see it, totally up to your design choices.

I'd recommend to consider a couple of things though:

• posts navigation on focus: overflow hidden on the container cuts-off the outline style
• disabled buttons maybe need a different style
• maybe add the border bottom (just on hover) on the Recent Entries and Recent Comments widgets, especially the latter because each item has 2 different links (comment and author URL), for example:

  .widget_recent_comments a:hover,
  .widget_recent_entries a:hover {
  	border-bottom: 1px solid currentColor;
  }
  

• consider the use of currentColor, browser support: ​https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Browser_Compatibility

thanks to ​Avryl's admin UI plugin for the list of elements

Example with alternate color scheme

Post navigation focus

[iamtakashi]

Adjust hover/focus styling for better accessibility

[iamtakashi]

Replying to afercia:

• maybe add the border bottom (just on hover) on the Recent Entries and Recent Comments widgets, especially the latter because each item has 2 different links (comment and author URL)

I hear you but I hesitate to introduce another hover pattern for widgets. I'll leave it as it is for now.

• consider the use of currentColor, browser support: ​https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Browser_Compatibility

It's interesting but the limited compatibility is a deal breaker for a default theme which needs to support reasonably IE8 and 7.

Good catch on other points. I've updated the patch.

[iandstewart]

In 30208:

Twenty Fifteen: make it clear that a link is a link in post and comment meta by underlining it on hover or focus

Props morganestes, iamtakashi, fixes #30108