dw_accessibility | Accessibility needs survey

I will be speaking this year at linux.conf.au on the topic of accessibility -- a one hour and forty-five minute short tutorial called "Beyond Alt Text: Accessibility for the 21st Century". The description of it is:

You know that your software project needs to be accessible to people with disabilities and people using assistive technology. You've tried, even -- but best practices documents are a morass of conflicting statements that leave you more confused than you were when you started, the high-level Web Content Accessibility Guidelines provided by the W3C are useful for identifying accessibility problems but not so good with giving you solutions, and you have no idea how you can make sure that your assistive technology users are receiving the same experience as conventional technology users -- especially since you don't have the thousands of dollars necessary to set up testing environments that cover the most common assistive technology use cases, and automatic accessibility checkers can only go so far in pointing out potential problems. On top of all that, you're worried that your accessibility work is being harmful instead of helpful, or wasting your effort on things that don't matter while ignoring the things that do.

The good news is, there is accessibility beyond making sure that all your images have ALT text, and there are ways for developers who don't use assistive technology to learn how to design for all use cases. This tutorial will cover "thinking accessibly": how to build your web application to be accessible from the ground up. Specific techniques will include:

* How to find and use available automated resources to evaluate how well your project conforms to accessibility guidelines, including what these tools can't tell you.

* How to use or simulate common assistive technology setups without needing to spend thousands of dollars on proprietary, closed-source programs.

* How to use navigational markup such as WAI-ARIA landmark roles to best effect for screenreaders and keyboard navigation devices.

* How to evaluate available open-source toolkits and plugins for accessibility purposes, including listings of toolkits that make accessibility a priority.

This tutorial will also include a series of universal design rules you can follow, from the small fixes you can start applying to your project right now to the big things to keep in mind when designing major features in the future. You'll leave with a better understanding of assistive technology and how to design for it, including what it's like interacting with the web with the help of assistive technology and what the biggest design irritants are. You'll also get a thorough grounding in specific, concrete principles and techniques of accessible and universal design that will benefit all your project's users.

Together, we will also evaluate example sites and make hands-on improvements, then view and experience them with as many different examples of assistive technology as possible. We will concentrate on web accessibility, but the universal design rules are broadly applicable to desktop software as well, and we'll include some desktop software-specific guidelines.

For maximum benefit, you should be comfortable with HTML and CSS, and at least passingly familiar with JavaScript. If possible, please bring a laptop with your choice of HTML editor and web browser. Accessibility exercises will be provided, but if you have a site or project you would like to use for the hands-on section, please bring all necessary files with you. If we have time, we will perform an "accessibility audit" of a project volunteered by the audience.

In order to gather as much data as possible, I'd like to ask people who interact with the internet with the help of assistive technology to take a short "survey" (okay, to answer a few questions, really) -- I know enough to know that there's no way I know everything, and the more perspectives I can get from assistive tech users, the better.

I'm particularly looking for input from:

* screenreader users (both wholly blind and low-vision users -- the contrast will be valuable!)
* voice input/navigation users
* keyboard-only navigation users
* people with accessibility concerns that don't necessarily need assistive tech (ocular migraines, seizure disorders, autistic spectrum disorders, etc) but who can benefit from accessibility work

Still, anyone who feels that they have accessibility concerns, or who feels like they benefit from accessibility improvements, is more than welcome to fill out the list of questions. The more opinions and perspectives I can present, the better.

Please leave a comment with your answers, or if you aren't comfortable discussing your answers in public, you can private message me or email me (denise AT dreamwidth dot org).

1. What assistive technology do you use at least semi-regularly to interact with the world wide web?

2. If you have accessibility needs that aren't covered by the former question, what are they?

3. What are the top five (or more!) things you hate when websites do, and why are they so annoying for you?

4. What are the top five (or more) things that websites do that make your life easier, and why are they so helpful for you?

5. If you could make every website in the world follow one accessibility rule, what would that rule be, and why?

6. What are the things you would want an able-bodied programmer to know, understand, or experience about your assistive technology and/or your accessibility needs?

7. What are some things that people do in the name of accessibility that aren't very helpful, or actively make your experience worse?

8. Is there anything I've forgotten to ask about but you think I should cover anyway?

And, here's for easy cut/paste so it's already formatted:

Flat | Top-Level Comments Only

1. What assistive technology do you use at least semi-regularly to interact with the world wide web?

Adjusting the font size and color scheme in my browser are the main big ones.

Also, captioning when it's available on videos, but that's actually quite a rarity.

2. If you have accessibility needs that aren't covered by the former question, what are they?

