Austin Seraphin’s posts on his experiences using the Voice Over technology in iPhone and Mac OS has been mentioned fairly widely and they are definitely worth reading. Many people understand that blind users, and people with other forms of disabilities, are dependent on screen readers to interact with computers, but what is likely to come as a shock is just how expensive high quality screen readers can be:

I joyfully look forward to the day when blind people finally catch on and realize that for $700, HALF the cost of JAWS for Windows, the most popular software used or rather pushed on the blind, they can get a fully functional computer that delivers a superior experience and comes with a superior screen reader with superior speech.

JAWS standard edition turns out to be $895 on the online store, professional $1095 but that still doubles the cost of a computer for users who need a screen reader. There are open source screen readers and my understanding is that some of them are quite good, but the defacto-standard is very much JAWS. Most accessibility testing that is done is with JAWS and so it’s an up-hill battle to use anything else.

If you keep that cost in mind, you can understand why old versions of screen reader software are so common. It also brings a new understanding to the blog post from the IE9 team indicating that screen readers would need to be updated to work with it:

IE9 fundamentally changes how users interact with the browser and how the browser takes advantage of the entire PC. Those changes also impact how assistive technology interacts with IE, which necessitates updates from some assistive technology. For example, the new notification model is not read by many screen readers, and screen readers can no longer depend on the GDI display subsystem since IE9 uses Windows Direct2D and DirectWrite as part of enabling hardware-accelerated HTML5.

The move to Direct2D and DirectWrite may well make sense, though it’s disappointing that screen readers felt the need to depend on a display sub-system instead of proper accessibility APIs for some reason. However, I find it quite appalling that the new notification model is inaccessible. Surely there is, or should be, a standard set of Windows APIs that can provide this kind of notification in a way that is also accessible to screen readers.

It seems to me that having the full screen reader API built in to the OS and maintained, as a priority, by the OS team is a pretty revolutionary step forward in terms of both reducing the cost of accessibility and improving it’s quality. It sounds like we still have an awfully long way to go though.

When I wrote my post on accessibility the other day, what I really meant to say is what basically what Rob Foster wrote. Very roughly summarized, accessibility is about real people, not checklists.

The issues of accessibility are a daily reality for my family. For us, it’s not a political issue at all. Our oldest daughter, Ramona, has cerebral palsy and uses a wheelchair to get around.

…

Here’s my point–if your brother or sister had a disability, you would give a crap. But you don’t have to have a sibling in a wheelchair to genuinely care, even if it’s only in your work.

And:

And from my perspective, accessibility is about giving a crap.

Accessibility is NOT a checklist.

Accessibility is about usability.

Accessibility is a paradigm shift.

Accessibility is a personal issue.

Checklists and accessibility reports are just tools to help you make things accessible – they can be really powerful if they’re used with the right intent, but they’re not the answer.

That’s why I’m so glad to see Ephox adding not just more and better accessibility checking and reporting into their products, but also tools to make it easier for authors to get accessibility right. We need to do more though, so much more, but at least it’s a start and we can start taking this message out to all the web content administrators that we talk to and try and get them to care.

Mark Pilgrim and Sam Ruby have been going back and forth and back again about accessibility and in particular the SVG images on Sam’s blog. In Mark’s latest post he explains the somewhat crazy world of access enablement:

Long answer: As far as I know, none of the commercially available screenreaders support svg in any way, much less reading the title of an svg image included inline in an xhtml page (as opposed to, say, linked from the src attribute of an <img> element, or embedded in an <object> element). Nonetheless, you have provided a text alternative for the image, and theoretically, that could be presented to a user in place of (or in addition to) the image. You have therefore fulfilled your moral duty, even though no one actually benefits from it. Welcome to the wacky world of access enablement.

Mark’s right – in many companies and other organizations you have to tick the boxes for accessibility rules and they are quite often just plain stupid. Mark calls that access enablement, I call it beurocracy or perhaps more kindly, the only effective way to get a large organization to meet difficult to understand objectives.

However, in the case of Sam’s blog, there really isn’t any loss of information if you can’t see the image. They act as a kind of category logo, and when you can see them, provide a quick way to scan the page for a particular topic. It would not be quick to scan the page if the images were displayed as a text alternative.

In fact, it could well be argued that adding the text alternative makes the page less accessible, not more. Compare:

Accessible

accessible

Mark Pilgrim: Deep thought: every post on @samruby 's blog since June 2006 contains an image without a text alternative.

With:

Accessible

Mark Pilgrim: Deep thought: every post on @samruby 's blog since June 2006 contains an image without a text alternative.

If you were a blind user accessing the page with a screen reader (the mythical one that supports titles in SVG), your screen reader would say the word “accessible” twice – once as a header and once as the alternate text for the image. You might get “Heading: Accessible, Image: Accessible” read to you but it’s still not useful. The single most useful thing that could be done with that image when encountered by screen readers is to simply ignore it.

One of the biggest challenges about accessibility is convincing people that it’s not just about adding alt tags to images, it’s about allowing people with disabilities to access the page. Following the rules to the letter is neither the absolute right answer nor a silver bullet. What you need to do is actually test with real world tools. That’s why the actual rules, particularly in WCAG 2.0, are so incredibly vague. The techniques are more detailed and more descriptive but the rules themselves are very high level.

The same thing applies in the real world. You have to provide ramps or elevators so that people in wheelchairs can get everywhere they need to go, but you don’t have to provide ramps everywhere. There are plenty of shopping malls and other public places that provide a normal set of stairs in the most convenient place and an elevator off to one side. Sam’s blog is a perfect example of that concept applied to software. I read Sam’s blog without seeing those SVG images all the time because they don’t come through to my feed reader, yet I can still tell what the post is about because it has a descriptive title.

If you’re asking yourself “does my site meet WCAG 2.0?” you’re doing it all wrong. You should be asking “is my site accessible?” Just meeting WCAG won’t necessarily make your site accessible – do it if that’s what is required to get paid, but don’t fool yourself into thinking that it’s the real aim.