Making WordPress.org

Opened 5 years ago

Closed 2 years ago

#4091 closed defect (bug) (fixed)

Remove all title attributes from navigation menu

Reported by: afercia's profile afercia Owned by:
Milestone: Priority: normal
Component: General Keywords:
Cc:

Description

Splitting this out from #3996.

I'd like to recommend to remove all the title attributes used on the menu items, for the same reasons why in the last years WordPress has been progressively removing title attributes in the admin. See: https://core.trac.wordpress.org/query?keywords=~title-attribute and see the main ticket https://core.trac.wordpress.org/ticket/24766

Title attributes are really something that belongs to the past. They're available only to mouse users. Screen reader users may get the title attributes (depending also from the verbosity setting they set in their screen reader) and all that text adds a terrible noise, often to communicate not so relevant information.

For example, I'm not sure what kind of relevant information a sentence like "Come here for the latest scoop." adds to the menu item "Blog".

The general rule the accessibility team recommends is:

  • if the title attribute adds relevant information: consider to make it available to all users, putting in plain text somewhere in the UI
  • if the title attribute doesn't add any relevant information: consider to just remove it

It'd be great to consider to make the menu embrace the best practices WordPress itself (the software) adopts.

Attachments (3)

w.org menu.png (66.7 KB) - added by afercia 5 years ago.
4091-submenu.diff (548 bytes) - added by ryelle 3 years ago.
Remove the title attribute from submenu items
4091-footer.diff (7.7 KB) - added by ryelle 3 years ago.
Remove the title attribute from footer items, wrap footer in labelled nav area.

Download all attachments as: .zip

Change History (39)

@afercia
5 years ago

#1 @Otto42
5 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

No. Titles in the menus may not be necessary, but they are there for flavor. And while some want to suck the life and all that is fun out of how we make our software, the "Howdy" still exists in core, and these still exist here.

The titles are not necessary and do not need to be accessible. But unless they cause actual harm to accessibility, which they generally do not as screen readers tend to ignore them, then we will leave them and continue to have some entertaining aspects of the site, beyond the merely "functional" aesthetic that seems to be a common refrain these days.

#2 @afercia
5 years ago

The titles are not necessary

In fact, that's one of the points of this ticket :)

and do not need to be accessible.

This is arguable.

But unless they cause actual harm to accessibility

They do.

which they generally do not as screen readers tend to ignore them

I think I've tried to explain they do get announced by default.

Will propose to discuss this issue with the accessibility team next Monday, and then report the team's feedback, You;re all invited to attend the meeting.

I'd only like to add WordPress should show best practices and lead by example.

#3 follow-up: @Otto42
5 years ago

What do you suggest replacing them with? How can we continue to keep the site interesting and fun if you alone decide to kill meaningless things with nothing in replacement?

Show me the actual harm. That is all I ask. I'll happily kill the thing if it is actually a problem. I'd prefer to replace it with something better, but until I see why it is a real problem, then I'm pretty sure it ain't a real problem, and just a fun thing.

Who defines "best" practices? You? Me? That other guy? There is no "best", there is what works and does what you want it to do. So, I need a real reason to work on the change. Because this has been there for over a decade. Show me a *reason* for change, and show what it should be changed to. And if your suggested change is "nothing", then yeah. not convinced without backing reasons for that.

Last edited 5 years ago by Otto42 (previous) (diff)

#4 in reply to: ↑ 3 @GrahamArmfield
5 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to Otto42:

Who defines "best" practices? You? Me? That other guy? There is no "best", there is what works and does what you want it to do. So, I need a real reason to work on the change. Because this has been there for over a decade. Show me a *reason* for change, and show what it should be changed to. And if your suggested change is "nothing", then yeah. not convinced without backing reasons for that.

@Otto42 I think you'll find that many accessibility specialists would agree with @afercia on this point - that title attributes are in many cases superfluous, only divulge their content to mouse users, and can cause grief for screen reader users. Depending what you want to do with title attributes, there is always a better, more accessible way of doing it these days.

There are a number of articles on the web concerning this. Here are two:

As you can probably tell, I also support this change.

Additionally @Otto42, maybe it's a language thing, but your comments to @afercia come across as both aggressive and dismissive - to someone who has done so much to attempt to make WordPress a more accessible place - both for us as developers, and our end users.

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


5 years ago

#6 @SergeyBiryukov
5 years ago

maybe it's a language thing, but your comments to @afercia come across as both aggressive and dismissive

FWIW, that was my impression as well. Having a strong opinion is one thing, but with all the efforts in the recent years to make the WordPress project more friendly to newcomers, immediately closing tickets as wontfix without any chance for a discussion is not cool :)

