Toronto Interacts presentation

On 2006.10.25, I gave a presentation about accessibility to Toronto Interacts. This page will eventually host my notes for the event.

Liveblog & photos

Read my liveblog notes, which took four unpaid hours to put together, and look at my scant few photos.

Quick links

• The Ability Panel is the U.K. company that allegedly has disabled people testing Web sites and acting as secret shoppers.

• No, I don’t know all the WCA Guidelines by heart. (Do you?) And no, I specifically didn’t bring a computer or a cheat sheet. So no, I could not name Priority 3 guidelines that are impossible to meet. Nonetheless, it is not in dispute:

  • Kynn Bartlett pointed this out way back in 2000 – twice
  • “No, your Web site isn’t AAA-accessible”
  • Be accessible; don’t use guidelines

• Priorities 1 and 2 really are a single guideline level for informed standardistas.

• The British advice on commissioning Web sites, PAS 78 (review), can be downloaded for free for a limited time.
• A good tutorial on accessibility – still valid after all these years – is Dive into Accessibility.

Question to one member of the audience

Could the Member of Our Diverse Communities seated one or two rows behind me who asked intelligent questions please get in touch? I’m sure we’ll have lots to talk about.

Speaking notes

1. This presentation was billed as discussing “accessibility and Canadian values.” I won’t be talking about that.
   • This is really a discussion of the intersection of usability and accessibility.
2. What do interaction designers do?
   • Interaction designers work by themselves, but they step outside themselves by using personas and doing user testing.
   • Accessibility requires you to step much further outside yourself, even if you actually have a disability, though most of you won’t.
3. I’m here to tell you that your existing Web-development methods are probably outdated or incorrect or both.
4. Web accessibility starts with Web standards.
5. We used to put out any old HTML we wanted as long as it worked. We had to test it in multiple browsers and we pretty much had to guess what to change to make things work.
6. Most developers were and are in thrall to Microsoft and Internet Explorer. These are people who barely even understand there is such a thing as a “Web browser,” let alone more than one.
7. Firefox upset the apple cart. Suddenly people couldn’t pretend there was only one browser in the world.
8. Now developers can say “It works in Firefox.” But when they say that, they’re acting as though “It works in Firefox” means something.
   • It means the same thing as “It works in IE6” or “It worked for me.” It means you haven’t created a Web site; you’ve created a browser site.
9. Web standards are about writing correct HTML, CSS, and JavaScript that any adequately compliant device can use – and that not-very-compliant devices can use as well as they can, and that very-compliant devices can use exceptionally well.
10. Web standards are based on the principle that Web sites are built in three layers:
    1. Structure, meaning HTML
    2. Presentation, meaning CSS
    3. Behaviour, meaning JavaScript or other scripting
    1. If you use correct HTML, the browser knows what you really mean. If you have a heading you’re trying to mark up, instead of writing <b><b><font size="+3"><font color="red">, write <h2>. Use the correct semantics for your content.
    2. CSS lets you create a visual or printed appearance, or several of them.
    3. JavaScript, which is a bit more troublesome, allows your page to do things.
11. What you’re trying to avoid is tag soup. If you view source on a page and you really can’t follow the code even after you pretty up the linebreaks, you’ve got a problem.
12. Standards-compliant code is smaller, easier to maintain, and easier for a browser to display.
13. It is also simply correct. Other kinds of code aren’t.
14. Standards-compliant code is useful for browsers, but it’s essential for accessibility.

WCAG and priorities

• Priorities 1 and 2 are really a single grouping
• Priority 3 is unattainable in principle and in practice
• Priority 2 requires valid code

Don’t even bother with WCAG 2, which is a disaster.

Standard code and accessibility

So: How does standard code actually help accessibility?

• Screen readers and magnifiers with linear reading orders
• Reflowing text
• Show/hide content

Usability and accessibility

Now we get to the fun part. You’re gonna love this.

1. Accessibility is a precursor to usability.
2. You cannot claim your Web site is usable if you have not designed and tested it for accessibility.
3. Your Web site cannot be usable if it is not accessible.
4. An inaccessible site cannot be used by some people.

This isn’t my idea.

