Make WordPress Core

Opened 14 years ago

Closed 10 years ago

Last modified 10 years ago

#16819 closed enhancement (fixed)

Accessibility: Internal Linking behaviour in Editor / TinyMCE

Reported by: stencil's profile stencil Owned by:
Milestone: 4.2 Priority: normal
Severity: normal Version: 3.1
Component: Editor Keywords:
Focuses: accessibility, javascript Cc:

Description

Issue

The default behaviour of the new 'Internal Linking' feature is to auto-insert the title attribute as a duplicate of the link text.

This is not best-practise and, contrary to some beliefs, doesn't actually aid accessibility.

Solution

The title field should be blank by default and only included if the uses enters data.

Why?

Title text is only useful when it is *different* to the actual link text AND provides additional information. Duplicating the link text in this fashion just adds fuzz to the page.

Change History (17)

#1 @stencil
14 years ago

  • Summary changed from Internal Linking behaviour in Editor / TinyMCE to Accessibility: Internal Linking behaviour in Editor / TinyMCE

#2 @jane
14 years ago

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

Where are you seeing that? When I use internal linking it does not pre-fill the title field.

#3 @jane
14 years ago

  • Cc jane added

#4 @nacin
14 years ago

  • Milestone Awaiting Review deleted

If you click a post (as part of internal linking), the post title gets filled, but I'm really not sure what the report here is referring to.

#5 @stencil
14 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

When the Insert/edit link dialog box appears I see this:

Enter the destination URL
URL [ http:// ]
Title [       ]

I click on a post to link to eg. "Friday Travel Adventure", I get this:

URL [ http://mysite.com/friday-travel-adventure/ ]
Title [ Friday Travel Adventure ]

Auto-filling the title attribute with the exact (duplicate) content of the post name is the issue. The field should be left blank until the user enters useful information.

See also
http://www.456bereastreet.com/archive/200903/dont_duplicate_link_text_in_the_title_attribute/

http://www.w3.org/TR/WCAG20-TECHS/H33

#6 @dd32
14 years ago

Auto-filling the title attribute with the exact (duplicate) content of the post name is the issue. The field should be left blank until the user enters useful information.

Correct me if I'm wrong here, But the only way to insert a link is to select some text (In this case, I selected "See what I said about myself") click the link button, Find a object to link to (In this case I linked to "About"), The result is that the Title attribute contains what the link is actually linking to which is in most cases going to be different from the selected text.

Of course, If the text you're linking is exactly the same as the page title of the page you want to link to, you'll get your experienced duplicate title.

#7 follow-up: @stencil
14 years ago

@dd32 I understand the behaviour you mention, and yes it does differ from my 'issue' which is relating to text selected which matches the post title.

Sorry, perhaps this is trivial. I'm just not keen on automatically adding title attributes to every link. I imagine most users will leave the assigned title text because it's been filled in for them.

Perhaps a conditional in the JavaScript that if selection == post title don't auto fill the field?

#8 @ocean90
13 years ago

  • Keywords ux-feedback needs-patch added
  • Milestone set to Awaiting Review
  • Type changed from defect (bug) to enhancement

Perhaps a conditional in the JavaScript that if selection == post title don't auto fill the field?

That would be an enhancement and I see no problem with this.

#10 in reply to: ↑ 7 @lessbloat
12 years ago

Replying to stencil:

Perhaps a conditional in the JavaScript that if selection == post title don't auto fill the field?

My 2 cents:

I understand your idea around preventing the link text from ever matching the link title, however, here are my concerns with your proposed solution:

1) In order to replicate this issue you've got to highlight text for a link (i.e. 'My trip to Africa') that also happens to be the same as the title of the post or page that you're linking to. If this does happen, just change the title attribute in the add link modal to something other than the link text (so you could change 'My trip to Africa' to 'Thoughts on my 6 months in Africa').

2) I don't think we can outright prevent people from making the link text the same as the link title. If they want to make it the same for whatever reason, they should be able to. For example, they may have a plugin that relies on the text of the link title in some way. They should be allowed to set it to whatever they want.

#11 @iseulde
10 years ago

  • Keywords ux-feedback needs-patch removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

If the user don't want a title attribute, they can still remove it.
Besides, if you change the linked text after the selection and title used to be different, the title attribute will still be there.
I think in most cases the linked text and title attribute will end up being different anyway.

See also previous comments.

#12 @helen
10 years ago

  • Focuses accessibility javascript added
  • Milestone set to Future Release
  • Resolution wontfix deleted
  • Status changed from closed to reopened

I would agree that at the very least we should not pre-populate the title field like that. I feel like I've seen this come up again recently, but not finding a ticket. Possibly an a11y chat.

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


10 years ago

#14 @rianrietveld
10 years ago

As the accessibility concerns:

I agree on the not pre-populate the title field. For a11y it would be even better to let the title field out all together, but not pre-populate is already a good enough improvement I think, then it's up to the content manager, but not wrong by default.

Most screen readers don't read the title attribute, and if a content manager adds info there different from the link test, the screen reader users mis that information. But I think there will be huge resistance when we remove the title tag all together.

But a link text the same as the title attribute is useless for everybody

Version 0, edited 10 years ago by rianrietveld (next)

#15 @arush
10 years ago

Screen readers will ignore the "title" attribute unless the user specifically sets it to read that attribute. This very rarely happens. Thus for screen reader users the title attribute might as well not exist. This is not to say that it should be removed, as it has other uses.

#16 @iseulde
10 years ago

  • Milestone Future Release deleted
  • Resolution set to invalid
  • Status changed from reopened to closed

I agree on the not pre-populate the title field. For a11y it would be even better to let the title field out all together,

Well, we removed it now. :)

#17 @helen
10 years ago

  • Milestone set to 4.2
  • Resolution changed from invalid to fixed
Note: See TracTickets for help on using tickets.