¶ I consider myself to be pretty competent at making websites accessible but I know I don’t know everything. So one of the prime reasons for going to @media was to learn more from recognised experts in the field, and yet I came away confused and disillusioned.
That’s not to say I didn’t learn anything: Derek Featherstone’s working practices of an accessibility agency were extremely insightful, Joe Clark’s discussion of the needs of low vision users was an aspect largely overlooked and seeing Robin Christopherson – a blind JAWS user – demonstrate his daily struggle with a screen reader was a sharp reminder to us all.
But I wanted answers and none were forthcoming. I was aware that some of the issues (technical and otherwise) are still sketchy but I assumed that other people knew the answers. It seems not. I don’t know any more than I thought I did but we as an industry know less, which makes me wonder what ‘accessibility consultancies’ are telling people. Even those on the cutting edge of web accessibility have a long way to go. Here’s two big issues for a start:
Javascript support in screen readers
Screen readers are relatively easy to support. There’s no graphics to worry about, so just ensuring valid, meaningful mark-up and helpful alt text will get you most of the way there. But did you know that JAWS supports JavaScript? But it doesn’t just try to interpret Internet Explorer’s behaviour, it does its own thing too, and different versions of JAWS do it to varying degrees. So even if you’ve been good people and ensured your site works without JavaScript it might be your site still breaks in JAWS. For this reason, Derek Featherstone has gone so far as to recommend that JAWS users should disable JavaScript.
It’s worth adding that during a Q&A session, Robin Christopherson said that even skip links navigation are not necessary if you put navigation in a list because JAWS can just skip a list. But another blind reader in the audience disagreed with him on this principle. Which highlights another issue in itself: JAWS is so minutely configurable that one technique will help one person but hinder another, even if they have the same disability and use the same software.
Sites for low vision users
Not that many people are completely blind; a good deal more have some vision but there is very little provision for this group. Some low vision people use screen zoomers to magnify their entire screen, but many use normal browsers with text set to huge. Some find it easier with light text on a dark background, others prefer the inverse. Maybe Joe Clark’s zoom layouts are the solution for low vision users – they will certainly help some people – but are alternative style sheets enough or even the right approach? No-one knows, and thats my point. WCAG 1 is too prescriptive and out-of-date to provide an answer, and the forthcoming WCAG 2 is looking too abstract and generic to help.
And I’ve conveniently omitted mentioning the needs of deaf people (captioning anyone?), those with reading difficulties, and many other people with particular needs. Time for an industry group with their arses in the real world to forge a path, methinks.
Comments
1
Good post. I’ve said before, and I still believe, that unless you actually test your site with completely blind users and other severely disabled groups, you really have very little idea how accessible of a site you’ve created.
I don’t do it. And neither do 99% of other people developing on the web. If you’re good, you’ll try and follow the best practices laid out by experts like Derek and Joe but really, that will only improve your situation… not necessarily make it ideal. Or even close really.
I’ve always had a problem with the notion that you can serve the same graphically rich, navigationally robust, and distraction-heavy site to both fully-abled and disabled users and then just go hiding stuff with CSS in order to make things right. Sure, you’re making things “better”, but are you making them “right”?
I’m really becoming quite convinced that a lot of accessibility belongs on the server side. Abstract your site well enough to where your templates are able to spit out the same content to two different URLs. One for standard graphical browsers and one for people with special needs (which can also double as your mobile device site). People have ragged on this technique in the past because site authors, when creating two different sites, often let the latter site waste away, depriving people of content, but if you set it up right, that doesn’t have to happen.
I just think there are fundamentally different ways that disabled people would rather access the web (e.g. less navigation, less fluff, more top-to-bottom layout) and if we really want to serve them correctly, we need to admit that.
2
Interesting post Rich. One thing that @media did was leave me wondering how much of what we typically perceive to be accessibility should be built into websites and how much is the responsibility of assistive device manufacturers or even users.
If some screenreaders provide the ability to jump over lists of links, is there a need to provide skip navigation? If somebody is using a 4 year old screenreader, how much responsibility should that user take for accessibility issues due to using out of date equipment?
Rather than each individual site owner creating a zoom layout, shouldn’t this be handled by the user agent?
Shouldn’t screenreader users and site developers start putting pressure on assistive technology manufacturers in order to enforce some consistancy, in the same way WASP has done with web browsers?
3
Mike – you’ve brought up an important point there which is that accessibility is not about creating websites that work for people with disabilities, it is really about creating websites that work for people.
Thinking too much about serving specific disabilities, software or technologies can lead one down a blind alley, so to speak. That said, one-size-fits-all is rarely on a par with tailor-made.
4
Rich – excellent post; I am the first to admit that I don’t have all the answers, and that the more I know, the more I realize we know nothing.
I agree with Mike when he says you can follow advice all you want, but until you actually test, you really don’t know if you’re helping, hindering or neutral. Especially given that in reality, current best practices will likely be out-of-style in 6 months time as people create new techniques for doing things.
Mike – I generally don’t have any problem with accessibility belonging on the server side; however, I do believe that it belongs elsewhere as well. Building accessibility preferences in to your web site is a great feature – for your web site. My biggest concern with that is that it only helps people on one site. Generally, I advocate using a “what’s this?” type link for such server-side prestidigitation that explains what the widget is there for, and how that person might use their browser to perform the same type of functions. (I’m thinking primarily of easy things here, like text-sizing widgets, not full customization that you would only currently get via user stylesheets – the barrier to entry there is just too high)
Andy mentioned putting pressure on assistive technology vendors – that should be happening soon, to a certain extent. As I mentioned at @media, it would be nice to see an acid test for screen reader software emerge – that may be very difficult, though.
The bottom line is that that there is a lot of work to be done with real people, and even then we’ll still only be slightly better off.
5
Great post RIch! I just read the post and its everything that I would have liked to have read, and a ton more :)
Thanks.
Add your comment
Comments are now closed on this post. If you have more to say please contact me directly.