We can do better than that, for example by using the close and 2nd-opinion keywords as appropriate.

#7 follow-up: @Otto42
5 years ago

I wouldn't say "aggressive". But yes, "dismissive", certainly.

Understand that I will always back any reason to keep "meaningless" things in. The old smiley's, for example. Or the "howdy" language. Or titles on links, especially when they do no harm to anybody. Trying to justify removing these sort of things for the sake of "accessibility", well.. it devalues what I see to be real accessibility issues, and yes, that bothers me.

If there is a real issue with the existence of these that I'm not seeing, then I'm willing to learn. But really, from everything I know and have read, titles on links, by and large, are useless. They don't get read by accessibility software. They don't "do" anything of substance. So the general recommendation is to not use them for necessary information. Which is a valuable and useful recommendation.

But in this case, those titles aren't being used for anything of value. Those hover titles don't need to be visible to anybody in particular. They're there solely for fun. Ignoring them entirely is fine. I don't need an accessible way to make these titles available, because they don't actually need to be available to anybody. And if the argument is that everything which isn't immediately useful should be removed, then yes, I will take exception to that notion.

We're making software for human beings here, not just for machines. Having little human touches here and there is valuable to other humans. We don't need everything to be perfect according to some arbitrary standard, we need to adhere to the standards, and leave those human touches in where they don't cause any harm, and to give the software character and life.

So yes, this kind of ticket annoys me because it's unbacked by any actual data. Like I said, show me the actual problem, not just some theoretical problem created by adhering to an arbitrary standard which not everybody necessarily agrees with. I'll happily fix real problems, right away. But no, this should be wontfix'd just as much as the "remove 'Howdy'" ticket should be wontfix'd. And that is my opinion.

#8 @afercia
5 years ago

They don't get read by accessibility software.

This is not true. They do get read.

If you only took the time to actually read the core Trac ticket linked above, this conversation would be unnecessary.

As per the tone and language, I find them simply not acceptable.

#9 @Otto42
5 years ago

This is not true. They do get read.

Okay. Can you show me the resulting problem from this actual specific instance in which you have said there is a problem?

If you only took the time to actually read the core Trac ticket linked above, this conversation would be unnecessary.

This conversation is absolutely necessary, and you're acting as if I don't know the same things that you know. That by reading your links to general things that I will gain some additional knowledge. That isn't the case. I've read your links. Not one of them shows me the problem, here and now.

My issue here is that you're speaking in general concepts, but I want specific details. Why is this specific problem, with these specific titles, an actual problem? For this specific case, not just the general idea of "titles are bad on links".

Edit: The reason I ask this is because it seems to me that you have misunderstood the "because" here. Titles are bad on links *because* they are not accessible to screenreaders, mobile users, and other ways of presenting that content. That is perfectly valid and true. However, that because makes all the difference. When the content in the title is irrelevant to literally all viewers, then it doesn't make any difference if it is accessible or not. That's my point here.

So if the titles are actually causing a problem, then I want to know what that problem is, specifically. Because them not being accessible isn't a problem, because they don't need to be seen by anybody at all to still have value.

Last edited 5 years ago by Otto42 (previous) (diff)

#10 @afercia
5 years ago

I've read your links. Not one of them shows me the problem, here and now.

Seems you'd need to read the core ticket linked above again. Quoting:

For users of assistive technologies, the title attribute is useless at best and sometimes an annoyance. Users of text-to-speech software who have configured their software to do so will hear the title attribute twice.

That should be updated though, because to my knowledge and based on my testing, today all major screen readers read title attributes by default.

To clarify again the point: for many users, title attributes are not available or barely noticeable:

  • in 2016, mobile and tablet internet usage surpassed desktop usage: all these users don't get title attributes at all
  • keyboard users: they don't get title attributes
  • mouse users: if you think they actually pay attention to that tiny browser tooltip, I'm afraid you're overly optimistic
  • in WordPress core we've removed tons of title attributes, I haven't heard complaints

A bit ironically, screen reader users are the only ones constrained to get all those title attributes. The screenshot below is from Firefox + NVDA:

http://cldup.com/BU95BkXv_P.png

As a screen reader user, I'm highly annoyed by all that noise that doesn't add any value to the menu. I just want to navigate through the menu and get the links in the quickest and most efficient way.

This is not new. It's the result of years of research and implementation of best practices. Again, our general recommendation as accessibility team is:

  • if the title attribute adds relevant information: consider to make it available to all users, putting in plain text somewhere in the UI
  • if the title attribute doesn't add any relevant information: consider to just remove it

