Accessibility Rating

I posted this message a while ago, but apparently, it got lost and
nobody received it.

Here it is again.

PS: I ccing Robert since on a different thread on the wai-ig list, he
    asked about validity/accessibility.

=============================================

From: Daniel Dardailler <danield@w3.org>
To: w3c-wai-wg@w3.org
Subject: Accessibility Rating
Date: Thu, 26 Jun 1997 14:00:42 +0200


Another task mentioned in the WAI initial plan is a PICS rating and
labeling system for accessibility level (if you don't know what is
PICS, check http://www.w3.org/PICS - to summarize, it's a metadata
infrastructure: a computerized way to say something about documents)

I'd like to start working on that aspect in parallel to the Markup
guidelines since it's closely related. I propose that we:
  (1) openly discuss the various characteristics of page accessibility
     (what they are, how important they are, etc) on the list
  (2) try to organize them under a more formal set of category/scale
  (3) map the whole thing in PICS syntax and try it out.
  
Point (1) above is where we absolutely need visually impaired end-user input.
Point (2), the modelization, is the hardest part.
Point (3) is easy.

I already talked with Raman (this report really steams from the
feedback he gave me) and a few other people, and I'll try to summarize
what I gathered in a few axioms (only valid for non-visual
accessibility for now) :

  A) Knowledge of the page logical reading order is paramount.

  B) Presence of Alt text is necessary but not sufficient (see A)

  C) Navigability should be paid special attention

  D) Interactive content (FORM) should be rated separately


I'll further develop each point now.

Point A) is really about the fact that the statement "pure graphic
implies no access" is not commutative: a text-only page can also
implies no access when the reading order is messed-up, e.g. when an
alternate (1-dimentional) presentation model is used.

That is to say: the level at which logical markup is used vs.
presentational markup is important; as an example, are the tables on a
page real tabular data, or do they reflect pure visual layout (and a
complex one)? 

Point B) - the well known missing Alt text - is really saying that
although it's important to know what an image is about, or what it is
used for, it's often not enough to comprehend the page real
message. Also, the usefullness of Alt text needs to be checked: a page
shouldn't be able to defeat the system by supplying "image" as the Alt
string for all images.  At the same time, it may be reasonable to use
" " as the Alt text when an image is purely decorational (a convention
that the guidelines could recommend).

Point C) about navigability steams from the hypertext nature of the
Web. If the Web was just a bunch of documents - even with images -
accessible thru a big index (like a first generation online library),
with no links, solving A) and B) would be enough.

One important navigability aspect is predictability: does the user
know what to expect when s/he follows an edge ? For instance, images
which are embedded inside an anchor tag and don't have an associated
Alt text need to contribute more to the "badness" measure than inline
images that are floating on a page. The anchor text itself, of course,
is part of that (the "Click here" symptom, with no TITLE), and so is
the "one link per line" screen reader guideline.

The "navigability" measure above has to be normalized over the size of
the page; ie if a top-level page that serves purely as a site
navigation aid (and is consequently short) has a large number of
inaccessible edges going out of it, then it receives a bad rating as
compared to a large page with few edges going out of it, ie a page
with significant content, where some of these edges are non-accessible.

For point D), Interactive WWW content, e.g. WWW forms, we are really
talking about a special application framework that can or cannot be
supported altogether. One can always design a form that would get a
very high accessibility rating as a page that you can "read" but would
fall flat on its face if a user tried to "interact" with it (because a
given screen reader doesn't support input field and such).

Received on Tuesday, 22 July 1997 08:24:52 UTC