Web Axe / Episode 33

This is the transcript of my interview for Web Axe - Practical Web Design Accessibility Tips, conducted by Dennis Lembrée from CheckEngine USA and Ross Johnson from 3.7 Designs, 29 October 2006.

The interview is available on Web Axe and archive.org

Interview with Patrick H. Lauke

[Intro music: Show me how to live, Audioslave, 2002]

Voiceover: Welcome to Web Axe, practical web accessibility tips.

Dennis: Welcome to Web Axe, Episode 33: Interview with Patrick Lauke. This is your host, Dennis.

Ross: And I'm your co-host, Ross.

Dennis: How are you doing today, Ross?

Ross: Not too bad. How about you?

Dennis: Pretty good, pretty good. We've got a couple of news and another announcement to make. Computer Weekly magazine published an article about accessibility.

Ross: Yeah I came across this and thought that it was pretty cool that a magazine was publishing information about accessibility and getting it to the mainstream.

Dennis: It was a good article, and it's not very technical. It's geared more toward the general audience and business owners, which I thought was great to get the word out.

Ross: It seems like a lot of business owners don't know much about accessibility, if anything at all.

Dennis: Right. The other news item is the National Center for Accessible Media, NCAM, out of Boston, Massachusetts, USA, has released a set of accessibility guidelines, which I thought were very good and worth a mention. It's called Accessible Digital Media: Design Guidelines for Electronic Publications, Multimedia and the Web.

Ross: I haven't had a chance to look over them yet, but I definitely plan to, because anything that guides us on what we should look at to make sure things are accessible and everybody can access the information is beneficial.

Dennis: I agree. In the perfect world, I think one set of perfect guidelines that everyone in the world can go to would be wonderful, but this is not a perfect world. So, we have another set of guidelines, but I think are, like I said, are very good and worth taking a look at.

Ross: Definitely work in the right direction as far as guidelines and constructing something that we can put together to use as a whole.

Dennis: Right. We have one other announcement. We held a Refresh Detroit meeting last Wednesday.

Ross: That was great. The group is definitely growing, and we got some developers who work on the State of Michigan web sites to show off, which was great.

Dennis: That was really cool. And we'll be meeting again in Brighton, Michigan, next month, November 29th, at Stout Pub, so if anyone in the area is interested, you're welcome to join us. For more information, go to refresh-detroit.org and check it out.

Ross: We'll be having a short presentation on information architecture, so that should be worth coming by and listening to.

Dennis: Definitely. OK, well, that's enough for the announcements, and let's get on to our main feature. We have Patrick on the line.

Patrick: Hello.

Dennis: Patrick is a well-known resource in the web community. He has been the Webmaster at the University of Salford since January of 2001 … is that correct?

Patrick: Yeah, it is. Yeah.

Dennis: OK. And he's heavily involved in WaSP, Web Standards Project Accessibility Task Force, and is co-author of a new book, Web Accessibility. How are you doing this Sunday, Patrick?

Patrick: Oh, I'm doing great. Doing this podcast is a good excuse to get out of the usual cleaning chores, so I've got a good excuse to lock myself in my room for a bit.

Dennis: There you go.

[laughter]

Dennis: Let's see — well, I guess our first question is how did you originally get into web design?

Patrick: Let's see — back in, it must have been about 1996, I started doing a computer science course at the Swiss Federal Institute of Technology in Zurich, and I started getting involved in all the programming side of things, etc. But it soon became apparent that I wasn't really cut out that much to do the hard-core computer science stuff — analyzing algorithms and everything else — but what I did get out of my stint there at the Swiss Federal Institute was they had loads of open access PCs with access to the internet. At that point in time, I hadn't really experienced anything in terms of internet, so that was my first exposure to the web as it was back then, back in 96.

So, it was quite interesting. I started looking up the fledgling first corporate sites, things like MTV.com and everything else. I started getting very interested in the potential at the time of getting all this access to information readily available, and I also started dabbling with actually learning how to create web pages, what's involved behind the scenes, looking at HTML, starting to learn HTML pretty much from scratch by just following examples.

Back then, there weren't any major resources yet as far as I was aware on doing web design and everything else. So there was a lot of learning by doing, back in the days when we had … Netscape 4.7 was the default browser there on the computers, so I'd look at the source code, try to do my own little things with HTML, stumbled across the — back then, already — stumbled across the actual W3C site with the specification and trying to learn HTML from basic principles, really. Things like Java started appearing round about that time as well.

Dennis: Is this about the time you were … I believe you have a Bachelor's degree in graphic arts. Is this about the time you were doing that?

Patrick: That was before then. I've had a very checkered past, I have to say. Maybe to kind of backtrack a bit: originally I'm German, but I grew up in Italy and then went to school in Switzerland, before ending up over here in the UK.

Dennis: Oh, wow.

Patrick: That was the time when I was still trying to find my way in the world, and I thought at the time that computer science was the thing to do. Later on, I found out that I was wrong, but as I said, back in '96, the good thing is I started doing web stuff. So, I started learning HTML, tried to do my own little web page. We had some web space there available for the … all the computer science people had their little account, where they could put 20K or something of stuff on there, so you'd put a few images up and tried to create a cool web page or something.

Dennis: Now, you have a Master's degree in technology as well as your BA. Can you describe how your education in both design and technology have helped you in Web design?

Patrick: Yeah. You've already mentioned that I've got a BA in graphic design. That really came about because, as I said, I wasn't quite happy with the computer science stuff. I was interested in programming and everything, but not to the hard-core extent that they were doing. I switched over to graphic design and I came over to the UK. So, I did very much print-based graphic design; and then to round it off, I did this Master's, as you mentioned, in Creative Technology, which was, I suppose, the kind of way to bring the two together, really. A lot of the people in my course, in the Master's course, were doing a lot of installation art, and using sensors and triggering video and things like that. But, for my part, I started going more into using the web and putting my graphic skills to good use. I think that brought my two interests together. Even now, I've still got an interest in programming, but not to the analyzing algorithms and things like that extent. I do like programming from the point of view of … it's a way of achieving something, but at the same time, I've also got a certain kind of visual flair, a kind of a design flair, and this Master's course helped me bring it together.

