dw_accessibility | suggestion for style documentation

suggestion for style documentation

I'm curious as to whether or not I am the only person who ends up having accessibility issues when people modify their styles to change the text of basic features. Specifically:

1. It's bad enough when the text goes back and forth between two different standards (e.g. "user info" versus "profile").
2. It's worse when the text is something the style designer came up with to be original but which still carries clear meaning (e.g. "about me").
3. It's extremely difficult when the text is all flavor and doesn't convey much meaning (e.g. "happy tracks in the sand").

Am I the only person for whom this is an accessibility issue? If this is a general issue and not just me, perhaps we could write some documentation and propose it to the style team as guidelines for what kind of textual changes are worth avoiding if you really care about accessibility in your style. Since end-users can change those texts, not just style designers, we could come up with something brief and nonintimidating for the customization pages.

(By the way, I know I was working on a couple of open accessibility tickets, and I vanished for several months due to personal issues. I'm back as of this week, and have started looking at those tickets again. Sorry for the vanishing.)

Flat | Top-Level Comments Only

Isn't this the sort of issue where style=mine comes into play? I'm not sure how you can non-intimidatingly suggest to people that they shouldn't customize their own space because someone might have difficulty understanding their personalization choices.

I think this is also where titles on the standard links needs to be brought into play. Every system generated link, everywhere, needs to use the title attribute.

huh -- I forgot that style = mine also overrode the customized text, but you are right, it totally does. I'll have to configure to view everything in my own style. Thanks.

Title is an iffy one, actually. There has just been a whole long discussion of it on the webaim list, about how it is a lot less of a panacea than people think it is. For example, in most browsers, sighted keyboard-only users have no access to the title attribute whatsoever.

Title is, however, a part of the standard and an easy one to be brought into play for the standard links. It's an adjutant to properly formed and written links, not the cure for bad links, but that doesn't mean that it shouldn't be used. And the number of people who can benefit from a title far eclipses the number who cannot.

Title is a perfectly acceptable thing to add but it really isn't about disability accessibility. The WebAIM community has extensive discussion on this issue here (although that thread gets a little bit bogged down in arguments about opening in new windows). The short summation of the issue in most user agents, title is only accessible via mouseover tooltip: screenreaders only read title by default configuration in a very small number of cases, and keyboard-only users have no access to the attribute. Moreover, in most cases (all over dreamwidth, for example), people use "title" as a repeat of "alt". The only benefit this adds in user agents is to people who are doing mouseovers and want the tooltip; screenreaders will already be reading the identical alt text.

Jared Smith has a fabulous summary of when title should be used and for what purposes. A brief excerpt:

Title is great for conveying additional *advisory* information that
might be helpful to sighted users who do not use a keyboard or for the
few screen reader users that might hear it. It's great for providing
additional cues, instructions, or details that are useful, but not
vital.

...

My general recommendations:
- Use title if you want to when advisory information might be useful.
- Make sure the title text is brief and not the same as the visible
text or alt text.
- Recognize that many (most?) users will never know the title text is there.
- Do not use it for vital accessibility information, except on frames
and perhaps form elements that do not have labels

I think one phrase there jumps out as problematic and a hinge of the entire hypothesis. "Recognize that many (most?) users will never know the title text is there." That strikes me as false on its face.

His point is that title text is pretty much only available to most people as a mouseover tool tip -- not something most people see unless they are actually selecting the link. If I read between the lines of what he is saying, it seems to me as hypothesizing that most very rare exceptions, people don't tend to mouse over links they aren't expecting to click on in the hopes of seeing more information. At least, that would be my hypothesis.

While I can't assert the truth of that one way or the other, the fact remains that the title attribute is not an accessibility tool, except in those very rare cases (forms and frames). Physically disabled users who are using adaptive technology are less likely than able-bodied users to gain benefits from the title attribute, not more likely.

I suppose there might be benefits to cognitively disabled users from the extra information in the mouseover tool tip, although I've never seen that asserted anywhere. But if it were true, it would require training for those of us who write the pages and how to write good title text to accommodate those accessibility needs, since simply mirroring the alt text (which is what we currently do all over the site) is not going to add much functionality.

If your browser supports displaying title attributes, you normally have to navigate to that particular item in order to see it. For links, you also generally have to perform a different and slower action - such as hovering instead of clicking. So, I agree with

jadelennox that it's likely that many users don't know that title attributes exist or how to access them.

I also know that for me, on my browsers that I use, they're not a reasonable substitute for finding an item in the first place. I can skim a page of links a lot quicker than I can navigate to each link and read its title text. And on one of my browsers I can only even see that title attribute if it's on a link - I can't see title attributes on other items.

But as said earlier, this particular instance ends up being solved by style=mine (and related) options.

I feel this gets into arguments of how far a person should go to accomodate other people - who they might well not have invited into their space.

In a community, where many people can reasonable expect to be accomodated, then it's a fair enough point - it should be accessible to all members. But a personal journal is personal. I understand it's not private unless it's locked, but it is that person's space.

For example - I swear. A lot. In a community like this, I'm not going to because I don't know the audience. In my journal, I'm going to swear as much as I feel necessary because it's my space, and people who are there know what to expect. I wouldn't expect someone to come in uninvited and say "Modify your language because I want to read this."

I certainly wasn't arguing that we should prevent people from changing the text. But one thing I've discovered since I became a dreamwidth accessibility advocate is a lot of people have come up to me and said "teach me how to improve accessibility! I don't know how but I want to." What I was suggesting we do is give people the documentation to write more accessible styles, which people seem to want.

It's a big difference from telling people what they can and can't do.

That being said,

amadi is right about style = mine, which makes the point moot.

I think putting together a "How Can I Make My Personal Journal More Accessible" document is a fantastic idea, and it's certainly something I've got lots of suggestions about :)

