Accessibility in the design process

On 2007.02.07, I gave a presentation at Web Directions North on accessibility in the design process. (See podcast and other resources.)

I dedicated my presentation to my old friend Heidi Overhill in Toronto. She isn’t dead or anything, and she doesn’t even have a Web site. She’s one of the few female industrial designers in Ontario. Ask me about her research papers on chopping an onion and why soft things are never “industrial design” but hard things are. Heidi has actually taught design process and she’s the one who introduced me to it.

You can look at design process as having four or five stages. Today, I’m going with the five-stage option:

1. Observation
2. Ideation
3. Evaluation
4. Refinement
5. Presentation

Real-world case study

We will use as a test case the Toronto Transit Commission (TTC), the public-transit utility in Toronto that runs a 69-station subway system, plus hundreds of buses and streetcars. It’s a 1950s organization with an online fan base it ignored completely – until very recently. In my own catchphrase, “They run it but we love it.” (See blog post for links and background.)

There is, however, some hope in the form of the TTC’s new chief commissioner, Adam Giambrone, a 29-year-old who owns a Mac.

TTC Web site

Now let me tell you a few things about community development of the TTC Web site.

About a month and a half ago, four Toronto blogs took up a call to action about the Web site. None of the blog editors is a developer. They got a wide range of suggestions in blog comments, which tended to cluster around a few themes. I kept saying that we needed Web standards and accessibility before we started talking about new features. I also said we shouldn’t be doing this much work for free for a billion-dollar corporation.

Even though everything is online and the TTC could just read the comments, the blog editors gathered all the comments together in one place. And where did they put these comments on redesigning the TTC Web site?

In an Excel spreadsheet, using codewords. Never send a blogger to do a developer’s job.

Then, on 2007.02.04, we had an all-day event called the Toronto Transit Camp, something along the lines of a BarCamp just for the TTC.

• 70 people attended in a freezing-cold alternative hotel
• I gave a presentation about signage and wayfinding on the TTC
• I also worked on one of the panels in the so-called design slam. We designed a real-time information system for bus stops
• Another group redesigned the subway-car interior, and we so totally together they had a scale model and a slideshow of the scale model all ready to go when their time came up
• The other design-slam topic was the Web site, and about 70% of the people there worked on it. They’re in danger of becoming single-issue politicians

Observation

In the first stage of the design process, we observe the problem. So let’s observe the existing site:

Here is the current TTC Web site. In theory it’s at TTC.CA, but it redirects to a set of hidden pages inside the City of Toronto site. This site was thrown together by an animation student in 1998 and has really not been touched since.

• Uses tables for layout (seven of them)
• Plays a cutesy subway chime when you load the page, if and only if you have the right browser
• Has a crawling marquee
• Uses drop-down lists for navigation
• Lists transit routes by number only and doesn’t link one direction of a route to the opposite direction
• Has hidden features, like TTC commission reports and multilingual information
• Has no defined user
• Ignores the online fan base. In fact, it exists in a world that’s sort of like Microsoft Windows – the TTC is an entity that people use but nobody loves

Ideation

In the ideation phase, we come up with ideas to fix what we observed.

• Web standards, of course
• A trip planner
• Use RSS in some way
• Notifications of some kind, maybe a separate thing from RSS. It’s not clear what we need to be notified of. The next bus or streetcar that’s coming? A service disruption?
• Vehicle and route schedules in different formats
• An API

Evaluation

This is where accessibility really comes in. You’ve spotted all these problems and brainstormed all these solutions, but if you’re a typical designer or developer you’ll just forge right ahead and implement them. You won’t think for a second about accessibility. Even if you do, you almost certainly will not cancel a feature because you didn’t think about how to make it accessible or you can’t figure out how. Accessibility is never a dealbreaker in development.

But it should be, and I’m gonna show you it’s possible to include accessibility in everything. The surprising thing is how many times you have to cross over from Web accessibility to real-world accessibility.