More generally I think what you traditionally see still at this point in web design, more often than not you've got a very cut and dry split between graphic designers, often traditionally from a print design background, that are kind of dabbling with the web. They don't really understand it, they just see it as a delivery medium for their stuff.

Dennis: Right.

Patrick: They do things in Photoshop or whatever, chop it up, save as gifs, put it up on a ready-made web page that generates the mark-up and they think they're doing web design. Also on the other end of the spectrum you often get people that are really good kind of programmers and back-end developers that are doing fantastic stuff in terms of aggregating content and mashing things up and everything else, but you couldn't even tell them "Choose two colors that go well together," because they just don't have that flair. So they do something that works really well from the technology point of view, but really looks very horrid.

So it's often kind of a very pigeon-holed "you're either one or the other". Although in recent years I'm beginning to see that there is a new breed of web designers who've got a little bit of both skills. And I really think that, at this stage anyway, when you're doing a lot of projects on your own, unless you're in a big team where you've got very clearly defined roles — you know you've got your back-end developer, and then you've got your front end developer and somebody doing the middle ware — but if you're a one-man band kind of thing doing web, you really need to have at least a little bit of understanding of both disciplines. It's not enough to say "I just do design, I don't care about the markup" or "I'm just the back-end developer, I don't care about the output at the end of the day" in terms of what the HTML is and how it looks. You need to multi-skill on that level.

And there are a lot of the new breed of designers that are coming along here, people like Andy Clarke from Stuff and Nonsense. He is kind of the epitome of that kind of new breed, I would say. He's a cracking designer, he's also got a great understand of the markup and the CSS and what's involved. Because a lot of the tools that are out there at the moment for web development they're still very much … they're user-friendly to a certain extent, but if you really want to take advantage of web standards, you really need to get your hands dirty and start doing your code by hand.

At this stage, you need the two interests, you need to have both a very analytical kind of programming mind to do the HTML and working out the best way to semantically structure something, and doing the CSS, because the CSS stuff is still very much propeller head kind of stuff, if you're going beyond the basics — working around browser bugs and everything else as well. But at the same time you should really have some understand of what looks good, all the related fields like usability as well …

So I think that my kind of strange background in terms of starting off with the very dry, very boring — from my point of view — programming side and then moving over to graphic design and then bringing the two together kind of has helped me. I wouldn't say I'm an excellent designer, I wouldn't say I'm a perfect coder, but I think I bring enough of both disciplines that, at the very least, I can converse with both camps. Working in a team for instance, I've had it in on a few occasions working on a team of two or three people, I usually end up being the facilitator that can talk to both the techies and the designers and bring them together to a common ground.

Dennis: So what sparked your interested in web accessibility?

Patrick: Right … after my Master's course, I started obviously looking for a job — I had to, I had a few bills to pay at that point — and I noticed that there was a job advert at the university where I just finished my Master's course for Web Editor. So that was back in, as you say, January 2001, pretty much I started there. As part of the job, in the job spec itself, it mentioned that the candidate should have at least an understanding of web accessibility. As you do when you're preparing for an interview you think, "I've never heard of that, I'll quickly read up on it, so I can at least blag my way through the interview."

Dennis: [laughing]

Patrick: As you do, you know. So I started there, I had a quick look. Up until that point I think I vaguely heard about web accessibility, but it wasn't the cool thing to do especially doing more of my graphic design kind of stuff. I didn't really care about it, or I didn't really know enough about it to care, shall we say. For the interview, I started looking into it and got a little bit of an understanding. It obviously was enough to get me the job, so that was good. But as I then started with the job itself, I started looking deeper into it and taking it seriously, because it was a requirement of the job, and I started getting involved in discussions and conversations with my peers working at other universities. There are kind of various groups in the UK higher education and further education market who are associations of web editors and web people across the various universities. There's a very … a load of camaraderie going on, a load of sharing good practice and everything else, which was quite refreshing at the time; there's not much of a competitive angle there. So we started sharing experiences and sharing our understanding of web accessibility as part of our shared duty in terms of running university websites. Because universities traditionally have had a much stronger corporate responsibility in the sense of realizing that they need to actually provide this sort of stuff.

Dennis: Oh, definitely.

Patrick: So not purely from a web point of view, but also just recently a few years ago, a lot of the universities had to do a lot of changes to their physical environment to make sure that access ramps are put in place, etc. So from an organizational point of view it was quite a good one to work in because they do realize their responsibility. So what I found at the time when I started getting involved in all these discussions with my peers is that, everybody knew that web accessibility is something we need to do, and we need to start thinking about. But there was a lot of … beyond the basic kind of everybody pointing at the WCAG document, but beyond that, beyond the very basic of, "yeah we need ALT text if we put images in", there was still a lot of uncertainty — and there probably still is — a lot of uncertainty about what to do with the more complex scenarios and how to go about … what does it mean when you say we need an alternative? What is an alternative? Is there a cut and dry rule or is it up to the individual, can it change depending on context, etc. So I found that there was a lot of uncertainty and a lot of people just stumbling around trying to actually understand, make out exactly what they're supposed to do beyond the basics of, well this is the WCAG document, follow that. Well it doesn't make sense. Well, don't care, just follow the rule, make it up yourself. So a lot of the discussions really started crystallizing into "well I'm doing this, do you think this is good practice?"

So I found that it was quite interesting from my point of view because it's kind of the frontier land scenario, there's a lot of opportunities to contribute in a meaningful way because there weren't any ready-made kind of solutions. There was nobody that could say "you need to do exactly this" because it all depends on a variety of factors. There was still a lot of scope for working with it, coming up with a solution that maybe other people will find interesting and basically just carry on with the discourse and at the end of the day doing it for a good cause and trying to find good solutions to problems that a lot of people have. And if you've managed to solve them, that you make the web … you know that you can make the web a better place for certain types of people.

So that's what kind of sparked my interest really in it for some reason. I kind of started sliding into this …

Dennis: [agrees]

Patrick: … and getting quite passionate and quite vocal about it.

Dennis: Now, you're a team member now of Accessify.com.

Patrick: Yep.

Dennis: Can you tell us how you got into that and you know, what it's all about, what your plans are for the future?

Patrick: Yeah, sure.

I had a think because, when you sent me your initial rough questions, I knew that you were going to ask me about Accessify and I had to cast my mind back and try to remember "how did I get into Accessify.com"?

