Monday, September 22nd, 2008

What if we didn’t lump all “accessibility” requirements together?

Category: Accessibility, Editorial

Joe Walker was thinking about accessibility and wrote about a thought experiment that he had where he ponders ‘What if we didn’t lump all “accessibility” requirements together?’

What if, instead, apps are written for one audience. What could you do differently for different use cases?

Designing for Screen Readers

So you want to create a version of your site specifically for screen readers, ignoring everyone else. What might you do?

Scroll bars are generally bad for sighted people. They hide content, slow things down, and some people find them hard to use. But screen readers don’t care about long pages; the scrollbars are invisible anyway. So how about packing the whole site into a single page? Since the graphics are irrelevant, we can skip those, and for many sites still have less to download. The page can then start with a description of the access keys and the user can then navigate really quickly. We could quickly summarize the access keys at each page boundary in case they’ve been forgotten.

Designing for Dyslexia

Dyslexia is generally less of a barrier to web use compared to blindness, however it is very common and often overlooked. In contrast to the low graphic, high text approach for Screen Readers, some dyslexics think in terms of pictures, and may prefer a layout which uses a standard set of icons to back up common concepts. Many users without this disability may find this approach distracting, and it’s certainly going to be annoying to anyone with a screen reader, if the text goes on regular side-tracks reading the ALT text that is only there to back up the text anyway.

Designing for Cognitive Disability

One of the problems with the web, and computers in general is the level of distraction. Distractions are a problem for everyone whatever their abilities, but the problem is exacerbated by disability. I’ve noticed that as people slow down, they start to look around at their screens using their neck muscles, pointing their entire head rather than just their eyes, and I think it’s all about focus. We need a way to narrow our focus to concentrate on the important questions.

It might be possible to have a site where we could “zoom in” on what was important. If you could “zoom-in” to simplify GMail, what would you throw out? Invitations would go, as would links to other services, settings, maybe labels and the 2 sets of buttons that do the same thing. I think many people use email by just seeing their inbox, and maybe search. Ultimately email could be a wizard where you see what’s new and that’s it. Clearly this lack of detail isn’t going to be good for everyone, but having a “simplify it” function could be really useful in many cases.

Designing for Low Vision and Motor Impairment

I don’t know, but I suspect that the “zoom-in” to simplify concept is going to require lots of complex layout. In comparison to which, people with low vision or motor impairment want simple layout. They also want to zoom in, but probably just to make the words/buttons bigger. People with low vision often differ in how they need the screen enhanced. Is it black/white or white/black. Have colors gone, or might a flash of yellow help? Often the OS takes care of much of this problem, but websites that use yellow-fade might be helping, or might not, depending on OS settings. Good design for low vision is probably going to let the user select the type of visual aid that helps.

Of course, this sounds interesting in theory, but we have the sliding scale:

  • How many developers build for more than one browser, let alone…
  • Old browsers, let alone…
  • Accessibility, let alone…
  • Multiple accessible sites.

Christian Heilmann talked about having a movement for accessibility, and how we need to not be flailing in the wind.

Posted by Dion Almaer at 5:56 am
1 Comment

4.1 rating from 23 votes

1 Comment »

Comments feed TrackBack URI

I think it’s inevitable that you build more than one front-end to cater to different markets. Building a single front-end that scales from a low-end cell phone all the way to a full-blown desktop-equivalent ajax interface is pretty much impossible, either purely from a technical POV, or from a cost/benefit POV.
Looking at gmail they have at least 4 different front-ends: standard (and standard + chat), basic, html mobile, and java mobile.
Each of these is tuned to a particular audience. I think that approach makes the most sense.

Comment by Joeri — September 22, 2008

Leave a comment

You must be logged in to post a comment.