Interview with Matt May
Matt, you're probably best known for your work with the W3C's Web Accessibility Initiative - how long did you actually work there, and what achievements are you most happy with in that time?
I was with W3C/WAI for just over three years, from June 2002 through June 2005. During that time, I'd say that I'm proudest of the progress being made on the Authoring Tool Accessibility Guidelines 2.0, which should be released alongside WCAG 2.0, and being able to talk not just to the design community about accessibility, but also to software developers, XML geeks, policymakers, publishers and librarians. This isn't just about paying someone to run an evaluation tool over the site you launched six months ago. Everyone has a role to play, at every phase of development.
What is (or are) the biggest frustration(s) working for an organisation as widely distributed as W3C?
W3C operates on consensus. Consensus is about communication and trust. And both of those take lots of time. At my peak, I was on 16 hours of conference calls a week. I had some days that started with a call at 5am and ended with a call at 7pm. Somewhere in those other 24-44 hours a week, you have to handle meeting minutes, mailing lists, face-to-face plans, speaking engagements, inter-group coordination, and oh, by the way, be an international subject matter expert in your field. How my former colleagues can do it, I'll never know. I think they all secretly have assistants.
What made you decide to leave? And have you actually broken ties completely?
It was a decision I hated having to make, but ultimately I never doubted it was the right one. The skills necessary to coordinate and seek consensus are not the same as those necessary to lead. There are loads of people far more organized than I am, who would excel at coordinating a roomful of smart people to finish the work at hand. But that's not my skill set. I'm a technologist, and a kinesthetic learner. I'm most dangerous when I have an arsenal of tools at my disposal, and a hard problem that needs to be solved - which is what got me into accessibility in the first place. Knowing that, I felt I could more successfully advance and evangelize Web accessibility and modern design as a practicioner.
At this point, I am back to being an Invited Expert in the WCAG Working Group, which I've been in since 2000, and also in the Authoring Tools WG.
When do you think that WCAG 2.0 will move to final, agreed-upon recommendation status?
I think we'll know at the end of the year. If it's a Last Call Working Draft, I think you'll see a final Recommendation by mid-2006. We're meeting face-to-face here in Seattle in October, so hopefully we'll come out of that with a timeline we can hang our proverbial hat on.
What are the best bits that the accessibility evangelists can get excited about in WCAG 2.0?
Much of WCAG 1.0 is anchored to HTML as the dominant technology, and expects textual documents as the delivery method. It's too spread out, as well, with 14 guidelines and 68 checkpoints. WCAG 2.0 is more technology-agnostic and wide-ranging, but with a more compact set of guidelines. The Working Group wants to put everything they know out there so that authors can understand how a problem impacts users with different disabilities, what part of the process is failing the user, how the problem can be fixed sufficiently in a number of technologies, and why we took the approach that we did. It's a lot different from the "do this, don't do that" mode of accessibility we see in laws such as Section 508. But it will ultimately answer a lot of the whys individual developers may have been afraid to ask. That's good, because it lets them experiment, and improve on that knowledge. It also boils the guidelines down into four driving principles, and explains in detail how to meet those needs using various Web technologies. And that's important in itself, because it removes the excuse that accessibility is some kind of black magic that is incomprehensible to the outsider. Every guideline exists for a reason, and all those reasons are now spelled out.
And on the flip-side, what parts of WCAG2.0 don't, in your opinion, really hit the mark for whatever reason?
There are three priority levels in WCAG 2, just like in WCAG 1. And like WCAG 1, some people want there to be three conformance levels, too. I think that's the wrong approach. If you look at sites that claim to conform to WCAG 1 at Triple-A level, which means they covered all 68 checkpoints, you'll see without fail that they haven't. For a site of any complexity, Triple-A is simply not achievable. There are even cases in there where doing one checkpoint to satisfy the needs of one disability group will harm the accessibility of another.
Now, the value of marks like these is in the confidence among users that they mean something. If you put out a mark knowing that nobody is going to actually reach it, and people start to distrust the mark as a result, you're hurting the cause of accessibility overall.
I've lobbied for a long time to have only two levels of conformance: Single-A, where you meet all Priority 1 criteria, and Double-A, where you meet all Priority 1 and 2 criteria. If you want to say that your content meets this or that Priority 3 criterion, you may do so in metadata, so that users know what to expect. Those who want three conformance levels say this would make Priority 3 items optional. But I would much rather see people do what they know they can achieve than claim, through ignorance or just plain lying, that they've done things they really haven't. The conformance mark is about service, not status.
My other concern is with how the document will be received, though I don't think it can be solved (or is meant to be solved) by the WG itself. WCAG 2 sacrifices some of its usability for completeness. A lot of people are going to be disappointed if they expect WCAG 2 to be introductory or educational in nature. Some would say that's necessary: specifications are meant to be as unambiguous as possible, which means precision is more important than prose.
I've wanted to be as informative as possible in the document and its ancillary materials, but that's not a substitute for a higher-level explanation of the document. As a result, all the information will be there in excruciating detail, but you won't be able to hand the final spec to a novice developer and say, here, now get to work. Further, the WG isn't chartered to attempt this explication itself. There will need to be tutorials and methodologies and courses and books built around it before it gains traction in the real world. But, by the same token, I doubt very many people learned JavaScript or C# by reading the ECMA specifications. Specs don't mean much to the end user without context and interpretation.
You've just started a new company with a whole bunch of other great people. Tell us about that - how it came about, what your short term aims are
The company is called Blue Flavor, and it's made up of four people who got together because they wanted a challenge. Or, more to the point, a whole lot of them. We have a combined 42 years of professional Web development between us, and we've each grown organically into complementary roles: Keith Robinson is a creative powerhouse; Nick Finck is a top-notch information architect; Brian Fling is a mobile hotshot and a brilliant strategist. I like to make stuff that works. Together, we are driven by the user experience, and we insist on working with clients that feel the same way. Those who don't, we've turned away. Life's too short, you know?
Are you just going to be 'the accessibility guy' at Blue Flavor, or will you be given chances to flex other creative muscles?
My title is Director of Technology. I'll be determining how we implement the sites we design, prototyping them, doing a lot of the coding for them, and reviewing them for a number of factors, including accessibility. I made it a point to step back from being The Accessibility Guy so that I could see the big picture, and work on ways to integrate things like Ajax, Flash and voice over IP - where appropriate - into a better experience for everyone. I'm staking my reputation on proving over and over that accessible design can be just as beautiful and elegant as the inaccessible alternatives.
Back to accessibility again, what do you feel presents the biggest challenges to web accessibility in the near future?
Two things. First, the cost and capabilities of assistive technology. Recently, there's been lots of talk about the advanced capabilities of modern screen readers, for example. Many of the accessibility techniques we evangelize are broken, it turns out, in older screen readers like JAWS 4. Until we can establish that the Web is really a better place when you use these updated tools, content creators are going to receive conflicting signals as to the accessibility of their sites. It's analogous to that userbase of Netscape 4 users we spent so long adjusting to when we weren't wishing them away: is it our responsibility to adjust to their broken user agent, or is it their responsibility to stay up to date?
Socioeconomic factors come into play here: unlike upgrading your browser, for free, to take advantage of new features, it could cost $200 to $1000 to upgrade an old screen reader. We want users to avail themselves of the most capable tools for the job, but they may not be able to afford them. This is why I have high hopes and expectations for VoiceOver on OS X and Gnopernicus on Linux and Solaris. They're lowering the cost barriers for accessible computing to effectively zero, and both projects are tackling the hard interface issues in modern development, such as how to represent dynamic changes to the DOM in a logical way to the user of a braille display.
Number two: what is absolutely killing me these days is that as "accessibility features" are being used more and more by people who don't identify as having a disability, even more are so hidden from the average user as to be ghettoized. If you've used Find As You Type in the Mozilla Application Suite, you're using an accessibility feature. But there are all these others buried in the tools and operating systems we use every day: font and color selection and override, user style sheets (and now user scripts, with GreaseMonkey), keyboard shortcuts, magnification, monochrome and reverse displays, text-to-speech. I use several of these regularly, despite not having any perceptual disability. Why hide these features when they could help so many? We should have an Accessibility Hacks book just to show it all off.
You're heading up the WaSP Accessibility Task Force - can you tell us what's happening with that, plans for the next 6 months, for example?
I'm excited about what we have assembled here. We have a roster of very talented people who care about accessibility and technology, and that, in my opinion, is just what we need to be of service to today's designers.
We're going to start with a blog, to get the conversation started. I think we'll be asking as many questions as we're answering during that time. If the WCAG WG needs help fleshing out 2.0, we're there for them. The same goes for browser and authoring tool vendors. I'd like to take some real problems and show how they can be fixed without compromising on a given design. We can take a page from WaSP's own playbook here by taking a known-inaccessible interface out in the wild and showing how it can be done accessibly. It's not like we'd have to look very hard.
Playing devil's advocate, does the world need another accessibility group and what makes WaSP different from others with similar aims?
Accessibility has a long history of being at the leading edge of technology. We've seen that waiting for things to settle before making them accessible is not a successful strategy. With all of the Web 2.0 technologies flowing, and new architectures and interfaces to richer data springing up literally every day, we need a group of people who can blaze a trail. I want for us to provide the unvarnished truth about Web accessibility: what we can fix, what we can't, what we need. We don't want to "certify" people or sites, or present a competing standard, or sell executive reports. We just want to share what we know, learn what we don't, and push the state of the art of accessibility forward.
Let's end on some positives. Firstly, what sites or work have you seen recently that's made you say wow once you've realised that it's accessible
A couple years ago, I was looking for a photo site to post lots of my stuff: wedding pics, travel shots, you name it. I found Smugmug. Aside from its feature set, the thing that sold me was that it was built accessibly. Not only can you apply alt text to every image, but it will carry over to the thumbnails, and they'll add context in the form of the gallery title when you're at the top level. If you wanted, you could search for a picture of Matt May eating sushi on the Shinkansen, and buy a print of it, even if you can't see it yourself.
Why would a blind person order a picture? More people lose their vision during their lifetimes than are born without it. All of them have sighted friends and family. (I know two people who are totally blind and carry cameras with them to share their experiences with others: one uses an SLR, and one has a camera phone running a speech- enabled interface.) If they want to buy a photo as a gift for a friend, who are you to stop them? Instead of asking why they should care or who would want to do such a thing, and with very little effort and no fanfare, these developers just enabled it. If a photo site can enable the experience for blind users, why can't everyone else?
Secondly, do have any tales of how what you've worked on in WAI mode has had a direct impact on the way someone you know or have heard from that's made you think "That's why we do this"
I think the most direct feedback I got was from the paper I wrote on CAPTCHAs. CAPTCHA is a technology that is literally inaccessible by design, and the contortions and perturbations many CAPTCHAs have implemented have made it almost impossible for perfectly sighted people to use. I suggested that making Web resources inaccessible is not the way to stop spammers. It's a stopgap method at best, and we've already found numerous ways to exploit them, both programmatically and through cheap labor.
Since that time, many of the major users of CAPTCHAs have moved in other directions, including things like logic puzzles, heuristics and limited-use accounts which I outlined in the paper. Even the developers of CAPTCHA engines have shown themselves to be sympathetic to users with disabilities, and are working on more inclusive tests. I've also had tons of people explain that they now realize CAPTCHA is not the solution to all the world's ills, and they've gone back and thought about what it is that they're trying to guard against. I like it when people think. They tend to come up with solutions.