Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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=""?
Comment | File | Size | Author |
---|---|---|---|
#41 | 335281.patch | 3.35 KB | stella |
#30 | link.module_adding_link_title_attribute_v2incremental.patch | 2.43 KB | thePanz |
#22 | link.module_adding_link_title_attribute.patch | 1.88 KB | thePanz |
#6 | link-add_anchor_title_attribute.patch | 1.94 KB | thePanz |
Comments
Comment #1
sijuwi CreditAttribution: sijuwi commentedI'd like to know this too, seems to me of primary importance from an accessibility point of view1
Comment #2
no2e CreditAttribution: no2e commented+1
Comment #3
Paisible CreditAttribution: Paisible commentedYes, it would be great !
Comment #4
Tim Corkerton CreditAttribution: Tim Corkerton commentedI need this functionality as well. Any plans? Can anyone point me in the right direction to start?
Comment #5
lomz CreditAttribution: lomz commentedAny progress?
Comment #6
thePanz CreditAttribution: thePanz commentedHi, 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! ;)
Comment #7
thePanz CreditAttribution: thePanz commentedComment #8
lomz CreditAttribution: lomz commentedHow do I use your patch?
(After having added it successfully, of course...)
Comment #9
thePanz CreditAttribution: thePanz commentedgo 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
Comment #10
lomz CreditAttribution: lomz commentedSo what text do I provide?
Comment #11
mgiffordadding accessibility tag
Comment #12
thePanz CreditAttribution: thePanz commented@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
Comment #13
lomz CreditAttribution: lomz commentedThanks, will test
Comment #14
Summit CreditAttribution: Summit commentedThis was a wrong comment, sorry guys, greetings, Martijn
Comment #15
AntiHero118 CreditAttribution: AntiHero118 commentedHas 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
Comment #16
mgiffordJust 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.
Comment #17
AntiHero118 CreditAttribution: AntiHero118 commentedIn 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
Comment #18
mgiffordI'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.
Comment #19
AntiHero118 CreditAttribution: AntiHero118 commentedThough, 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
Comment #20
jcfiala CreditAttribution: jcfiala commentedI'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.
Comment #21
mgiffordMight 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.
Comment #22
thePanz CreditAttribution: thePanz commentedI updated patch for 2.8 release.
@mgifford: please read WCAG Guidelines for links; here is a fragment of it:
Comment #23
mgiffordThere 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
Comment #24
thePanz CreditAttribution: thePanz commentedMike, 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
Comment #25
mgiffordI 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.
Comment #26
jcfiala CreditAttribution: jcfiala commentedAlright, 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.
Comment #27
jcfiala CreditAttribution: jcfiala commentedAh, should have set to fixed.
Comment #28
thePanz CreditAttribution: thePanz commented@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 :)
Comment #29
mgifford@thepanz - sounds great. Can't do everything and it's great to see this accessibility initiative take place in the contrib modules!
Comment #30
thePanz CreditAttribution: thePanz commented@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 :)
Comment #31
thePanz CreditAttribution: thePanz commentedNew patch, so setting Issue status back to "needs review" :)
Comment #32
jcfiala CreditAttribution: jcfiala commentedOh, 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.
Comment #33
thePanz CreditAttribution: thePanz commentedAs 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?
Comment #34
jcfiala CreditAttribution: jcfiala commentedOkay, 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.
Comment #36
strestus CreditAttribution: strestus commentedAlso it should be possible to add individual titles when creating cck nodes including the title files rather than having global title for all links
Comment #37
thePanz CreditAttribution: thePanz commentedStrestus: 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
Comment #38
strestus CreditAttribution: strestus commentedI 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
Comment #39
strestus CreditAttribution: strestus commentedNoone Interested ?
Comment #40
alanburke CreditAttribution: alanburke commentedSub
Comment #41
stella CreditAttribution: stella commentedThis 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.
Comment #42
Everett Zufelt CreditAttribution: Everett Zufelt commentedThis issue really isn't about accessibility, it is about adding the title attribute to the anchor element. This has almost no impact on accessibility.
Comment #43
dqdthanks 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.
Comment #44
dqdokay 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.
Comment #45
stella CreditAttribution: stella commented@Digidog - awesome, thanks!
Comment #46
dqdstella: 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.