The Accessibility Chronicles
Dean Kamen’s self-elevating wheelchair: not just assistive, but liberating.So everyone’s all of a sudden talking about accessibility again. Just as you thought 2005 was going to be the year of folksonomies, APIs, and Ajax, the discussion over the last two weeks seems to have centered on a “new” aspect of accessibility:
Whether we really know what we think we know.
Ever since the original movement towards web standards led by the WaSP and many others, we’ve had similar messages sent to us:
“Valid code makes for accessible websites.”
“Use proper semantics to help screenreaders interpret your pages.”
“Use lists for navigation and any other list-like content to improve accessibility.”
And so, for several years designers and coders took these rules of thumb to heart, tried in earnest to follow best practices, and went about thinking their websites were “accessible”.
Why would they think that? Not because they physically observed it, but because they were told it. And who could blame them? You’re a web worker with a million things on your plate. Which is easier to do: hire an accessibility consultant to physically test your sites with disabled people or simply believe what you’ve heard? 99% of us, including me, chose the easier route.
Is accessibility really a “bonus”?
Now, I’ll be the first to admit, I adopted web standards in my work at ESPN, ABCNews, Disney, and other properties for at least five reasons parallel to accessibility:
- Browser agnosticism
- More maintainable code
- More creative page layout options
- More interactive advertising possibilities
- Bandwidth savings
I also created sIFR for reasons only tangentially related to accessibility.
Accessibility was, as people would have you believe, a “bonus” which happened to come along with the use of web standards. Great. I like bonuses. The newer sites we designed did seem more accessible than the old, but how accessible were they?
That is where the recent discussion of observable accessibility comes in and that’s where it should have been from the beginning. Not “what should work better in theory” but “what actually does work”.
Does CSS-P automatically create a better user experience for blind people than table layouts?
Those who know say no.
Are unordered lists always more navigable than manually linebreaked items?
Those who know say no.
Are today’s screenreaders able to consistently interpret even the cleanest of code?
Those who know say no.
So it seems what we’ve been following here for the last few years is a mental model of accessibility than none of us has had the time, resources, skills, or desire to even test. I’ll admit I’m one of those people, but at the same time, I’ve never really bought into the concept fully from the get-go.
Now, keep in mind I’m talking about major media sites here because that’s what I’ve been working on for the last 5 years, but I simply don’t buy into the concept that you can create a huge site which is designed to be explored spontaneously through wildly varying page layouts and intentional distractions and then just go hiding things with CSS in order to make it “accessible”. People come to sites like ESPN partly because they aren’t just a list of links. They come for golf and they end up in the Fantasy Football section… and that’s a good thing. For both them and for ESPN. But does a blind person benefit from this sort of thing? I don’t think they do. The tolerance for distractions, advertising, and indirect navigation paths would seem much much lower for this group of people.
What all of us would really like is to create experiences which put disabled users on as equal footing as possible with fully-abled users… much like Dean Kamen’s self-elevating wheelchair pictured above (the “iBot”). Kamen didn’t like the fact that wheelchair-bound people couldn’t climb stairs or that they were always positioned a couple of feet below everyone else so he built technology to eliminate both of those problems. The end result wasn’t just assistive… it was liberating. So why should we settle for basic wheelchairs on the web when we may be able to create iBots instead?
Solutions for the real world
It may be difficult to get buy-off from your company on such a strategy since accessibility is currently not a monetizable endeavor in most cases, but that’s when the emerging mobile industry comes to the rescue. Create a bare-bones variation of your site with essential navigation and content, and bam… you’ve got a mobile site which likely works on the majority of wireless devices out there today — whether they support CSS or not.
But enough about server-side implementations… that’s not what this article is really about. It’s about exploring ways to turn accessibility into something real. Something that designers and developers can learn and then put into practice in a meaningful way.
The realities of cost/benefit analysis
I, for one, would love to help the disabled. However, there are limits to how far I and everyone else should be expected to go in the real world. Here are some examples:
- A small percentage of adults are either completely illiterate or read at a 2nd grade level or below due to a disability. Does that mean every sentence on a web site should be written at a 2nd grade level?
- I just found out about a 1000 pound man who, due to congenital obesity, can’t even make it through a standard doorway. Does that mean all doorways should be twice as wide?
- Because people in wheelchairs can’t walk up steps, should we be expected to install ramps on all buildings?
Whoa. Wait a second. That last one is legit. But why is it commonly accepted while the other two aren’t?
Because of its cost/benefit ratio.
In case #1, you have a cost that is too high. Expecting all content creators to translate every single word on their site into remedial reading material would take forever. It’s simply not a reasonable thing to demand.
In case #2, you have a benefit that is too low. How many 1000 pound people are there in the world? Probably 9,999 out of 10,000 people can fit through a standard doorway so you’re not helping enough people by enacting a law to widen doorways.
In case #3, you have a relatively low cost and a substantial number of people you’re helping, and that’s why it’s a law. A building costs hundreds of thousands (or millions) of dollars to erect and a ramp is a tiny fraction of that… thus the low incremental cost. And if you combine all paraplegics in the world with elderly wheelchair-bound people with people who simply have an easier time walking a ramp than stairs, you have a substantial group of people.
SO… how does this relate to web development? Let’s apply the cost/benefit ratio. Benefits first. There are clearly enough low-vision and no-vision people in the world to where the target group is large enough to matter to us. I don’t have any stats on this, but I imagine the number is higher than that of people who need wheelchair ramps. So that part is taken care of.
Now comes the hard part though: cost. It seems that from the number of either completely inaccessible sites out there or sites which think they are accessible but really aren’t, we have a problem of costs being too high. Following are some elements of that:
In the 1990s, most people just never really learned about accessibility. The web developer or designer who had a proper knowledge of the subject was tough to find and thus, cost a lot more by definition. Thanks to the web standards and accessibility movements, I think this element has begun to take care of itself. A larger percentage of web workers out there now at least pay attention to accessibility, even if they are not masters at it.
We’ve seen some progress in this area as browsers and screenreaders have improved, but as Eric Meyer points out, I’m not sure we’ve seen enough. Every browser but PC IE will now scale fonts specified in pixels, which eliminates the potential cost of designers losing font control (once people get off of IE), but in the screenreader world, have things really gotten much better? Are companies still spending their time concentrating on reading bad code when so much better code is now being released? Have makers of screenreader software fallen a bit behind the times now? I don’t know that they have… I’m just asking, because when I read more and more reports about how perfectly valid, perfectly semantic code still isn’t read optimally by screenreaders, I begin to wonder if we’re chasing a false ideal here. Here’s a thought: why aren’t governments funding the development of better assistive technologies on the web? If Freedom Scientific has to charge $1095 for a copy of JAWS, that either means they are very greedy or the market is too small for them to recoup their costs of development in a cheaper pricing model. I’ll assume the latter. If the latter is true, perhaps this deserves a subsidy. Seems like a noble cause to me. The other option is for OS makers to step up their efforts. I’m not sure how the new assistive technology in OS X is, but I’ve heard decent things. How about Microsoft? Could a $270 billion company afford to help out here? I think so. The bottom line is that if you want me, as a developer and designer, to code using methodologies that are “accessibility friendly”, you need to make sure those efforts actually result in good experiences for end users. Right now, I’m not confident they do.
This is the biggest problem spot as far as I’m concerned, and I’m not sure how it can be improved. Simply put, if you don’t test your site specifically by putting it in front of blind or vision-impaired people, you have very little idea exactly how accessible it is. That doesn’t mean grabbing yourself a copy of JAWS and pretending you’re an actual screenreader user and it doesn’t mean putting on a blindfold and seeing how well you can do. The fact of the matter is that people with disabilities have their own unique ways of dealing with assistive technology and any attempt by you to emulate that will yield false results. Currently, there are firms out there who will test your sites with disabled subjects (for a fee) and that’s probably the best option for now, but I can’t help but think this won’t be the norm for quite awhile.
So that’s my addition to the Accessibility Chronicles of the last two weeks. If I could leave you with a question, it would be this:
What can we do to lower the costs, monetarily and figuratively, of creating truly accessible web sites?