#16819 closed enhancement (fixed)
Accessibility: Internal Linking behaviour in Editor / TinyMCE
Reported by: | 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
@
14 years ago
- Summary changed from Internal Linking behaviour in Editor / TinyMCE to Accessibility: Internal Linking behaviour in Editor / TinyMCE
#4
@
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
@
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/
#6
@
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:
↓ 10
@
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
@
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
@
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
@
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
@
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
@
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
#15
@
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.
Where are you seeing that? When I use internal linking it does not pre-fill the title field.