dw_accessibility | Title/alt text for icons

Title/alt text for icons

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%)

Flat | Top-Level Comments Only

Okay, I may be in the total minority here, but I don't see why we need username in either alt or hover. I mean, it's right there right? It's currently not in alt, and I have never missed it. And that would shorten things slightly. (Though I bet if you took it out of hover now, people would freak out).

Also on the length front, my thinking is that what I really want is the description, and anything else is just gravy. So frankly you could append whatever you wanted to the end of the description, and I wouldn't particularly care how long it gets because I could hear the description first, and then move on at whatever point in the rest of the reading I want. I don't have to hear it all if I don't want to.

Also, not sure if this is a bug, but when someone chooses their default icon, the hover says "default." Which might be valuable information, but shouldn't it also say the keywords?

FWIW, I have no deep philosophical or technical attachment to the 'alt and title must match' standard. I mean, I get what they're going for, but yeah, not married to it.

IIRC, the way things are set up, "default" is a specific keyword, so (for instance) my "default" icon and my icon keyworded "me" and my icon keyworded "standing outside a broken phone booth" are all separate things as far was the system is concerned, even though they're all leading to the same thing. (I'm sure if I'm wrong someone will correct me!)

Meanwhile, that's good information to know, that a screenreader could skip ahead without losing any information. I was of the impression that skipping ahead in the screenreader would advance to the start of the comment (losing the username/date/logged IP address/action links header), but if it doesn't do that, we could be less picky about alt text length.

Well, it depends on what you skip ahead by -- you could skip all that info and hop directly to the text, which I would often choose to do, or you could just down arrow and read date etc., too. Basically, you can stop a screenreader mid-flow on anything and move to the next thing without any difficulty.

I think the only people a looooong text might irritate would be screenreader users who "read all" down the page. Meaning they hit a single keystroke and the screenreader goes off reading, and they have to hit another keystroke to stop it, or shift to skip it ahead a paragraph. But that would be a very strange behavior on comments, and waste a lot of time. I mean, do you sit there and read every character on a set of comments? I definitely don't, except in really weird circumstances.

Sorry, this is my brain on narcotics, more thinking:

What I meant to say above is that I am perfectly happy with a solution that has information in a different order for alt and hover, and that the more I think about it, the more I think that might meet the most needs.

Also, I wanted to check my understanding -- in the absence of a description, alt jumps to keywords, correct? That seems like a sensible progression. But my thought was, if description does end up in the title text, maybe there could be some sort of indication when it has not been filled out? Like, I don't know, a ? or a little grayed out bit? Something that will not be irritating but that people will notice and go "hey, I should fill that out."

Ooh, that's a good idea. (And honestly, I'd be okay with being just a little bit irritating to encourage people to fill out the descriptions, heh. I know many people haven't filled theirs in yet because they imported and haven't gotten around to describing all the imported icons -- I know I'm one of them; I go do four or five of them whenever I have the oompf -- but anything we can do to encourage people to add descriptions to newly-uploaded icons is a good thing.)

And yeah, I'm pretty sure alt jumps to keywords in the absence of description. Not positive, but pretty sure. I will go check if nobody knows for sure.

Confirming here: alt falls back to keywords if there is no description. (You can see this in action on my icon here, which has no description.)

About why I voted to always have the username included:
When I view this page with images, I see your icon and a hover text of "lightgetsin: (default)". But when I block images, I see instead the line of text "The Doodledog with frisbee... innocence personified" (with no identifying hover text) and on the next line "[personal profile] lightgetsin". However, having the username this close on the screen to the icon text depends on journal layout, and in some cases there's a random linked line of text ("innocence personified") just... there, and it takes a moment to figure out, "Oh, that's an icon" and whose it is. Including the username would never leave that question.

Okay, I may be in the total minority here, but I don't see why we need username in either alt or hover. I mean, it's right there right?

I agree, and my "other" is "alt = description; title = display name (rather than username): keywords".

Since the display name is often interesting (for example, if people put the name they like to be called in it), but it's not easily available on a comment.