Dennis: [laughs]

Patrick: I've got no idea. I think it's probably around the time probably 2002, 2003. I was heavily kind of active on the SitePoint forums. At the time I kind of ended up becoming a moderator, and later on even an advisor, which is kind of one level up on the SitePoint forums

Dennis: Yeah.

Patrick: … and flying the flag really for accessibility and everything else. At the time there wasn't really a sub-forum or anything specifically for accessibility, so I was kind of following the general web design kind of sections and also a little bit of the PHP kind of forum itself, because I started doing a lot of PHP at the time, but mainly in the web design bit, there were a lot of questions every now and again about accessibility, so I started getting heavily into that in terms of spending everyday at least two or three hours spread out through out the day, being on the SitePoint forums, answering questions, trying to work out, you know, are there other people on the forum that share my interests, and everything else. And, I guess, I'm not sure but I guess that Ian Lloyd, who is the chap that actually started Accessify.com, I think he was, yeah he had already written I'm thinking a few articles for SitePoint at that point and time. I do remember that there was an article about accessible forms which I think was one of the first ones that I came across on such a kind of major general interest kind of site.

Dennis: [agrees]

Patrick: And, I'm guessing that I must have got in touch with him back then through the forum when he started Accessify and I became part of the initial kind of contributor team that flagged up articles and wrote little bits of information, pointed at other pieces of info that might have been around at the time. And, probably the relationship there developed. I mean Ian and I are now great friends and whenever we kind of bump into each other at conferences or so the beer flows quite freely at that point.

Dennis: [laughs]

Patrick: But Ian went off for a year, he kind of took a sabbatical for a year from his job at Nationwide — one of the big banks here in the UK — where he did a lot of work already on accessibility. So he took a year out to travel the world and he went you know to Australia, Thailand, all over the place really, with his … I think she was his fiance at that point, she wasn't his wife yet …

Dennis: [agrees]

Patrick: … his girl, say, and at that point he basically asked me if I could kind of mind the shop for him while he was out, effectively. So I effectively took charge of the Accessify.com, I kind of baby-sat it while he was traveling the world and being in places where often you would have like, you know, a 28k modem at best. So he did say "You know I can't run this site while I'm on the road, would you mind, you know, just looking after it, making sure it ticks over." And I got heavily into you know I went through a phase of posting you know three or four stories a day, really, on Accessify and making sure that things were running smoothly. When he came back we then … he then switched service providers, and we went from ASP to PHP and I helped out with that aspect of recoding in some of the tools that you had and everything else. And, I've been kind of active behind the scenes on Accessify ever since. In recent, probably in the last year or so, I've kind of had to scale my involvement, my direct involvement down a little bit, so I go in phases, sometimes I post like three or four news stories and then I might go for months of not actually posting anything. But you know, I'm still there, I'm still behind the scenes, and … yeah, I think that pretty much is the story of Accessify.

Dennis: Yeah, the tools and wizards on Accessify are really cool, so anybody listening if you know about web standards and accessibility then you'll really appreciate what some of those tools and wizards can do. Because they make it easier for just some common tasks.

Ross: Yeah, they're pretty helpful.

Patrick: Exactly. Yeah, they take the initial fear away from "oh, who do I do an accessible form or an accessible table". I find them excellent, yeah.

Dennis: Yeah, I use them myself quite a bit.

So you also freelance? And you have your site at splintered.com? Do you want to talk a little bit about your freelance projects and things you've done with that?

Patrick: Yes, splintered.co.uk. I haven't managed to get the dot com yet, although I'm …

Dennis: OK.

Patrick: … I'm waiting until that one frees up. Yeah, I do the occasional bit of freelance. I mean I'm in the very lucky situation that my day job, although it doesn't pay that fantastically, it does keep me afloat quite nicely. I manage to pay the bills on time and pay the mortgage and everything else. So I'm probably in the very enviable position that when I do freelance, I can pick and choose which projects I really want to do. And, often its projects that I've got personal interest in, something that somebody says that, "you know I'm thinking of doing this", I can say "oh, yeah, cool", I'll help out. I often do … my middle name should be pro bono because I do a lot of stuff for friends, and associates, and families, and everything else.

But, yes, I'm quite lucky in that respect. I don't have to choose jobs because I know that I have to pay the bills, and I can turn jobs down … you know the nightmare jobs that you hear about on mailing lists, when they say "how can I convince my client that an all Flash site is really disingenuous kind of idea?"

Dennis: Yeah, right.

Patrick: So, I'm in the lucky position that I can, right from start, I can say, "look, no offense but I don't really have the time to do that at the moment." I can point them to other people and say "I've got a little network of friends that do freelance as well." I can point them in that direction, but I don't have to slog through projects that I just hate, so that's quite good.

Dennis: You can point em to us if you want Pat. [laughs]

Patrick: Okie dokie. We'll get a little … after this we'll get a little commission base as well.

Dennis: [laughs] Yeah. Sounds good.

Patrick: We'll haggle on the percent price, yeah.

So yeah, I do the occasional bit of freelance but it's not my main drive. I mean my main interest is, because the monetary side of things is sorted, I've got more time to just do the experiments and things on the website, that's really where my passion lies.

So, I often see that the kind of freelance work that I do is secondary. The primary role of my site is really … if I've got some kind of crazy idea, some … I've been doing a few Firefox extensions, etc. I like to post them there and say "hey, you know this might spark some conversation, this might be a good idea", and just get some … just get something out there. It's really kind of a playground for crazy ideas that I've got in terms of CSS and crazy uses of …

Dennis: Yeah, I've seen you're experiments, you've got … Frugal Google? [laughs]

Patrick: Yeah, just recoded the Google website — basically the Firefox Google kind of home page thing — and actually using web standards, because what's currently there, the kind of default Google Firefox page, is just horrid table based markup.

So yeah, little experiments, little things in terms of … often web standards and I used to do a little bit of Flash years ago, so I've got a few experiments in Flash back in the archives. And yeah, just trying to have fun really; that's my main purpose with these things is having fun and if something good comes out of it, share it with the rest of the world. It might not be fantastic but it might start greater minds to follow those lines of inquiry and come up with something good.

Ross: Yep, and also …

