Weblogs: Web Accessibility

Screen Readers: A web developer failure

Wednesday, September 05, 2007

Ian Hickson (Hixie), one of the editors of what might become HTML 5, rants about JAWS and accessibility. There are some home truths as well as some visual-biased perceptions of screen readers. The commentary about the accessibility people in the HTML 5.0 Working Group are painfully spot on, and he notes the malaise within the accessibility community. (Correction: There are accessibility people in the group that making excellent contributions. Its unfair on my part to lump all the accessibility people into one group and tar them. I apologise to the accessibility people who are making positive, researched and respectful contributions.)

I want to focus on the screen reader concerns Hixie raises. I understand his frustration, but that frustration is absolutely nothing compared to the frustration of the screen reader vendor, and people who rely on screen readers to use the Web. We web developers only have ourselves to blame.

The thankless screen reader

The story of screen reader development is littered with people who couldn't give a damn, and wouldn't live up to their responsibilities. Some of the problems of today are the responsibility vendors like Freedom Scientific and GW Micro, but tracing the roots back through history, they had close to zero support from the web development community.

JAWS is a screen reader. It is not a browser. It sits on top of Windows, and on top of applications it supports. These applications make information known to the screen reader using an accessibility interface called MSAA - the Microsoft Accessibility Architecture.

The key thing to remember in JAWS, as with any Input and Output device, if it receives garbage, what absolutely must come out is garbage. Garbage In and Garbage Out.

No matter Ian Hickson's denigration of screen readers, the fact is that they do a good enough job to allow people with disabilities to be a part of the Web. Its easy to criticise the tool that tries to build on top of a hideous mess of tags - forgetting that its the web developer that created this particular problem in the first place.

Snubbing screen readers

The Web has been unkind to disabled people using screen readers. Through the dark times before web standards was something other than an academic exercise, web sites were typically structure-less blobs of markup. The main group of markup were tables, and then mainly used to simulate a coordinate system for the purposes of layout. For a great number of years, there was hardly structure that could be used. People didn't use headers because they looked horrible, and the blockquote element seemed to be the only reliable way to indent any text. List items offered very little selection of bullet points, so of course, the inline image was used to bring in a better bullet point.

These were the days before CSS came to be decently supported. The days where Netscape 4 represented the pinnacle of web development. Even after Netscape 4 usage dropped to single digits, this form of web development was essential for any site that looked above average.

The web developers were let down by the standards - a specification for CSS arrived in 1996 which was far too late to affect the outcome of the browser wars, and that standard only became decently supported in web browsers from about 2002 - and then only for styling text.

The ability to do stylesheet based layout only solidified in the last three years or so. The main barrier to this has been the usage of Netscape 4 and Internet Explorer 5.5. Just as today that no-one would build a business on a website that failed to work in Internet Explorer 6, people back in the last century could not build a website that failed to work in Netscape 4.

Web developers felt they could not alienate their visitors. And in doing so, we alienated people who needed a logical structured content, not just a visual perception of structure.

How could a screen reader support the over-abundant structureless deposits of web content? They did the only thing they could - screen readers extracted the text of the document, ignoring all the tags around it - except for cases like anchors, and presented that to the user.

Screen readers had no choice. Somehow they had to bend web content into some structure when there was no logical structure to begin with. And they had to do it with no support from web developers. They were on their own - we left them to hang and dry.

Web Standards impact

Has much changed today? Well, there is a small healthy segment of web developers who can build good looking sites that are based on a structured content approach. But that segment is so small. The typical web developer either survived the dark browser wars learning table hacks, and are still using them today; or learnt from materials written by that same group. Armed with spacer gifs, obtuse attributes, nested table hacks, they produce web pages that meet the visual requirements. The same techniques back then still work today.

Hixie seems surprised that JAWS doesn't support the paragraph element - I don't see why. We don't have a World Wide Web that predominantly uses structural elements for structural purposes. Expecting a pause after every paragraph means some pages will have a long period of silence before anything is read out, or perhaps a lengthy bout of silence in the middle of a piece of content. Both give the impression to the screen reader user that there is no more content to be read out.

HTML 5 and screen readers

