How to Restore the Link Title Attribute Removed in WordPress 4.2

WordPress 4.2 is a week old and has been downloaded more than six million times. One of the first things I noticed after updating is the change to the Insert/edit link modal box. Instead of having to apply a title to the URL, the title is replaced with Link Text. The text that is highlighted before adding a link is automatically inserted into the Link Text box.

WordPress 4.2 Add Link Modal on the Left WordPress 4.1 on the Right

While I found this behavior to be annoying at first, it has quickly become one of my favorite changes. Adding links is quicker and more efficient. Several other people however, don’t like the change. WordPress user Enticknap created a ticket on Trac reporting the issue as a bug when in fact, the change was deliberate.

Drew Jaynes, who led the WordPress 4.2 development cycle, explained why the change was made.

The ‘Title’ field was intentionally removed from the wpLink modal in #28206 largely because it was often confused with the actual link text itself.

In recent years, we’ve begun to actively discourage the use of title attributes in links as they are largely useless outside of providing the “hover tooltip” many visual users enjoy, and more importantly, they don’t promote good accessibility.

If you’d like to continue using title attributes in links, you can add them manually using the Text mode in the editor.

Several people took part in the conversation, explaining why the Title box is an important part of their work flow. Andrew Nacin, who helped design the original Link dialog, said, “I wish this is how it worked from the start.” Nacin described the Title attribute as an edge case and that its bad for accessibility.

The discussion was heated at times, but the conclusion is that the Title attribute will not be added back to the dialog box. Instead, users are encouraged to use the Restore Link Title Field plugin developed by Samuel ‘Otto’ Wood and Sergey Biryukov.

Link Title Attribute Restored
Link Title Attribute Restored

With the plugin activated, the Insert/edit link dialog is restored to how it was in WordPress 4.1. According to the WordPress plugin directory, the plugin is activated on 100+ sites. I asked Wood if there are plans to add additional features.

“I don’t think adding new features is in the cards as there’s not much to add,” he said. “We might change it up as we fix some of the problems in core causing it to be difficult to do properly.”

WordPress is Continuously Evolving Software

I sympathize with those who are upset that the Link Title attribute was removed from WordPress 4.2. If a feature you depend on in WordPress is drastically changed or removed, the first instinct is to be upset. It forces you to change your workflow and the change is often unexpected.

I’ve traveled this path, but I’ve realized WordPress is continuously evolving software that tries to cater to the majority. Features removed from WordPress generally never go away as they’re replaced with plugins. A good example is when the ability to add borders and padding to images was removed in WordPress 3.9.

Advanced Image Editing Styles
Advanced Image Styles

This change lead to a lengthy discussion both on and support forums. Gregory Cornelius created the Advanced Image Styles plugin which re-adds the ability to adjust an image’s margins and borders as you could prior to WordPress 3.9. According to the plugin directory, it’s active on more than 20,000 sites.

I’m not saying you shouldn’t speak up when something you use in WordPress is removed. Rather, it’s a reminder that there is a way for everyone to get the features they want as WordPress core undergoes changes.

Note Before installing the plugin to restore the Link Title attribute, please read this post shared by Peter Wilson in the comments.