• Web standards: Sure, but how far back do you want to go in terms of compatibility? A recent report (PDF) on accessibility of electronic banking in Finland had the author refusing to use the label element because it wasn’t supported in Opera 6. Are you going to go that far?
• A trip planner is a concept that always seems to rely on Google Maps. Well, what if they go out of business sometime between now and 2015? The current Web site wasn’t updated in eight years; what happens if the new site isn’t updated in that time, either, and you lose your map provider, in this case Google?
  • A trip planner with maps assumes you can see and use a mouse.
  • How’s it going to handle vague inputs, or Toronto landmarks that engineers down in California have never heard of? If I say I want to get from the Starbucks in the Beach to the Loblaws on Dupont, will it tell me how?
• RSS is a really hot idea for elite Web users, but what will you use it for? Very little changes day to day in a transit system; only a few routes need updates at any given time. Will you really be reading RSS while you’re waiting for the bus?
• Schedules, sure, but for which devices?
  • iPods?
  • Accessible PDAs like the BrailleNote? (The BrailleNote site uses a Flash demonstration file and links that work only with JavaScript.)
  • Podcasts of some kind?
  • hCards or vCards?
  How many of those things can a blind person use? Shouldn’t you be thinking of alternatives, like a simple phoneline?
  • We had a system in the ’80s and ’90s called the TimeLine, where every bus or streetcar stop had a phone number you could call. Won’t some people, like seniors, prefer that sort of thing to a Web site? We now have four area codes in Toronto; there’s room to set aside a few thousand phone numbers.
• Then there’s the topic of using text messaging to send updates out. Text messaging isn’t as widespread in Canada as in other countries; that may be a feature just for the online transit fans.
• I’m gonna cheat here and put Wheel-Trans into the evaluation category. Wheel-Trans is a paratransit service for people who cannot “use” the regular TTC and who meet a rather restrictive set of criteria. You call in to book a ride four days in advance, you pay a full fare, and they shuttle you around either in taxicabs or these really crappy buses. They turn down tens of thousands of rides a year, and sometimes they can get you where you’re going but not home again or vice-versa, and they might want you to wait an hour for the bus to show up. Telephone reservations are a complete nightmare and people have already asked for online reservations. Is that kind of system going to be more accessible than the rest of the site or is everything going to be equally accessible?
  • What if you try to book a ride on Wheel-Trans but you could actually get there on an accessible bus or subway? Will your system spot that and make a suggestion?
• Multilingualism. You know your site has to be multilingual, which becomes an accessibility issue because WCAG requires a change of language to be specified. That implies that the original language must be specified.
  • But how are you going to handle right-to-left languages, like the big three in Toronto, Urdu, Farsi, and Arabic? What about sign language? If you add sign language, what are you really adding?
• You want an API. Well, how does that help real users and not developers? What are you going to do with the API? Make a Dashboard widget for the minority of TTC riders who use Macs?

You’re gonna have to take all these questions, come up with answers, and produce some kind of prototype, which I’m not gonna show you here.

Refinement

This is where testing comes in.

• Which groups are you going to test with? For their signage projects, TTC already has done tests with “regular” riders with no special characteristics, visually-impaired people, ESL speakers, and people with low literacy, mostly young students. Is that a good place to start?
• It’s time-consuming but easy for the developer to test the prototype on everything from Mac OS 9 to Linux to IE7 to VoiceOver. You can test keyboard accessibility yourself. For a lot of other testing, you need human subjects.
  • But don’t you need a budget for that?
  • And your typical Web-site testing methods use a think-aloud protocol, where the test subject tells you what they’re doing and thinking while they’re doing it and thinking it. Doesn’t that conflict with the voice output from a screen reader?
    • New research from Google interns: They had to use a “screen-reader interpreter,” possibly the stupidest thing ever, as it adds yet another voice to the mix. Besides, you aren’t user-testing the screen reader
    • Why not just use headphones?
  • What about a test subject with cerebral palsy who has a hard time talking?

