Title/alt text for icons

[denise]

We have discussed, multiple times, how to utilize the varying combinations of keywords, descriptions, and comments on icons. Bug 2773 is one of the places where that discussion has been happening, and there has been previous discussion here in dw_accessibility: Title attribute and userpics. (There was, unfortunately, no consensus, indicating that -- as always -- one person's accessibility is another person's accessibility nightmare.)

Currently, the description is used as the icon's alt text (viewable/read by screenreaders, text-based browsers, and most browsers with images turned off), the keywords are used as the title text (viewable in a popup when moused over in most graphical browsers; unavailable to screenreaders and most mobile devices), and the comments/credits are only shown on the icons page.

Some of the issues that have been brought up/discussed:

1). Information should never be available to graphical browsers and sighted users that isn't available to screenreaders, text-based browsers, and non-sighted users. Right now, keywords are only available inline to people who can mouseover the icon image and read the resulting tooltip.

2). Web standards say that alt and title text should not be the same. (We're more than willing to ignore standards when standards are wrong, but it's still a consideration.)

3). Making alt text be username + icon keywords + description + comments (aka, combining the existing alt text and the existing title text) would result in hellaciously long alt text that would have to be read out every time.

4). Various people already using any of the four pieces that go into the alt text and the title text right now -- username, keywords, description, and comments -- have come to rely on having that information available, and would prefer it not be removed.

5). Hover text (which most browsers use the title attribute for) can only be reached by mousing over the image (which already excludes a large group of people).

6). Most browsers only keep hover text visible for a short length of time, meaning that long title text would not be readable in the time it stays visible.

With all of that said, please take the poll below indicating which option you'd prefer. There are two polls. One is for people who interact with the site visually/graphically; one is for people who interact with the site purely text-based/screenreader-based. Please only answer the poll that is applicable to you.

The polls are anonymized; everyone will see the answers and who voted for what, but nobody will see a name attached to them. If you have a problem answering the poll, please comment to this entry; anonymous commenting is enabled in this community if you aren't comfortable commenting while logged-in.

(The results of this poll will not necessarily determine what we do, but it will be part of the information we use while we decide.)

Poll #8008

This poll is anonymous.
Open to: Registered Users, detailed results viewable to: All, participants: 59

I interact with the site visually and would be okay with any of these options:

View Answers

The way things are now: alt text = "description", title text = "(username), keywords"
49 (86.0%)

Alt text and title text to be the same: "keywords: description"
38 (66.7%)

Alt text and title text to be the same: "(username): keywords, description"
35 (61.4%)

Alt text and title text to be the same: "(username): keywords, description, comments"
19 (33.3%)

Alt text and title text to be the same: "(username): description, comments"
16 (28.1%)

Alt text and title text to be the same: "(username): description"
29 (50.9%)

Something else, which I will explain in comments
3 (5.3%)

I interact with the site visually and my single preferred option is:

View Answers

The way things are now: alt text = "description", title text = "(username), keywords"
17 (34.0%)

Alt text and title text to be the same: "keywords: description"
10 (20.0%)

Alt text and title text to be the same: "(username): keywords, description"
7 (14.0%)

Alt text and title text to be the same: "(username): keywords, description, comments"
5 (10.0%)

Alt text and title text to be the same: "(username): description, comments"
0 (0.0%)

Alt text and title text to be the same: "(username): description"
8 (16.0%)

Something else, which I will explain in comments
3 (6.0%)

Poll #8009

This poll is anonymous.
Open to: Registered Users, detailed results viewable to: All, participants: 2

I interact with the site with screenreader or text-based browser and would be okay with any of these options:

View Answers

The way things are now: alt text = "description", title text = "(username), keywords"
2 (100.0%)

Alt text and title text to be the same: "keywords: description"
0 (0.0%)

Alt text and title text to be the same: "(username): keywords, description"
1 (50.0%)

Alt text and title text to be the same: "(username): keywords, description, comments"
0 (0.0%)