So if you think those title attributes are important enough, I'd suggest to make them available to all users in plain text, in the design of the related pages. Personally, I don't think this is the case.

I wouldn't say "aggressive". But yes, "dismissive", certainly.

That said, I'm not interested in continuing a conversation with a person who thinks a dismissive tone is perfectly appropriate, as that is disrespectful not only towards me but also towards the entire accessibility team.

#11 follow-ups: @Otto42
5 years ago

Okay, so is there any way to make that text remain, but not have screen readers read it out? Because as I stated, it is indeed unnecessary, but that doesn't make it without value. A solution that would prevent such assistive technologies from seeing it would be preferable to "consider to just remove it".

#12 in reply to: ↑ 11 ; follow-up: @Adrian Roselli
5 years ago

Replying to Otto42:

is there any way to make that text remain, but not have screen readers read it out?

No. title attributes are on the link itself. You cannot hide it without also hiding the link.

I did some quick tests with a user and then made a video of two examples (with the speaking rate slowed way down):

It wasn't until listening to the video that I realized the user in the NVDA example was tabbing before the Support or Documentation links had finished announcing all the title text. The commas introduced enough of a pause to make the user think it was done.

Commas and periods do not belong in navigation; it should be quick, to the point, and not make me wait to see if there is more to hear. Further, starting the title text with the same text as the link was a bit verbose (Plugins, Documentation, About) so they would warrant new copy anyway.

Also, the button announcement in NVDA is pretty awful. Listen. To. The. Pauses.

Anyway, the feedback is that the title text adds nothing and only slows the users down. This is particularly true for every visit to the site after the first visit ever.

While I am here, is there an issue somewhere to add aria-current to the currently active link in the navigation? The screen reader should announce that I am on the Plugins page. As it is, sitting through each entire link to hear if it is the current link was a bit annoying. The title attributes just added time to using the navigation.

#13 in reply to: ↑ 12 ; follow-up: @SergeyBiryukov
5 years ago

Replying to Adrian Roselli:

While I am here, is there an issue somewhere to add aria-current to the currently active link in the navigation?

There are some tickets on Core Trac: #WP41859, #WP43191, #WP43522, but I think the WordPress.org global menu is hardcoded, so it would be a good idea to create a ticket for it here on Meta Trac.

#14 in reply to: ↑ 11 @anonymized_7658014
5 years ago

Replying to Otto42:

Okay, so is there any way to make that text remain, but not have screen readers read it out? Because as I stated, it is indeed unnecessary, but that doesn't make it without value. A solution that would prevent such assistive technologies from seeing it would be preferable to "consider to just remove it".

Based on the discussion above, could we agree standard title attributes are not the most inclusive/accessible way to convey humour that otherwise may be a welcome, necessary, and important feature of wordpress.org?

I’d suggest an approach where the copy currently stored in title gets stored in data-title which according to MDN is ignored by assistive technologies:

Do not store content that should be visible and accessible in data attributes, because assistive technology may not access them. In addition, search crawlers may not index data attributes' values.
https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes#Issues

In our case, that would make data-title a perfect fit, wouldn’t it? A ‘tooltip’ emulating title’s :hover behaviour can be implemented via a minor amount of JavaScript, or probably even with CSS only.

Unless I’m missing something, this approach would preserve the fun aspect for users who don’t rely on assistive technology while users who do could browse a functional menu without any additional noise.

Last edited 5 years ago by anonymized_7658014 (previous) (diff)

#15 @anonymized_7658014
5 years ago

Fixed it with CSS only:

#wporg-header ul li a::after {
	content: '';
	opacity: 0;
	transition: opacity .2s ease-in-out;
	transition-delay: .8s;
}
#wporg-header ul li a:hover::after {
	background: rgba(200,200,200,.9);
	box-shadow: 0 1px 2px rgba(0,0,0,.5);
	content: attr(data-title);
	color: #111;
	font-size: .9em;
	left: 0;
	line-height: 1.5;
	padding: 0 .25em;
	position: absolute;
	top: 3em;
	white-space: nowrap;
	opacity: 1;
	z-index: 9999;
}

Tooltip with default title attribute:
🖼 https://www.dropbox.com/s/5x3x8iarqlrvmq4/wp.org-menu-title.png?dl=0

Tooltip with data-title attribute:
🖼 https://www.dropbox.com/s/cnehach5mirvine/wp.org-menu-data-title.png?dl=0

Update: Enhanced CSS proof of concept above to better emulate a system tooltip. Works with submenus:
▶️ https://www.dropbox.com/s/n1cts99t6avso35/wp.org-menu-data-title.mp4?dl=0

