Kynn's Soapbox: Accessibility and Usability (was: accessibility makeovers)

At 2:22 PM -0700 3/27/01, Paul Bohman wrote:
>One of the concerns that Web developers often have is that they think that
>accessible web pages are boring or ugly.

That's true -- it's a startlingly persistent myth.

>To disprove this myth, I am doing
>"accessibility makeovers" of some of the more popular sites on the Web. I
>decided to start with Barnes and Noble's Web site, because it was very
>inaccessible to screen readers, and the fixes were relatively easy.

Thing is, though, you can only get so far.  I don't want to sound like
I'm purely making a pitch for my company's product, so I'll point out
that other people BESIDES Reef are exploring this concept.  That said,
here is my philosophy on accessibility.

Yes, you can take a highly graphical, mostly inaccessible (to certain key
audiences) web page and make it "accessible".  This is relatively easy
and won't hurt the graphical layout; in fact, this is the basis of
1999's "Kynn Challenge" -- I have yet to find any page where the
graphical user interface is _harmed_ by adding elements and attributes
to increase the accessibility of the page.

HOWEVER, the next problem is one of usability.  Once you have allowed
a screenreader user to _access_ the information, the next question
becomes "can they do it _well_?"  And sadly, this is not the case; it
is not nearly as easily done.

In other words, yeah, you can get at the alt text, you can find the
content on the page, but have you created a great "web user interface"
for the screenreader use?  The answer is a solid "no" -- it's nearly
impossible to craft a web UI with a high degree of "usability" for
screenreaders, while keeping that web UI a derivative of the graphical
web UI.

Conversely, if you want to make a web UI (by which I mean "the parts
of the user interface -- presenting information, navigation, etc --
which are under the control of the web developer/designer"; in other
words, the stuff you create in HTML or the like) which works _well_
in screenreaders (high degree of usability), you will probably
create something which is _not_ optimized for the graphical browser

Accessible, yes -- you can make something which can be _accessed_ by
everyone -- but usable equally easily?  Or putting aside even the
concept of "equal" (which is darn hard to pin down), can you even
make a _good_ user interface for screenreaders, based on the graphical
browser user's interface?  No.  No, you can't.

That's why I've been working on this Edapta stuff for over a year --
now "Reef EveryWare" -- because I want to see dynamically generated
pages which build an accessible and _usable_ user interface for
each user.  Wherein each user is considered first and foremost as
who they are, and not made to rely upon using "someone else's"
interface with additional tags/attributes added.  Whereby we deliver
to each person the best we can create _for them_.

Our Edapta/Reef plan is to not _only_ provide accessibility, but also
to provide _usability_.  The accessibility stuff is relatively
easy (for most audiences) -- it's a solved problem, at least, for
screenreader users -- but usability is the next hurdle.  It's not
enough to say "well, you can get at the alt text, use the site!";
we need to go further and treat everyone with dignity, respect, and
high usability in a user-centric model.

No more coding to the "least common denominator" -- code instead
to each individual user.  This can help with a number of other
problems which are as yet fully unsolved -- such as cognitive
disabilities (dynamically linking glossaries, adding icons,
doing English-to-English downstep translations, etc).

So that's my soapbox.

I'll get off it now and say that nothing here is meant to minimize
your project, which is very good and very useful.  I don't want to
discourage you from this course of action; indeed, I hope you
proceed.  However, I think it's important to note that for most of
those sites you've mentioned -- which are dynamically generated
database-backed sites anyway (and thus perfect platforms for
dynamic adaption) -- the long-term solution will be something like
the scenario I've described above, and not merely a matter of making
sure the graphical browser user's version has proper "accessibility

Kynn Bartlett <>

Received on Wednesday, 28 March 2001 23:21:46 UTC