You're not the only one!

Official styles will always have consistent text, so that hopefully helps to some degree.

I am mostly just waiting on http://bugs.dwscoalition.org/show_bug.cgi?id=168 to solve all my browsing problems :)

Man oh man, does that one look like a nice feature request.

Reading this entry has helped me understand why it's an accessibility issue for me because of cognitive impairments: I can't always decode the user-specified choices. (And proof that insight is patch: I used to sue "re:me" instead of "profile," but have changed it right now.)

I used to change all that text as well, until I realized that I couldn't figure out what was going on on other people's pages, and I realized I should probably change it back. :-)

I don't understand how this is an accessibility issue, as opposed to a "poor communicators communicate poorly" issue. Could you explain more, or tell me what I need to read up on to get it?

For me, consistent text makes it much easier for me to navigate the page, because as I navigate with voice I can program macros to take me to anything with predictable text. For example, on any page where the text "previous 20" appears, I can use the spoken word macro "previous friends page" to take me to that text. If the text isn't predictable, I need to seek for it with either a search-ahead macro (eg. "slash papa romeo echo victor india oscar uniform sierra spacebar numeral two zero") or scanning the page for the direct link made accessible via mouseless browsing.

Now, I know my accessibility use is pretty strange (I've met more NaturallySpeaking users working on dreamwidth that I've met anywhere else in the world before), so I was wondering if this was also an accessibility issue for screen reader users, who I think are more common. I was hypothesizing ways in which your screen reader might be configured to do something specific upon reaching predictable links. But since none of the screen reader users in this community has answered, I'm guessing the answer is no. :-)

Luckily, as

amadi pointed out, I can do a workaround with style=mine. I still have some accessibility problems in the style I've been writing, but one thing you can give it is consistency.

To me, what you just explained there is a totally different issue to what you explained up-page. The stuff up-page made it sound like it was a "I don't understand what the words/term they're using means" thing, nothing to do with technology. Which is a totally different matter.

Just a note: Accessibility isn't always about technology. For me it's more along the lines of "I can understand what this means if I really try, it just takes so much energy that I'd really really really rather use on other things."

Same issue, different cause.

Perhaps issue was the wrong word. But "I can't understand the words you use" has, to me, very little in common with "there's a conflict of technology here."

Because to be blunt, I don't feel my journal needs to be accessible to the wider world. It needs to be accessible to the people I want using/accessing it. So someone I've never heard of saying she doesn't understand... has no bearing on what I do, because as far as I'm concerned, she doesn't want/need to access my journal so there's no action I need to take.

However, "Changing text affects people who use adaptive technology" is something I need to know as a community mod - I haven't changed any text, but that's just been because I've not felt the need to, as opposed to a concious decision to keep it accessible for whoever might want to come in. Now I know, I can make sure the text doesn't change.

Does that make sense? I know what I mean, just not how to put it into words. It probably came out all wrong, but I really can't think of a better way to put it. I guess the analogy would be the difference between making my bedroom accessible, and making an office accessible. One isn't public space anyway, so I know the issues of people who are coming in, and I don't need to adapt it for people who wouldn't be there anyway.

Jack, I appreciate that your viewpoint is legitimate but I'm not sure it makes sense to write it here. If you don't care about accessibility for your personal journal that's your own choice to make, but as community mod I'd prefer if you kept your not-caring to yourself. This is a community for talking about accessibility issues and if somebody raises an accessibility issue and is told "oh, that doesn't matter" it's really not creating an atmosphere that's going to help others feel they can bring up their concerns.

