Skip to main content Skip to main menu

What Does Accessibility mean

By Jonathan Snook
2007 Nov 27

If you were to ask people that question, I suspect most would say that accessibility
is about making sure something – in our context, a web site or web
application – that works for those who are physically disabled. Maybe they’re
blind or maybe they’re a quadriplegic and unable to use a keyboard or mouse
in the traditional sense.

Accessibility Is A Spectrum

That definition of accessibility is pretty narrow and I’m sure plenty of people
would argue otherwise (including me). But my point is that many people see
accessibility as affecting a small group of people – a group of people
that can be ignored. In actuality, accessibility is a spectrum. On one end,
there
are those with the most extreme mental or physical disabilities that I couldn’t
even begin to assume I know how to accomodate for. And on the other end…
well, what is the other end?

Is accessibility a concern for perfectly abled people? What about those who
need to wear glasses, or are colour-blind, or just like to use the keyboard
instead of a mouse on occasion? Where do they fall on the spectrum and what
issues should you, as a developer or designer, choose to contend with?

Accessibility As Usability

I recently spoke at the Future of Web Design and my presentation, Ajax and
Design, didn’t talk about code. It was about the usability concerns that you
have to consider when implementing Ajax.

I argued that the web is founded on a limited set of interactions: links, buttons
and forms.

And because these interactions are limiting rich experiences, we constantly
try to extend how those controls behave (like providing a tri-state checkbox)
or creating new interactions all together (like drag and drop). Anytime we add
interactions or change how the default interactions behave, we create barriers.

Once we’ve created a barrier to usability, either through understanding or
technology, we have to work to eliminate those barriers while still maintaining
the new interaction.

At the end of my presentation, I was asked why I didn’t mention accessibility
after having talked for almost a half hour on Ajax – a technology that
has
been derided by many for hindering accessibility.

My response to that was that all things that apply to making a site usable
apply to making a site accessible.

Conclusion, accessibility is just usability but marketed to a particular segment
of the population.

Accessibility Is Hard?

How do you make a site usable/ accessible? The best advice I can give is this:
get people to use it. I often get people to see my design at various stages,
especially people who’ve never seen it before. I might ask my wife to look at
a design I’ve done and will ask for first impressions. “If you were looking
to find widgets, what would you do?” Or maybe, “You’ve arrived at
this page, what do you think it’s about and what would you do first?” I’ll
send designs
to friends and colleagues and see if I’ve missed any glaring issues.

So, I design and build a site based on my breadth of experience as a fairly
abled individual and I show my work to people who also happen to be fairly abled
individuals. Essentially, I’m dealing with a limited set of testers. The next
obvious step is to get it in front of a wider variety of people to test,
including those who may have a different set of limitations when using the web.

But guess what… I don’t really know anybody that really falls under that
“accessibility” umbrella. I don’t have anybody I can ask to test something
out
(without paying hundreds, if not thousands, of dollars for actual usability
or accessibility testing). I suspect this is the case for most people.

I can see why people might not want to take the extra step to support a seemingly
small group of people. Jeremy Keith’s
selection of quotes
in response to the Target lawsuit seems to not only affirm that but demonstrate
some downright ignorance. It’d be easy to think that accessibility is hard
and simply not worth the effort.

Remove Limitations

However, what’s interesting is that covering the majority of the usability/accessibility
spectrum can actually be pretty easy: just use semantic HTML. Of
course, there are plenty of considerations when adding layers of technology
on top of that like CSS, JavaScript or Flash, each of which has its own usability
and accessibility concerns. Those layers of interactivity create increasingly
complex barriers to overcome.

The Target site is, for the most part, an example of a typical web site. There’s
no reason it couldn’t be made accessible to a larger market of people,
including blind people. Just use recommended coding practices (recommended by
the W3C’s
WAI
and the standardistas among us). Even simple things like proper alt-text can
go a long way to providing a superior experience

Read through the
legal complaint
and you’ll see that the highlighted complaints are relatively easy to solve:
“alt-text on graphics, inaccessible image maps, [and] the lack of adequate
prompting and labeling.” This isn’t complex stuff. It’s not drag and drop,
it’s not tri-state checkboxes. These are things that any professional web developer
worth his salt should be able to do.

Now I’m not trying to be elitist or snobby and scold the bad web monkies. We,
as a community, should continue to spread the message of professionalism and
quality.

If we can make the effort to care about cross-browser compatibility then we
can make the effort to care about cross-person compatibility.

There are sites, however, that are much more complex than a Target site. Sites
like Gmail or Google Docs. Applications using Flash and heavy uses of Ajax
are more complicated. You’re adding in multiple layers of interactivity that
override or add to those default interactions.

A company like Google might be able to afford the usability/accessibility testing
but I know I can’t. And I’m not going to stop developing these types of
applications. In these cases, I don’t ignore accessibility. I continue to build
with the core that I know works: semantic HTML. Then each layer is added
on in hopes that it doesn’t create too much havoc for people. Am I limiting
my audience? Potentially. I know that might happen.

That doesn’t mean it has to be perfect. I can tell you right now that this
site isn’t perfect in every browser. But when I learn that something is broken,
I try and fix it. And that’s the way I approach accessibility.

I remember way back when I first learned about alt-text. To help out those
who relied on alt-text, we added “Link to” to the beginning of any
images that
were linked. If it was a help button, it’d say, “Link to Help”. What
was enlightening was seeing somebody with a screen reader trying to use this.

Two main issues were discovered: First was that the software was announcing
that it’s a link. That meant the person was hearing, “Link, Link to…”.
Yeah,
you can imagine how annoying that’d be. The second issue was that the person
was able to bring up a list of all links on the page (a useful feature for
even sighted users, in my opinion). Problem there was that all the links started
with “Link to” so the person couldn’t even navigate the list alphabetically.

This goes back to my earlier point. Build something and get it in front of
people. And learn from your mistakes. Web development techniques change. Usability
problems change. Tools change (be they the browsers or content management systems
or whatever else we use to build sites). As a result, we have to re-evaluate
things. And best of all, we don’t have to re-invent the wheel. There are plenty
of people who’ve done the usability testing and the accessibility testing
and we can incorporate those findings into our own work.

As a web professional, I try to build sites that reach the largest audience
possible. Every design decision has a consequence and those consequences have
to be weighed against the goals of the site. Accessibility is just usability
after all. We’re not designing and building these sites for ourselves, we’re
doing it for other people, too. While it may seem easier to just ignore whole
segments of the population, for the vast majority of us building web sites,
we already have the tools and knowledge out there..

Boiling It Down

So, let me try and boil this down into some bullet points:

  • Accessibility is usability. We’re all just trying to make things that
    people can use.
  • Basic accessibility isn’t hard. We should be doing stuff like alt-text,
    making sure form fields are labelled, etc.
  • Don’t expect perfection. It’s possible to get it wrong, especially as
    more layers of interactivity is added. It’s not a bad thing. Just learn from
    it.
  • Just because we can’t, doesn’t mean we shouldn’t. By this I mean, just
    because we might not be able to cater to everybody doesn’t mean we shouldn’t
    do
    it at all.

When it comes down to it, I’m a pragmatic individual. I don’t ‘preach’ accessibility.
I just do what I know works. I use the tools made available to me
and use what I’ve learned from others as the best possible way to wield those
tools to build sites and applications that people will use. I won’t shy away
from using Flash or Ajax but I will try to use those tools in the best way I
know how to reach the most people I can.

Reproduced from http://snook.ca/archives/accessibility_and_usability/what_does_accessibility_mean/.