Live blogging a presentation at Webstock 09 by accessibility and web development expert Derek Featherstone:
Derek starts with an example of a blind user trying to call a website help line.
Blind User: “Hello? I need some help please”
Help desk staff: “What is your login password please?”
Blind User: “Just a moment”. (He starts JAWS screen reader that reads out his password login info that’s stored in notepad)
Help desk staff: “Is there someone in the room with you sir?”.
Blind User: “No, it’s my screenreader”.
Help desk staff: “Sorry sir, but my superviser says I have to hang up on you now”.
BEEEEEEEEEP
This actually happened. User experience encompasses EVERYTHING. Even the help desk phone manner. People need to think about this! User support etc. Accessibility is SO important
Derek then showed the example of an accessible door sign with white lettering on a black background, plus raised lettering underneath, plus braille on a raised angle. This equals excellent accessibility and it should be inspiration for what we do on the web. Can we do things on the web to help people with a disability? We can and we should.
Derek’s vision: “People with disabilities will have their preferences and needs always available so the web / environment could adapt to them for a change.” Imagine if we could walk into a bookstore and signs would adapt to your personal disabilities, flaws or needs?
Accessibility is not always inspiring or cool. Most people think of the W3C guidelines when they think of accessibility. But we should think of progressive enhancement when we design accessible websites:
1) Content
2) Presentation
3) Behaviour
That is the baseline for an accessible web site. Let’s go beyond this.
Small barriers can become big ones for people with disabilities surfing the web. Derek gave an example of an Advanced Search form which is completely unusable. Showed another example where the word “news” was used for popular items on the site. This created false expectations in the user because the items were nothing to do with breaking news items. The web designers should have used “highlights” instead.
Just because something is technically compliant DOES NOT mean it’s going to be easy to use. He showed an example of a hugely complex and challenging wheelchair ramp. It may have been technically compliant, but it would have scared the crap out of wheelchair-bound users. Accessibility doesn’t have to be hard.
Derek then played a sound-bite example of tags on Amazon URL being interpreted by a screen reader – it took foreeeeevvveeeerrr. Accessibility FAIL. He then played example of Chapters URL interpreted by a screen reader – All layout is done with CSS, using JavaScript correctly, implemented web standards properly. BUT something gets lost. The pop-up comment box interrupted the navigation. ALL tags get read out. Result = confusion and the Amazon site was actually easier to use for a visually impaired visitor. Goes to prove that even the sites who try the hardest can get accessibility wrong.
Derek was born with a club foot. He wore a cast for the first year of life. He had a major operation to correct it at age 3. But sports were still impossible as a kid. NOW, he does triathalons. Between his first in 2006 and his latest in 2008 he got better and fitter. Like Nat said yesterday, he had successful failures and learnt from them. He pushed his limits and got better.
We should do this on the web in terms of accessibility. Let’s get better at this stuff and keep improving accessibility. Derek showed an example of Google Maps – zoom not accessible via tabbing for visually impaired visitors, so they must use grids. Ugh. For a voice recognition user, this is awful. Luckily, Google Maps API allows us to create our own accessible version of Maps.
Someone challenged Derek to make an online crossword puzzle accessible. They said it couldn’t be done! He did it by using labels on clues, using JavaScript to jump from one clue to the next. He created a field set in correct numerical order and then applied JavaScript to make the crosspoint easier to use.
This is the type of thing you can do if you think a bit harder about accessibility. Previous version was image-based. You can also do Inline Editing and hover navigation. In BaseCamp, there’s no way to navigate without a mouse. So he created a GreaseMonkey script that allows disabled users to use BaseCamp right now. 37Signals should address the accessibility issues but who knows when?
The Social Accessibility Project is a FireFox plugin that uses crowdsourcing to improve usability experience for disabled surfers. It provides and takes instant feedback from user community in real time.
On August 1 2001, a Mozilla Bug Report was filed about a major accessibility issue in FireFox when trying to view Flash movies. Nothing has been done about it! So Derek and others took the same approach they used with Google Maps and hacked a solutionto use tabs to control play/pause, mute/unmute, again using a GreaseMonkey script to add keyboard controls. Awesome.
Some people created Outfox, a GreaseMonkey script using Firefox that brings voice to Firefox using JavaScript. It reads out maps etc. and effectively creates a talking map. Is this helpful? He’s not sure but let’s push the limits and see. These are all just experiments.
Ubiquity for FireFox enables Derek to invoke granular data such as specific addresses, links etc. The web is so much more complicated now – people say “I wish I had a command line”. So Derek thought, what could we do with this? What if we could create a play command line using Ubiquity so that a user doesn’t have to tab 30 times to get to the control they want? There are lots of applications here.
This stuff is cool to Derek. It may not be as cool as online gaming, but if it improves the User Experience, it is cool to him. What type of functionality can we all build into the web to improve it? Let’s see.