Title attributes galore. They serve no useful purpose.

[karlgroves]

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
wp_authenticate_username_password()


// post-template.php
wp_page_menu()
wp_get_attachment_link()

// media.php
get_image_tag()

// media-template.php
wp_print_media_templates()

// link-template.php
edit_term_link()
edit_post_link()
edit_comment_link()
edit_bookmark_link()
get_adjacent_post_rel_link()
the_shortlink()

// default-widgets.php
widget()

// comment-template.php
comments_popup_link()
comment_form()

// class-wp-theme.php
markup_header()

// 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
render()

// category-template.php
get_category_parents()
get_the_category_list()
wp_generate_tag_cloud()
start_el()

// bookmark-template.php
_walk_bookmarks()

// author-template.php
get_the_author_link()
the_author_posts_link()
wp_list_authors()

// rss.php
wp_rss()
get_rss()

// general-template.php
get_calendar()

// class-wp-admin-bar.php
_render_item()

• Note:

Ignored: All Third party classes

[johnbillion]

Previously: #24203

[ryan]

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.

[sabreuse]

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.

[tw2113]

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.

[sabreuse]

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

[jorbin]

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

[karlgroves]

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

[esmi]

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

[ryan]

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

[sabreuse]

​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()

[wonderboymusic]

these are all marked 3.7-early

[helen]

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.

[karlgroves]

Helen,

Yes, there should be text in the span.

[nacin]

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.

[helen]

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.

[esmi]

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.

[nacin]

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.

[sabreuse]

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

[helen]

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

[sabreuse]

I can work on breaking this up this weekend.

[sabreuse]

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.

[nacin]

In 25570:

Remove redundant title attributes.

props sabreuse.
see #24766.

[sabreuse]

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.

[nacin]

In 25675:

Remove redundant title attributes.

props sabreuse.
see #24766.

[nacin]

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.

[esmi]

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.

[tw2113]

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.

[helen]

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.

[helen]

Also, punting. Needs attention, though, please.

[joedolson]

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.

[joedolson]

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

[helen]

This has commits against it in 3.7.

[joedolson]

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

[ocean90]

In 38075:

Import: Enhance accessibility on the Import screen.

• Remove title attributes.
• Show "Install Now" and "Details" links if the importer isn't installed yet.
• Show a "Run Importer" link if the importer is installed. It also handles activation if the plugin isn't activated.
• Add aria-label attributes to each link.
• Unify the importer descriptions to make them independent from the plugin state. The API was changed in ​[meta3690].
• Adjust JavaScript callbacks for ajaxified importer installs.

Props afercia, swissspidy, ocean90.
See #24766.
Fixes #35191.

[afercia]

To give an idea of the progress done so far and have some data for history, I've scanned the codebase from version 4.0 to 4.7. Searching for occurrences of title= (space title equal) within .php files in the wp-admin directory, so this count leaves out title attributes in other files and the ones added via JavaScript:

4.0: 157 results found in 37 files
4.1: 156 results found in 37 files
4.2: 146 results found in 35 files
4.3: 101 results found in 30 files
4.4:  97 results found in 32 files
4.5:  21 results found in 12 files
4.6:  19 results found in 11 files
4.7:  17 results found in  9 files

Checking the 17 title attributes in 4.7:

• 4 are legit because they're used on <iframe> elements
• 7 used in the wp-admin/includes/class-wp-theme-install-list-table.php file, as far as I know no more used by core
• 1 used in the wp-admin/includes/class-wp-themes-list-table.php file, as far as I know no more used by core
• 1 used in the Dashboard for the Search Engines Discouraged link and since 4.5.0 The default for $title was updated to an empty string

That leaves us with 4 title attributes still candidate for removal:

• 2 used for the Comments icon in the Posts and Media list tables header
• 1 used in the Posts list table for the expanded post date
• 1 used in the Bulk Edit form for the "X" icon in the list of the edited posts

From 157 down to 4, not to mention many of these occurrences were within loops so the number of title attributes actually output was higher. It would be really interesting to check if any complaints or usability regressions caused by the title attributes removal have ever been reported for the last 7 releases. Personally, I haven't heard any.

[afercia]

In 40816:

Widgets: Remove the title attributes used in the Tag cloud widget.

• improves accessibility using an aria-label attribute to match the information conveyed visually with the one exposed to assistive technologies
• adds an option in the widget to display the item counts, consistently with what other widgets already do (Archives, Categories)

Props adamsoucie, emirpprime, Samantha Miller., MikeLittle, rianrietveld, sami.keijonen, adamsilverstein, westonruter, afercia.
See #24766.
Fixes #35566.

[afercia]

As for other accessibility long-term tasks, see for example #23432, this should be set to blessed task and Future Release.

[afercia]

In 45728:

Accessibility: Remove title attributes from the Meta widget.

• removes the Powered by WordPress, state-of-the-art semantic personal publishing platform. title attribute
• removes the title attribute from the abbreviations: contrary to a common belief, title attributes on abbreviations are only available to a minority of users, see ​https://developer.paciellogroup.com/blog/2019/03/short-note-the-abbreviation-appreciation-society/
• changes the term RSS to feed, as RSS is a technical term not all users are supposed to be familiar with
• improves the widget_meta_poweredby filter documentation