In case you misunderstood, nobody was saying your personal journal (or even communities you mod) have to be accessible to the wider world. Jade suggested that IF it were a widespread problem we could write optional guidelines which would help people who wanted to make their journals/communities more accessible. Which I think is a great idea and will follow up.

In terms of accessibility it's not significant whether the breakdown is in a piece of technology or in my brain (or somewhere else). The effect to me is the same - I can't access whatever it is - and the easiest solution is still "well don't do that then" (in this case, don't change the text in question).

I am assuming that since you're here reading and bothering to comment that you do care about accessibility for your communities and you do have goodwill. I just want to point out that making private journals accessible and making public communities accessible involve exactly the same issues and requires taking the same steps.

Dreamwidth doesn't say "you can't make a totally inaccessible journal/community". We certainly wouldn't encourage anybody to do it, but (within the bounds of the Dreamwidth site's abilities) it's ultimately up to the community mod or the journal owner whether or not they follow any accessibility guidelines.

Ricky Buchanan

OK, clearly I've explained myself badly. In which case, I'll just say apologies to anyone I offended, and leave.

it might be more productive to try explaining again, and stay :) do the links i posted below help clear things up at all?

It wouldn't be productive, because I can't explain myself properly, it seems, and the links were nothing to do with what I was talking about - I never said text wasn't considered a usability issue.

I believe there is a difference between technological issues and organic issues. However, since the community mod tells me that I'm wrong and there isn't, then there's no point in me being here, because I'm not going to change that mental categorisation to fit community standards.

there is a difference between such issues, but they can both be accessibility issues. i think that's what folks felt you were dismissing, if that makes sense.

that said, if you're that set on leaving, i'm not going to try and discourage you further.

Right - and that's where I've not explained myself clear because I was differentiating (which I felt was important), not dismissing.

are you willing to try again, then? Because both kinds of issues are important. Some issues are technological and can be fixed at the systemwide level (e.g. WAI-ARIA compliant HTML; alternative text for images; well-designed forms). Some issues are technological and are up to individual style designers, which is where education comes in for those who are interested in said education. Some issues are organic and can also be resolved with education for those who are interested in it. I'm still not clear about which distinction you were trying to make, but I am interested, now that you explain that you weren't being dismissive.

Please don't leave! Having conversations like this can be difficult at times, as people try to figure out how to most effectively communicate with each other, and the biggest problem with talking about accessibility (I've found) is that something that might be a critical accessibility resource for one person has never even struck someone else as being an accessibility issue at all.

We just need to remember that when someone's already dealing with an accessibility problem, and has mentioned it to this community as such, hearing back that the audience doesn't consider that something an accessibility problem can give the OP the impression that Dreamwidth doesn't care about them, even if it's not a Dreamwidth representative making the comment. (Not to mention that being told that your experiences and perceptions of the world aren't valid is something that a lot of people with disabilities hear a lot, and as a PWD myself, I can testify that it's pretty much immediately rage-inducing!)

I also think it's critical for us to remember that there are two separate things being discussed in nearly any accessibility discussion in this community: what Dreamwidth-the-platform can do to make the site more accessible for people (in terms of the choices we as a service provide and what defaults we assume), and what individual people can do to make their journals more accessible for their readers. Something that we-the-service can do to make the site more accessible is different than something individual people can do to make their journals more accessible, and we-the-service have different priorities (because we have a much broader range of users, with a correspondingly broader range of accessibility needs) than an individual journal owner.

A specific person might know that none of their readers or friends has this particular issue, so it's not something they have to take into account when designing their style. But they might not know that it's an issue for some people -- maybe they'd want to make those choices, but they don't even know that the choices are available, or they've never thought of something like this as being an accessibility issue at all.

That's what the documentation that

jadelennox is talking about is -- a set of "Things to think about when considering accessibility" that the average person, who doesn't have those issues or needs, might never think about. It's one of the ongoing projects in this comm: not only a set of recommendations that people dealing with accessibility needs can put into use to help them adapt the technology in their own individual ways to make things most accessible for them, but also documentation on "hey, here are some things that might be an issue to some people, along with ways you can make them less of an issue for your readers; you may want to think about whether any of these are things you want to do".

Nobody's saying that anybody has to do any of those things, but one of the projects that

dw_accessibility is working on is making accessibility information more clearly available: pointing out things that can be a problem to some people, and then letting individual people make their own decisions about how many of the recommendations/workarounds for avoiding those hotspots they want to implement.