28 responses to “How to Restore the Link Title Attribute Removed in WordPress 4.2”

  1. Yes. Like Peter said, adding this plugin ia like going back in time. When features are removed from WordPress it is typically for a very good reason, and only done after extensive discussion. The argument that the removal of the title field disrupts a workflow is a bit of a red herring: if the workflow includes the title tag, then the workflow goes against recommended practice. Things change and improve over time and we need to change with them to stay ahead. This is a perfect example of evolution in software. Move with the flow.

    • I understand what you’re saying. For example, I used to paste in the URL to both the URL and Title fields out of habit, so people would see a tooltip to the full URL it points to. That’s why I’m primarily a fan of the change. As for workflow, I meant it in a general sense. When WordPress drastically changes a feature or removes it, it forces people to change their work flow. Most of the time, it’s for the better, but change is hard.

    • Of course it’s Morten who says exactly what I came to say! :)

      I completely agree and took issue with that same line. I think it’s really important that we use these moments to educate rather than offering a way to undo the change and encourage people to keep doing the same worst practices. The change wasn’t arbitrary. It was supported by a growing body of best practices!

      The next time something like this happens (like when WP hopefully removes that checkbox in the link modal!), I’d much prefer a WP Tavern article called “Users Upset as WP 4.2 Removes TItle Attribute from Links. Here’s Why That Change is Good.”

  2. Seems like a proper update to me – that’s a great overview there, Jeff.

    Although it’s an interesting problem in general – removing core features from WordPress. We keep adding things like Emoji or Press This (or enhance them while in Core) and remove other small bits like the media library options or the Title link here. We have long and dramatic discussions over things such as Post Formats UI.

    Some discussions are oriented toward “WordPress as a framework” that does not include all of the unnecessary things in core for a lot of projects, other claim that WordPress can’t survive without Jetpack (so why don’t integrate it in Core, right). And the stats for the Advanced Image Styles plugin that you linked above are also good to note – 20K+ active installs is not a small number, since I’m fairly certain that a good number of the users is struggling since they don’t know that this plugin exists, or they have implemented something custom, or another plugin, or the theme provides some styles and so on. The actual number of people with that problem certainly much higher, so I’m curious what does the decision making process look like in that case (or, as with the Post Formats UI in 3.6).

    Maybe it’s also time to resurrect and make some community effort when it comes to “what’s needed in WordPress according to the general public” :)

    • You’re right it’s hard to find out what little core enhancement features are available in (quality) plugins. I wish there was a “Tiny Repo” site that did this.

      It’s worth listening to what “the general public” wants, but the result tends to be “kid in the candy store who wants some of everything.” Take a popular, simple product, load it with endless “features,” and you will have a real challenge to keep the code and interface manageable. You might just end up with an “enterprise” product that can do everything but requires a month of training for users to get the hang of it, and at the end of all that they hate the cussed thing.

      The “advanced” image parameters came and went without me ever noticing they existed. I’m glad to see the title attribute field go away too. I agree with Morten about “going with the flow,” because overall the flow has been wise and certainly not self-sabotaging IMO.

  3. This is probably one of the few changes in recent years that I agree with. That title field was confusing and I always had a hard time explaining clients that that field wasn’t the actual link text.

  4. I’ve recently been convinced of the merits of removing title attributes from links, so this was a welcome change (or rather, it didn’t bother me in the least). The one thing I’m curious about is, if this was done partly in the name of accessibility, then why was the “Open link in a new window/tab” checkbox left there? Opening links in a new window isn’t accessible for anyone, so I’m surprised this was overlooked… Since it seems like WordPress 4.3 will be focusing a lot on improving accessbility, I wonder if this is another change we can expect fairly soon…

      • I don’t think it’s a case of trying to trap people on onto any particular site, more a case convenience. I for one always open links by right clicking the link and selecting, Open link in new Tab (Firefox). My reason! I tend to forget which site I came from, especially if the link is unrelated to the research I’m doing, plus, I tend to have ten plus sites open at once. Also, I hate having to backtrack using the, Go back one page button, especially when I’ve browsed through many pages. This is a real drag.

        • That’s entirely what it is. IIRC, this is why browsers came to use tabs and disallow a link attribute from opening a new window.

          I use browsers the same way you describe, and that’s the point — we decide when we’re going to get a new tab or window. Having the site you’re on decide that left click (or a tap or spoken command) may or may not result in a new tab or window does not make for a good, consistent user experience.

  5. To start, I’m a believer in an accessible web. Visually impaired folks need to access the web too.

    However, after reading that article I’m not convinced you shouldn’t use title attributes. Honestly it kind of sounds like the screen readers are the ones shooting people in the foot. Why not activate reading title tags by default? Additionally, I feel like people are insinuating that using a title attribute is discriminatory against those who are impaired. That’s simply not true. Use both! One of my favorite parts of the comics is the tooltip when you hover over the comic. Forcing that text into an invisible span tag would ruin the comic for me and everyone else who doesn’t need a screen reader.

    Rather than resort to hacky span tags and css,why don’t screen readers make a simple switch to reading it?

    • There are a few problems with using both:

      -Some screen readers do read the title text automatically, while some users do turn on the option. So if the title text is the same as the anchor text, then screen reader users hear the same thing twice in a row. And since screen readers read everything on the screen, that’s a real problem for comprehension and user experience.

      -But if the title text is different than the anchor text, then it mustn’t contain necessary or even relevant information, since keyboard-only** and mobile users can’t access it at all, and of course, many screen reader users won’t, either.

      -And what’s the point of including irrelevant or useless information? Who does that serve? Will the users who can view or hear the title text appreciate it?

      So no matter what, by using the title attribute, it’s a bad user experience for someone.

      ** I don’t think anyone has mentioned this so far, but title attributes don’t show up on keyboard focus, and there’s no technique to add info such as with the screen-reader-text class, as far as I know.

  6. I’ve never used that link modal, so it’s not a big concern of mine. If I want to put a title attribute in my link, I simply type it out. It’s much faster.

    Most of the arguments I see against using the title attribute are not because it’s bad to do so. Rather, the arguments are because the title attribute isn’t helpful to people using screen readers and people on mobile devices. Even Peter’s article linked above is the same. So, if the title attribute isn’t read/seen by certain groups of people, that doesn’t necessarily make it bad. It just makes it useless. And, people who are stuck in a habit of using them but being told they’re useless doesn’t do much to motivate them to change.

    What we really needed was an argument for why they’re actually bad or harmful to get users away from using them. I bet if you wrote a post called “Title Attribute Bad For SEO”, folks would drop them like a bad habit.

    • I bet if you wrote a post called “Title Attribute Bad For SEO”, folks would drop them like a bad habit.

      Well that’s the truth.

      While I think you’re right that there’s nothing explicitly bad about the title attribute itself, my concern is always that it makes think people they can use it to make up for bad link text, fix accessibility problems, affect SEO, etc. I’ve see all those things actually happen. If people have a need for tooltips, we should make sure that they provide those in a way that actually works for everyone.

    • There is something bad about the title attribute. Screen readers read everything on the screen, so there’s already an overload of information, and when the title text matches the anchor text, the user hears the same thing twice, which can be very confusing and annoying.

      Also, title text has no effect on SEO, as far as I’m aware, whereas anchor text does, right? Maybe the title of the article should be “Pump Up Your SEO with Strong Anchor Text & Blank Title Attributes” ;) Looking forward to reading it, whoever does end up writing it!

      • Screen readers do not read title attributes by default. That’s an option that must be enabled. However, I will agree that titles should never match the link text. Otherwise, they’re definitely useless in any context, regardless of how the user is reading/viewing the site.

        The “SEO” article was a joke about finding a way to get people to drop the title attribute. Although, your proposed article would make for a good read.

        • Some screen readers read the title attributes automatically, some require that the option be enabled, and some don’t even support it at all, so there’s no way to know for sure what experience a user will have. Either way, it looks like we’re on the same page ;)

          I suspected the SEO reference was a joke, but I also thought it had some real merit to it. I just did a quick search to see if maybe the article we want already exists, and I found a few interesting things:

          Think that you can simply add descriptive text to your “click here” link’s title attribute? Think again. Back in the 1990s I too thought these were the bee’s knees. Turns out they are completely ignored by all major search engines. […] They have nothing to do with Google.

          -from 16 SEO Tactics That Will NOT Bring Targeted Google Visitors

          In all of my testing scenarios, the title attribute do not seem to be picked up by Google and adding a link to that element did not seem to affect this result at all. If you really think about it, this makes complete sense. Since you can place title attributes in almost every element of a website, it would be very easy for a user to affect the search engines by keyword stuffing throughout their web pages, something that Google and the other major players do not want, hence why title attributes do not help with SEO.

          -from Do Alt and Title Attributes Help With SEO?

          They’re both older articles, but somehow, I doubt things have regressed since then…

  7. I don’t use the link modal either, and really couldn’t care less about the Title field being there or not. I only wrote the first version of the plugin as an exercise in how to modify some core javascript. I’ve learned quite a bit from doing so. Not a JS guru. :)

    In any case, I support users having choices, and if somebody wants that field back, then by all means, a plugin to put it there and make it work simplest it is the right way to go. In the process, we discovered a few minor core issues making things like this somewhat difficult to do, and with any luck, we’ll get those fixed for 4.3 as well. So, well worth the time spent on it, I think.

  8. More than anything this discussion (and the one about the image style features) brings up an important point about explaining what is going on and why it’s happening. As with the image styles, there was no official announcement from the core team about this feature being removed nor an explanation of why. For the average end-user this is terrible because lack of info means they’ll most likely think something a) is wrong with their site, or b) is wrong with WordPress.

    As we move forward it is more and more important that changes like these are announced and explained to the end user in the same way that new features like emoji and Kickstarter support is announced.

    This isn’t a feature problem, it’s a communication problem.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.