Perhaps, one of the goals the HTML 5 Working Group should produce, is a logical algorithm that a screen reader could use to determine whether a page contains structured markup that reflects the structure of the content (and so the screen reader could read the page out in 'structured mode'), or determine whether the markup offers no logical structure (in which case the screen reader could ignore all markup and use just the raw text.

Or even better - invite screen reader vendors to participate in the Working Group. I'd be particularly interested in seeing the pitch of why its in their interests.

For long-needed improvement in screen reader capabilities, web developers need to understand we caused this mess, and made it a lot worse when we used logical HTML elements for visual purposes. We did that, and its our fault. We must accept we made a big mistake of ignoring the needs of screen readers when we built those sites many years ago.

Its clear back in the days when screen readers could have benefited from web developer support, that support was non-existent. Now today, screen readers have solved the problem as best they can with the tools on offer, that work is done, without the support of web developers. Its fairly obnoxious to criticise screen readers vendors for trying to serve the interests of their users. It would have been better had we tackled the screen reader problem when their vendors were screaming out for help.

Its clear that screen reader vendors do need to be involved in the development of HTML. But what's not clear is why they should care and where are the benefits for them. Its academically interesting talking about structured content and more meaningful documents, but in the grand scheme of the web, it doesn't solve the massive amount of junk markup that's accumulated and still accumulates. It doesn't remove the burden of screen reader vendors to support the existing web.

No regrets, no remorse?

I see many people talk about the epiphany of web standards. And yet, not a single one of those posts showed any regret or remorse about the barriers they created before their awareness of web standards. And that we need to actively tackle.

HTML is tainted because of its past. Web developers have damned it into being useless as a structural language for content, because it suffers under the burden of our sins. The ones we prefer to quietly sweep under the carpet. The sins we committed that we don't talk about, and yet hypocritically condemn others for continuing in the same vein.

I'm as guilty of this as the rest of us. And I regret the table hacks, the JavaScript hacks, the spacer hacks, the paragraph hacks, the image hacks. All of it. I regret it unconditionally. I regret my solution to taking a page that took three minutes to load up over a modem and bring it down to 18 seconds - that was Legal & General's previous website design, with three levels of precision-required mouse movement and 156 links per page. It annihilated accessibility to achieve that aim, and it took me five years to rectify it. I haven't forgiven myself for it, but that's a good thing.

I let down disabled people that needed accessible content. Yes, it was before I understood the humanity behind accessibility. But ignorance is no defence. I'm just as guilty as the people behind the genuinely inaccessible sites of today. Today I'm lucky in that I have the opportunity to make up for the grievous harm I did before.

HTML 5: Advancing screen readers

I'm not convinced the HTML Working Group can do anything to improve the markup framework that feeds into a screen reader. Another written specification or recommendation doesn't make the web easier to translate into speech. It just creates yet another group of pages that are exceptions to the rule.

For a true advancement of screen readers we need a clean slate. We somehow need to conjure up a situation where websites built in the traditional pre-web standards mould disappear, or are of no value to a screen reader user. Otherwise, screen readers will have to support this abominable mess, and because of the hackery of supporting that mess, there's no practical benefit of screen readers implementing any structural content awareness. (Not enough benefit to outweigh the cost of implementing and trying to figure out when to use it)

Hixie has it wrong when he claims the usability of JAWS is worse than leaving out the accessibility requirements of images. The usability problems of JAWS can be, and are, worked around by their users. Missing textual equivalents on images cannot be worked around. The terrifyingly poor state of the screen reader software in the context of the web is our fault - as web developers we all produced garbage.

Web developers using screen readers

I caution Hixie on using his own experimentation to assess the ability of JAWS. JAWS is for the person who relies on aural inputs. Our visual perceptions skew our aural perceptions. What Hixie finds as a problem in JAWS may be because he is fully sighted, thus a lot less dependent on his aural faculties. For reliable measure of screen reader use, you need to be measuring with people who have no choice but to use screen reader technology.

My general rule of screen readers is - web developers never ever use them. The only people who should be testing in screen readers are people who need to use screen readers in their normal course of the day. Web developers using screen readers leads to a lot of spurious findings and misinformation. Visual versus aural, its a completely different perception of awareness.

Hixie, get a screen reader user to help you asses whatever you are using JAWS to assess. You work for Google, so talk to TV Raman to find out who uses screen readers in their daily job (but not a screen reader power user unless you are testing whether something is just accessible without regard to how usable or findable). Or approach a local accessibility organisation for volunteers. In the UK, both the RNIB and the Shaw Trust can do this on an ad-hoc basis, at reasonable prices.