Dennis:And going back to …

Ross: Oh. Go ahead.

Dennis: Oh. I was saying, going back to Accessify.com, are they a part of Accessites.org?

Patrick: No that's two separate kind of initiatives. Accessites, that's a guy called Mike Cherim — I'm not quite sure about the pronounciation …

Dennis: Were you involved with that?

Patrick: I was at one point, it was … I think that was just before Christmas last year. Mike was kind of … he's already been active on the Accessify forums which … I'll do a little plug here as well for. It's, even though it's part of the Accessify site itself, it's actually a separate project run by a chap called Nigel Peck, who has got a web design consultancy in — uh, where is it? — Sheffield. He set up the forum kind of a few years after Accessify started, and that's another great resource for you know just sharing your thoughts on accessibility and chatting to like-minded individuals on accessibility.

That's another one where I started off as a simple kind of mere mortal poster and then I managed to wangle my way into becoming a moderator and often Mike — sorry not Mike, Nigel — often Nigel was away again on business and again I ended up minding the shop for him. So a good resource if you want to have a chat about accessibility with kind of slightly hardline but quite likable individuals like myself, that's a good place to be. I think this guy Mike if I remember, Mike Cherim, he was part of this group of people that were kind of chatting online. I knew him from various kind of mailing lists.

Just before Christmas last year he decided to set up this site, this Accessites website, which essentially offers kind of free, completely free site accessibility testing. And they give out little awards and everything else for best site, best accessible site etc. It's kind of a grassroots accessibility testing and showcase site. And I was involved in the very early stages: Mike was gathering a lot of … the great and the good of accessibility to help out as testers, basically, for these awards that they were giving out. Now unfortunately in the end it turned out that I didn't have enough time to actually really devote myself to Accessites, because I ended up with, at that point a lot of freelance work strangely enough, and a lot of stuff during my day job really kept me from getting involved. So I kind of stepped back from that one, because I thought, you know, if I can't devote myself to it properly then there's no point in having my name under the team and everything else. Didn't want to let the team down.

But I still provide them with … they've got kind of an internal mailing list that they run, so I still provide them with the actual mailing list platform, so they can use that to communicate and I think I still link to them.

And they're doing a great job, there's a lot of really really good, technically good and also as people, good people there that help out. People that are good friends of mine like Andy Saxton etc. Some of them slightly lesser known people, but nonetheless very, very knowledgeable and very good in terms of wanting to do the right thing. And also my old nemesis Tommy Olsson works there, as a tester. I say nemesis — we had a few disagreements, we have a banter going on, he's very hardline in ways that I'm not hardline, so we've had a few disagreements in the past.

But you know it's a good bunch of people and they're doing quite a good thing. Certainly helping with the cause, the general cause of accessibility by just devoting a lot of their free time to these kinds of things. Because it does take a lot of time to give a good kind of accessibility test to a site, and really run in through its paces and say these are the things that need tweaking, etc. So hats off to the guys for really doing it out of the goodness of their heart.

Dennis: Yeah it's a neat site. They have a lot of good resources listed, they have an interesting checklist on how they create and evaluate sites and they're doing a great job. Well they must be doing a great job because my company CheckEngineUSA.com actually received an award from them a couple of months ago. So yeah that was pretty neat.

Patrick: Yeah and their testing parameters, I think they strike a good balance between … they're not just ticking the WCAG boxes, but — the thing that I'm keen on — they're very pragmatic in many ways and they're more real world than basically just saying "we run your site through Bobby and did a few manual checks." So I think they strike a really good balance with those kind of real world checklists, so yeah … great job.

Dennis: Ross?

Ross: As far as the Web Standards Project which you're a part of — and that can be found at webstandards.org — it states that the Accessibility Task Force works with accessibility organizations, technology vendors and others to help promote web accessibility. Can you give us a couple of examples of what you do specifically?

Patrick: Yeah the WaSP ATF, as we like to call it, that's been formed I think after @media2005, that was. In the kind of drink session after @media we were talking to people like … Molly Holzschlag was there, obviously she's the webstandards.org main lead at the moment. We started talking about accessibility in general and really what … the group itself came out of, was born out of, the frustration that a lot of us have in terms of: here we are trying to do a lot of good stuff with web standards, but at the same time browsers, screen readers, assistive technology in general are still very much in the dark when it comes to web standards.

A lot of screen readers, although it's got better in the last year or so, a lot of screen readers still don't really care about web standards. They don't really understand web standards; and you can't blame them to a certain extent because they might take the attitude that 90% of the web is still tag soup and everything else, so why should we honor web standards when nobody else does? There was this frustration of: here we are, we're talking about … we're having really heated debates about what is the most semantic way of marking this up and marking that up when at the end of the day a lot of the assistive technology doesn't even care about it or doesn't even understand it. They'd much rather use heuristics and treat all your content as kind of tag soup anyway then try to work it out for themselves rather than look at the markup.

Because with the markup there's a lot of stuff in HTML where you can define very clear unequivocal relationships between pieces of information on a page, for instance. But a lot of AT, and a lot of browsers, and screen readers etc. aren't taking advantage of it, although as I said it's slowly coming around and becoming better. On the other hand you've also got content management systems, blog software, authoring tools in general that are still kind of … a lot of them are still very much ignoring web standards. Again, this is slowly changing, but there's still a lot out there particularly when we start talking about the big iron kind of CMSs like Overture and things like that — Overture? Am I thinking right? Yeah, one of them. [Editor's note: no, I actually meant Vignette … ah well, French name anyway]

They still, they don't produce valid markup and they're not accessible, they don't care about accessibility, their output is not accessible and their actual interface behind the scenes is not accessible. So there's a lot of snake oil salesmen out there that try to sell you the perfect magic bullet kind of solution. And they say "oh well you as a site owner, you don't have to worry about accessibility, just buy our product … the text transcoder, and whatever, we create a text only version from your site, that's accessible, you don't have to worry about it." So all of these things really brought out the frustration in us to do something … to try to do something about it. As I say, we did set up the ATF. Now although we've been … well, we formed about a year and a bit ago, we're still at the very early stages to kind of forge relationships with these various browser developers, screen reader manufacturers, etc. So we're still doing a lot of ground work but we're aiming to work along the same lines as the Web Standards Microsoft Task Force, who've done a great job of just meeting and just kind of chatting with — not to belittle their work, they obviously did a lot more, but you know in general, in basic terms — they had good conversations all the time with Chris Wilson and co. from the Microsoft IE team. And really kind of get into a discourse with the actual browser developers and make them understand: this is why we care about web standards; this is where your products still need to kind of fill the gap really; they're still not compliant in certain aspects here, they're not taking advantage of this. So we're aiming to work along those lines and what we've done recently is we've drafted a full-on manifesto on the — which you can find on the webstandards.org site — all about what we're aiming to do, what the current situation is, explaining all of this about you know: we do web standards, some of these tools still don't take advantage of it when they really should.