1. It was stated by Bill Killam of User-Centered Design Inc. in Ashburn, Virginia on the CHI-Web mailing list way back in 2002:

   Accessibility is a precursor to usability. If a product is inaccessible it is, by definition, unusable since you cannot get access to it.... Once access to a product is made, the question of its usability can be determined.

2. So if you’ve been proudly trumpeting your sites as having been usability-tested, you’ve been making a mistake if you haven’t included accessibility.
3. This is another way to upset the apple cart. If I seem to be saying that traditional usability methods have not actually produced usable sites, it’s because I am saying that.

Usability benefits of accessibility

• We have actual published evidence that accessibility leads to better usability, even for nondisabled people.
• This really means that Web standards lead to better accessibility.
• That’s because if you use Web standards, suddenly your site actually works in browsers.
• It forces you to think about what every component of your page means, should look like, and does. You leave very little to chance.

Published examples

Legal and General Insurance

(This case was not published by theinsurance company itself, but was reported on various standardista blogs – GAWDS, David Sloan, Bruce Lawson, others.)

• Saving of £200,000 a year on site maintenance
• Increase of 95% in site visitors getting an insurance quote
• Increase of 90% in online sales of life insurance
• 30% increase in site traffic
• 75% reduction in page-loading time
• No browser complaints at all

Disability Rights Commission, 2004

The Disability Rights Commission did a controlled study of six Web sites in 2004 (PDF), three with high accessibility ratings and three with low accessibility ratings. Test subjects were blind and nondisabled.

On the sites with high accessibility, both groups successfully completed nearly all their tasks. However, on sites with low accessibility, non-disabled users still completed all their tasks, whilst blind users completed only 67%.

[B]oth blind users and non-impaired users took far longer on low accessibility sites than on high accessibility sites, and that this effect was not much more pronounced for disabled users: 51% longer for blind users, and 46% for non-disabled users. It follows that all users, not just disabled people, would benefit greatly from the measures required to make sites accessible and usable by blind people.

Usability testing with people with disabilities

1. It isn’t always necessary to test with actual disabled people for small projects, just as it isn’t always necessary to test with nondisabled people. You can do easy and inexpensive in-house testing.
   • You can use Firefox with the Web Developer Toolbar, which can turn different features on and off and show you things like images without alt texts.
   • You can use Opera on Windows or Linux, or, if you really have to, on Macintosh, since it includes lots of built-in accessibility features like full keyboard access, zooming the whole document including images, and stylesheets you can select for high contrast and single-column layout.
   • I wouldn’t use VoiceOver on Macintosh. It’s still a Version 1.0 product and doesn’t really work all that well with Web sites.
2. Recruiting people with disabilities is usually a problem. You can often find blind people who use screen readers, because blind people have been on mailing lists forever. But even then, you may have to pay the subjects and you always, always have to go to their homes or offices. You have to use their equipment with their settings.
3. I’ve done usability testing with blind users twice – once for an E-commerce site, once for Ajax applications.
4. Even Jakob Nielsen finds it hard to recruit subjects and carry out testing. So does Fidelity Investments down in Boston.

Conclusions and exhortations

1. Accessibility should not be a new way of thinking for any of you. Very little of what I have just told you should come as a surprise.
2. Toronto is one of the few large cities that still acts like Web standards never happened
3. When it comes to modern Web-development practices, Toronto sucks. I run the Web-standards club and we can barely get anyone out for a drink three times a year.
4. People interested in usability should be at the vanguard of knowledge. You should be as good as developers in the Australian state capitals, several of which have large Web-standards clubs. You should be as good as the developers in the seaside town of Brighton, England. You should be as good as a couple of teenage boys I know.
5. What Toronto needs to do is completely turn around its development culture, to the extent it even has one. You’ve all been trying to improve usability; that’s why you belong to Toronto Interacts. You can’t do that without improving accessibility, which also means improving Web standards, which for most of you will mean upgrading your skills.
6. If there’s one lesson I want you to take away it is to improve your work so it meets today’s standards. Then you can become accessible. Then you can become usable.

Updated 2006.10.26

You were here: Homepage → Appearances → Toronto Interacts presentation, 2006.10.25