Link Text box in Insert/edit link

[Enticknap]

Previously in the Link Text box on the Insert/edit link panel, it was possible to customise the text that appeared when the cursor rolls over the link - the link title.

In 4.2, the only Link Text enabled is the actual text which is being linked; if I change the Link Text, it also changes the text in the blog.

This applies to new links created post 4.2. Earlier links still display the rollover link text.

[SergeyBiryukov]

Hi @Enticknap, welcome to Trac!

This was a deliberate change in [31713], see comment:9:ticket:28206.

[netweb]

See also: ​https://wordpress.slack.com/archives/core/p1429148945004442

Helen
we definitely removed the title attribute and are not putting it back.

[DrewAPicture]

Just to give you a more complete answer:

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.

[Enticknap]

Replying to DrewAPicture:

Just to give you a more complete answer:

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.

Thanks for explaining that - I've always found that field handy but I understand the logic of changing it if users are confused. Manual text mode is good. Apologies for raising it as a bug, I did search to see if it was deliberate but couldn't find anything. Congrats with 4.2 which looks great.

[netweb]

Replying to Enticknap:

Apologies for raising it as a bug, I did search to see if it was deliberate but couldn't find anything. Congrats with 4.2 which looks great.

Don't apologise, it was a good thing, if you were correct we'd now know about the issue, I closed a ticket earlier because I thought it was a theme issue (which it kind of is), but nevertheless it was a new function introduced in 4.2 I didn't know about :)

[ocean90]

#32098 was marked as a duplicate.

[SergeyBiryukov]

#32100 was marked as a duplicate.

[ocean90]

#32107 was marked as a duplicate.

[ikulagin]

Hi guys. Yes it might confuse somebody, but still I was using it a lot, actually for any link in my post. I have read some comments there that in most cases people use TITLE the same as the anchor. I don't know, may be in English language websites they do, but for me on Russian websites it's much more useful to place a short link and a good description which website's visitors really use and more often click those links.

Adding TITLE links through plain text as recommended is pain. It was really one of my favorite options in WordPress to automatically place TITLE attributes when you link to a post on your website.

I think that it's unfair to decide for everybody and eliminate such a useful function.

This option should be returned, at least it should be hidden under advanced options link.

Changing link text instead in the link editor is an unnecessary option at all as in most cases you will never change it.

[ocean90]

#32124 was marked as a duplicate.

[TempAcc]

Why WordPress Developers prefer the mobile users at the expense of desktops? This is very similar to the insult!

[Hansaplastique]

I hope this is not inappropriate to post/contribute/chime in here,...
To avoid all kinds of extra tickets in Trac, I figured give this a try first.

Wouldn't it be something to consider to offer the "title" tag optional?

For example, by default not visible (to support your vision to get rid of the title tag), but if folks insist to keep using it, they can enable it again? Maybe even hidden in /wp-admin/options.php?

I for one still actively use the title tag and this change makes editing posts a lot more cumbersome (manual adding the tag).

