Christian is up now with a talk called Fencing in the Habitat — How to do the right thing and get it wrong. He reckons that some of the things he has to say will annoy some people here. He thinks that we are selling accessibility the wrong way. Christian is assuming that most people here want to make accessible products so he doesn’t have to convince anyone here of the benefits.
Genuinely usable and accessible sites and products are very rare says Christian. This is a problem because why should people care about making things accessible when most others (including the gig guns) don’t bother. People only grudgingly embrace the need for accessibility. For designers, this taps into a subconscious fear of losing the ability to see.
Then there’s the numbers game: when you are asked to supply numbers about how many disabled users are using your product. It misses the point; these are human beings. Anwyay, statistics lie.
Here’s a recurring problem. You have an old, broken, unloved product. Some third-party expert comes in and scatters magic accessibility pixie dust and everything is hunky-dory. It just doesn’t work that way. You might have to tell them what they don’t want to hear. You might have to tell them that starting from scratch is the best option. Also, there’s no point telling the people with the money about the technical things like links and forms.
Now Christian dives into a tangent about how people read on the Web. He’s over-generalising by saying that people don’t pay attention to tone and nuance on the Web.
Anyway, we’re the do-gooders, the hippies, the tree-huggers and we’ve got to sell accessibility to the suits. A lot of the time we wrongly characterize accessibility as making a habitat for disabled users. Instead of ghettoising disabled users, we should take them along with us. Accessibility is really little more than a good tough usability test.
Now there’s the issue of universality—providing access regardless of technical environment. That doesn’t mean every browser gets CSS and JavaScript. Graded browser support is the way to go.
Here’s a harsh truth: we will not be able to cater to everybody. Different disabilities have different needs and sometimes they clash.
A lot of the time we do little things supposedly for the sake of accessibility but they’re really there to salve our conscience. Font-resizing widgets (especially ones that have tiny low-contrast buttons) are a good case in point. Either use a readable font size from the start or explain to people how to resize text in their browser. Skip links are another example. These are genuinely useful and not just for screen readers; they’re handy for mobile too. But people go too far and put tons of skip links all over the place.
It’s not about gadgets. These things are mostly about making us feel good and they cost time that could be better spent. They are a quick fix that stagnate over time.
Here’s an example of a bad interface from the real world. Braille buttons in an elevator but the braile buttons don’t do anything; they are next to the real buttons. But if you think about it, the reasoning is that they don’t want people to accidently press the button when they’re just trying to read the button.
Another great example: a wheelchair-accessible toilet …where the toilet roll is five feet away.
A speaker, like the ones with your hi-fi, is a piece of assistive technology. It was created to help someone who was hard of hearing. Now it makes people hard of hearing.
The main problem with accessibility is that people don’t see the need. The driving force for things like semantic markup and progressive enhancement is (drumroll please) geeks that care. Hug your developers. They are the people who do the extra work that makes the Web better for all.
The best way to sell accessibility is to use the old search engine optimisation trick. Page titles, for example, are really important for both accessibility and search engine optimisation and yet people get it wrong so often. Titles show up everywhere: in the browser bar, in bookmarks, in seach results.
Stop saying “alt tag”. Yeah! It’s an attribute. More importantly, it’s alternative text.
The bogus accessibility software sellers are harmful. Bobby is dead, hurrah!
Sell accessibility by using technology hypes: mobile devices are a great convincer.
Simplifying the interface for users spells success. Just look at the games world. Microsoft and Sony battle it out with features, then the Wii comes along and blows them out of the water. That’s because it’s easy to use. This is how we should approach accessibility.
Is Web 2.0 bad for accessibility? Well, define Web 2.0. For Christian it’s a methodology, a read/write mindset. That’s a good thing. Web 2.0 can be great for accessibility because users can take up the challenge of annotating and transcribing content. Slideshare, for example, will take your slides and convert it to Flash but it will also convert it to HTML. They will provide an API so that you can create accessible versions of your content.
What about video? Viddler allows users to tag the actual videos, not just comment on them. The quality of the discourse is far better than a site like YouTube.
JavaScript and Flash used in the right manner can actually increase accessibility. He plugs FlashAid. Yay!
Christian demos his YouTube captioner, a nice piece of work.
Here’s Twitter again. Christian has used Google’s translation API to take Twitter’s RSS and detect the language of the messages. Then he inserts the appropriate lang value. icanhaz.com/twitterwithlang (This is great: it ties in with what I was saying in my keynote about looking beyond the website and treating RSS and APIs as accessibility features. It also contrasts nicely with Steve’s talk. Instead of just pointing out the problems with the Twitter site, Christian built a working solution that lives at a different URL.)
Flickr gets a hard time for its inaccessible interactions. But the edit-in-place functionality allows far more people to edit titles and descriptions. So that’s an accessibility feature really.
To summarise: don’t fence in disabled users in a habitat. Instead let everybody benefit from a more usable product and a better experience.
Now it’s question time and someone is taking issue with Christian’s claim that text widgets are not a good solution. Christian responds: if you build a widget for every possible disability, you still don’t please everyone. Also, the widgets are a sign of a deeper problem. A lot of the time the deeper problem lies with the site but it can also be a problem with the browser or the operating system. Why should web developers be responsible for patching those flaws?
A comment from Kath: we shouldn’t be arguing about who’s responsible. It’s like when someone farts and everyone looks at the dog or at the other people in the room, wondering who is to blame when, really, we should be complaining about the smell.