So I gave a presentation at PyCon about HTML, which I ended up turning into an XML-sucks HTML-rocks talk. Well that’s a trivialization, but I have the privilege of trivializing my arguments all I want.
Somewhat to my surprise this got me a heckler (of sorts). I think it came up when I was making my <em> lies and <i> is truth argument. That is, presentation and intention are the same. There are those people who feel they can separate the two, creating semantic markup that represents their intent, but they are so few that the reader can never trust that the distinction is intentional, and so <i> and <em> must be treated as equivalent.
Someone then yelled out something like "what about blind people?" The argument being that screen readers would like to distinguish between the two, as not all things we render as italic would be read with emphasis.
It’s not surprising to me that the first time I’ve gotten an actively negative reaction to a talk it was about accessibility. When having technical discussions it’s hard to get that heated up. Is Python or Ruby better? We can talk shit on the web, where all emotions get mixed up and weirded, but in person these discussions tend to be quite calm and reasonable.
Discussions about accessibility, however, have strong moral undertones. This isn’t just What Tool Is Right For The Job. There is a kind of moral certainty to the argument that we should be making a world that is accessible to all people.
I fear this moral certainty has led people self-righteously down unwise paths. They believe — with of course some justification — that the world must be made right. And so many boil-the-ocean proposals are made, and even become codified by standards, but markup standards are useless unless embodied in actual content, and this is where accessibility falls down.
There are two posts that together have greatly eroded my trust in accessibility advocates, so that I feel like I am left adrift, unwilling to jump through the hoops accessibility advocates put up as I strongly suspect they are pointless.
The first post is about the longdesc attribute, an obscure attribute intended to tell the story of a picture. Where alt is typically used as a placeholder for the image, and a short description, longdesc can point to a document that describes the image in length. Empirically they (Ian Hickson in particular) found that the attribute was almost never used in a useful or correct way, rendering it effectively useless. If the discussion had clearly ended at this point, I would have deducted points for those people use advocated longdesc based on bad judgement, but it would not have effected my trust because anyone can mispredict. But the comments just seemed to reinforce the belief that because it should work, that it would work.
The second post was Ian Hickson’s description of using a popular screen reader (JAWS) — you’ll have to dig into the article some, as it’s embedded in other wandering thoughts. In summary, JAWS is a horrible experience, and as an example it didn’t even understand paragraph breaks (where the reader would be expected to pause). What’s the point of semantic markup for accessibility when the most basic markup that is both presentation and semantic (<p>) is ignored? Ian’s brief summary is that if you want to make your page readable in JAWS you’d do better by paying attention to punctuation (which does get read) than to markup. And if you want to help improve accessibility, blind people need a screen reader that isn’t crap.
Months later we started talking a bit about the accessibility of openplans.org. Everyone wants to do the right thing, no? With my trust eroded, I argued strongly that we should only implement accessibility empirically, not based on "best practices". Well, barring some patterns that seem very logical to me, like putting navigation textually at the bottom of the page, and other stuff that any self-respecting web developer does these days. But except for that, if we want to really consider accessibility we should get a tool and use it. But I don’t really know what that tool should be; JAWS is around $1000, all for what sounds like a piece of crap product. We could buy that, even though of course most web developers couldn’t possibly justify the purchase. But is that really the right choice? I don’t know. If we could detect something in the User-Agent string we could see what our users actually use. But I don’t think there’s information there. And I don’t know what people are using. Optimizing for screen magnifiers is much different that optimizing for screen readers.
Another shortcut for accessibility — a shortcut I also distrust — is that to make a site accessible you make sure it works without Javascript. But don’t many screen readers work directly off browsers? Browsers implement Javascript. Do blind users turn Javascript off? I don’t know. If you use no-Javascript as a hint to make the site more accessible, you might just be wasting your effort.
There’s also some weird perspective problems with accessibility. Blind users will always be a small portion of the population. It’s just unreasonable to expect sighted users to write to this small population. Relying on hidden hints in content to provide accessibility just can’t work. Hidden content will be broken, only visible content can be trusted. Admitting this does not mean giving up. As a sighted reader I do not expect the written and spoken word to be equivalent. I don’t think blind listeners lose anything by hearing something that is more a dialect specific to the computer translation of written text to spoken text. (Maybe treating text-to-speech as a translation effort would be more successful anyway?)
A freely available screen reader probably would help a lot as well. I write my markup to render in browsers, not to render to a spec. Anything else is just bad practice. I can’t seriously write my markup for readers based on a spec.
Automatically generated list of related posts:
- lxml.html Over the summer I did quite a bit of work...
- Python HTML Parser Performance In preparation for my PyCon talk on HTML I thought...
- Avoiding Silos: “link” as a first-class object One of the constant annoyances to me in web applications...
Thanks for the thought provoking post.
I don’t have the answers to your many questions about accessibility and the often poor support on different platforms, but I attended a presentation last year that I found enlightening:
http://www.nuug.no/aktiviteter/20071211-accessibility/
The resources for the presentation, including the slides and video, are available.
Would it be possible for the blind to read through an annotation layer similar to Ping’s Crit http://zesty.ca/crit/ in which they and others with poor vision could collaboratively edit a screen reader appropriate layer?
I’m a blind screen reader user, and try to keep my own web site as accessible as I can, whatever ‘accessible’ means to any particular person.
I don’t understand all the technicalities being discussed here, but maybe a few comments would be helpful.
To me, a good web page is just a well-structured page, with content that I actually want to read. Get the structure right and most other things will follow.
I visited a friend’s site because he wanted accessibility comments. It was great – the screen reader told me everything I needed to know, and it did it without any glitches.
But when I ran the code through an HTML validator, the validator moaned about various supposed accessibility problems. These amounted to stylistic niceties. The id attribute for some of the paragraphs wasn’t explicit enough. Well, big deal, who cares? It didn’t stop the page reading fine.
It’s hard to imagine anyone getting heated over the longdesc tag. Don’t use it, is all I’d say. Use succinct alt tags instead and nobody needs to break their brains trying to make graphics accessible. Alt tages being absent altogether can be a major problem, however, if you’re expected to hit buttons that just look like a series of blobs – something you often come across on the Web, and in desktop programs, for that matter.
There are freely available screen readers, and some are getting very good. NVDA at http://www.nvda-project.org/ is possibly the best of these. It is fairly JAWS-like in some ways, but costs a thousand dollars less, and doesn’t do horrible things to your video display or your registry.
There’s also System Access to Go, which has been made available free as a web based screen reader at http://www.accessibilityisaright.org/
Then there’s Thunder, free from http://www.screenreader.net. Arguably Thunder is the weakest of these screen readers, but whatever floats your boat… It does seem to go down well with less expert computer users.
What do blind people actually use? Well, moot point. Most don’t use anything, and don’t go near computers, which are too alien to deal with. At the other end of the market, the elite of screen reader users are relatively well catered for, not least because many get access tech paid for so they can do a job, and get subsidies from Governement agencies. That’s the only reason that things like JAWS can exist. The point, though, is that accessibility has been pretty much formulated for screen reader users, and other people with disabilities don’t get anything like so much of the action. I have an axe to grind as a once partially sighted computer user. Then there are dyslexics, colourblind people, those with minimal dexterity, deaf people and on and on, who also deserve a slice of the cake. But in the end, so long as web designers don’t put up unnecessary barriers, they won’t cause any of those people too much grief.
Less well known, and cheaper, screen readers are Window Eyes, Hal, and Serotek System Access (paid version). Although JAWS is the well-known one, it doesn’t seem to rule the place like it used to. Every screen reader has its advocates, but then, once you’d paid up and mastered all those dastardly 4-finger keystrokes, you’d better believe you’re using something really good! At the moment, it seems that the jury’s out on which screen reader will prevail longer term.
I can’t believe JAWS cam’t recognise paragraph markup! NVDA does it fine, but you need to spend a minute setting up the config so that it does it. JAWS, I understand, has a jungle of verbosity settings, and with enough fiddling about, I’m sure it can be made to treat the markup of pages in many different ways.
Worth mentioning that JAWS and the others I mention are confined to the Windows platform. Voiceover on the Mac is now a serious contender, not least because it’s included in the price of the computer. Then there’s Linux……..
Quick mention of CSS – a great way for sighted people to have their eye candy and for blind people to eat it too.
I don’t like the sound of a separate layer for blind people. I don’t know what it means technically anyway, but let’s stay mainstream, please.
To your point about freely available screen readers, I can testify that the screen reader built into Mac OS X is very usable, and I’m told there’s screen reader infrastructure built into Windows XP.
I’m all for empirical testing of the accessibility of web pages, but I suspect you’ll find that after you play with the screen reader on a representative sample of code, you’ll gain an intuition on what works and what doesn’t very quickly, and will use the software less over time.
Screen readers do indeed execute JavaScript (or rather run on top of browser DOM trees that have already executed it for them) – they have to, or a huge number of sites would be completely useless. That doesn’t mean that unobtrusive scripting can’t help with accessibility though. The principle accessibility problem facing heavy JavaScript sites today is that there’s no reliable hook for telling a screen reader “that part of the page was just dynamically updated”. If you submit a form by Ajax and then refresh the contents of a div with a thankyou, a screen reader user won’t hear anything – they’ll have to manually rescan the entire page to figure out what just happened.
With unobtrusive scripting, you can provide an “accessible version” which is actually just the regular site but with all of the window.onload style handlers disabled. A simple checkbox (hidden off screen with CSS if you like) which sets a cookie and you’re done.
Hey Ian, I was a bit surprised by your heckler but you seemed to perk up, as if challenged. If it were me I doubt I’d be able to handle it so smoothly. Good job ;) PyCon isn’t well suited to having a “discussion” during a talk but, then again, that may or may not have been useful.
There was an important message I got from your talk that deserves mention: the web is filled with bad HTML and we are stuck with it, so let’s learn to deal with it instead of despise it. Accessibility purists have a hard to time coming to terms with this.
On a personal note, I am highly grateful for your work on lxml.html because it has been the only reliable way for me to apply xpaths to ebay HTML descriptions (for a project where I want to analyze thousands of auctions). Anyone who is familiar with the site knows these descriptions are created by sellers and quality wise are on par with geocities markup. Yet for my purposes contain information I want to parse and there is nothing I can do about their abuse of HTML. So, thanks!
Bat: thanks a lot for all the links. I gave NVDA a try, though only with limited success. It seemed to have performance issues that caused it to delay for long periods of time with no feedback, or start reading something that had moved from the screen a while ago. It ended up swallowing keys from the right-hand side of the keyboard, even though its speech claimed to be typing those keys. Luckily I at least was able to see the page to realize this was happening. I tried a couple times to navigate with the screen turned off, but it was quite unsuccessful.
Another issue I had was with links, which sometimes NVDA would read out in full (the href — a long, tedious, and unhelpful link). I don’t know why it chose to do that sometimes and not other times. There seem to be a number of toggles which I imagine you’d turn on or off depending on the page. But you have to be familiar with the tool to know what to do when.
In the end I got [a couple ideas](http://www.openplans.org/projects/opencore/blog/2008/03/24/accessibility-on-our-site/) of small things we could improve, but only small things. Actually getting into the site revealed problems with NVDA that I didn’t know how to get past. I’ll be giving some other tools a try as well.
You may want to try the following LiveCD: http://clcworld.net/mozcsun2007_iso.zip
Details at: http://lists.becta.org.uk/pipermail/oats-sig/2007-March/000919.html
It uses the following: 1. FireVox – the screen reader add-on to Firefox giving access to both browser and the web 2. CLiCk, Speak – the add-on that speaks and highlights the web under user direction 3. NVDA – the open source windows screen reader.