It's definitely not us-the-service making choices and assumptions for people (such as by not letting them change text at all); it's us-the-service providing documentation that says "hey, this is a problem for some people, and you can still choose whether or not you want to take advantage of this feature we've provided, but if you do, you should be aware that it will have a negative impact on some people". There are a lot of people out there who care about this sort of thing, they just don't know where to start with making their journal/community more accessible, so the documentation project is to list off those "oh, I never thought of those" things.

And because of that, multiple viewpoints is always better to have, because one person's solution to an accessibility issue might make things worse for others, etc. (The more perspectives we have, the greater our chances of offering recommendations that will work for the majority of people.) And in cases like these, there may very well be things where the same behavior (in this case, changing the link's text) is a problem for more than one group of people (in this case, adaptive technology users and those who have differing cognitive functions), and understanding that the same behavior can be problematic for two entirely differing root-cause reasons can give us more information to make those informed choices.

Does that make sense?

to elaborate on what

rb said:

using "nonstandard" navigation text is pretty widely considered a usability issue. Jakob Nielsen explains it well in #10 on this page, and in more depth here.

hope that helps!

Thanks for the explanation.

I find it cognitively confusing, especially on days when my brain isn't working well. Having to figure out that "profile" "user info" "about me" and "tracks in the sand" all mean the same thing uses up cognitive energy (spoons) which I'd rather use reading blogs.

But for me, the style=light is a fine option and once we get sticky style=mine I'll be a much happier camper!

r

I have exactly the same issue - I like seeing people's journal styles as far as colours (now that I have a black-on-white plugin!), images, etc; but I do a cmd-F on a page for navigation text when I get lost, and when people change the text for profile or leave-a-comment, I usually just stay lost.

Even folks without significant cognitive impairment get baffled by really obscure comment text. If it does not literally say "leave a comment", "speak", or something directly related to commenting, it becomes a puzzle that I have to work out. The worst example I can think of is "down to acorn" for "reply to this comment". I have to look at the links to figure out which is which, every single time, unless I have been in there recently. It is difficult for me, and I am not impaired. I boggle to think of how difficult it would be for someone who is impaired.

Generally speaking, consistency will always make things more accessible in lots of small ways - if people know what to expect they can find things more quickly, regardless of what technology they use, and they can if need be adapt their technology better if it can 'hook in' to predictable consistent things.

When you meet an unfamiliar web page you will expect certain things as regards the layout, the way navigation works, what types of things you can do on a page. This is an example of consistency (doing what everyone else does) helping make the web easier for everyone to use. Hence a lot of accessibility techniques are in fact just about trying to codify and implement consistency in one form or another. So it's not just about learning specific techniques, its about a whole attitude, a way of looking at the web.

Hah! Put like that it sounds all romantic and beautiful!

But if you prefer a specific example: I have an illness that can make thinking hard on occasion, when it strikes I literally cannot process the information to understand language easily. On those days, finding a familiar text link will be much easier than having to 'translate' unfamiliar links and work out what each one means.

Oh, and I also very much like the idea of having a page or document or something, somewhere, that gives a list of ways and reasons to design for accessibility. With some sort of header about how while the list is all good things to consider, even just picking a few to fix will make a design more accessible to more people. I bet the wiki's a good place to start?

Belatedly, but some guidelines as to whether navigation, etc, (Recent Entries, Profile, etc links) may be placed before the main content would also be good.

I am looking into it, jumping of from the links to WebAIM in one of your other entries and it looks like some people are against, some people are for? I'm trying to gauge whether it would be a good thing, a bad thing, or a neutral thing for some styles to have navigation links or other content in between the header and entries content, and the feedback I've seen makes me lean towards: as much as possible, no, but some may find it useful.

Hm, do you know if having two sets of standardized text (a long form and a short form) would pose the same problems?

The properties in question are the entry management links, like so:

"Previous Entry" => "Previous"
"Next Entry" => "Next"
"Add to Memories" => "Memory"
"Track This" => "Track"
"Untrack This" => "Untrack"
"Tell Someone" => "Tell"
"Leave a comment" => "Comment"

In all cases, the first is the one currently used by all layouts; the second is one we're considering as a second set to allow layouts to use, if they need more space in the footer bar.

(And if you think this should be a top-level entry, I can do that as well)

Make it a top level entry for us, please. I think everybody but Jade and I will probably miss it posted here :)

For the record, it would be OK with me if there were 2 standard sets like that. A lot easier than one standard set plus a bunch of non-standard shortenings, anyway!

r

Flat | Top-Level Comments Only

suggestion for style documentation

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