Accessibility issue

[zvi]

I pointed out a sort of overarching issue with the FAQ documentation as currently written to rho, and, in traditional DW fashion, she asked me to take the first pass at solving it.

The problem is that some of the documentation is written with visual, spatial, or movement-specific language. To the extent possible, FAQs/sitedoc should not be written with the assumption that the eventual reader is going to be seeing the same images and screen ratios, nor that they'll be interacting with their computer with the same input devices as the writer's. On the one hand, you have people with disabilities using the site; on the other hand, you have people with an array of mobile devices using the site; and on the third hand, you have a few people out there still cruising in lynx, because they're Richard Stallman. (Not to mention that we'll support different siteschemes, and people will do all manner of funky things with their journal styles.)

I'm going to do a first sweep through the FAQ docs as currently written, but I strongly suggest you guys hook up with the Accessibility team for more expert advice. (For instance, I am unsure about whether or not dropdown menu is a term that is meaningful on a screenreader.) My inexpert advice is that, wherever possible, instead of describing a visual element, you include the image and its alt-text as it will appear on the site (maybe with a note that it's the site default?), and if you can skip the visual element and just link to the thingy in question, that's even better.

By visuospatiai issue, I mean that the FAQ says "perform this motion" for interacting with the site, or "item found to the left of second item" or "choose the [textual description of image] to accomplish task" Any language which requires the user to be seeing the same site visually or using the mouse or keyboard like the writer.

Additionally, all link text should be meaningful ("Choose your sitescheme" instead of "click here to"), and, a title attribute should be set when the link text doesn't match the page title of the page the link refers to.

FYI Each tab of my account settings has a URL, so you can link directly to that tab.

FAQ's w/ visuospatial language

How do I confirm my email address? typed rather than entered

How do I change my email address? verbal redirect to settings tab

How do I change my password? verbal redirect to settings tab

How do I post an entry? vs

How do I post an entry to a community (or alternative journal)? vs

How do I restrict who can see my entry? vs

How can I choose which usericon to use? vs

How do I edit or delete an entry? vs

How does comment threading work? vs

What happens when there are large numbers of comments? uses "see" a lot

What are the limits on comments? see

Can I edit or delete my comment? vs

What can I do with comments posted to my journal? vs

How do I control who can comment on my journal? settings tab; vs

What is comment screening? vs

What is comment IP logging? settings tab, vs

What is a profile and how do I update mine? vs

How do I subscribe to other journals? vs

How do I grant access to my protected content to other journals? vs

How do I unsubscribe or revoke access from another journal? vs

What are notifications? settings tab

What is tracking? This might be a good model for how to deal w/ images that will be changed on user site schemes!

How do I stop tracking something? settings tab

P.S. Psst. forthwritten. May want to include site-specific URL forms in What Dreamwidth specific markup can I use?. All the lj were replaced with site.

Comments

[rho]

Thanks for taking the time to do this! I definitely want to try to make sure our docs are awesome from an accessibility standpoint, so this sort of correction is very welcome. Speaking only for myself, I know I have a lot to learn on this front. I'll poke at rb next time I get a chance to see if we can come up with some way of coordinating this properly.

[zvi]

You're welcome. And the short format of each FAQ meant it actually wasn't difficult to do, I could pull up a whole category to read all at once.

[jeshyr]

My suggestion would be to have a "best practices of inclusive language" guide which supplements the style manual.

The trickiest bit is balancing the use of language that normative (this means 'statistically average' BTW) users expect such as "click here", and language which is more inclusive and helpful. If you go too far in the other direction it becomes difficult for people to understand.

Suggestions:
- "follow" links rather than "click on" links
- "click on" buttons though, because there's just no better verb
- "enter" text rather than "type" text

You've all been so quick at updating the links zvi provided that I can't spot a lot of the problems any more! Might need more examples?

[jadelennox]

As many times as I see dw's commitment to accessibility, something new always comes up which floors me. zvi, seeing somebody outside the accessibility evangelist or disability community expressing concern about exclusive language in documentation is just not something I have ever seen in my life. *wipes away a little tear*

All that being said, I completely agree with rb here that having a best practices guide supplementing the style manual for all site copy is a good idea. Most of the things which immediately come to mind have already been mentioned here in this post and comments: meaningful link text (this is the most important one for usability), no mouse-specific language such as "click" or keyboard-specific language such as "type". No assuming that people can see icons: if an icon is required for documentation and describe it but also refer to it by its alt text. No assuming that people can see colors, or that page layout is going to be controlled successfully by CSS.

I think it would be very interesting to turn off CSS and images and see if the documentation still works. It would also be interesting to turn off CSS, images, and unplug a mouse and see if the documentation still works, although this requires having a tester who knows how to navigate the Web without a mouse. Luckily, our code makes it pretty easy. :-)

[jeshyr]

I agree it's totally mind-blowing to have a project that cares about accessibility so much and in so many directions! \o/

I mostly agree about 'click' and 'type' but can you think of appropriate language for submitting forms where the buttons aren't labeled 'submit' and users don't usually know what "sumbit the form" means? I can't think of clearer language than 'click on the BLAH button', personally.

And about your CSS/images test - I usually load images (although I have 'use placeholders' set for everything but small ones) but my basic method of reading involves wiping all site-loaded CSS and most other formatting and replacing it with what suits my eyes - white text on green. I read everything that's longer than 2-3 paragraphs this way, so pretty much all journal stuff.

I have a bookmarklet that does it, for anybody that's interested you can try this one:

Zap Formatting And Replace With Ricky's

(For those unfamiliar with bookmarklets, it'll go back to normal if you reload the page or click on any link). I think I got the escaping on that right, I guess I'll see when I post it ...

The bookmarklet's built for Firefox but last I checked it worked in Safari too so it should work with Chrome. No guesses about MSIE though. If it actually looks useful to you guys I can easily modify it so it leaves you with black text on white - probably easier for those with normal eyesight!

(Actually I have 3 bookmarklets, this is the "first level" one and there's two more than do heavier duty formatting removal for stubborn sites with nasty things like tables for layout. Happy to share if anybody's interested.)

Cheers,
r

[jeshyr]

OK, I totally fail with the bookmarklet thing. If somebody can urlencode the @$*&( thing properly and post it that'd be cool. I might fight with it tomorrow if I have the energy - bed time now.

[jadelennox]

Another good way to test,in Firefox is using this fantastic accessibility extension. I use it to turn off accesskeys (which interfere with all of my shortcuts), but it has some great testing features. Opera has a whole slew of built in stylesheets, including some designed for accessibility, which can also show you how a webpage might look for people using accessibility software. (On opera, they are in the "view" menu.)