Title attribute and userpics

[deborah]

There's been a brief but meaty discussion going on in bug 2773 about what we should put in the title attribute of image elements used for userpics. This is only tangentially an accessibility issue: most screenreader users and all keyboard-only users never see the title attribute (screenreader users can configure their screenreaders to read the title attribute, but I've been told this is rare in practice). However, it was a conversation around accessibility which led to some concerns about userpic's use of the title attribute, as it was very difficult for non-screenreader/text-only browser users to have any idea of what descriptive text was for userpics. That descriptive text (the "alt" attribute) was information to which several users wanted easier access.

So what is the "title" attribute? The HTML 4 standard says that This attribute offers advisory information about the element for which it is set. The HTML 5 standard is slightly more informative, saying The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image; on a paragraph, it could be a footnote or commentary on the text; on a citation, it could be further information about the source; and so forth.

Because of limitations with browsers and screenreaders and their implementation of the attribute, the title attribute is one of the most controversial parts of HTML that I have seen accessibility experts argue about. In practice, almost the only people who will ever see the title attribute our mouse users who are hovering over an image or link. In that case, modern browsers will show the title attribute as a tooltip. (Many used to show the alt attribute if title wasn't set, but I'm not sure if any browsers do so anymore.) Because the information in the attribute isn't available to most screenreader and all keyboard-only users, it's important that the title attribute only be used for information which is accessible in some other fashion as well.

Web accessibility experts will get in knockdown, drag out fights over whether title should just be abolished, alt and title should be identical, or alt and title should be different. Often it comes down to the difference between what the HTML standard says is best practice, and the reality of what actually happens in browsers and screenreaders. In my occasionally humble opinion, Dreamwidth be striking a middle ground: following the standards wherever they help and do not hinder our users.

So what does that mean for us? It does seem that, contrary to common practice, there is a desire among many users to have access to that descriptive information that is provided in the alt text of a userpic. For one thing, that descriptive information often reports the context of an image: the fandom; the character; the pet.

Right now, that title attribute shows the keyword. Just as some users have the desire to see the alt text, other users have expressed the continuing desire to see the keyword, because it shows why the posting user chose that userpic, or how the posting user catalogs his or her userpics. However, there has been some user confusion because the tooltip shows similar but different text from the description in the alt text, which is making it more difficult for non-screenreader users to understand which text is which.

But wait! What about that last piece of information we have about each userpic: the comment! It has also been pointed out that comments, which by convention include icon credits, would also be really useful advisory information to show up in a tooltip.


So after that ridiculously wordy preamble, here's a proposal:

title = "Image keyword: " + $keyword + $description + $comment

In other words, the title, primarily available as a mouse-hover tooltip, should contain the image keyword, the alt text description if available, and the comment if available. On the one hand, this might make for somewhat long hovers. On the other hand, descriptive text shouldn't be getting crazy long anyway.

What do people think? This is clearly a usability design issue primarily for people who use the mouse-hover feature. Again, its accessibility issues are primarily tangential, in how we can potentially expose high-value accessibility features to people who don't need them.

Comments

[aveleh]

I'm being pedantic but only for informational purposes; it doesn't actually change anything. As far as "all keyboard-only users never see the title attribute": I do see the title attribute when browsing using elinks, although I think it's only when the title is for a link, and even then it's probably got a character limit based on my screen size. But I have made use of them.

Does it maybe make sense to move some of this to the hover thingy? I wonder if people who like having all that descriptive title text might be happier for it to be in a place where it can be formatted. I suspect that the hover is mostly not accessible to the same people for whom the title text isn't accessible, so I don't think it would be making it less accessible and would only serve to make it more readable for those who can access it.

(You can't access the hover thing on keyboard only and I'm not sure how it works for someone using a screenreader. I haven't given a good description of it; maybe someone else can?)

[deborah]

oh, I know which hover that you mean. The mouse over that you see with JavaScript enabled, that gives you links to subscribe, allow access to, etc.

*Ponders* There is something to be said about that, something good. For one thing, having both a title attribute and a JavaScript-prompted hover means two pop-ups, which can be a little complex.

For another thing, well I don't think it is right now, that JavaScript pop-up can be made accessible to both (some) screenreader and (some) keyboard-only users. I'm not sure if screenreader users would want access to it, as I can imagine it would be a little distracting. We would probably have to make a test instance in order to ask people to try different ways of working with it. But making it accessible to keyboard-only users could be valuable.

(I did realize as I was writing that some versions of elinks and lynx show the title attribute in certain circumstances, but I figured it was already so wordy I could avoid the long tail in my explanation. Since, as you say, it doesn't change the practicalities. *g*)

[aveleh]

:nods: Also, I can't swear to all versions of IE, but I seem to recall that in at least some of them, the title popup doesn't show if that hover popup is activated. So I think there's some value to putting all that information into the hover popup. Of course, then there are a variety of users who can access the title popup but don't or cannot access the hover popup. To me, the question then becomes "is it too confusing for some users if the same information is displayed in both the hover and the title" and then to determine which place makes more sense. (I don't know if it's a good idea to suggest blank titles in the case where the hover is on, I'm just throwing ideas out there at this point.) But if we can do it in both places, that should get the most number of users.

[deborah]

Idea from allen I really like: get rid of the title attribute altogether. Then, in the ajax, add a little link "more information about this icon", which when clicked expands the Ajax box to give keyword used, comment, and alt text maybe in italics.

[jeshyr]

Without commenting on the merits of this suggestion, are the Ajax hovers accessible to (a) keyboard users or (b) screen reader users?

I believe that they're not, which would make this potentially problematic.

r

[deborah]

no, but neither is the title attribute accessible, so we are already talking about spell that of modifying something which isn't accessible to those two sets of people.