p.s. I see plenty request in Trac concerning this topic, and at least one post in the support forum. So I would assume that not everybody agrees with the vision to drop the title tag ... :-(

[Sabinooo]

I'm also in favour of returning the title field, it can be made as optional, in something that must be ticked as "additional options" in the hyperlinking dialogue box, if necessary.

I'll politely try to adress the "mobile users are not seeing it anyway" and the "accessibility" arguments, with a simple metaphor : if the internet is a forest rich with many trees, we can't chose our favorite tree, and chop off the branches of the trees having more branches than our ideal tree.
See the idea ? Less is not necessarily beautiful, here, you're depriving part of the users of something they could have found good, while those who didn't view it won't be caring in the first place.

Additional note : it's mostly in English that there is room for confusion between the notions of title and link text, I asked around, and for the 4 other languages for which I could have an answer, besides my own, the confusion wasn't possible.

(edit : looking back, I should have left the page as "resolution closed", I apologize about that! I'm nto familiar with Trac)

[negue.c]

Hello everyone.

I too was using the title tag for virtually all my links. I know how to add/change them manually, but I link many times a day (it's a lotto site with results updating every few hours).

Couldn't it be at least optional? Go to Settings and tick for yourself if you want the title tag or not when clicking to edit/add the link in "View" mode?

Thank you all for your time and energy on this!

[ocean90]

#32133 was marked as a duplicate.

[tedweinstein]

I agree: I'm disappointed that WP removed this functionality. If there was user confusion, there are ways to address that. One idea: in the link settings popup, label it as optional "hover text". It's frustrating to have this functionality removed, especially for the many many WP users who aren't comfortable editing HTML directly.

[dmchale]

After a conversation in Slack, Otto posted a link to a plugin he whipped up for people to add the Title field back ... he admits it's relatively untested, but if it works for people he'll likely add it to the repo. I definitely fall in the camp of "wish this was discussed more before it was removed" since I too use title tags all the time (and created one of the apparently-duplicate tickets about the issue) but at least we can easily add it back with this for now. Works for me on the 1 website I've installed it on so far.

Otto's plugin: ​Click here

[Radices]

I'd love to see the back ground data that supports the notion that it confused lots of people. I haven't seen one instance in the support forums where someone was having issues with the Title attribute in a link.

It's an attribute just like any other. You need to understand it to use it properly. I use it exclusively to inform users that the link will open in a new window. That's good practice some would argue.

​http://www.ucop.edu/electronic-accessibility/web-developers/inform-users-when-a-link-opens-in-a%20new-%20window.html

In any case "We took it out and we are not putting it back" is not very community spirited. I like the suggestion to make it an advanced option.

It's telling that the first line of Otto's plugin is "put the title field back where it belongs"

[nacin]

I was one of the people who led the original design of the link dialog. I wish this is how it worked from the start.

Title attributes are an edge case. They're bad for accessibility (as a reader), they're pretty useless for the writer, and the user experience for adding a link deserves having the anchor text front and center (countless other applications out there that also do this). I'm not even just arguing that this option shouldn't be here — I'm arguing that title attributes probably shouldn't be used, that they are themselves mostly useless.

This wasn't just a decision for mobile. It is unquestionably a better user experience. There is no advanced options UI here, nor should there be — we make decisions; we don't add options. (​http://nacin.com/2011/12/18/in-open-source-learn-to-decide/, ​https://wordpress.org/about/philosophy/)

I wasn't directly involved in the decision process for this. In fact, I first noticed it when I was writing a blog post a few days after it was added. As someone pretty intimately familiar with WordPress's UI, I instantly noticed something was different. But what I also noticed is it felt right.

If you want to add a title attribute, the "advanced option" is the HTML editor. Or, use a plugin! It's cool that one exists.

[Der-Bank-Blog]

I am clearly voting for the title tag in Terms that it supports SEO and the UX. I really would love to see this Feature back again.

Plugins are not a really good Option. It should be avoided to decrease WP's functionality and afterwards increase it again with a plugin. That is never a good way.

[Hansaplastique]

Resolving this with yet another plugin is something I can't really see as a good permanent solution to fix something that should probably not have been broken to begin with. I keep my plugins to a bare minimum, because of the usual lack of maintenance and further development of plugins.

Taking away WP functionality is in my opinion one of the causes why things break (plugin or workflow).

I can see and understand the "why"it was removed, but with removing things like this, more user involvement would have been better to collect data to see if this is even wanted. Maybe a poll on the Dashboard or something like that, with a minimum number of votes ...?

When I look back at the "removal" over "Links": this was done the right way.
It's no longer obviously there, but those depending on it can still use it.
That's probably the route that should have been taken here as well.

As for the possible confusion by users: I have never met a user that got confused by it. Better wording would have resolved that right away ... instead of taking away functionality.

Arguing the "user experience" is something the admin of a website should decide for herself/himself.

The user "netweb" posted a nice "fix" in #28206, and if "title" is confusing then use something like "hint (optional)" ... for example:

[Hansaplastique]

Really not intended to fire up the discussion even more ... I'm just trying to point out that both views are supported ...

On "that page" (HTML5 draft):
It says nowhere "stop using this" or "no longer support".
However it does state exactly what most of us are using it for: appropriate for tooltips.

It also says that "relying on it is discouraged", as it may not reach all users [agents] ...

(from ​http://www.w3.org/TR/html51/dom.html#the-title-attribute).

3.2.5.2 The title attribute

The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image; on a paragraph, it could be a footnote or commentary on the text; on a citation, it could be further information about the source; on interactive content, it could be a label for, or instructions for, use of the element; and so forth. The value is text.

Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).

If this attribute is omitted from an element, then it implies that the title attribute of the nearest ancestor HTML element with a title attribute set is also relevant to this element. Setting the attribute overrides this, explicitly stating that the advisory information of any ancestors is not relevant to this element. Setting the attribute to the empty string indicates that the element has no advisory information.

[earnjam]

If you want to create non-accessible content that's only helpful for users with a specific type of device, that is your choice, and it is still possible through a variety of methods.

However, core does not need to actively encourage the use of something that is discouraged by the HTML spec itself.

[Hansaplastique]

I do respect everybody's opinion ...
But it seems that the draft is read differently by different people ... (no pun intended)

"discourage the use of the title tag"
ie. do not use it, it's broken, it's bad, it's evil, we'd like to drop it, etc.

or

"discourage relying on the title tag"
ie. Use it but be aware of it's limitations (not all user agents might display it).

It clearly says "Relying on the title attribute is currently discouraged" ...
It also says "The title attribute represents advisory information for the element, such as would be appropriate for a tooltip".

My interpretation is therefor: Use it, it's appropriate, but be aware that it has limitations on some user agents.
Not to mention that tooltips work just fine in on my tablet and mobile phone.

I have zero experience with screen readers, but doing some searching with Mr. Google shows me that some screen readers support the title tag for A HREF just fine, some prefer aria over title (supporting both), and others do not support it unless you change your screen reader settings.

So we disagree on the interpretation of the HTML5 draft ...

[ifingers]

@Hansaplastique: The example you give of setting the title attribute to "Me scuba diving", where the link text already says "me scuba diving last summer", Is a great example of why the title attribute is not needed.

I don't buy into the arguments that the title attribute is useful for SEO and UX either. When you really think about it, what could be more honest, easier to understand than good descriptive link text? If you are creating websites for people, the more inclusive the site, the more people will use it. Which is the biggest SEO win going. Even forgetting the improvements to accessibility. This is a real no brainer. The title attribute must die! If you want to continue using it, you can do so in the html editor or by using a plugin. But I would argue that you are doing it wrong.

[Hansaplastique]

@ifingers:
I agree that the SEO value will be minimal at best.
And I admit the example picture is not the best to illustrate the case why, or why not, the title should be used. I just picked a picture I found in Trac to illustrate how it could be implemented.

As an illustration how I use the title tag;
On my website I have a menu on the side, which is width limited, so I'm limited in what I can write there. So I display a "short" version of the title. When the user (that can see tooltips) hovers over the link, a tooltip will show more details, like a more detailed explanation or even what language to expect, etc.
This tooltip works fine on desktop, laptop, tablet and mobile phone (tested with Android and iOS).
So in my opinion, my tooltip serves a very large group of users.

Bottom line, I think it's up to the website owner to decide what he or she thinks is good UX - each their opinion.
Specially since the HTML5 draft considers it a valid and appropriate tag for the tooltip purpose.

[ifingers]

@Hansaplastique: Sure, it's your website.

I too was at first dismayed to hear about the demise of the title attribute, because it was one of my favourite tools in my toolbox. But, when someone kindly took the time to explain to me the effect the title attr. has for screen readers in particular. I realised that I would need to find other ways of presenting long links, and other elements in width restricted areas.

Forget mobile-first, put people-first. ;) Best of luck!

[Avantart]

Replying to ifingers:

I don't buy into the arguments that the title attribute is useful for SEO and UX either. When you really think about it, what could be more honest, easier to understand than good descriptive link text?

this is not ok.

1) The link text very often is part of a phrase, follows grammatical rules, or you write kind of slang but the link title should be no-slang ...

2)
what is the profit of offering the input for link text and pre-filling it with the linktext from the post? The user overwrites it and by this accidently breaks the consistence of grammar (I cannot explain it better)

do you see my points?

[ifingers]

@Avantart: TBH, I'm not sure I follow you.

1, In my opinion the link text should be the title of the page/site that you're linking to.
Usability expert Jared Spool way back in 2004 found that links of 7 to 12 words achieved the highest success in getting people to the information they were seeking. Source: ​http://www.uie.com/reports/scent_of_information/.
2, Sorry, I don't understand your point here.

[bryceadams]

At the end of the day, the only features that need to be in WordPress are those that are used by 90% of users. What % of users do you think actively use and rely on the title attr option? I would guess under 10%. But then of those that do use it, they are probably aware and capable of adding it to the HTML itself.

Keeping it just because a minority group finds it of value completely goes agains the [WordPress Philosophy](​https://wordpress.org/about/philosophy/).

kudos to the team on removing it and to Enticknap for being very understanding of the reasons behind it.

[Nevis-1]

Just another bug as far as I am concerned, now need to use ANOTHER plugnin to get the usability back.

[Radices]

Bully's should need to be challenged no matter where they are encountered!

[DrewAPicture]

Replying to Radices:

Bully's should need to be challenged no matter where they are encountered!

We do our best to encourage civility in discussions that happen here on Trac. Nothing discussed here should be taken personally. WordPress is an incredibly inclusive community and anyone interested is encouraged to participate and make it better for everyone.

Please do not reopen the ticket again. Discussion can and should certainly continue here, but the ticket doesn't need to remain open for that to happen.

[Radices]

Fair enough but the closing of the ticket obviously had a chilling effect as I'm sure most thought as I did that comments were closed as well.

[SergeyBiryukov]

Restore Link Title Field plugin is now available in the directory:
​https://wordpress.org/plugins/restore-link-title-field/

[ReckonMind]

After updation of wordpress version 4.2.1 there is a bug in Insert/edit link feature available in posts.

This has made internal site linking very difficult and tedious task.

How earlier Insert/edit link feature worked:
Steps to use Insert/edit link feature

1. Go to draft post and type [Read: xyz (xyz is any random alphabet which will later be replaced by the link text after step5 )
2. Select xyz and click on Insert/edit link
3. Type the Search word
4. Select from the published post from Insert/edit link search box
5. On selection of post the url and link text use to get updated as per the selected post in previous wordpress version. However in current 4.2.1 version the Link text does not get updated with as per the selection of post title.

This has made internal site linking very difficult and tedious task.

[ReckonMind]

Replying to SergeyBiryukov:

Restore Link Title Field plugin is now available in the directory:
​https://wordpress.org/plugins/restore-link-title-field/

Thanks for sharing however it does not pick up the title automatically. The Title and Link text still remains blank unlike in previous version of wordpress..

Please help in getting back Title and Link text field filled automatically as it was happening in earlier version. This has really made the site linking work too tedious and time consuming.

[SergeyBiryukov]

Replying to ReckonMind:

On selection of post the url and link text use to get updated as per the selected post in previous wordpress version. However in current 4.2.1 version the Link text does not get updated with as per the selection of post title.

There were no Link Text field in 4.1, it was a title attribute.

The Link Text field is new to 4.2, and it's supposed to preserve your input, not update automatically.

[wordpresssites]

Replying to SergeyBiryukov:

Replying to ReckonMind:

On selection of post the url and link text use to get updated as per the selected post in previous wordpress version. However in current 4.2.1 version the Link text does not get updated with as per the selection of post title.

There were no Link Text field in 4.1, it was a title attribute.

The Link Text field is new to 4.2, and it's supposed to preserve your input, not update automatically.

The title text should be included automatically. This makes adding related post links more efficient as it saves time because you don't need to add the title text each time you select a related post.

This has already been made crystal clear several times in other tickets you have closed. https://core.trac.wordpress.org/ticket/31678#comment:4

The changes you have made in 4.2 are not an enhancement, they are a step backwards because it takes more time to complete linking to related posts as you have to add the title text manually for every link.

[dmchale]

Sidestepping some of the vitriol happening here... @SergeyBiryukov as a plugin feature request, would it be possible for the "Restore Link Title Field" plugin to prefill the Title attribute field with the name of the page/post when selecting internal links, the way that it used to <= 4.1? I think that is the primary concern of @ReconMind and @wordpresssites.

Personally I agree that the new Link Text field should remain unchanged based on the way that field is designed to work.

[SergeyBiryukov]

Replying to dmchale:

as a plugin feature request, would it be possible for the "Restore Link Title Field" plugin to prefill the Title attribute field with the name of the page/post when selecting internal links, the way that it used to <= 4.1?

Looks like @Otto42 already implemented that: ​https://plugins.trac.wordpress.org/changeset/1150518.

[Otto42]

This is plugin territory now, and if you have any suggestions along the lines of fixing bugs, the support forums are better. :)

[jaapdewit1978]

I don't wish to offend anyone, but this is by far the most horrible change I have ever seen in any software ever. And I've seen quite a few bad changes in my career as a software engineer. I'm sorry, but you really should have either kept it as it was, or added an extra field. The functionality as it is now, makes no sense at all. Replacing the title by the link text is confusing and above all, unnecessary. For most people, link texts are written in the natural flow of writing a news article or blog post, and then links are added later. The fact that some people use the title attr incorrectly is no excuse for a change like this. There are many people who have a valid use for it. Having to use a plugin to get core functionality back is just insane. Words cannot describe how disgusted I am by this change. My apologies for being so harsh, but I'm so upset that I am seriously considering downgrading back to 4.1.

[Otto42]

If you want the field back, there's a plugin that does exactly that.

​https://wordpress.org/plugins/restore-link-title-field/

I'm committed to keeping this plugin up-to-date, and to making future changes to keep it compatible as well as making the link dialog more adjustable by plugin code.

[jaapdewit1978]

Like I said, using a plugin for functionality that should be core functionality and to fix a change that should never have happened is insane.

[sevensoutbill]

Just adding my two cents here. We require the Title attribute on links to meet legal AODA (Ontario, Canada) and WCAG requirements - it's not just a usability issue. We have a large number of editors with no HTML experience who will now be required to edit HTML (defeats one of the main advantages of using a CMS). This will make it much more difficult for us to meet this accessbility requirement on our very large website. Please add this field back to the Insert/edit Link pop-up.

[Otto42]

We require the Title attribute on links to meet legal AODA (Ontario, Canada) and WCAG requirements

Neither of those standards requires title attributes on links. WCAG 2.0 actually recommends against it.

The title attribute technique is described by WCAG 2.0 here: ​http://www.w3.org/TR/WCAG20-TECHS/H33.html

Note this text in the description:

Because of the extensive user agent limitations in supporting access to the title attribute, authors should use caution in applying this technique. For this reason, it is preferred that the author use technique C7: Using CSS to hide a portion of the link text (CSS) or H30: Providing link text that describes the purpose of a link for anchor elements.

Basically, WCAG actually says not to use the title attribute, but to use hidden text via CSS or provide better link text.

[GaryJ]

Replying to sevensoutbill:

We require the Title attribute on links to meet legal AODA (Ontario, Canada) and WCAG requirements.

From the few minutes I've just spent looking into AODA, ​http://www.aoda.ca/wcag/ seems to be the relevant document. That says that Government and public organisations, and profit / not-for-profit organisations with 49 or fewer people don't need to comply.

As for WCAG, ​http://www.w3.org/TR/WCAG20-TECHS/H33.html seems to be the relevant technique which satisfies two success criterion. However, that WCAG document also says:

Because of the extensive user agent limitations in supporting access to the title attribute, authors should use caution in applying this technique. For this reason, it is preferred that the author use technique C7: Using CSS to hide a portion of the link text (CSS) or H30: Providing link text that describes the purpose of a link for anchor elements.

Even with all of that, you can install the plugin and restore the previous functionality for all your editors. But the lack of need for the title attribute for the majority of users, combined with it's dubious use as a technique within WCAG means it's definitely not a core requirement.

Edit: Beaten by Otto :-)

[sevensoutbill]

Thanks guys, for setting me straight! My mistake. You are correct regarding Title attribute. Forget I said anything... :-)