Last edited 5 years ago by anonymized_7658014 (previous) (diff)

#16 in reply to: ↑ 7 @souri_wpaustria
5 years ago

Replying to Otto42:

I wouldn't say "aggressive". But yes, "dismissive", certainly.

But indeed it is very aggressive and an inappropriate writing!
So I second Sergey's comment - so you have it.
Two oppinions on your behavior.
Is this better for your understanding? Does Sergey's opinion is now more valuable???

Overall:
That's inacceptable. I read your comments open-mouthed.

If this is the new language to long-serving developers than count me out!
@Otto42

#17 follow-up: @Otto42
5 years ago

@glueckpress Perhaps a "data-tooltip" instead, but yes, this method seems acceptable.

#18 in reply to: ↑ 17 @anonymized_7658014
5 years ago

@Otto42 Excellent! Yes, please rip it apart as you see fit.

#19 follow-up: @stommepoes
5 years ago

Better to Javascript them if you're going to keep them:

I need to be able to tell if this stuff that appears on hover is something I need to know. Am I missing something? Is it necessary or is it just extra? I can't read it all to tell.

Then, because they do appear on hover and cover stuff and my mouse determines where I can see: something to close them so I don't have to move my viewport, like the Esc key. So using Javascript would allow hovering over the visible title entirely AND let me close it when I choose while keeping my view in place.