We've been giving out the manifesto and an open letter, a call to action to kind of browser developers etc. We're here to help, if you want to engage in a discourse with us. We've already started kind of giving these out in the printed form and email form to a variety of kind of developers, people like Freedom Scientific who make JAWS, various kind of smaller screen reader developers. I mean I'm hoping to soon tap all this. There's a very well known one here in the UK called Dolphin who've create a product called HAL, which is one of the screen readers here. We're trying to basically, as I say, just initially, forge some links with these people. We've got also task force members who are more directly involved already. We've got James Craig, who's a member of the task force, who is now working at Apple and he's forging contacts with the Safari team and the VoiceOver teams within Apple.

Also, myself and a good friend of mine, and a task forcer as well, Bruce Lawson, we've been in direct contact with people at Opera. We've got a really good contact there in Opera who … they're really keen on accessibility. And Yahoo! as well, I've got a few people … we know a few people at Yahoo! UK. Also got contacts with people in Yahoo! over in the States. And really kind of trying to, at this stage, get a discourse going, get some engagement, get some discussions going.

We're getting ready to release … we've kind of jotted together a little wishlist within the task force, a little wishlist of things that … where we think browsers aren't really following the spirit of the User Agent Accessibility Guidelines. You hear a lot about the WCAG, the Web Content Accessibility Guidelines, but there's another set of guidelines that's aimed specifically at user agent developers, in terms of: your products need to make it easy for people to just navigate content by keyboard etc.

There's a lot of things that … browser developers mainly seem to follow the letter of UAAG, of the User Agent Accessibility Guidelines, but not the spirit. There are a lot of things where, for instance, keyboard access still isn't 100%. Where for instance, if you have title information on a link or something like that, you only get that information usually if you hover over it with a mouse; if you go via the keyboard, there's no way that you can access the title information. And that's just the most … that seems to us, anyway, the most basic kind of requirement.

If it says … you might be a sighted user, so it's not an issue purely of "the screen reader should deal with it", but say you just haven't got the use of your hands and you're just using the keyboard to navigate. You can see the screen perfectly well, why isn't a tool tip coming up on a link that has got a title when you navigate with the keyboard? Why is it purely with a mouse? That's such an obvious kind of example where the browser developers just don't follow the general kind of User Agent Accessibility Guidelines.

So we've kind of … that was one of the many points that we've put together. We're still finalizing it, it's taking a little while because we are a large group and it's often difficult to get full-on consensus. But Bruce Lawson and I, mainly, are kind of trying to push that through and we've already sent this list to our contacts at Opera and Yahoo! and they were quite interested. Opera obviously from a browser implementation, native implementation point of view. But we were chatting with people at Yahoo! in terms of: if the browsers don't do it quickly enough maybe we can bridge the gap with things like the Yahoo! Toolbar for instance. It could offer additional kind of hooks for people who need it. And the response on that one has been really, really positive, I have to say. A lot of people that are very willing to listen at these places.

So as I said, to sum this whole rant up a bit, we're still at the early stages even though we've been formed for a year and a bit, but we're slowly making progress, I would think.

Dennis: That's great. That sounds like you're filling a big void as far as, you know, connecting all these technologies and developers and the community together.

Patrick: Exactly, we're trying to, anyway.

Dennis: So, as a member of the community, what can we do to help with the WaSP ATF task force? I saw on the site you guys recommend reporting like browser bugs to help promote standards? I guess the same would go with screen readers and things like that, if users could report any kind of bugs or issues with web standards?

Patrick: Yeah exactly. I think a lot of users really need to start being more vocal about things. Without going too much into this because it's my kind of hobby horse argument, there's a lot of pressure always on web content developers and, you know, web designers to make up for the problems that user agents have.

You know, the classic one of "Internet Explorer doesn't resize pixel-based fonts so you need to use ems or something." That is the right thing to do in that particular scenario. But I've seen more and more there's things like "users don't know that they can resize their text, so you as a web content developer need to put a widget on the page that says, you know, text plus / text minus."

Or things like "users don't know that they've got a print preview option, or that they can print, so you must provide, or you should really provide, a link to a printer friendly page or print preview and everything else." Which, in my mind, that kind of crosses the line a bit between: are we web content developers or should we … is it our responsibility to patch up shoddy implementation in browsers? And also the fact that users are, to a certain extent, they're not educated enough to know that they can resize text. Is it our responsibility to kind of patch these things up?

So, sorry I kind of went off on a tangent here, but yes users are — that will happen very often. No, if users find that they can't do something on a web page, it's quite often the fault of the browser for not giving them that particular option. So I would welcome it if users who are in the know could then start complaining; more of a grass roots kind of movement from the users point of view saying … demanding better products from browser developers, rather than instantly jumping on the web content developers and designers, saying "you need to provide us with a widget on your page to do text resizing."

I mean just on that text resizing issue: I mentioned before my experiments … one of my experiments is a little extension for Firefox that simply puts the text resize options that are built into Firefox — you know, text plus / text minus and normal text size — creates a little toolbar that just puts it into the actual chrome of the browser. Now, you know, a lot of people would say that's a trivial kind of extension, but the amount of people that I've had emailing me from around the world on that extension … it's my most popular extension. I get emails from people saying "thank you very much for finally enabling me to, you know, use the web in a better way because I hate sites that have the text too small." And you feel like saying "you know, you're quite thick, because that font resizer is built into your browser." But the browser isn't making it obvious. It's not exposing that functionality in a clear and simple way, where really it should be. It should be … the onus is on the browser developers to make sure that their customers can make the most out of their browser.