I believe this is the way LiveJournal does it. (So this might have been a conscious change on Dreamwidth's part to remove the display name from the hover.)

I'm likely wrong because I despise the use of display names (they confuse me), but isn't the display name what comes right before your username?

Eg just beside your icon it says "pne

pne wrote in

dw_accessibility"

I was going to say "no", but then I realised that after ages of using Dreamwidth, I never got around to setting my display name.

Now I'd say: I see the display name in the format you mention ("Display Name (username) wrote in journalname") when replying to a comment on a separate page - but not on the comments in the normal entry-comment view. (I use site-style/Tropo Red.)

So that wouldn't help discoverability of the display name unless I started to respond to every single comment, then closed the window.

+1-ing this.

some people change their display names all the time, or set it to something like "sunny days sweeping the clouds away friendly neighbors this is where we are". Just out of curiosity I went looking at some of my friends' display names, and I would never be able to connect those display names with who they actually are.

I was flipping back and forth among "She Kisses Wyverns (the Disneyland analogy)", "Sister Hand Grenade of Courteous Debate", and "Hello Kitty, Destroyer of Worlds" for a really long time. *G*

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...?

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.)

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!)

*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.

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.

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.

(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.)

The title attribute is usually suppressed by the user popup in the browser I use (Chrome) (unless I'm hovering wrong? but hovering is generally something I get right) so I don't see either piece of information unless I ask Chrome for the element information, which shows me alt and title at once. So I'd prefer to have the alt and the title either exactly the same so it doesn't matter which I read or completely different so that I can read both of them through without duplication.

In the version of Firefox I've got now, "View Image Info" on icons shows "username: keyword", i.e. title text. I can't see the alt text at all, unless I'm having connection problems and the icon itself doesn't load. On other sites and when people post images in their entries, "View Image Info" does show the alt text; are they all duplicating it in the title, or does the hover suppress it?

I'd be a lot more willing to go to someone's icon page to find out about an icon if the link went to the icon, instead of having to search through lots of them. (I usually want to know "Who is that character?" or "What does that tiny text say?", and wish people would put that info in their descriptions more often.)

Ooh, yes, making the link go direct to that icon would be awesome. Then I wouldn't mind so much what the title text said. Do you want to put it through Suggestions, or shall I?

I've done it! (It came up in comments at the previous discussion Denise linked to, but I guess it wasn't followed up on.)

The way Firefox's View Image Info works is, it puts the title text in "associated text" if it's present. If it's not present, it puts the alt text in if it's there. This means that for an image with both title and alt text (like the icons on Dreamwidth), both the hover and View Image Info will only display the title text, and the alt text will be hidden unless you view the source of the page (or the image doesn't load, yes.)

If you're seeing the alt text show up in the VII dialogue box on other sites, either that image has no title text, or the title equals the alt. An easy way to check is to highlight the image and then right-click, "view selection source".

Thanks! That shows me the info I'm looking for (if I manage to select the image without too much of the surrounding territory, which is easier when it's not a link).

Just for reference: I use a dwell clicker so I don't (generally) actually click the mouse manually - I use a piece of software that automatically clicks anywhere I hover. It's hellaciously useful and saves a lot of finger/wrist movement BUT it means that it's almost impossible for me to ever see anything like a tool tip or title text which depends on me hovering the mouse over something.

I am therefore not voting on the basis that I don't actually have a personal stake in the outcome.

See, I think you do have a personal stake in the outcome for multiple reasons.

