Allow/encourage title attributes to links list entries

[matgb]

Title:
Allow/encourage title attributes to links list entries

Area:
styles

Summary:
Create text area within the Links list for link TITLE text, that would then display as per browser standards.

Description:
Currently, the only option we have for a Links List entry is URL and link text. It's good practise to give links Title text as well, that normally, depending on browser settings, then displays as a tool tip.

Other platforms, such as Wordpress, allow and encourage links to be given Title attributes, following usability guides and allowing users to give expanded explanations of what a link is, and why it's there in the sidebar.

Example: in my links list, I link to Miss_s_b using her name. For sidebar space reasons, that's all I can give. I'd like to allow users to know if they hober over a link that she's my fiancée and give a brief description of her content. That's good practise, recommended by usability experts. It can also aid search engines and is recommended white hat SEO behaviour.

Poll #3478 Allow/encourage title attributes to links list entries

Open to: Registered Users, detailed results viewable to: All, participants: 34

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
17 (50.0%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
7 (20.6%)

(I have no opinion)
10 (29.4%)

(Other: please comment)
0 (0.0%)

Comments

[jadelennox]

Outside of frames and tables, the title attribute is inaccessible to keyboard-only users and most screenreader users in most user agents. (Screenreaders can be configured to read title attributes, but almost never are.) Additionally, user testing shows that most able-bodied people never see hover text.

If we do enable this, there should be a link to a help text explaining how to write good title text (such as this one from webaim). Many people will otherwise assume title text will be seen or at least accessible by all their readers, which will encourage them to put unique information in that attribute.

[ratcreature]

Yeah, then guidelines would be necessary. After reading what you linked, I have no idea what I ought to put into the title field at all though.

I'm apparently using it totally wrong so far on my website, because I'm mainly using it so that people who display thumbnail images in galleries could see the alt-text with the description of the full picture in hover. Like in my drawble gallery, which is rows of preview thumbnails of sketches I did for other people from prompts, the alt texts give the prompts and the name of the recipient, things like "iguana in a spacesuit for hsavinien" and the same shows in the title field to help visitors who do see the thumbnail, which is often only from part of the sketch, to decide which image to see in full.

[kyrielle]

Looking at your web site, the title is on the img tag rather than link - but I downloaded and fiddled and it behaves the same either way. If I hover over it, I get the title text. Which is nice, except I seldom if ever see that, so I don't mouse over things. I think only a sighted user with a standard interface who hovered their mouse over it would see that normally - without instructions, pretty rare.

When I test it in a local html file with a link with no image, in Internet Explorer, it doesn't pop up for an instant or two after I hover (probably to let me click if I want).

I almost never move a mouse over a link unless I'm about to click on it, so absent this suggestion I might never have even discovered the possibility (and anyway, my mouse is sometimes not quite where the pointer claims it is, and my hand isn't always steady, so there's no guarantee I could hover successfully if I were trying).

I'm not opposed to this change, but I'm not sure how useful it is either.

[matgb]

Ah, see, this is why I do usability, not accessibility; you'd have thought by now they'd combine, but apparently not.

I had no idea screenreaders didn't automatically read title text, and was also unaware of keyobard navigation not displaying it; that's a weird issue I'd have thought would be resolved.

Definitely agree it should be explained in some way, and we'd need to ensure that people don't assume it'll be read. But it's there to give extra info for those interested; it displays on mouse hover, something I do before clicking in order to see where the link's going. I suspect that might partially be because I've always been aware it's there, and always try to code it in for my links whenever possible, because it is a recommendation.

Nielsen recommended it in Jan. 1998 and reinforced it when he did a study on blogs/journals specifically.

But, given it's just extra, optional, data, it isn't actually an accessiblity problem unless the person using the feature is an idiot, right? Or am I missing something?

[liv]

Not if it's going to be an accessibility problem, no. Implementing some useful features that other blogging systems have is fine by me, but superficially imitating the aesthetic of Wordpress isn't going to make Dreamwidth journals more like "serious" blogs. A journal can be a blog, if you want it to be, but that depends a lot more on the content than on trying to look like other systems. Dreamwidth should play to its strengths, and one of those is really good, built-in accessibility. (If it weren't for the comments, I would have thought that your proposal was ok.)