I mean, Internet Explorer has got the option to … I think in the IE7 it's now kind of more visible, but in … certainly IE6, the button to actually do text resizing … there is an actual button for the standard toolbar. The thing is, it's not enabled by default so a user has to go through to the customize settings and actually make that button visible. Now my reasoning would be "well, wouldn't it make more sense to have it visible in the first place, and then if you're a power user and you know how to customize your browsing experience, then you can say I don't need that and I should remove it."

And I've had a long rant back in … end of August we were … Bruce Lawson again, and I — he's sort of my partner in crime when it comes to these things — we were invited down at a little gathering of web developers called Geek in the Park. I've recently put up the transcript and the audio file from that, and that was kind of an evening's rant, basically. I ranted for about an hour and a half in a very much Bill Hicks style and chain-smoking away, but ranting about these kinds of things, about "there is an onus on the browser developers to make sure that their tools are better suited to people."

Just installing IE7 the other day on my machine I noticed that, after you've installed it, the first … the first run dialog that comes up gives you options of setting your privacy, and do you want to have pop-up blocking and everything else? Again, I think that's a missed opportunity there. They could have had right there … they could have said "have you got … are you visually impaired? Do you need text to be bigger or smaller? Do you want the capability to do that quickly?" Just as a simple question in their kind of wizard, that basically then just enables that particular button.

Dennis: Yeah that's a really good point, definitely.

Patrick: So there's a lot of opportunities there, but then the browser developers aren't grasping them. To bring it back to the original point: so yeah, users that are having problems with sites for whatever reason, or think, you know, "I really wish I could — I don't know — I wish there was an easy option to linearize this page." It's not always the web content developers that need to do it. It's not always a case of "I'll complain to this website because they don't let me linearize it." It's about … be vocal about it to Microsoft and to Opera and Mozilla Foundation. And say "look we really want a linearize option in your kind of dialogs, in the accessibility dialogs." There's a lot of stuff in the accessibility dialogs in the browsers that say "ignore the … say … color choices of web pages." Well why not take it further and say "ignore any kind of positioning choices or any floating choices so that the page can be linearized." And there's a lot of toolbars out there, like the Firefox Web Developer Toolbar, which are aimed at developers. So they have a lot of propeller head kind of functions that help in terms of building web pages. Why isn't there like an equivalent … well, there are a few, but we need really high level toolbars also aimed at the users themselves.

So if the browsers at this stage still don't offer that functionality, I'd love to see toolbars that give that kind of option very much specifically for users. So none of the web developer kind of functions in there, but purely the ones that users could benefit, like linearize this page … that's one of the options in the Firefox Web Dev Toolbar. That would be great for just your regular users. Obviously they would still need to install the plug-in itself, the extension itself, so you've got that first hurdle but, you know, that would be a great thing. And I think I'll stop there, because I'm kind of ranting in circles.

Dennis: That's an excellent point. Yeah let's move on to the web accessibility book. There's maybe 10 or 12 co-authors. Which portions of the book did you write?

Patrick: Right, I only joined the team very late on, really. I was kind of called in at the 11th hour for a variety of reasons, because they just needed a chapter on the retrofitting of a website. A website that starts off as fairly inaccessible, and how it was then changed to be more accessible. So my contribution to the book itself really was a single chapter, and it's kind of very much defined purely in the chapter. I didn't have much involvement with the rest of the book.

At one state when I was first asked I didn't even know about the content in general of the rest of the book. So I kind of had to blindly kind of start writing, with direction from my editor Chris Mills at Apress/Friends of ED.

He had to kind of give me a bit of guidance and say "look you don't need to talk about this because we've already covered that there. You don't need to do the long preamble about 'why is accessibility good' for instance. On that point they know it, just talk about the redesign." So mine is chapter … I think it's chapter 15.

Dennis: Yeah I'm looking at it right now actually … Retrofitting Case Study: Redesign of a University Website.

Patrick: That's the one, that's the kiddie. Yeah so do you want to hear a bit about that one or …

Dennis: No, I think we'll move on actually, because we talked a bit about that book … actually we had an interview with Chris Heilmann who wrote the chapter on accessibility / JavaScript. Yeah … but we did have a couple of other questions just about accessibility in general.

Ross: One question I had: I noticed in the book there's a section on accessible Flash. And … do you see Flash as being truly something that can be accessible or is it just, you know, webmasters have to kind of patch around it?

Patrick: Yeah, I have to admit that personally, just from my point of view, I don't use much Flash. I used to do a few small experiments, again on splintered. I've got a few kind of silly Flash based kind of things and experimentations. But in my day-to-day job I don't really do much Flash, and I still have to admit that I can't really wrap my head around the kind of Flash tool, the Flash interface, of the actual authoring tool.

Adobe used to have an excellent tool called Livemotion which unfortunately just came in a little bit too late in the whole Flash era. Flash was so far ahead, at the time, Macromedia Flash platform was already so far ahead that Adobe pulled it after the second version because it just couldn't compete. But that environment I found that a lot more intuitive from my point of view, because it was very similar to — I don't know if you've ever used it … I used to do a lot of video stuff, so the interface was very much along the lines of Adobe AfterEffects. And I found that far more intuitive than the whole keyframes kind of weird scenario that the Flash authoring tool does.

But that's a complete aside … accessibility and Flash, really, I don't have a first hand experience on that. But obviously whenever you mention Flash and accessibility in the same sentence there will be a lot of hardliners that will say — you know, people like Tommy Olsson … little shout out to Tommy — who will say, you know, and rightly so … they will say "there is no such thing as accessible Flash, because if I don't have the plug-in it's not accessible. Full stop." And for a lot of these people that's the end of the discussion. You know, you've finished there and there's just no value in taking it further.

But what I would suggest is that a lot of people kind of start intermixing accessibility with … you know, they see it as synonymous purely with access for blind people on a text based kind of browser or something like that. But accessibility is a lot more, there's a lot more shades of gray, there's a lot more levels of accessibility. For instance, Flash can be an absolutely essential tool for conveying very complex kind of, I don't know, complex worfflows for instance, or complex scenarios to people that might have learning difficulties, cognitive disabilities, people who are more visual rather than textual. For instance, I don't know, the functioning of a normal kind of engine in a car. To a lot of people they'll read the text-based explanation of you know the various phases when the fuel is injected into the cylinder etc. and the various things that happen there. Some people might understand that. Some people are very much kind of text based people and they can really grasp it. Other people might be completely confused, and they would benefit far more from a kind of animated diagram, or an audio version of that that runs alongside like a narrated kind of animation. So, for those people Flash is probably the best thing you can do really.

