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.

[lightgetsin]

I think you know I'm in favor of this because exposure to tools means more and better use of them. Also, people have said the data would be interesting to them in a "wait, who is that person?" moment. My only concern would be that sort of information -- this is a picture of Adam Lambert -- overtaking the actual accessibility function of the description -- Adam Lambert is doing dirty things to his microphone with the caption 'insert something dirty here.' But that doesn't seem very likely.

[deborah]

*nod* I am with you on both counts. Also, I do think that if people saw the alt text, they would have a much better sense of how to write well.

There is nothing in the HTML standard that says what user agents should do for tool tips, and I think it was a real loss when the browsers stopped showing alternative text. It used to be much easier for sighted users to get a hold of it.

[azurelunatic]

Yeah, I think everybody's alt text writing skills will improve when there are good examples readily available.

[zvi]

Er, are we getting rid of the username from the title attribute? I am not in favor of that, but I don't feel very strongly about it. But I think we have styles where the username and the icon are visually separated, don't we? I mean, wasn't that part of the impulse to have icons on left or right side?

[deborah]

Reaction: "what username? The username isn't in the title attribute. *Goes to check* What the hell how long has the username but in the title attribute?"

Sometimes I am not very bright.

No, you're right, as long as we are keeping hover, that should probably stay in there.

[foxfirefey]

Hey--is there a reason this is marked 18-and-above only? I think it may have been an accident!

[deborah]

thank you for catching this. Fixed!

[azurelunatic]

I like your proposal.

[torachan]

descriptive text shouldn't be getting crazy long anyway

Wait, it shouldn't? Is there a tutorial for how we should be doing the icon descriptions? Because I have sometimes found myself running up against the character limit, so maybe I'm doing it wrong?

[deborah]

I wonder if we should write up a longer explanation about how to do the descriptive text and link it from the userpics page for those who are interested. Writing good alt text is an art, not a science, and it's an art pretty much nobody has perfected. I reread the webaim documents on how to write alternative text with some regularity.

The key thing to remember is that everything you put in your descriptive text is going to be read aloud in a linear fashion by a screenreader, and the way we use userpics, your icon -- and therefore its description -- might appear 10 times in a thread. Screenreader users can skip ahead of particular elements, but even so, the trick is to strike a balance between sufficiently informative and not-too-long.

Of course, this is more difficult with userpics then with a lot of other web images, because with userpics, we really are trying to convey character, emotion, action, words, etc., in a way that we don't often need to with other web images.

In other words, strike a balance between the information you think is important to convey and brevity.

if you are curious, you might find it informative to load a journal page in an online screenreader to see what it sounds like to you, although of course skilled screenreader users will be much more efficient at moving around the page. (If you use firefox, you could also try using firevox.)

[deborah]

also, for what it's worth, I just looked at your icon descriptions, and I think you strike that balance pretty well (although that might be because you work coming up against the character limit). The one piece of information you have on several of those that might be worth leaving out is information like "an image" or "a painting". Screenreader users do know that what they're hearing descriptions of our images, so you never need to prepend that. Type of image, such as "painting" or "cartoon" is something you should only include if you think it's going to be informative in the brief context of a userpic description(which of course, sometimes it will be, which is why this is an art and not a science). Otherwise, getting across the content, words, mood, or whatever else is the primary thing you are expressing to sighted users is what you are going for.

[torachan]

Thanks for the info & links.

