Just back from @media Ajax with a few ideas buzzing around. One based on this comic:
It's patently absurd. And yet it's what we do with accessibility all the time, and in some ways the differences between someone with a visual impairment and someone with dexterity difficulties could be greater than the differences between a Spanish and Italian speaker.
Now it's true that, unlike translations, many of the guidelines aimed at one group don't get in the way of other users. But what would we do if we designed pages just for one group of users. GMail and other sites have taken vague steps in this direction. At a very brief glance I can see Standard, Standard+Chat, Basic HTML and Mobile versions. What would GMail for screen readers look like?
So I'm going to take a stab at the thought experiment. Feel free to chip in with some ideas:
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.
The Real World
I have no idea if any of these ideas would work as expected, but I'd love to see the results of some research in these directions.
Perhaps the biggest issue is the extra work. I think it’s possible to create top notch user experiences by focusing on ability in this way, but it’s probably going to cost more, and it’s not required on order to make an accessible site. Maybe one of the worst outcomes is that someone puts the effort into creating a top-notch site in this way, but then lets the effort lapse and over time the end result is some accessible pages that lag behind the rest of the site. The WCAG guidelines warn against multiple sites for this reason. If you’ve created a genuinely top-notch experience then it’s hard to see a sane person complain that you should be doing a worse job, just for the sake of following a recommendation.
[...] more at SitePen Blog » Accessibility Experiment [...]
Ideally, we should have a framework that abstracts away all these differences and generates different interfaces for different target profiles – something like what GWT does for different browsers.
[...] 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” [...]
for simple sites, it’s very feasible to make a single sites that serves the needs of all these groups reasonably well, by using nothing more than html’s built-in affordances and accessibility hooks. these then interact with the user’s specific browser/AT setup to allow for the presentation/interaction that’s right for them.
certainly, as sites become more complex (with lots of ajax interactions, motion video, etc), this task becomes exponentially more difficult. the danger, however, is to “ghetto-ize” users based on their “disability”. thinking for instance about the old “text only” versions of sites, these were quite typical (and in some circles still are) of sites that were so utterly inaccessible in themselves that the only option to provide a modicum of access to users that didn’t have 20/20 vision, full multimedia capabilities, and the ability to click minute pixel-sized buttons and such was to cart them all off into a no-graphics, stripped-down poor relation of the site.
it’s a slippery slope, but i guess this will depend on each specific situation.
Here’s five basic problems with this approach:
1. Real people are more complicated than any categories you’re going to come up with. For example, you assume “the graphics are irrelevant” to a screen reader user. But many screen reader users are partially sighted and can still make some use of images, while images can be social objects even for totally blind users (e.g. some blind users want to share baby photos with relatives via photo sharing sites). Conversely, many of the features you propose offering only to people with certain disabilities are potentially useful to a much wider audience. For instance, I don’t normally use a screen reader but I regularly select the all-on-one-page version of an article for reading, sharing, and printing. Again, starting users with a simple interface that can disclose a more complex interface is a common approach in interface design for everyone, not one that is only appropriate to people with cognitive disabilities.
2. The effort available for accessibility is limited. In reality, most developers aren’t going to implement multiple versions of sites, those developers that do will tend to take different approaches (reflecting either different mental landscapes of disability or just different technical whims), and the activity saps effort from other accessibility efforts (e.g. captioning video). This is supoptimal compared to supporting native user agent features that provide consistently accessible experiences across the web. Two of your example ideas duplicate functionality already available from today’s user agents:
(a) Removing images from a site for screen reader users is pointless since every popular browser offers the ability to disable images.
(b) “[P]eople with low vision or motor impairment want simple layout” and Opera (for example) provides a series of accessible skins that can be applied to every site. Developer energy is better spent ensuring such global skins work correctly, or creating good hooks for user customization engines like Stylish, than creating skins specific to their site.
3. The sites most likely to suffer from lack of maintenance are the versions fewer people see. It’s not uncommon to find “accessible” versions of sites that are out-of-date or simply broken compared to the normal version.
4. Having multiple sites interferes with deeplinking and social bookmarking, since you can no longer point people at a single node that works for everyone. Worse still, the “accessible” version of a node is regularly inaccessible except navigating via the homepage of the site (and there are plenty of sites that fail to advertize “accessible” versions effectively even on their homepage).
5. Having multiple sites interferes with friends and colleagues sitting at the same machine and consuming the same site. e.g. Harry, who is totally blind, might nevertheless want to leave images on for his friend John, who has dyslexia.
In conclusion, W3C, RNIB, and other organizations warn against the seductive multiple-versions approach to accessibility with good reason. I would never rule out multiple versions as an option, but if you take this route, I recommend thinking in terms of creating multiple versions useful to as many people as possible rather than as narrow a group as possible. (I get the impression the most successful “accessible” versions appear to be the mobile versions of sites, precisely because these had to be maintained for users without disabilities.)
As an aside, you say (of ALT text for illustrations) that “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”, but if the ALT text doesn’t add anything to the main text and isn’t needed a text for a control, then it should have ALT=”" and will (typically) be ignored by aural and braille user agents.
Just to be clear:
The post is about an *experiment* (it’s even in the title) into what the absolute best might look like. We’re prevented from doing the absolute best that we can for some groups because it’s clearly bad for everyone else. The pack-everything-into-one-page idea is perhaps the best example.
The reason for the experiment is what you could learn about creating top notch accessible experiences. I expect that there is a lot you could do with JavaScript to allow pages to morph from their original state into versions that suit some people better.
I think it would be an interesting experiment to conduct for demonstration purposes. Though impractical for real-life usage, this may bring to light some usability issues, specific to certain disabilities, that otherwise would be lost in a universally-designed site.
As a “thought experiment”, I think it is a very useful exercise, but no further than that.
The majority of the alterations can be achieved via CSS and presented to the user as options they can choose.
The whole idea of presenting a “you’re different in ‘this way’ you should go here” context, is just begging for a discrimination complaint.
Some people with disabilities are touchy about this.
You might be faced with the choice of which screen reader to code for, or worse, which version? Here, the tip of the iceberg starts to show itself. This goes for screen magnifiers, self-voicing browser technologies (more are popping up every day) and any number of alternate interface technologies.
I have found that applying web standards, good semantic mark-up, and not imposing my own perceptions of how a site should “look” to people with differing levels of ability is the safest route.
Are you ever going to please everybody, regardless of their level of ability or available technology, probably not. You are going to present an adaptable, usable, flexible design which will play nice with the majority of Adaptive Computer Technologies.
If one were to undertake the actual coding of the thought experiment, I’d love to hear the amount of effort that was required to implement it. It would be a really good case study on the folly of such an endeavour.
Again, as a “thought experiment”, we should all give it real consideration every time we think about designing for a particular audience.
I thought I’d share a little story with you about a lady I worked with once. This lady used a voice-activated screen reader. But not because she had any visual impairments at all. She was undergoing rehabilitation for RSI (repetitive strain injury) and was not able to use a keyboard or mouse.
I imagine that there are many users out there who are using screen readers because of fine or gross motor impairments rather than visual impairments.
Nobody seems to consider this user group when they are discussing accessibility.
As Benjamin Hawkes-Lewis states above, using imagery for dyslexia doesn’t have to be as invasive as you suggest.
For example, I use a 16×16 icon with ALT=”" for the “logout” link on my web apps since the link text (within which the image is located) already contains everything the sighted and non-sighted visitor needs. The icon becomes a non-obtrusive bonus.