I will posting up new articles and interviews directly on to the home page until I put the redesigned and rebuilt Accessify (coming soon), so apologies if this is the world’s longest post - but I think you’ll agree it’s an interesting read from a very knowledgable guy, a certain Matt May. Enjoy.
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.