Would it be possible to implement an extra text-field in the link-field so that I can set title="" in addition to >link-text and href=""?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sijuwi’s picture

I'd like to know this too, seems to me of primary importance from an accessibility point of view1

no2e’s picture

+1

Paisible’s picture

Yes, it would be great !

Tim Corkerton’s picture

I need this functionality as well. Any plans? Can anyone point me in the right direction to start?

lomz’s picture

Any progress?

thePanz’s picture

Hi, I needed that feature (for a standard HTML and accessibility reasons) and I implemented it! :)
Try and review this patch!

Would you like to say "thanks" to me? send me a beer! ;)

thePanz’s picture

Title: Be able to set title="" » Feature to add the "title" attribute to anchors (for HTML accessibility)
lomz’s picture

How do I use your patch?
(After having added it successfully, of course...)

thePanz’s picture

go to your widget options, at the bottom you'll find the "HTML link title" setting.
For now it's really simple. it's a widget-setting, not an instance data. So you'll provide a text for all fields (you can use also tokens).

Regards

lomz’s picture

So what text do I provide?

mgifford’s picture

Issue tags: +Accessibility

adding accessibility tag

thePanz’s picture

Status: Active » Needs review

@lomz: my use-case is pretty simple: I have a page that represents an "Association" webpage. Page owner can set its own external web url with Link field. Note that I'm using Tokens module.

So I type in my widget "html title" this string:

"Visit the [title] website"

In my document the (single) link will have the html-title setted to (for the page "MyAssociationNode") the following text automatically displayed:

"Visit the MyAssociationNode website"

Hope this helps

lomz’s picture

Thanks, will test

Summit’s picture

This was a wrong comment, sorry guys, greetings, Martijn

AntiHero118’s picture

Version: 6.x-2.5 » 6.x-2.8

Has this feature been added? I upgraded to link 2.8 for 6.x but, I still cannot add the title tags anywhere. I need this because my content will not display properly unless my views Style is Unformatted, and my Row Style is Fields so I can't use content templates to achieve this another way.

Really need some help on this.

Cheers

- Jared

mgifford’s picture

Just for clarification, adding a title attribute isn't necessarily going to increase the accessibility of a link.

Most assistive technology users don't enable the reading of title attributes as they usually aren't helpful.

Often the information in them is redundant.

AntiHero118’s picture

In my case the information contained within the title attribute tag for the link must be included because it is required for vision impaired users who use screen readers, the information is relevant to the content I'm linking to.

This is a very basic feature of any link, and I don't understand why it can't be specified when adding the link name and link url.

I'm really struggling to get this issue resolved.

Cheers

- Jared

mgifford’s picture

I'm not blind but my staff person who is did question the logic of inserting title tags for vision impaired users.

What standard are you trying to reach? If it's WCAG 2.0 then I don't think that title tags are the right approach either.

AntiHero118’s picture

Though, I'm not exactly sure what standard is trying to be achieved here, I have been instructed that they MUST contain these title tags.

I am only trying to comply with what I have been required to do.

Cheers

- Jared

jcfiala’s picture

Assigned: Unassigned » jcfiala

I'm planning to put a little time in on link this weekend, and I'll have a look at this patch and see about including it on the 2.9.

mgifford’s picture

Might be worth asking why.

As you can see in this issue here, there can also be problems with adding titles to links if they don't add useful information.

thePanz’s picture

I updated patch for 2.8 release.

@mgifford: please read WCAG Guidelines for links; here is a fragment of it:

In addition to clear link text, content developers may specify a value of the "title" attribute that clearly and accurately describes the target of the link.

If more than one link on a page shares the same link text, all those links should point to the same resource. Such consistency will help page design as well as accessibility.

If two or more links refer to different targets but share the same link text, distinguish the links by specifying a different value for the "title" attribute of each A element.

"Auditory users" -- people who are blind, have difficulty seeing, or who are using devices with small or no displays -- are unable to scan the page quickly with their eyes. To get an overview of a page or to quickly find a link, these users will often tab from one link to the next or review a list of available links on a page.

mgifford’s picture

There are two WCAG Guidelines at this point. I think the text you used was from WCAG 1.0 which was written in 2000:
http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-text

The relevant WCAG 2.0 links are:
http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H33

"JAWS 7.0 and above will speak the value of title attributes depending upon a JAWS setting. This setting can be changed temporarily or permanently within JAWS."

WCAG 2.0 also links to WebAIM as an example - http://www.webaim.org/techniques/hypertext/

http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html
"Note: 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 (HTML)."

Ultimately, browsers, screen readers and users have changed a lot since 2000 and so has the thinking about the use of title elements.

The preferred method providing additional textual content is with text hidden by CSS:
http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C7

Mike

thePanz’s picture

Mike, what do you suggest to do? I think that hiding link parts with CSS is a little bit difficult to do and manage: Link module should ask the user witch part to hide and witch to show.

I need link title for accessibility laws defined in Italy for public administration web sites and I think that other web sites will need WCAG1.0 guidelines conformance too.

Regards

mgifford’s picture

I don't use this module, I'm just bringing up what I know of the reality of today's screen reader users and current best practices.

I'd have to look at it to see what are the best approaches for meeting WCAG 1 & 2.

Specifically though, WCAG 2 says "authors should use caution in applying this technique", it doesn't say "don't use title tags".

I'd suggest there are a couple things you can do.

1) put a clear notice to users explaining that this option to use title tags is for the older WCAG 1.0 standard
2) put in an option to display the additional text as either a title tag or hidden text, depending on what is more relevant
3) do a check to confirm that the title tag is not the same as the main link title. Repeating the data twice is just useless for everyone.
4) suggest that Italian public admin sites need to update their standards to WCAG 2.0 which was actually released in 2008.