1. First of all, you have a personal stake for exactly the same reason I do (as a dictation user, I also never see hover text): it's not right for there to be information on the site only available to a small pool of users. If you look around these conversations on the site, you'll discover that a lot of people who do have access to the hover text think that everybody does (because they reasonably expect that information to be available via some other method, because they don't have any reason to expect the utter fail on the part of every single major browser manufacturer). Therefore, some communication occasionally takes place where the people involved in the conversation assume that hypertext is available to all.

2. But also, I know you care about accessibility, and one of the problems that we've had with encouraging people to use descriptive text is that (see above regarding utter fail on the part of every single major browser manufacturer) the descriptive text is invisible to most sighted users, so people don't see the value in it.

As a disclaimer, I'm a sighted user and don't use a screenreader or any other accessibility software.

I strongly oppose removing keyword info from the title text - which specific keyword is chosen for a comment or a post is information that isn't exposed anywhere else besides in the title text, and it's not possible to find by visiting the icons page, either, unless the icon only has one keyword. (This also applies in cases where a keyword was used and then later deleted; the keyword will still be attached to the comment/post, but the icon will be the default.)

I don't really have *too* much opinion on the other fields' placements. (I'd prefer not to see the description or comments on every icon, since it's largely stuff I only look up as needed, and I feel it would make the tooltips too long. But it's not site-breaking.) Whatever works best for people. But please keep the keywords attached to the icons when they're posted.

I know "adding new options" is not usually the preferred direction, but given that accessibility needs can be highly individual and that accomodations to make the site usable for one person can cause the site to become unusable for another person, it might be worth making this a sitewide customizable setting

I'm a visual GUI user. While I've stated a preference in the poll, I hope that the final layout is heavily weighted towards preferences expressed in the screenreader/text only poll.

Fear not; that's why I separated the two in the first place. :)

to be fair, there are users who are visual who don't have access to the title text for other accessibility reasons, so who also have a vested interest in not having information on the site hidden from them.

Seconding this, namely in mind of mobile devices like iPhones that use a touch screen and thus have no hover capabilities. Click triggering is better for those kinds of interfaces.

Speaking as a visual user who never remembers that the icon hovertext feature even exists, I honestly have no preference whatsoever which option is eventually chosen for implementation.

Unpopular opinion: I wish my keywords weren't exposed, sheerly for privacy reasons. I understand that they ARE exposed, and I name them accordingly, understanding that information is available to everyone. But for me they are quick indices into how I grab something from a drop-down list, and that means they can be a greater insight into my state of mind than I really wish were exposed to the world. I understand that I am going to lose that battle.

Less unpopular opinions:

1. I think that the Web standards saying that TITLE and ALT attributes need to be different did not take into account the problems with browser implementation of TITLE. I think we can adjust to them being the same.

2. Keeping in mind

lightgetsin's comments about reordering data elements above, I personally want the two attributes to have all of the same data elements, except in cases where it is guaranteed that the data elements in question will be displayed visually near the icon in all normal cases (e.g. possibly username). I have fairly strong feelings about there being information available to only a small pool of users. If the keywords need to be made available to sighted users with mouse access, then they also need to be made available to the rest of us.

3. From the standpoint of somebody trying to make other people understand accessibility, I really want the alternative text to be available in hover so that sighted users understand what it is and how it works, at least a little bit. There is a very very common misunderstanding that alternative text is available in the hover, and I think that's left over from the old days when browsers implemented it that way, and it's hard to reeducate people on something that widespread. But if we can just choose in this particular instance to put the alternative text in the hover, at least it will be easier to educate people about adding descriptions. Right now, we are trying to convince sighted users to add descriptions that they will almost never, ever see. That's really hard from an educational standpoint.

I actually never realised keywords were exposed this way until we had this discussion. I knew they were (semi)public because they're on my /icons page but I didn't realise which specific keyword I'd chosen for a specific post/comment was something easily knowable by casual users. Most of my icons have more than one keyword and not all of them are really nice ... I have to go do some editing now :/

I think of keywords as the name of the icon, and when I hover over an icon keywords is what I am trying to learn. I am totally fine with being given more info than that, but I don't want to lose that info.

I'd personally prefer to combine the keywords and description in the alt text and keep just username and keywords in the title, but I'm a visual user and am more than willing to defer to people who know the frustration of working with a screen reader when I definitely do not.

Alternatively, I'd be open to including the icon keywords, description, and possibly also the comments in the contextual hover menu, particularly since that can be turned on or off, and assigned to either the userhead or the icon. You might even include an extra option where people can specify which parts of the icon information they want to see in the menu.

A related possible (?) option out of left field, that might also help with the "not everyone can hover" issue: instead of making the hover menu a, well, hover menu, why not make it click-triggered instead? Combine that with the icon information and it seems to solve all the problems in a reasonable way.

One additional thing which may have been addressed elsewhere, and I apologize if it was and I missed it: are there any plans to change "(username)" in the title to the user's actual (public) name instead? We already know the username due to it always being included in a comment header, so it seems silly to have that information reiterated when we could have the user's proper name instead, especially when the proper name would be more helpful. (I know I continually forget which people go with which username, at least.)

Right now, no, no plans -- mostly because the user-supplied displayed name can be really long, and that goes back to the same problem of "long things in the title are very inconvenient".

You could hit up suggesitons with it, though! (I'm horribly behind, but will be dealing with it soon.)

Might be worth it to impose a shorter length limit. Most of the stuff people put in there should really go in their journal title anyway.

Thanks! Will do. I know I'm not the only one who's been bothered by this, especially amongst RPers.

Flat | Top-Level Comments Only

Title/alt text for icons

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject