suggestion for style documentation

[jadelennox]

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

Comments

[jeshyr]

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

[jackandahat]

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

[hypatia]

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

[jackandahat]

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.

[hypatia]

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.

[jackandahat]

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

[jadelennox]

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.

[denise]

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?