Include information about icons in text-notifications for comments

[azurelunatic]

Title:
Include information about icons in text-notifications for comments

Area:
comments, email notifications

Summary:
Include information about the icon in text-only emailed comment notifications.

Description:
For people who get plain text comment notifications and read their comments primarily in email, and load the site only when replying, this would be helpful in not missing nuances of the conversation being carried out in icons.

It is now easier to include icons meaningfully in text notifications because of the icon description field (though visual users using a graphic browser can still load the page and see the icon for themselves). The keyword used to select the icon should also be included, as this can provide some nuance in why that particular icon was chosen. If the comment was not chosen by keyword, the description should still be included: while many people know their friends' default icons by now, it may be a stranger commenting, or someone may have a new default icon.

This gives better historical context for people who save their comment notifications, as sometimes people change their icons. Rodney McKay viciously removing stupid obnoxiousness is a much better pair with a rant about Not Being That Guy than a mostly-unwrapped Pretty Young Thing.

The addition of icons can change a conversation: for example, "I see" is fairly neutral. A positively themed icon would make it unambiguously positive; a "FAIL" icon would make it unambiguously negative, and might push the conversation over the line where a community administrator might want to step in. (This situation happened years ago, but I remember it vividly.)

This would also be useful for comment edits: sometimes people (like me) edit their comments and only change the icon, and forget to put an edit reason. This results in the same text, without explanation, being sent in the emailed text notification of the edited comment. An observant recipient is probably going to figure that it was an icon edit, but including icon information in the notification would be helpful.

Poll #6523 Include information about icons in text-notifications for comments

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
34 (61.8%)

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

Shouldn't be implemented.
4 (7.3%)

(I have no opinion)
17 (30.9%)

(Other: please comment)
0 (0.0%)

Comments

[deborah]

I know this is a minority viewpoint, but I don't think keywords should ever be displayed. Long descriptions are descriptive metadata; keywords are administrative metadata. I don't write my keywords with the idea that they will be exposed to the public, I write my descriptions, my alt text, with the idea that it will be exposed to the public.

For accessibility purposes, we should be encouraging people to encode the nuance of their icons into the description.

[arethinn]

I don't write my keywords with the idea that they will be exposed to the public

They already are, though: they're easily visible on your icon page (http://deborah.dreamwidth.org/icons). However, I agree with your main point: I wish they were not visible (or that this was access-list controlled, perhaps). Comment/description, yes; keyword, no.

[turlough]

Interesting. I guess everyone uses icons differently because to me and to most people in my circle an icon's keywords are something you put a lot of thought into and like to show off to other people. In fact, it's never occurred to me that keywords would be something you didn't want to display. It's what you see when you hover over an icon in most layouts after all.

[deborah]

Yeah, I know they are visible, but I do wish they weren't.

[deborah]

That last point you make has been brought up here before as a reason that keywords should arguably be hidden. Hover text (which comes from the TITLE attribute)is invisible to people with a vast array of disabilities: anyone using screenreaders with default settings, anyone keyboard only, anyone who uses zoom and turns off hover text because it's difficult on a magnified screen. Putting meaningful content into something which is only available to a subset of our users seems like an accessibility flaw at best.

I know I've been shot down for bringing this up before, but I really do feel like the universal design solution is to have ALT and hover text be identical in this case.

[turlough]

Well, I guess it depends on how you look at it. To me it sounds more reasonable to try to make the TITLE attribute discernible for all users, regardless of the means they use to access the site, than it does to remove something already in existence.

[deborah]

You can't make the TITLE attribute discernible for all users, because of the way browsers have chosen to implement it. You could choose to make the keywords discernible to all users by putting them in the ALT attribute along with the long description, but last time we talked about that we got bogged down in a discussion about how long the alternative text would then become.

The idea is not to remove something already in existence (keywords) but to make sure that there are not fields available which are inaccessible to many of our users. Additionally, the idea is not to expose information people might prefer to be private. So you have a field for information intended to be exposed, and another field for information intended to describe the images.

Whether those fields are called "keyword" or "description" or what have you is not important to me, as long as all users understand what will be exposed, what will be accessible, and what will be neither.

*Goes to look for that discussion*

Oh, it wasn't here, it was in dw_accessibility: "Title attribute and accessibility".

[marahmarie]

Interesting point, and I do try, when I can (obviously icon keywords don't or can't apply to this scenario) to make alt and title text identical - but, and this is a big "but", I've heard doing this is bad from an accessibility/usability standpoint.

The mantra I've been taught (and if you like, I could probably link you to some of what I've read on this) is that ALT is for describing the image ("large orange cat on red carpet") while Title is for expounding upon the image ("Large orange cat rolling around on red carpet, how cute is that?").

The reason it's supposed to be better that way is to give those who can only access/read the alt text a fair idea of what's going on in the image, while allowing those with access to both to have a clearer idea of what the image conveys.

So, from an accessibility standpoint, what I'm doing is bad. For instance, I'll put up a pic of my cat with matching alt and title text that says, "My cat is on his back, acting like a flea brain." Which tells you almost nothing and might do a slight disservice to those who have access to either or both versions of the text.

[deborah]

Among accessibility experts, the jury is out (since the standard says they need to be different, but the practice makes that inaccessible). But in general, it's a bad idea to make content available if you know it isn't going to be available to users with disabilities.

I think it's not supposed to be better when they are different from an accessibility standpoint; user agents don't make title text available to keyboard users and the most screenreader users, so it's simply not accessible content to that audience. The people I see arguing that they should be different say that simply because the standard says they should be different, and there is a large core of accessibility experts who says that we should be writing to the standards and insisting that the developers of browsers and adaptive technology support the standards properly. Which, I am totally in favor of in theory. But in practice, people keep putting content in the title attribute that I have no access to.

So in other words, from a STANDARDS standpoint, what you are doing is bad. But from an ACCESSIBILITY standpoint, what you are doing is exactly right. IMHO.

[marahmarie]

Excellent response. In my own head, I agree with you, standards be damned (especially that one - it makes no sense whatsoever, which I realized yet again while trying to explain it to you). That's why I always put all the information I can cram in into both tags.

My only wish - and this is fully under my control, so I have no excuse except laziness, lack of time, and/or lack of creativity - is that my descriptive text for images was more descriptive. I often use it for things like snarky asides that don't tell you much, when I should focus more succinctly on exactly what the picture conveys.