Follow Accessibility News on Twitter
You are viewing the "Old" version of this website, for the most recent, start at the home page if you came in by way of a search.
Ads
Advertise with us
When people are starting up a new site development project, questions usually
come up around the "Accessibility"
requirements of what's being
built. Does
this site need to be accessible to screen readers? Does it need to conform to
federal standards of accessibility? What kind of audience will be visiting
this site? And so on. All good questions, and questions worth asking.
But I think these questions are too often asked not with the intention of providing
conveniences specific to certain audiences, but instead to find grounds
on which to ignore the concept of "Accessibility"
as a whole, an excuse
to knock it off as one less thing to worry about: "No blind users coming
here?
No need for accessibility then"
. Yikes. This points to some confusion about
what it really means to produce accessible content, and I'd like to try
and
clear up a bit of that by taking a closer look at what it really means to be
"accessible"
.
Right, so let's start with the word "Accessibility"
. The term
has been fashionable for years now, but it grew to be a little ambiguous as
the idea became
more popular and more people starting tossing it around. All in all I think
it's still centered around the right idea, but there are at least two sides
to that coin (the um coin of accessibility?) and I think we might stand to benefit
from a quick look at what those are.
We can all agree that one of the great things about the web is the way that published material can be accessed from pretty much anywhere with a connection, and using a huge variety of software tools. Properly coded content can be syndicated, redistributed, rewrapped, re-styled and reborn with little or no effort, due to the clever design of the technology involved. Now this is nothing new - we've all heard it a million times by now - but we've also learned from experience that it's not quite so simple, either. Things do go wrong - and given the complexity of it all, there are a number of ways they go about doing it.
Take me, for example. As a user, I'm pretty mainstream. I run Firefox
or IE on Windows with a big, full-colour screen and good multimedia support.
I don't
exactly fall into the category most people think of when they're worrying
about "Accessibility"
but nonetheless accessibility problems
still arise. Server
is down? Then I can't access the site. Connection dies between client and
server? No access. Google can't see the site? I can't find it. Flaky
browser
chokes on a piece of code? No access. What I'm getting at here is that,
strictly speaking, the word "Accessibility"
refers to "the ability
to access the
material being presented"
.
But as the industry matured, people began to give serious thought to what they
called "universal accessibility"
, in an attempt to understand the
difficulties
faced by those of us working with physical limitations. Not only should mainstream
audiences be able to access the site, the thinking goes, but so should
those using screen readers, braille devices and voice-activated software, too.
Enter initiatives like the Canadian Government's Common Look and Feel standards,
and Section 508 in the United States. All noble goals, and all worthy of attention,
which they received.
However, the development trends at the time were such that the main challenge
for "universal accessibility"
was not in finding ways to make things
easier
for the so-called "disabled"
crowd, but in finding ways to allow them
just to get in the front door. Unnecessarily heavy reliance on images, scripts
and
non-standard widgets to deliver core content resulted in the majority of websites
being almost entirely inaccessible to people using assistive technologies.
It was in this atmosphere that the term "Accessibility"
took hold
and really started to go somewhere.
Support for the idea grew, which at first seemed to be motivated by ideas of equality and non-discrimination - the worthwhile pursuit of being as inclusive as possible. But as time went on and people began to understand web standards and move back towards using these technologies the way they were intended, it became clear that universal accessibility is already inherent in the design of the medium if you publish a plain HTML page, everybody will be able to access it simply because it's in HTML.
Where the problems kick in is when people pave over their plain HTML content
in a way that accidentally locks out certain segments of the population. And
that's sort of the sad part of the story here the way we were building
sites those days, we were actually starting off with an accessible solution
and
then inadvertently erecting these barriers as we put more effort into construction.
Then, failing to understand where we had gone wrong, we took what we
had and tried to address these barriers by putting even more effort in - on
top of the slightly misguided construction done so far - to try and make our
inaccessible product at least "degrade gracefully"
. Like spending
cash on building a wheelchair ramp to get people over a high curb that arguably
shouldn't
have been put there in the first place.
Now - without a doubt - a site that "degrades gracefully"
is better
than one that is totally inaccessible, but in truth there is no need for anything
to
degrade at all. Instead it is better to remember that the pure content we're
putting online is the product and is already accessible to all sorts of different
people - and that the visual designs and snazzy scripted widgets are upgrades
to the basic offering. Done properly, nobody gets a degraded version at all
- instead it's just a question of how many of the upgrades the user takes
advantage of during their visit.
So back to the two sides of accessibility, that stupid coin I was talking about.
The old-school approach sees accessibility as "the ability of disabled
or
. People coming
from this perspective understand the challenge to be about the elimination of
accessibility
barriers that would lock these users out."alternative"
users to access your content"
The other take on accessible design is based on a more modern approach in which universal accessibility is achieved by keeping core content clean, to allow everybody and every machine access to your content and then applying layers of enhancements for those who can make use of them. The big difference between this approach and the other is that the old way is about removing barriers to entry - and the other is about ways to make things even easier for alternative users to make their way through the already barrier-free content. And from here it becomes clear: any effort taken which confounds, obscures or otherwise mangles your core content is not only creating potential barriers for alternative users, but also may be locking out other segments of your audience based merely on their choice of browser, operating system, bandwidth or display setup.
Clearly, the modern approach has won out, not only due to dreams of equal-access-for-all, but also largely driven by the fact that the most modern and powerful technologies are not steered by human eyes but are instead software entities operating in much the same way as screen-readers do: by reading the HTML. People began to realize that if the screen-reader couldn't read their website, then neither could Google. That got people's attention pretty quickly.
So I guess what I'm saying is that we should try not to talk about accessibility
as if it were just an option to be applied as an afterthought, or as some
kind of favour for blind people. If your server is down, if your fonts are too
small, if your site is too heavy to be downloaded easily, if your content
is hidden behind proprietary plugins or buried away in scripts somewhere, these
are all accessibility problems. This is about so much more than just catering
to some "disabled"
demographic it's about making sure people
can get what they came for:
"open in new window", allowing people to bookmark pages, etc.)
Okay then. So if we can agree that the old notion of the "accessibility
problem"
is best left to the modern, standards-based design tactics, then
what is
there to talk about when it comes to making things easier for people with actual
disabilities?
Well, as I said, most of the old "Accessibility"
tricks were less
about providing conveniences for disabled users and more about dealing with
the problems
that kept them out entirely. Now that we don't have to put effort into
providing workarounds for those barriers any more, what better way to spend
that
time than to work on implementing bonus features that make their visit a little
easier? Having now removed the barriers to entry, we're in a better position
to think a little bit about things we can do to help out this is where
"skip navigation"
links come in. Or special stylesheets that help
screenreading
software do a better job of reading your site. Or setting up a more useful tab-order
in your site's links, or establishing keyboard shortcuts, or you
get the idea. Lots to talk about there, but that's a whole other conversation.
For now, just remember: Accessibility = Interoperability.
Taken from http://blog.istudio.ca/?p=171
Accessibility News Published by