So yes it can have problems in terms of: if I'm a blind, a completely blind user and I don't have the plug-in and I'm on a platform that doesn't allow me to actually install that etc. then purely providing a Flash kind of movie isn't accessible. But we shouldn't lose sight of the fact that there are shades of disability. There's as many kind of disabilities as there are people really. Everybody's got their own particular situation.

So if you go beyond the initial hurdle of "I can't use Flash", if it's a case of "yes I can use Flash" that there are a lot of advantages. Obviously, if you're providing a lot of content in your Flash you should really start thinking about a) making the Flash itself as accessible as you can, and Adobe and Macromedia kind of have done a great job there really to at least set the foundations and allow for accessibility to be kind of built into movies. It might still take very skilled experts to actually do something as accessible as … there was the example a few months ago of the J.K. Rowling website, the Harry Potter kind of stuff, where that was … that was flagged up as the flagship example of accessible Flash. And it wasn't too nasty. You could use keyboard, apparently … I didn't have a chance to test it, but apparently it worked reasonably well with screen readers etc.

So the actual Flash platform itself is now working more and more towards allowing for knowledgeable authors to actually build accessibility in. Obviously you still need to have experts at hand, and I think there were quite some high level people involved with that site who've been working in the field of accessible Flash for quite a long time. For the kind of normal guy, little developer who's got hundreds of other things to do and they just dabble with Flash, obviously it would be at this stage still very difficult to create something that's completely accessible in Flash.

But at least the option is there. And obviously once you've done your Flash as accessible as possible, you should still cater for people who can't use Flash, or who've got Flash installed but would prefer the content in a slightly different way. They might have a screen reader that is not the latest version and still doesn't take advantage of all of the accessibility hooks in Flash, so they would benefit from still getting a more standard HTML version of it. And if you're following modern practices and if you're really doing more of the … build it the way it should be built where all your data isn't actually held in the movie, but the movie, the Flash movie itself is only a container and your actual content is held as XML or database content or whatever.

Then it becomes reasonably easy to do, anyway. It's a case of: the content is there in a kind of format-neutral way somewhere in a database, say, and then you give the user the choice. Do you want to see kind of all singing all dancing bells and whistles within the Flash kind of framework, or do you want an adapted version that still pulls in exactly from the same content source as an HTML version? Yes, there will be certain things that one medium can do that the other one can't. But it's about finding the right balance. It's about providing the same content or at least equivalent content for a variety of audiences. And yes then you get all the benefits of indexability for search engines etc.

So, as I said, I wouldn't say … I'm certainly not in the camp of "all Flash is evil", because I have been vaguely involved also with discussions across the university sector, for virtual learning environments and providing learning modules and learning objects for people with disabilities, including, say, deaf people, people with cognitive disabilities. And for those kind of audiences, first to say "oh, we're not going to use Flash because 100% blind users might have difficulty" would be doing them a disadvantage, because they could benefit very much from Flash. So it's not cut and dry; it's not black or white; it's not either or; it's not just providing HTML, otherwise nobody can use it. It's … you should really start with a good foundation that is accessible and as much as you can do in HTML and CSS and everything else. But if you then have the means and the knowledge to create an accessible Flash version as well, then by all means go ahead and do it. So, it's about knowing your audience and knowing what works for specific target audiences, and still trying to do the best for all of them.

The myth of universal access, that you do one thing that works for everybody in every single situation is a bit of a myth. But using various kind of methods, doing both Flash and HTML, you can probably get it as close as you can to that particular one.

Dennis: OK, Ross you have one more question?

Ross: Yes … with technology getting better and better, do you see the speed of technology especially in web design … is it going to be a kind of a tool that [can] help accessibility, such as better screen readers and browsers getting better? Or will it get more difficult such as the widespread use of AJAX?

Patrick: Yeah, well as you mentioned: screen readers, user agents in general, seem to be getting better. And I'd love to take some credit and say that's all because of the WaSP ATF stuff … but, you know, it's people that are complaining and telling browsers "you need to do this." It's also obviously the browser developers and accessibility developers themselves, knowing that there are certain gaps in their products and you need to patch them. So yeah, the products themselves are getting better, which is great to see. It's great to see that the latest versions of a certain screen reader might handle things like AJAX a little bit better.

There's still a lot of onus on the developers to then still care about accessibility. I think there's … for instance with the whole rise of AJAX, it's great but it's technology that's kind of moving so far ahead without any consideration for accessibility in many angles. And the kind of very bright people that are working on this cutting edge stuff, often … out of ignorance or out of sometimes sheer arrogance, seem to just go ahead without any regard for "what about blind users" or "what about users that are just purely keyboard based." There's a lot of attitude of "well, you're stifling my creativity, you're stifling technology by basically saying: it's great that you're using AJAX, but we need to make sure there's also fall backs for people who might have difficulty with this."

I think there's still a lot of education to be done in terms of … yes, technologies like AJAX are great, if used for the right reasons. There's a lot of spurious uses of AJAX where you really think "that's just gimmicky kind of effects." I mean, that begs the question what is AJAX really, because that's an overused term anyway. As soon as you do anything that has got like a little yellow fade or something, people start talking about "uh, that's AJAX." But the real AJAX in terms of: there is content that's actually changing on your page and your entire page might change completely without a complete page refresh, but it's only sections of it are being refreshed. That can in many situations at this point still cause a lot of problems. Screen readers are getting better at recognizing when … it's basically that the triggering itself, it's the screen reader often is not notified, or rather the user of the screen reader isn't notified that "hey something has changed on the page, you might want to refresh this page. Do you want me to re-read it from the start, or do you want me to jump to the thing that has now changed?" There are still a lot of problems in that area and it's about … it's kind of a shared responsibility: the tools need to be better, need to get better in terms of looking out for those kind of things. So, obviously a screen reader should flag something up, should look out for "has the page itself changed somehow since the last time I read it out?" But developers also need to be aware of that, so when they're building AJAXy type applications they should know that, at this stage in this … in the real world now, pragmatic kind of world, there might be people that can't use this. It would be good if you could provide a fallback at the very least, and offer maybe a switch in the preferences or whatever for your web app that says "do you want me to do the all singing, all dancing AJAX, yellow fade, things pop up on the screen etc. or do you want me to go for a more traditional kind of server response, browser server backwards and forwards kind of model."