Passing on the caution in the use of this technique to the content owner is probably the best.

Btw, if you're doing sites for government we should talk offline. They are a strange beast, but we've had some good experiences getting Drupal into government lately.

jcfiala’s picture

Status: Needs review » Closed (fixed)

Alright, I'm not sure how necessary it is for accessiblity, but it's already written in a patch (Thanks, thePanz!) and I was able to write up some tests to exercise the change, without too much trouble. So, this is now added and will show up in either the dev version or in 2.9 sometime soon.

jcfiala’s picture

Status: Closed (fixed) » Fixed

Ah, should have set to fixed.

thePanz’s picture

@jcfiala: Thank you for your commit. I think that we also need to provide a check to not set title attribute if it's the same as link text (like mgifford said) I'll provide a patch (against latest -dev) soon.

@mgifford: you're right for (1) my patch lacks of "WCAG 1.0" text. Also for (2) I'll fix it! :) For (4) I guess I can't do nothing ;) They created an "accessibility" guidelines using parts of WCAG 1.0 guidelines.. but not the complete set! :|

Regards :)

mgifford’s picture

@thepanz - sounds great. Can't do everything and it's great to see this accessibility initiative take place in the contrib modules!

thePanz’s picture

@jcfiala: please review attached patch:
- title-attribute is removed if it's equal to link text
- fixed help text referring to WCAG 1.0 (added WCAG version)
- fixed a typo in "rel" attribute (double "have have" in help text)

@mgifford: I'd like to help in adding accessibility in other modules, is there a group or a common initiative for Drupal? I've already posted some patches to Date and Calendar a long time ago, but I don't remember if they were committed or module owner focused on accessibility issues.. :|

Regards :)

thePanz’s picture

Version: 6.x-2.8 » 6.x-2.x-dev
Status: Fixed » Needs review

New patch, so setting Issue status back to "needs review" :)

jcfiala’s picture

Oh, sure, make me write more simpletests. *grump*

Nah, thanks. If you think that's useful, then I'll wire it in, although I'm unsure why it matters if the title matches the link text.

thePanz’s picture

As mgifford suggested (and accessibility guidelines) title attribute should give further info about the link itself, if it's the same as link text it loses it's function! :) ... maybe we should leave it, but empty?

jcfiala’s picture

Status: Needs review » Fixed

Okay, I put in the patch, and poked at it - there were some fixes I needed to make, but soon enough the new simpletests were working and it seems fine now. Try it out in the dev version and let me know.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

strestus’s picture

Status: Closed (fixed) » Active

Also it should be possible to add individual titles when creating cck nodes including the title files rather than having global title for all links

thePanz’s picture

Strestus: please consider opening a new issue ticket for your feature-request (and then re-close this one).
My patch only added per-field "title", having a "per-field-value" title could be useful too, but requires a more data handling code. You can use my patch to implement your needs.

Regards

strestus’s picture

I thought it will be just like another patch to the one you have done. It is related to the same thread so I think it will be better to keep both together

strestus’s picture

Noone Interested ?

alanburke’s picture

Sub

stella’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev
Status: Active » Needs review
FileSize
3.35 KB

This patch never made it into the D7 version so attached is a patch for that. It also extends the functionality slightly so that it allows the title attribute field to be modified on a per-entity basis if enabled.

Everett Zufelt’s picture

Title: Feature to add the "title" attribute to anchors (for HTML accessibility) » Feature to add the "title" attribute to anchors
Issue tags: -Accessibility

This issue really isn't about accessibility, it is about adding the title attribute to the anchor element. This has almost no impact on accessibility.

dqd’s picture

Status: Needs review » Closed (works as designed)

thanks to all 4 your contribution and patches! Please feel free to expand the module to your needs. But let me give some words on this issue:

Not sure if this will make it into final release since a module should be kept as much flexible as possible in general to adapt with other modules. Note, the module is for storing link data in database as custom fields to be made available on content types in the first place. With some validation typical for links.

Since there are many modules out there handling the output and markup, I am not sure if it would be very modular nor very "drupish" to do it the sticky way on link module. Since the title is already there - it only needs to get "redesigned" to show up twice. I am pretty sure that views or display suite with code field add on would do that perfectly for your needs. And much more flexible depending on content type or rules or whatever ...

Note: If you can please help us with testing latest 7.x-1.x-dev shot to push next beta release. Would love to get ready with final D7 release before end of fall.

dqd’s picture

Status: Closed (works as designed) » Fixed
Issue tags: +scheduled for beta1

okay all I say now is for 7.x only:

@ stella: after thinking about it twice I think we should add it like you suggest and I took the time to test your patch. Thanks a ton for your patch. It mostly works, only how the field occurs for the default value in the field creation settings process is a bit confusing since there is already a fieldset for default values. But I think this is for cosmetical optimization somewhen. However it works nicely, also with tokens! stella++

Thanks for your contribution - I will mark it as scheduled for beta1 release and will commit the patch against latest 7.x-1.x-dev.

@ all others: Feel free to update to it, since latest dev has many other fixes already.

stella’s picture

@Digidog - awesome, thanks!

dqd’s picture

stella: we have to thank!

and sorry that I have the DON'T DO-IT ... done. The '#' in the beginning of the commit message. Arg, It was by accident when I had to reset --soft HEAD^ and copy/paste from here again (was @ 3 in the morning). I hope the message and the credits for your work stay in git repo, since I heard that sometimes it disappears when # in the beginning.

Can you do me another favour and take a look on this -> #1217396: "multiple-value" & "required" breaks input/save and produces error: "At least one title or URL must be entered." Dunno where to look at since it isn't my base code.

Status: Fixed » Closed (fixed)
Issue tags: -scheduled for beta1

Automatically closed -- issue fixed for 2 weeks with no activity.