WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#30108 closed enhancement (fixed)

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

Reported by: KatherineMancuso Owned by: iandstewart
Milestone: 4.1 Priority: normal
Severity: normal Version: 4.1
Component: Bundled Theme Keywords: has-patch needs-testing
Focuses: ui, accessibility Cc:
PR Number:

Description

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.

Attachments (12)

30108.diff (466 bytes) - added by morganestes 5 years ago.
style.css
ScreenCapture at Sun Oct 26 16:11:41 PDT 2014.png (12.0 KB) - added by morganestes 5 years ago.
Underlined link on hover with icon next to it.
30108.1.diff (539 bytes) - added by morganestes 5 years ago.
Corrects the janky underlines in icons and adjusts links inside the post to visually alter links on hover.
edit.gif (12.3 KB) - added by GrahamArmfield 5 years ago.
Screenshot of edit link with funny underline.
30108.2.diff (1.8 KB) - added by morganestes 5 years ago.
Remove underline from Genericon-prefixed links on hover and focus.
30108.3.diff (2.6 KB) - added by morganestes 5 years ago.
Updates page and entry content rules, and updates customizer rule for elements that have the border removed on hover/focus.
ScreenCapture at Wed Oct 29 14:14:28 CDT 2014.png (64.6 KB) - added by morganestes 5 years ago.
Edit comments underline fix
ScreenCapture at Wed Oct 29 14:12:49 CDT 2014.png (38.7 KB) - added by morganestes 5 years ago.
Customizer with menu underlined
30108.4.diff (3.0 KB) - added by morganestes 5 years ago.
30108.5.diff (12.1 KB) - added by iamtakashi 5 years ago.
Add/remove bottom borders to/from links on hover/focus.
30108.6.diff (16.5 KB) - added by iamtakashi 5 years ago.
Adjust focus and hover style for better accessibility.
30108.7.diff (20.4 KB) - added by iamtakashi 5 years ago.
Adjust hover/focus styling for better accessibility

Download all attachments as: .zip

Change History (41)

#1 @johnbillion
5 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.1

@morganestes
5 years ago

style.css

#2 @morganestes
5 years ago

  • Keywords has-patch added; needs-patch removed

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
5 years ago

Underlined link on hover with icon next to it.

This ticket was mentioned in Slack in #core by morganestes. View the logs.


5 years ago

This ticket was mentioned in Slack in #core-themes by morganestes. View the logs.


5 years ago

@morganestes
5 years ago

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

#5 @morganestes
5 years ago

Note: second diff from inside the src folder.

#6 @GrahamArmfield
5 years ago

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
5 years ago

Screenshot of edit link with funny underline.

@morganestes
5 years ago

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

#7 @morganestes
5 years ago

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.

#8 follow-up: @iamtakashi
5 years ago

  • Keywords needs-testing added

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.

This ticket was mentioned in Slack in #core-themes by iandstewart. View the logs.


5 years ago

@morganestes
5 years ago

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

#10 in reply to: ↑ 8 ; follow-up: @morganestes
5 years ago

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

This ticket was mentioned in Slack in #core-themes by morganestes. View the logs.


5 years ago

@morganestes
5 years ago

Edit comments underline fix

@morganestes
5 years ago

Customizer with menu underlined

#12 in reply to: ↑ 10 ; follow-up: @iamtakashi
5 years ago

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.
  1. If you specify border:none; in L: 1763, do we need border-bottom: none; in the big chunk of changes in style.css?
  1. Then we can remove the.entry-content a:focus and .entry-content a:hover from the chunk.
Last edited 5 years ago by iamtakashi (previous) (diff)

#13 @iamtakashi
5 years ago

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

https://cldup.com/LkRxZrHC5l.png

#14 in reply to: ↑ 12 @morganestes
5 years ago

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.
  1. If you specify border:none; in L: 1763, do we need border-bottom: none; in the big chunk of changes in style.css?
  1. 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.

@morganestes
5 years ago

#15 follow-up: @iamtakashi
5 years ago

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?

#16 @iamtakashi
5 years ago

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.

#17 follow-up: @joedolson
5 years ago

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.

#18 in reply to: ↑ 17 ; follow-up: @iamtakashi
5 years ago

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

#19 in reply to: ↑ 18 @morganestes
5 years ago

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.

#20 @joedolson
5 years ago

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

#21 in reply to: ↑ 15 ; follow-up: @afercia
5 years ago

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.

This ticket was mentioned in Slack in #accessibility by morganestes. View the logs.


5 years ago

This ticket was mentioned in Slack in #accessibility by katherinemancuso. View the logs.


5 years ago

#24 in reply to: ↑ 21 @iamtakashi
5 years ago

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
5 years ago

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

#25 @iamtakashi
5 years ago

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

@iamtakashi
5 years ago

Adjust focus and hover style for better accessibility.

#26 @iamtakashi
5 years ago

Some examples of this change.

Post meta (Hover)
https://cldup.com/iaNzJouFkc.png

Post meta (Focus)
https://cldup.com/mQR3gPSLqE.png

A link in text widget:
https://cldup.com/oa0_Z7eUe7.png

A link in text widget (Focus)
https://cldup.com/aSEFBdhe04.png

#27 follow-up: @afercia
5 years ago

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

https://cldup.com/WXHVF4a9qP.png

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

Example with alternate color scheme

https://cldup.com/sLUA3gPISV.png

Post navigation focus

https://cldup.com/bhhi-HjY96.png

@iamtakashi
5 years ago

Adjust hover/focus styling for better accessibility

#28 in reply to: ↑ 27 @iamtakashi
5 years ago

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.

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.

#29 @iandstewart
5 years ago

  • Owner set to iandstewart
  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.