Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 21 months ago

#24766 closed defect (bug) (fixed)

Title attributes galore. They serve no useful purpose.

Reported by: karlgroves Owned by:
Milestone: 3.7 Priority: lowest
Severity: normal Version:
Component: Accessibility Keywords: 3.7-early has-patch needs-refresh
Focuses: Cc:

Description (last modified by DrewAPicture)

This is a full list of methods, including what files they're from, where HTML title attributes are in use.

The title attribute provides a tooltip on certain browsers. Other than that, it is essentially useless. As provided in Wordpress, the title attribute is both redundant and useless, because in most cases, it is a complete duplicate of the link's text. Therefore the tooltip provided is of no value whatsoever.

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.

Essentially the extensive use of title attributes throughout Wordpress Core amounts to unnecessary code bloat.

I recommend eliminating the title attributes from all of the methods below:

// user.php

// post-template.php

// media.php

// media-template.php

// link-template.php

// default-widgets.php

// comment-template.php

// class-wp-theme.php

// class-wp-editor.php
wp_fullscreen_html(). There is one title attribute here on what I think is a TinyMCE button. If that looks like a button, it should actually be a button.

// class-wp-customize-section.php

// category-template.php

// bookmark-template.php

// author-template.php

// rss.php

// general-template.php

// class-wp-admin-bar.php
  • Note:

Ignored: All Third party classes

Attachments (4)

24766.diff (21.0 KB) - added by sabreuse 2 years ago.
24766.1.diff (2.9 KB) - added by sabreuse 2 years ago.
24766.2.diff (10.7 KB) - added by sabreuse 2 years ago.
24766.3.diff (10.9 KB) - added by sabreuse 2 years ago.

Download all attachments as: .zip

Change History (49)

#1 @tw2113
2 years ago

  • Cc michael.d.beckwith@… added

#2 @sabreuse
2 years ago

  • Cc sabreuse added

#3 @johnbillion
2 years ago

Previously: #24203

#4 @ryan
2 years ago

See also #18984, which has some conversation on how heavily people use the title attribute for tooltips. Note that every time we remove a title attribute, we get lots of complaints.

#5 @sabreuse
2 years ago

The complaints we've gotten seem to be mostly (maybe all?) about removing titles from images, where they're used for xkcd-style punchlines. These all appear to be tooltips on links -- mostly things like "see all posts in $category". Furthermore, the proposed changes don't do anything to take away the end user's ability to add a tooltip to their own links in content.

+1 to remove, because of the accessibility concerns and not just for random clutter-busting.

#6 @tw2113
2 years ago

While it'd be slightly more work and also a touch of javascript, I think anyone using it for XKCD style punchlines could use something like data-* attributes or maybe rel tag, though that last one may be considered improper user.

#7 @sabreuse
2 years ago

@tw2113, awesome plugin, dude!

