Re: Murky ratings

I apologize for the following long posting, but I do feel that
it addresses the problems in the current structure of the guidelines
with a reasonable and simple alternative providing a great
deal more power and flexibility.

Josh Krieger
CAST

I'm beginning to see some common issues in the current WAI guidelines
which, in terms of the current framework, are hard to resolve and which
will continue to cause problems in the future. These issues primarily
revolve around the longevity of individual guidelines (when in time they
begin to be relevant and when they cease to be relevant) and an attempt
to, I think incorrectly, entirely tease out authoring issues from
browser and assistive technology issues.  The model we have been working
with is one of a static set of guidelines in which we determine as of
the release date of the guidelines, whether a page is accessible or not
in regards to some ill-defined population using an unknown browser and
unknown assistive technology.  For example, take this apparently simple
guideline:


2.1. [REQUIRED] Provide alternative text for image maps.
Solution: Use the "alt" attribute on AREA tags.

The following qualifying information is never mentioned:

1. The guideline is not relevant for HTML before version 3.2 since at
that point in time there was no ALT support in the AREA tag.  An
alternative approach must then be taken here. See point 6 below.
2. Even if the page were authored during or after HTML 3.2, if a blind
person were using Netscape Navigator 3.0 or IE 3.0, regardless of the
screen reader, the image map would not be accessible because Navigator
didn't display the ALT text for AREA tags then.
3. In IE 4.01, if image loading is turned off, the alt text for the
image map areas are not available because the image map is replaced only
by the image alt text.
4. When Jaws 3.2 is release this month or next, because of the IE 4.0
document object model, IE 4.01 now becomes accessible with regards to
this guideline.
5. A page that uses this guidelines is accessible for people who are
blind using any screen reader and Lynx 2.5, 2.6, 2.7
6. If the strategy of using the ALT attribute is ineffective for a
particular browser, one should provide redundant links in the body of
the HTML page.

What we see clearly is that the seemingly specific guideline 2.1 is
actually inadequate to convey a detailed notion of accessibility.  This
is not because the guideline is wrong, but simply because it is not
defined with regards to the specific browsers and ATs for which it is
relevant. By defining this relationship, we also define a notion of
longevity of the guideline which replaces the problematic interim label.
For example, let's rewrite guideline 2.1 as follows:

Guideline: Provide alternative text for image maps.
Solution: Use the "ALT" attribute on AREA tags.
Guideline Relevant For: America On-Line Browsers v2.5,v2.6,v2.7,v3.0
Assistive Technology Relevant For: All screen readers
Population Affected: Non-sighted

Guideline: Provide alternative text for image maps.
Solution: Use the "ALT" attribute on AREA tags.
Guideline Relevant For: Internet Explorer 3.0,4.0
Assistive Technology Relevant For: All screen readers
Population Affected: Non-sighted

Guideline: Provide alternative text for image maps.
Solution: Use the "ALT" attribute on AREA tags.
Guideline Relevant For: Internet Explorer 4.01
Assistive Technology: Jaws v1.0,v2.0,v3.0
Population Affected: Non-sighted

[ In this last example note that Jaws v3.2 is not included because, with
regards to this guideline, IE 4.01 is accessible]


I've only included the first three instances of this guideline above,
but check out the last section of this document for some more examples. 
Also, I defined these instances as separate entries, but practically one
could define a very simple computer language that would allow the
expression of all these variants in a single structure. 

Ratings:

Building the guidelines as a collection of these instances allows us to
create a complete database of what accessibility means with regards to
HTML over many years. Such a database can then be used to GENERATE
documents containing lists of accessibility guidelines that are relevant
for particular people and organizations' needs. We lose very little by
storing the guidelines in this new format. In fact, if we so chose, we
could generate the current guidelines automatically.  For example, we've
found with Bobby that we can't just change the standard on people
suddenly requiring their organizations to implement a whole new set of
accessibility measures on thousands of pages of which they've already
invested considerable time making accessible.  Some government
organizations established policies requiring Bobby and HTML 3.2 approval
before posting pages on their internet site and those pages don't cease
to be accessible if Bobby or the guidelines suddenly change.  Besides,
if an organization wants their pages to be as accessible as possible and
yet still has an HTML 3.2 policy, we can't suggest they add all sorts of
HTML 4.0 tags. It doesn't make sense.  All these issues now arise as we
attempt to encourage the use of the accessibility support built into
HTML 4.0. These issues will continue to arise in the future as more
changes and additions are made.

I do also want to add that by labeling individual guidelines as
Recommended/Required we essentially implement a de facto rating scheme.
Further, this rating scheme is fixed in time.  This is not the purpose
of the guidelines! The guidelines need to be separate from rating and
well defined in time. Given that our database exists as I described
above, we can then define an abstract measure of accessibility that can
change at predefined intervals (i.e. once every year).  For example,
what CAST now calls "Bobby Approved" could mean that all database
entries for Netscape Navigator 4.0, Internet Explorer 4.0, and Lynx 2.7,
that are relevant to all affected populations with all possibilities for
assistive technologies are taken care of (well that's a little broad,
but you get the point).  In this way, web accessibility can be well
defined and measurable according to annual WAI policy decisions about
what accessibility means with regards to the database.


Additional information to store with the guidelines

There are probably other relevant items that people want to store with
each guideline, but it occurs to me that it would also be useful to have
an entry for whether or not a guideline can be automated (can a program
like Bobby find it without human intervention).


More examples:

Below are some more examples of how the guidelines could be rewritten:

2.1. Provide alternative text for images. 

Guideline: Provide alternative text for images
Solution: Add "ALT" text to image tags.
Guideline Relevant For: All browsers
Assistive Technology Relevant For: All screen readers
Population Affected: Non-sighted


Guideline: Insure that alt text does not wrap for images:
Solution: Browser dependent
Guideline Relevant For: All browsers except IE 4.01
Assistive Technology Relevant For: All screen readers
Population Affected: Non-sighted

4.1. Provide a text transcript of all audio information

Guideline: Provide a text transcript of all audio information
Solution: Full audio transcripts include spoken dialogue as well as….
Guideline Relevant For: All browsers
Assistive Technology Relevant For: None
Population Affected: Non-hearing

Received on Wednesday, 13 May 1998 12:02:39 UTC