Poor motor coordination. Way too many sites make it too easy to accidentally click a button that does Very Bad Things with no confirmation, or put too many links in close proximity that do very different things. Bad enough with a mouse; worse yet with a touch-screen phone or tablet. And often, the sites that make these mistakes also completely ignore keyboard navigation, naturally.

3. What are the top five (or more!) things you hate when websites do, and why are they so annoying for you?

1. Sites that require Flash. Can't adjust the font size or font color, or even copy text to make it more readable. Often breaks navigation totally. And it doesn't even work on my PowerPC Linux box or my iPhone, because Adobe simply doesn't make a player for that platform.

2. Video/audio without even a bare summary of what the content is about, much less a decent transcript. "Hey, you should struggle to make out the dialogue over the really loud background music in this uncaptioned video, possibly using up all your spoons, because it's really important!"

3. Text stored as images. Bearable when it's only used for headers and when it has alt tags. Not so bearable when it's used for body text or untagged. And on a related note, CAPTCHAs-- which are essentially text stored as images that are designed to be inaccessible and difficult to read.

4. Auto-playing audio. Startle reflex, anyone? It's no wonder I often surf with the computer on mute, but when I'm listening to music it comes as a definitely unwelcome surprise.

5. Failing to define both foreground and background colors when defining a custom color scheme. I've seen so many posts written using LiveJournal's rich text editor that hard-code a black foreground color, which is... quite hard to read on my journal layout's black background, to say the least. Similarly, I've seen message templates on Wikia that were, e.g., 'default foreground color' on pale yellow, which is not good when the default foreground color in your style override is white!

4. What are the top five (or more) things that websites do that make your life easier, and why are they so helpful for you?

1. Captioning or transcripts of audiovisual content. So much. It makes it so much easier to enjoy the content without struggling to decipher it.

2. Gracefully reformatting if I set my browser to override your specified font, font size, or color scheme. The reasons should be obvious.

3. Alternate versions that are easy to find. For instance, a Flash-heavy site having an HTML-only version with mostly equivalent content (which I often find easier to navigate). Or a graphics-heavy page having a more easily reformattable text version that was actually designed by a human rather than transcoded by a machine.

4. Sensible tab order. So much easier when I'm entering data into a form, for instance, if the cursor doesn't jump around the screen wildly while I tab from field to field. Keyboard accessibility in general, for that matter-- and that includes not overriding the standard behavior of browser keys like the up and down arrows and the 'close window' and 'go back' shortcuts.

5. No distracting animations. I can read text with such distractions, but it takes so much longer-- if the distractions are gone and I can actually focus on blocks of text, it's so much easier.

5. If you could make every website in the world follow one accessibility rule, what would that rule be, and why?

Test your site! Try changing your browser's color scheme. Try changing your font size. Try watching the videos with your volume turned all the way down and see if it makes sense. Try testing it on an iPhone, or some other platform for which Flash doesn't exist. And so on.

6. What are the things you would want an able-bodied programmer to know, understand, or experience about your assistive technology and/or your accessibility needs?

Mainly, although I'm not deaf or blind, I do have issues with visual and auditory processing. Thus, a lot of accessibility features that are useful for blind and deaf people-- customizable fonts/sizes/colors/layouts, captions/transcripts-- are useful for me for the same reasons.

7. What are some things that people do in the name of accessibility that aren't very helpful, or actively make your experience worse?

As mentioned above, overriding expected browser behaviors, whether they be with the mouse or with the keyboard.

Hiding links to alternate versions so that they're only seen, e.g., by a screen reader or with plugins turned off. In the former case, as a sighted user with screwy vision, I can't find a version that may be more accessible to me without either disabling style sheets or looking at the source code. In the latter case, the FlashBlock plugin causes Flash to be detected but not displayed, thus hiding the link from me.

I'm sure there are others, but I can't think of them at the moment-- I'll leave them in another comment if I do, though.

8. Is there anything I've forgotten to ask about but you think I should cover anyway?

"Are there any accessibility features that don't exist, but do you wish existed? These can be realistic or completely fantastic; your decision."

I don't really have an answer on this, but auto-captioning that actually works (unlike YouTube's...) would be absolutely awesome. Not that it's going to exist anytime soon, of course-- and I say this as someone studying natural language processing!

Hiding links to alternate versions so that they're only seen, e.g., by a screen reader or with plugins turned off.

This, this, so much this. Because so many people think that programming for accessibility means "programming for blind users who are using screenreaders, which of course means JAWS because that's the only one we know about", they think that making alternate versions and alternate functionality available in a way that is hidden from everyone but screenreaders is valid. I actually have to have a NaturallySpeaking macro for "toggle styles", because turning off CSS is the only way I can find those alternate versions and that alternate functionality.

I would KILL for universal speech to text >_

Accessibility needs survey

no subject

no subject

no subject