Alt text and title text to be the same: "(username): description, comments"
1 (50.0%)

Alt text and title text to be the same: "(username): description"
2 (100.0%)

Something else, which I will explain in comments
0 (0.0%)

I interact with the site with screenreader or text-based browser and my single preferred option is:

View Answers

The way things are now: alt text = "description", title text = "(username), keywords"
0 (0.0%)

Alt text and title text to be the same: "keywords: description"
0 (0.0%)

Alt text and title text to be the same: "(username): keywords, description"
1 (50.0%)

Alt text and title text to be the same: "(username): keywords, description, comments"
0 (0.0%)

Alt text and title text to be the same: "(username): description, comments"
0 (0.0%)

Alt text and title text to be the same: "(username): description"
1 (50.0%)

Something else, which I will explain in comments
0 (0.0%)

Comments

[mirthalia]

I have a question for you born of pure technical curiosity.

How does your screen reader read the hover menu/other JavaScript floating objects? Does it jump to reading them when they appear in the code, or does it miss them entirely if they appear higher up on the page than where you are at the moment, or...?

[deborah]

Disclaimer: I'm not the person you're asking the question of, and I'm sighted. The only reason I have answers for this is because, as I've been doing a fair amount of accessibility programming, I have been testing with several different screen readers and have a fairly good sense (to the extent that a non-regular user can) of what happens.

The answer, unfortunately, is very much "it depends." It depends on how the floating objects are coded, how they are activated, what browser is being used, what screen reader is being used, and even what screen reader version is being used. And these things all interact with each other in odd ways!

For example, WAI-ARIA code can be used to explicitly tell an appearing object how insistently the screen reader should announce that it has appeared, with values ranging from "off" (for not at all) to "rude" (for immediately). Whether or not the screen reader pays any attention to that instruction depends entirely on what screen reader is being used, if it is recent enough to understand WAI-ARIA, and if it is being used in conjunction with a browser which is recent enough to understand that same WAI-ARIA instruction.

That being said, anything which appears on mouse-activated hover, without any keyboard-based alternative method of making the hover menu appear, is really unlikely to get intentionally triggered by a screen reader user. Not impossible, but unlikely. For one thing, screen readers don't announce that there are mouse actions in specific page locations.

(Screen reader users correctly if I am wrong.)

[mirthalia]

Thank you! Can you think of any specific coding and activation methods that might make a floating object more likely to be picked up? (Other than making it click-activated, I'm assuming.) I code sites for a day job and I'm always looking for new ways to make them more accessible. (And a lot of accessibility stuff can be applied really well to mobile design, I'm finding!)

[lightgetsin]

*finally arrives*

Yeah, what deborah said. The only thing I'll add is that, effectively, it all shakes out to "not much at all." As in I rarely if ever find myself interacting successfully with hoverstuff, and I'm assuming that 95% of the time, I never even know the content is there.

[mirthalia]

Same question posed to you, then. Do you know what kind of hoverstuff does work well for your reader? Even just example site links could be useful.

[lightgetsin]

See my previous point: how would I know? I mean, see accessible youtube -- http://tube.majestyc.net -- I get realtime announcements of status when I hit play or pause, or even just as a video is playing. I actually here "buffering...playing." But I don't know if that's a hoverthing somehow translating correctly, or if it's an ajax region that somehow talks straight to the screenreader even though I'm not on that part of the page ... *shrug*. That's one of the few websites I can think of where something of that sort works consistently, but I have no way of knowing what it is, visually.

Let me put it this way: I have been using lj since 2001, and came over to Dreamwidth back when you had to know D in person to get an invite code. And I did not know until two months ago that there's some sort of content you get for hovering over a userhead. This stuff is just utterly outside of my universe of content.

[denise]

(FWIW, the hover menu contains the relationship you have with the person and a bunch of links -- things like send a PM, modify your relationship, view journal/profile, yadda. It's essentially a shortcut to keep you from having to load the profile page directly; it's more or less the same set of links that are on the profile action menu.)