Cheers,
Bill

[orelweb]

Hello, I don't mean to be rude or unkind here, but I've been a user of WP for several years, and I have been reading some of the comments up there, and sincerely I believe that using a link title is a decision that should be left to WordPress software users, and that we should decide where and how to target our own audience (e.g. PCs v. mobile users). I've always used the Link Title attribute for all my posts either in my own servers or in my WordPress.com subdomains. I don't think that the reply "we definitely removed the title attribute and are not putting it back" is a very customer oriented attitude either. Adding a title link with html code is awkward at best, and (like somebody said before) it does defeat the purpose of using a CMS. I'd also like to suggest to consider adding that title link feature as an "advanced option" that will appear only if it's set up in admin settings, so those "confused" users will never see it unless they are looking for that option. I don't think that we are the minority (for the number of posts I saw here in favor of adding back that title link feature), and without any disrespect, even minorities should have rights. As an "advanced option" suggested above (by Hansaplastique above and repeated here by myself), the majority will never see the Title Link option unless it's deliberately set in admin settings; so (as it's argued) they won't be "confused". I think, however, most WP users are smart enough to figure out the right use of that option. However, that is just my opinion (maybe a radical opinion). I hope that WordPress won't become like another Microsoft, a company that is continually getting its customers upset with their changes and bright ideas.

[helen]

My sentence "we definitely removed the title attribute and are not putting it back." was never, ever directed at non-core developers and is in context of the rest of the development conversation that was being had. I very much wish it had not been quoted at all in this forum, as there is a difference in communication styles depending on context and audience.

[akibjorklund]

#33040 was marked as a duplicate.

[atomicjack]

Replying to helen:

My sentence "we definitely removed the title attribute and are not putting it back." was never, ever directed at non-core developers and is in context of the rest of the development conversation that was being had. I very much wish it had not been quoted at all in this forum, as there is a difference in communication styles depending on context and audience.

Regardless, the part "are not putting it back." seems quite rude and distasteful to those who actively used the title attribute.

What, exactly, is wrong with users setting their own title attribute? Or, at least, having it optionally, under an 'Advanced' accordion?

[sabernhardt]

#32638 was marked as a duplicate.