(But seriously. Users should be able to add tooltips to their content, but the list in this ticket is UI elements + template tags -- stuff that isn't part of the content editing workflow at all.)

#8 @jorbin
2 years ago

I'm going completely agree with @sabreuse here. I think this is something we should aim for 3.7 early.

#9 @DrewAPicture
2 years ago

  • Component changed from General to Accessibility
  • Description modified (diff)
  • Keywords dev-feedback added

#10 @toscho
2 years ago

  • Cc info@… added

#11 @karlgroves
2 years ago

Nothing useful to add other than to say thanks to all of you for your attention and discussion. Thanks

#12 @Frank Klein
2 years ago

  • Cc contact@… added

#13 @esmi
2 years ago

+1 to getting rid of as many title attributes as possible. Apart from creating unwanted noise for screen reader users, they are completely inaccessible to sighted keyboard navigators. If some scrap of data is so important that it MUST be added via the title attribute, then you have to wonder why it's not in clear text on the page where everyone has access to it.

#14 @ryan
2 years ago

No objections from me. My earlier comment was just the obligatory providing of history.

#15 @helen
2 years ago

  • Keywords needs-patch 3.7-early added; dev-feedback removed
  • Milestone changed from Awaiting Review to Future Release

2 years ago

#16 @sabreuse
2 years ago

24766.diff is a first pass at cleaning up most of these, with the following exceptions:

  • the_author_posts_link() - deprecated, so not much point in updating
  • rss.php - deprecated
  • wp_fullscreen_html() - this occurence is the tooltips on each of the editor buttons; in this case, I feel they're true tooltips and not just interface clutter, especially for some of the more cryptic editor icons
  • get_adjacent_post_rel_link() - this function is used for search metadata in links in the html head, not in the body
  • _walk_bookmarks() - the title on bookmarks is opt-in, and is not rendered (even as an empty attribute) unless the user has chosen to fill it in on each individual bookmark. For that reason, it seems to me more like a title tag that was deliberately added to user content.
  • get_image_tag(), the_shortlink() - in both cases, the title is passed to the function as an argument, and both functions are used in plugins. We can't change the function calls without breaking things, and I don't feel right leaving the args totally unused without at least a look at what a better design might look like.

Bonus round! I found a few more title attributes that weren't included in the original list.

  • two instances in wp-login.php
  • get_archives_link()

#17 @sabreuse
2 years ago

  • Keywords has-patch added; needs-patch removed

#18 @wonderboymusic
2 years ago

  • Milestone changed from Future Release to 3.7

these are all marked 3.7-early

#19 @helen
2 years ago

Seems like some of these need to be more closely evaluated, e.g.

<a class="media-modal-close" href="#" title="<?php esc_attr_e('Close'); ?>"><span class="media-modal-icon"></span></a>

I guess the text should be in the span and then pushed off screen / otherwise accessibly hidden.

#20 @karlgroves
2 years ago


Yes, there should be text in the span.

#21 @nacin
2 years ago

Looking through 24766.diff, I'm finding a lot of questionable ones. Can we start with a patch that only removes title attributes that exactly match the anchor text? The remaining ones are less straightforward. For example (in addition to the media modal strings that Helen highlighted):

  • "Are you lost?" is an easter egg of sorts — does not match the title text.
  • $login_header_title is a little "Powered by WordPress" statement.
  • "Password Lost and Found" could also be considered a bit of an easter egg — again, does not match the title text.
  • $topic_count_text_callback is a tooltip that displays the actual number of tags, when viewing a tag cloud.
  • The ones in the meta widget add information.
  • The RSS widget is a title tag attached to an anchor surrounding just an image.
  • Removing the API to specify a title in the toolbar could have ramifications. For example, hovering over the Updates item gives you a breakdown. We should remove any bogus title tags we are passing into the API, but not actually remove the API.

So, basically, some questions to ask:

  • Does the title attribute add some useful information to the anchor text?
  • Are they designed to be used as tooltips?
  • Are we removing an API?

A yes to any of these questions doesn't mean "OMG the title attribute must stay." I'm all for stripping title tags out of template tags and such, and I led the charge in #18984 to remove tooltips from media. Happy to consider removing more title tags than not, but it would be good to do this with a fine-toothed comb.

#22 @helen
2 years ago

Can we also break patches for this ticket up a little bit? Not necessarily one per file, just not one giant one to reduce the risk of a patch going stale and effort spent refreshing.

#23 @esmi
2 years ago

In order to preserve momentum on this, I think that separate tickets is an excellent idea. So one ticket to remove "noisy/redundant" title attribs, yes? What about the others? I suspect that many would need to be argued on a case-by-case basis.

#24 @nacin
2 years ago

helen was only suggesting multiple patches, not necessarily multiple tickets.

I proposed multiple patches in the form of phases — start with removing purely redundant attributes and work from there.

#25 @sabreuse
2 years ago

Yes, I agree with multiple patches -- starting with the easy ones is already an improvement.

#26 @helen
2 years ago

Nobody interested in making some smaller patches? We can start with the purely redundant ones.

#27 @sabreuse
2 years ago

I can work on breaking this up this weekend.

2 years ago

2 years ago

#28 @sabreuse
2 years ago

Two updated patches attached. 24766.1 contains changes that are identical or near-identical to the link text (for example: title text of "edit this" on a link that says "edit" isn't an exact match, but it isn't really adding much else). 24766.2 is the changes that are more "tooltippy". I still favor removing, but if folks feel that those are needed & used as help text, then let's discuss.

For now, I've left out the trickier issues raised by Helen and Nacin, including the easter eggs, in the interest of getting some of this committed.

#29 @nacin
2 years ago

In 25570:

Remove redundant title attributes.

props sabreuse.
see #24766.

2 years ago

#30 @sabreuse
2 years ago

24766.3.diff removes two more titles in _get_plugin_data_markup_translate() and fixes a thing in .2 where I accidentally added one. No, I have no idea how or why that happened, for the record.

#31 @vinod dalvi
2 years ago

  • Cc mozillavvd@… added

#32 @nacin
2 years ago

In 25675:

Remove redundant title attributes.

props sabreuse.
see #24766.

#33 @nacin
2 years ago

  • Milestone changed from 3.7 to 3.8

24766.3.diff needs to be refreshed after [25570] (and [25675]). Also:

  • It often leaves title attributes in the same function. (For example, only one of six are removed in get_the_category_list()).
  • I'm not sure we should remove "Visit author's homepage" and such for plugins and themes. Could someone argue one way or the other why these should stay or go?
  • It breaks some strings (example: the "Log out of this account" title attribute), which is fine, but not for 3.7.
  • Sometimes code is no longer referenced, but isn't fully removed. For example use_desc_for_title.

This looks good, just needs more review/examination. Solid work so far in 3.7.

#34 @esmi
2 years ago

I'm not sure we should remove "Visit author's homepage" and such for plugins and themes. Could > someone argue one way or the other why these should stay or go?

They should go. I think that the general purpose/context of the link is obvious (ie "this is going to take me somewhere that relates to the author") so I don't see a need to over egg it. Secondly, the title attribute is only going to be available to mouse users. The majority of non-mouse users won't be able to access it.

#35 follow-up: @tw2113
2 years ago

Curious what anyone's thoughts or objections will be to removing from the media uploader/edit image modals. I know of one person who is confused by this part. When she sets a "title" on upload, which sets the attachment title, she sees a blank title field in the "Edit image" popup, when clicked in the visual editor, that is setting the title attribute on the image.

If for some reason it's decided to keep those, then perhaps set a default title attribute that matches the the attachment post title for the upload.

#36 @matt
2 years ago

  • Priority changed from normal to lowest

#37 in reply to: ↑ 35 @helen
2 years ago

Replying to tw2113:

Curious what anyone's thoughts or objections will be to removing from the media uploader/edit image modals.

That's not what this ticket is about.

#38 @helen
2 years ago

  • Keywords needs-refresh added
  • Milestone changed from 3.8 to Future Release

Also, punting. Needs attention, though, please.

#39 @joedolson
2 years ago

I think breaking this up into sub tickets is the way to go. As is, this is a little too big to easily manage for such a set of discrete tasks. The original ticket breaks it up by file, so unless somebody strenuously objects to that in the next few minutes, I'll create new tickets on that basis.

#40 @joedolson
2 years ago

Split into new tickets:

#26547 - user.php
#26548 - post-template.php
#26549 - media.php
#26550 - media-template.php
#26551 - link-template.php
#26552 - default-widgets.php
#26553 - comment-template.php
#26554 - class-wp-theme.php
#26555 - class-wp-editor.php
#26556 - class-wp-customize-section.php
#26557 - category-template.php
#26558 - bookmark-template.php
#26559 - author-template.php
#26560 - rss.php
#26561 - general-template.php
#26562 - class-wp-admin-bar.php

#41 @joedolson
2 years ago

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

#42 @helen
2 years ago

  • Milestone changed from Future Release to 3.7
  • Resolution changed from invalid to fixed

This has commits against it in 3.7.

#43 @joedolson
2 years ago

Great - hopefully that means some of the new tickets will be resolvable quickly, once I'm through them all.

This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.

22 months ago

This ticket was mentioned in IRC in #wordpress-dev by jessepollak. View the logs.

21 months ago

Note: See TracTickets for help on using tickets.