• You test the trip planner and blind people and mobility-impaired people can’t use it. So what do you do?
  • You can give route directions in prose – writing out in words how to get from A to B.
  • You can show a static picture of a map, or maybe just a schematic of the streets you have to travel on.
  • You can hack your own keyboard controls to move the map around the viewing window.
  • TTC has its own in-house cartographer – at least one that I know of. That gives you a backup in case Google goes tits-up.
• Web standards? Make it work without JavaScript first, then without CSS too. If you fix the map problem, in theory you the user can get by without JavaScript or CSS.
• Schedules? Well, let’s take a look.
  • Really good HTML tables.
  • Write them out in prose.
  • Make some files compatible with iPods and BrailleNotes.
  • You can make printable versions that are nice and big and can sit on your fridge door, then smaller ones you can fold up into your pocket. But if you do that, you also have to make the same things in large print – and not using Arial, either.
• Language: Everything from the TTC logo to navbars to Go buttons has to work right-to-left. And use the colours red and green with caution.
• For people with learning disabilities, this is actually a case where we can really do something, with a simple version that walks you through things step by step.
• Your testing will have found that you forgot to deal with customer feedback. Can we finally get that online? Can you make it easier to find the telephone and TTY numbers that will still be working?
• Your testing will also probably show that people will confuse the accessibility of the site with the accessibility of the transit system.
• If you find that things still aren’t accessible for some people, then break the rules and do things like shoot some videos and post them on the site.

Then you have to test everything all over again once you fix these problems.

Breaking the cycle of PDFs

Another important feature is to wean the TTC off the use of PDFs, and from using Microsoft Word to export “HTML.”

• If you have Acrobat 5 or later on Windows, Microsoft Word 2000 or later can tagged PDFs automatically. The tagging results aren’t great, but it’s a start.
  • There are two big advantages to adding any kind of tags to a PDF. One is you usually force the authoring application to explicitly specify all the spaces between words. Believe it or not, PDF by default does not save space characters between words; PDF is based on PostScript, and the whole idea is that the pen merely lifts up and moves a bit to the right or left to begin a new word. Tagged PDFs tend to have all space characters explicitly indicated, meaning the whole file does not appear to be one long word.
  • Also importantly, tagging produces a so-called logical reading order. PDFs are databases of objects, and it is not always clear what to read first. PDF tags are XML and they force a tree structure that can be interpreted as a reading order.
  So even if you use nonsemantic tags – marking everything as a paragraph – you will probably enjoy those two benefits, which are not small things.
• You may simply have to move people away from using Word as the final software before publication. The U.S. Senate came up with their own editing software that always produces correct XML output. Why can’t we try something like that here?
• You can set Word up to produce less horrific HTML, if you really work at it.
• Or you might just have to hire someone to do this kind of document conversion.

I think the bigger problem will be weaning the TTC off PowerPoint, which has a lot of accessibility problems that practically no one ever talks about. The TTC is a prisoner of PowerPoint. They’re Eddie Tufte’s worst nightmare.

Presentation

• This is not a time to be modest: You need to get the word out that your new site is online.
• A printed brochure is a good idea. Yes, a paper brochure to advertise a Web site. Most people in Toronto use the Web on their computers, which they don’t have when they’re riding to work. Give them something tangible so they can take it home and look up the site later.
  • Then you must create alternate versions in Braille, large print, and audiotape. This, however, defeats the purpose of producing a brochure that people who didn’t know about the new Web site could run across by accident. It may be sufficient to duplicate the brochure’s copy on a separate Web site, as Interesource did with RNID Teaser.
• Videos on YouTube with captioning.
• Now you publish podcasts, with transcription.
• Get Newmindspace to run a subway party in your honour.
• Co-opt the bloggers all over again.

Updated 2007.02.15, 2007.04.29 14:29

You were here: Homepage → Appearances → Web Directions North presentation, 2007.02.07