I think I used painting, etc. only if that was different to what it would usually be. Like if I just said "a woman blah blah blah" you might assume it was a photo. But it doesn't really matter if it's a photo or a painting, so I can probably ditch it. It's trying to determine what matters that can get tricky. Sometimes I find myself thinking I need to describe every last detail so someone can compose a picture of it, but that's really not necessary. (And I hadn't thought about the fact that it would be repeating the same info over and over if an icon appears multiple times, so I can definitely see how less is more there.)

[jeshyr]

Yeah, it's more putting in the bits that matter. If you have a cartoon of Obama and Bush together it might be totally relevant that it's a cartoon, or if your painting of a woman is done in a very specific style which is relevant to the meaning of the icon.

I guess you sorta have to figure out what the icon is there to *say* to the reader, and put that in the description - check out Deborah's icon descriptions and you get a great example of this. I think mine are less good, but feel free to look of course :)

[cesy]

There were plans to write a FAQ on it, though I'm not sure if it's finished yet.

[jd]

I would really prefer to keep the title (hover) text on icons short. When it's several lines (like, the length of an xkcd title text, for instance), it can be difficult to read all of at a time (it can disappear quickly), and honestly as a sighted user most of the time I don't care about either the description or the comment - if I want to know that information, I can just click through to the allpics page. Keywords, by contrast, are required to be short. Plus, since icons can have multiple keywords, it's more important to draw focus to which keyword in particular is used in each instance, as the description and comment stay constant.

My understanding of comment vs description is that comment is basically for crediting and context, and description is a textual equivalent of the image. Almost all of the time I would say that the comment will be entirely irrelevant as hover text (again, if I want to know who made an icon, I can go to allpics), and for sighted users (correct me if I'm wrong, but if I understand this post correctly, they're the ones who interface with the hover text almost exclusively?) including the description field of the icon is redundant information.

So, in summary: I strongly favor the status quo. Keep the title attribute "username: $keyword", keep the alt attribute "$description", and keep the $comment field relegated to the allpics page.

[turlough]

I agree with most of this comment. It might make things a bit easier not to have to got to allpics to find out who made an icon, but compared to the issue of having over-long hover text it's something I definitely can do without.

[triadruid]

I agree with the summary statement.

[axiom_of_stripe]

I would definitely appreciate having the keyword, description, and comment all available immediately with the userpic. The immediately obvious place for it is in the image title, because that would put the information in the same place for all browsers/screenreaders; I don't like the idea of using the user pop-up because that currently contains general user information and links, not context-specific information, so it's not necessarily where users will go for contextual information. A third option might be to make the standard style display this information in text alongside the image so that both are visible at once; a problem with this would be duplication of information if a browser/screenreader displays the image's title and then displays the information again which was in the image's title (are there some layouts that would help with this?), but an advantage would be that the information would be visually more stable.

While the allpics page is great for browsing a user's icons, it isn't very useful for getting information about a specific icon, especially in the context of an ongoing discussion. And while I'm used to not having that information easily available now, I suspect that, like ajax cut-tags, once I have it I won't want to give it up again!

[sophie]

I've been thinking about this.

Personally, I really, really like the icon keyword being in the title field. But one thing that I have found is that sometimes I want to see the other fields too. But when that happens, I mostly want to see all of them - credits, description *and* all the other keywords for it.

Right now I love that the icon actually links to the icons page - it makes this easier. But it's annoying to have to scroll down the page. Maybe the solution would be to add an anchor to the URL to the specific icon, and add IDs on the icons page to make this possible. I would really, really love that, and it would solve my problem much more than adding new text to the title attribute would.

Alt text is meant for when the picture isn't or can't be displayed, and that's where a description should be for accessibility purposes.

[cesy]

I would also love it if it linked to an anchor in the right place on the allpics page.

[deborah]

I was thinking about something like this as well. I was also thinking about just generating a minimal page with nothing on it except for the information about the current icon -- icon + comment + keywords + description, with current keyword bolded or something.

[jeshyr]

This is a really smart idea, and outside-the-box too. I like it!

[deborah]

Trying to find other opinions about this where I see them and collate them into this conversation. Elsewhere, insptr_penguin said Yay! Oh now, I can see the text for all of mine, so long as the images aren't enabled. I do hope they do put the descriptions back into the hover text. It would give each icon another dimension. As someone who spent a lot of time in text-based MOOs as a teenager, I find the idea of text descriptions very nifty and familiar-- obviously not as important as the accessibility side of things, but a side bonus.