If you've built your application in a sensible way, in terms of the AJAX functionality, then presumably it wouldn't be such a major problem to invoke things doing the call that only updates that one particular bit, or having — if it's in the non AJAX version — do a full submit that then triggers exactly the same function. So we're not talking about the whole app would need to be completely recoded. It's just about having a bit of consideration and saying "there might need to be a fall back."

So I think in terms of the future of accessibility and the future of technology there's … I think we're currently in a state where a lot of developers have kind of jumped so far ahead in terms of "hey, we can do AJAX stuff now" and that's fine. In many cases it's about "I want to use this technology, let me find a use for it," rather than using the technology for a particular reason.

It's about making sure that there are other bright kind of people that are working — and that's happening at the moment — bright people that are kind of trying to work out "Yes, we've jumped ahead now with AJAX. How can we kind of close the gap again in terms of accessibility?"

There are people like James Edwards aka Brothercake who's also part of the task force. You know, he is the wizard of JavaScript. He's working very heavily on that, and there's a lot of testing going on, a lot of reports are coming out, in terms of "Can this AJAX app be made accessible? Is it working with these particular screen readers?"

So we're currently in a phase of catching up with developers who might have gone off and done all these clever things, but have no understanding of accessibility. And, as I said, often you get the very arrogant initial response of "Well, our apps are … you know, blind people don't use the web anyway, or they wouldn't use these apps anyway."

From what I remember, was it … oh, what were they called? Basecamp … 27Sig … 37Signals — sorry, left 10 out — 37Signals apparently didn't see accessibility as such an important kind of aspect. Now I'm reporting from memory, I might be completely wrong, so if I'm offending anybody it's really my memory. But, I seem to remember that there was a whole discussion about … accessibility wasn't really on their top priority list, because their main concern was … they want to do this whole AJAXy stuff and this product that works for 99% of their user base, and screw the 1% that might not be able to use it. So, it's about … there's a bit of arrogance there, but I think there's a lot of just not knowing, there's a lot of ignorance in terms of the fear of the unknown. [Editor's note: what I was alluding to, but couldn't reference at the time, was Joe Clark's take on Jason Fried's attitude and his subsequent usability test of Basecamp with screen reader users]

I saw that recently with — just stop me if I'm rambling too much — but I saw itrecently, a few months ago, when there was the announcement that Target was getting sued by the National Federation of the Blind. And, surprisingly, now up until that point I thought we're on the right track in terms of accessibility. I think a lot of developers are understanding the issues, but you know as soon as that broke out in the news, on various kinds of websites like C|Net and stuff, you saw all the kind of … the comments coming out, all these people coming out from under the woodwork that I thought weren't even there. People that were really kind of aggressive … aggressive towards accessibility in terms of, you know, "look at these blind people, they're stifling our creativity." And a lot of really kind of … comments that I would have thought didn't even exist anymore. Things like … very misinformed things where they're saying "Blind people should stay at home and if they need to shop they can ask their friends or relatives to help. Why should Target have to be accessible. Can't they just shop somewhere else" etc.

Yeah, and even the bizarre things like, "Well what's going to happen next? Why aren't they suing car manufacturers for not making cars accessible to blind people?" And that shows, to me, the fundamental misunderstanding of accessibility, really, which is: it's not about blind people — or generally people with disabilities — it's not about "they want to be able to do exactly the same thing that everybody else does." You know, I'm sure that no … well, there probably are a few, but I'm sure that generally blind people aren't going around saying "I really wish I could drive a bus or a car." What they are after, though, is that they want to be independent and they want to lead a valuable life without assistance, and that's the main thing. It's all good and well saying "Well, can they not just get a sighted friend over, or a sighted relative?" The main point is: technology allows them to lead a life independently. And, you know, do their business online, do shopping online etc. independently, and that's all they want. They want a certain kind of … it goes back to a certain dignity of life. Anything could be like "Well, can they not ask a friend to … why should we put a ramp up? Can they not have a friend give them a piggyback ride up the steps, or something like that."

It's not about wanting to do exactly the same. It's about dignity of life and when it's easily achievable, like in most cases with web accessibility, just doing a few little considerate things — like providing alternative content, making sure that things work even if you just use a keyboard — can make the world of difference to people who might have difficulty getting around by themselves, in terms of … if I was completely blind or heavily vision impaired, what would I rather do? Would I want to navigate my way around, get to the bus stop, get a bus and navigate a physical shop and having to ask an assistant for help, or wouldn't it be great if I could just go online and do my business there. Again, it's about the quality of life, independence and being able to lead a valuable life independently without having to rely on other people.

Dennis: Definitely. OK well …

Patrick: Does that make sense?

Dennis: Yeah that makes lots of sense.

Patrick: Off on a rant there.

Dennis: That's all right, that's very valid points and why we're all doing this and why the accessibility movement is valid and should be recognized by everyone.

Well we're going to stop the interview there Patrick, but we want to thank you for taking the time out to speak with us.

Patrick: Thank you for having me.

Dennis: Sure, it was a pleasure to have you and … let's see … look for his … at least one chapter in the book Web Accessibility and go online to find out more about Patrick and his work. accessify.com and splintered.co.uk.

Patrick: That's the one, yeah.

Dennis: Great.

Patrick: Excellent.

Dennis: Thank you, Patrick. Take care.

Patrick: Cheers, bye bye.

[Outro music]

Dennis: The Web Axe blog and podcast is located at webaxe.blogspot.com. Email webaxe at webaxe@gmail.com. To leave a voice message call 206 203-0585. Web Axe is sponsored by CheckEngine USA - Website tune-ups and overhauls.

Initial transcript provided by CastingWords, with subsequent editing by Patrick H. Lauke. Released, like most other works on this site, under Creative Commons Attribution-NonCommercial-ShareAlike 2.0.