Props nishitlangaliya, chetan200891, audrasjb.
See #46980, #24766.
Fixes #46978.

[afercia]

Update: [47879] removed the title attribute used in the Posts list table for the expanded post date.

That leaves us with 16 occurrences of title attribute in the wp-admin directory. As mentioned in comment:47, some of them are legitimate and others are unused. Still to do:

• 2 title attributes used for the Comments icon in the Posts and Media list tables header
• 1 title attribute used in the Bulk Edit form for the "X" icon in the list of the edited posts, see #35483
• the whole wp-includes directory: only one ticket so far, see #26562
• title attributes in the various JavaScript files
• title attributes in the bundled themes

[audrasjb]

In 53392:

Taxonomy: Set use_desc_for_title to false by default in wp_list_categories()

This change removes the default title attribute of category links returned by wp_list_categories(), for better accessibility.

Props just0nequestion, joyously, andrija, audrasjb, sabernhardt.
Fixes #55530.
See #24766.

[SergeyBiryukov]

In 53414:

Accessibility: List Tables: Hide the Comments column icon and title attribute from screen readers.

The element already has non-visual text, making the icon and the title attribute redundant for assistive technologies.

Follow-up to [22439], [27548], [31513], [32991], [50804].

Props sabernhardt, ryokuhi, afercia, karlgroves, SergeyBiryukov.
Fixes #55555. See #24766.

[joedolson]

#56415 was marked as a duplicate.

[audrasjb]

In 54884:

Twenty Eleven: Remove useless title attributes.

This changeset removes title attributes from various links, as they are adding redundant information.

Props sabernhardt.
See #57199, #24766, #24203.

[audrasjb]

In 54885:

Twenty Nineteen: Remove useless title attributes.

This changeset removes title attributes from links, as they are adding redundant information.

Props sabernhardt.
See #57199, #24766, #24203.

[audrasjb]

In 54922:

Twenty Ten: Remove unwanted title attributes.

This changeset removes title attributes from various links, as they add redundant information.

Follow-up to [53844].

Props sabernhardt, costdev, mukesh27.
See #57199, #24766, #24203.

[audrasjb]

In 54923:

Twenty Thirteen: Remove unwanted title attributes.

This changeset removes title attributes from various links, as they add redundant information.

Follow-up to [53844].

Props sabernhardt, costdev, mukesh27.
See #57199, #24766, #24203.

[audrasjb]

In 54924:

Twenty Twelve: Remove unwanted title attributes.

This changeset removes title attributes from various links, as they add redundant information.

Follow-up to [53844].

Props sabernhardt, costdev, mukesh27.
See #57199, #24766, #24203.

[audrasjb]

In 54925:

Twenty Twenty: Remove unwanted title attributes.

This changeset removes title attributes from various links, as they add redundant information.

Follow-up to [53844].

Props sabernhardt, costdev, mukesh27.
See #57199, #24766, #24203.

[joedolson]

This is so close to finished, I think we should try and close this ticket in 6.5. There's almost nothing left, but those last remaining items will need some work and decision making.

[adnan.limdi]

Remove Unwanted title for rss.php

[adnan.limdi]

Remove Unwanted Title Descriptions for rss.php

[adnan.limdi]

Remove Unwanted title for author template file.

[adnan.limdi]

Remove Unwanted title for author template file.

[sabernhardt]

@adnanlimdi Thanks for the patches!

The rss.php file is likely not worth editing now because MagpieRSS is a deprecated external library, and it may be removed (ticket:59548#comment:2).

For the author functions, #26559 retained some title attributes because the "Posts by author" and "Visit author's website" tooltips still had a small additional value for anyone who could access them. (The important information was already in the visible link text.) If that decision should be reconsidered, a new ticket could focus on those functions, and any ​patch would need to update the unit tests too.

[webcommsat]

Raised in bug scrub Dec 19, 2023:
@adnanlimdi thanks for working on this. Would you be able to update this ticket with a reply on the patch and updating the unit tests? Thanks @sabernhardt and @adnanlimdi for helping move this ticket forward.

[adnan.limdi]

@webcommsat

I have reviewed unit test and it's working fine.

Replying to webcommsat:

Raised in bug scrub Dec 19, 2023:
@adnanlimdi thanks for working on this. Would you be able to update this ticket with a reply on the patch and updating the unit tests? Thanks @sabernhardt and @adnanlimdi for helping move this ticket forward.

[audrasjb]

Replying to sabernhardt:

For the author functions, #26559 retained some title attributes because the "Posts by author" and "Visit author's website" tooltips still had a small additional value for anyone who could access them. (The important information was already in the visible link text.) If that decision should be reconsidered, a new ticket could focus on those functions, and any ​patch would need to update the unit tests too.

Shouldn't we just replace the title attribute with aria-label?

[joedolson]

This should also consider a text order change. For screen reader users, the unique information should go first: 'website: author', 'posts: author'; but for voice command, the visible information should go first: 'author: website', 'author: posts'.

[joedolson]

There are just a few outstanding instances of this remaining in core. We should document them, create new tickets for those we still want to fix, and leave documentation here for any we have chosen not to fix intentionally. Then we can close this ticket.

In my opinion, it doesn't help us to leave giant unapproachable tickets like this open when the majority of the work is already done.