Example of limited view (that's my whole screen), where the title attribute of the Plugin link shows but if I were to move my mouse over to see the rest of it, I wouldn't be hovering on the link anymore, so cannot read it all.
https://i.imgur.com/yGUW9Z2.png

#20 @afercia
5 years ago

Thanks @stommepoes. For reference, that's why the Web Content Accessibility Guidelines require custom implementations of "tooltips" to be:

  • dismissable by the user
  • hoverable
  • persistent

WCAG reference:
Success Criterion 1.4.13 Content on Hover or Focus
https://www.w3.org/TR/WCAG21/#content-on-hover-or-focus
https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

See also in Gutenberg:
https://github.com/WordPress/gutenberg/pull/8147
https://github.com/WordPress/gutenberg/issues/7004
https://github.com/WordPress/gutenberg/pull/8033

#21 @Otto42
5 years ago

@afercia @stommepoes Okay, so if the CSS approach isn't a good one, what is a compliant way of doing these? Is there a standard library or fragment of JS code that implements such things in an appropriate manner?

#22 in reply to: ↑ 19 ; follow-ups: @anonymized_7658014
5 years ago

@stommepoes Since those tooltips don’t carry essential information, I guess a media query could solve the issue with smaller viewports, but there is a broader angle to the whole topic that even a ‘fun’ feature should be available for everyone (see https://twitter.com/bamadesigner/status/1090665644385800192) – which leads to the question if tooltips are a suitable way of implementation at all. However, fwiw, since this ticket addresses the implementation with title attributes, I’d rather see a quick fix like the one sketched out above than having the issue be dismissed entirely.

#23 in reply to: ↑ 13 @Otto42
5 years ago

Replying to SergeyBiryukov:

Replying to Adrian Roselli:

While I am here, is there an issue somewhere to add aria-current to the currently active link in the navigation?

There are some tickets on Core Trac: #WP41859, #WP43191, #WP43522, but I think the WordPress.org global menu is hardcoded, so it would be a good idea to create a ticket for it here on Meta Trac.

Agreed. I made a new ticket for it, and this seems easy to add to the current code:

https://meta.trac.wordpress.org/ticket/4131

#24 in reply to: ↑ 22 @Otto42
5 years ago

Replying to glueckpress:

which leads to the question if tooltips are a suitable way of implementation at all

That is actually a valid question which I had not considered. If the idea is that these titles should be removed, where should the content they convey actually go? What would be an appropriate location for the microcopy?

#25 @Otto42
5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

For the time being, I have changed these to data-title's, until we can come up with an implementation to show this content again in a different way.

I'm not opposed to fixing accessibility issues or even adhering to accessibility standards. I'm opposed to implementing them without this type of discussion or thought being applied to the problem. Blanket removing things because they don't fit with the latest viewpoints isn't a good way to go forward, IMO. That was why I originally opposed this ticket.

But since we have had discussion on it, and seen that some other approaches may exist, then I'm happy to hide the content for now until we can find a better way to surface it.

Note that the global menu used here on .org is heavily cached, so the changes may not propagate to other systems such as trac and the codex and so on for quite a while. But they will get there eventually.

Fixed in [dotorg:14783].

#26 follow-up: @anonymized_7658014
5 years ago

Thanks, @Otto42, that’s a great first step! Fwiw, I disagree that accessibility concerns fall into the category of ‘latest viewpoints’, but let’s keep moving here.

Coming back to your question of what would be an appropriate location for the microcopy currently stored in data-titles, the only place I can think of from the top of my head would be applicable on small screens only, as a kind of subtitle to the menu item. I’ve mocked it up here (could be made prettier, of course):
🖼 https://www.dropbox.com/s/9c8ebpin64bxol1/wp.org-menu-data-title-small-screen.png?dl=0

In that approach, we could probably totally move away from data- attributes altogether and use spans with a small-screen-only class and appropriate aria attributes. (@afercia, correct me if I’m wrong?)

Applying the same approach to larger screens doesn’t seem feasible, though, without considering a full redesign of the horizontal menu. I’m not sure that would still be within the scope of this ticket, but then again, a designer might have better ideas for a more holistic approach.

#27 in reply to: ↑ 26 @melchoyce
5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to glueckpress:

Coming back to your question of what would be an appropriate location for the microcopy currently stored in data-titles, the only place I can think of from the top of my head would be applicable on small screens only, as a kind of subtitle to the menu item. I’ve mocked it up here (could be made prettier, of course):
🖼 https://www.dropbox.com/s/9c8ebpin64bxol1/wp.org-menu-data-title-small-screen.png?dl=0

I think from a design standpoint, this works great within the existing mobile menu.

Applying the same approach to larger screens doesn’t seem feasible, though, without considering a full redesign of the horizontal menu. I’m not sure that would still be within the scope of this ticket, but then again, a designer might have better ideas for a more holistic approach.

This would definitely require a redesign of the header, IMO, not just the menu. We're long overdue for it, but I think that'll need to be addressed separately.

Edit: Just to clarify, reopened because I think we should implement @glueckpress' mockup, but I'm happy to close again and make a new ticket if that seems more appropriate.

Last edited 5 years ago by melchoyce (previous) (diff)

#28 @anonymized_7658014
5 years ago

Thanks, @melchoyce! 🎉

#29 @Otto42
5 years ago

Kinda makes the menu a bit tall on a phone though.

#30 @adamsilverstein
5 years ago

A good somewhat recent exploration of accessible tool tips: https://www.sarasoueidan.com/blog/accessible-tooltips/

#31 @joostdevalk
5 years ago

From a marketing perspective, these titles are detrimental. We're working on adding an Enterprise page to wordpress.org because as you all know, WordPress IS used in the enterprise. So there are at minimum two attributes that, no matter how we fix this, need to change:

  • "Come here for the latest scoop." is not something I understand. My English is good, but not native, just like for a large group of our users. So we should replace it with something less colloquial. "The latest news about WordPress" seems better to me.
  • "Find a home for your blog." doesn't do justice to all the types of sites that are built with WordPress and should thus be more like "Find hosting for your WordPress site".

Also, I'd totally be 100% OK with removing the title attributes altogether and not spending all this time of very valuable contributors :)

#32 in reply to: ↑ 22 @stommepoes
5 years ago

Replying to glueckpress:

@stommepoes Since those tooltips don’t carry essential information, I guess a media query could solve the issue with smaller viewports...

As mentioned in later replies, responsive decisions on this are a bit of a separate topic, but I just wanted folks to understand that media queries will affect (desktop) zoomers, but won't affect screen magnification such as in my example. So, viewport size queries wouldn't change the specific issue I was talking about, because the viewport will be large/desktoppy and zoom will likely be at normal/100% (I personally play with zoom per domain because some pages are nicer when they switch to "mobile" while others make me click a bunch more so I stay zoomed out... but both would be viewed through magnification, which lays "on top of" the browser-- the web page and JS have no knowledge of it running).
Cheers,

#33 @anonymized_7658014
5 years ago

@stommepoes Gotcha, thanks for following up! Makes total sense.

#34 @SergeyBiryukov
5 years ago

In 8166:

Trac: Menu: Move titles to data-title for now, as we come up with a better way to show these tooltips.

See [dotorg14783] for the change to global header.

See #4091.

#35 @wpfed
5 years ago

I just wanted to add, I worked with multiple professional accessibility experts and they absolutely despise title attributes, they must be removed!

@ryelle
3 years ago

Remove the title attribute from submenu items

@ryelle
3 years ago

Remove the title attribute from footer items, wrap footer in labelled nav area.

#36 @ryelle
2 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

The new header & footer don't use title anymore, so I'm going to close this.

Note: See TracTickets for help on using tickets.