W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2000

Is AAA Onerous?

From: Kynn Bartlett <kynn-edapta@idyllmtn.com>
Date: Wed, 20 Dec 2000 09:59:05 -0800
Message-Id: <4.2.0.58.20001220090731.00be6ba0@garth.idyllmtn.com>
To: "Bailey, Bruce" <Bruce_Bailey@ed.gov>
Cc: "'Frank Tobin'" <ftobin@uiuc.edu>, "'w3c-wai-ig@w3.org'" <w3c-wai-ig@w3.org>
At 06:29 AM 12/20/2000 , Bailey, Bruce wrote:
>I am confused by this position.  It seems to me that going from double-A to
>tripple-A is not that much work.  What are the checkpoints that are onerous?

Fair question, let's take a look at the Priority 3 checkpoints:

In General (Priority 3)
4.2 Specify the expansion of each abbreviation or acronym in a
document where it first occurs.

This can be difficult especially if it is demanded that the word
be expanded _regardless of audience_ and if it is demanded that
it be encoded using _markup_ and not naturally as English allows
for.

In other words, with a strict interpretation, this quickly becomes
onerous -- and we've seen in recent days that many people are very
quick to demand strict interpretations.

4.3 Identify the primary natural language of a document.

This is easy and is done via template.

9.4 Create a logical tab order through links, form controls, and objects.

This is harder, as there are few tools which support and create
TABORDER attributes, and it's difficult to test.

9.5 Provide keyboard shortcuts to important links (including those
in client-side image maps), form controls, and groups of form controls.

This is a nightmare to enforce, for two reasons:

(1) Technology-wise, keyboard shortcuts via ACCESSKEY are very 
     difficult to include and make usable in any reliable method.
     Different meta keypresses on different operating systems and
     no reliable way to indicate hot keys compound the primary
     problem of there being few "safe", unused ACCESSKEYs to use.

(2) The word "important" means this is another interpretation issue,
     which means that if you're a designer you will choose your own
     comfort level, and then someone who wants to prove your site
     "non-compliant" will adopt a stricter standard and "prove" that
     you fail Triple-A.

10.5 Until user agents (including assistive technologies) render
adjacent links distinctly, include non-link, printable characters
(surrounded by spaces) between adjacent links.

Anything which is labeled "until user agents" is automatically going
to be a problem, especially as the average web author, with no
experience with assistive technologies, has no idea whether or not
this guideline should be followed.  Heck, I don't even know this
one -- can someone tell me whether or not user agents currently
render adjacent links distinctly?

How can someone know whether or not they are Triple-A compliant
based on this?  If I choose wrong, then someone will produce an
obscure, older user agent, and will be quick to point out that I am
in violation of this rule.

11.3 Provide information so that users may receive documents according
to their preferences (e.g., language, content type, etc.)

This is so broad and overreaching as to be impossible to meet. 
What does it mean?  The following "note" states that content
negotiation should be used "whenever possible."  Vague, vague
language which you can drive a truck through, or alternately
block off the highway entirely!

This checkpoint seems to be saying that you should provide a
version of all content in any language requested by the user, and
in any data format!  Do you disagree?  If you do, then what _is_
this checkpoint saying, and how do you know if it's checked?

 From a strict standpoint, this is very much demanding alternate
formats and alternate language versions, but _without limit_, which
pushes it far into the "onerous" realm of things.  From a non-strict
standpoint this checkpoint says _nothing_.

(I will note, however, that this checkpoint itself is an excellent
argument for everyone to use Reef's Edapta technologies, coming to
a website near you in 2001!)

13.5 Provide navigation bars to highlight and give access to the
navigation mechanism.

This is potentially onerous because it demands a specific presentation
form and type -- "navigation bars" -- which is both an intrusion on the
ability of the designer to create as she wishes, -and- an assumption
that "bars" are always going to be the best way to provide access to
navigation features.

It's onerous because it's mandating one specific solution and pretending
as if it's the best way of doing things.  Also, "navigation bars" are
never defined, and are certainly not a construct which is present
within HTML itself -- so how do you know if you've met this
checkpoint?

13.6 Group related links, identify the group (for user agents), and,
until user agents do so, provide a way to bypass the group.

Have user agents provided that yet?  Anyone, anyone?  (Again, this
illustrates the difficulty in anything labeled with "until user
agents" -- which is why it will likely be eliminated completely in
WCAG 2.0.)

This is onerous because, when using a single-source/single interface
model, there's no way beyond the hack of "invisible gifs" to include
a "skip navigation" function for screenreaders without making the
appearance unattractive, confusing, and unusable for graphical/visual
users.

13.7 If search functions are provided, enable different types of
searches for different skill levels and preferences.

This is difficult and I'm not even sure what it means.  Does it simply
mean an "advanced" search in addition to a straight-forward
box-and-button?  Or does it mean something else?

The techniques document suggests the following:
"Search engines might include a spell checker, offer "best guess"
alternatives, query-by-example searches, similarity searches, etc."

Incorporating those types of search functions is not nearly as simple
as adding a tag to an HTML document; writing (or even installing) a
search engine is difficult work.

By a strict interpretation, all of the above could be considered
required -- as the checkpoint is another one which is very vague.  If
I don't include a spellchecker in my search engine -- if you can't
find "constable" by typing "constible" -- then someone with a view
to disprove my Triple-A status could easily conclude that I have not
adequately met this checkpoint, and I will need to rewrite my search
engine in order to gain Triple-A compliance.

Onerous.

13.8 Place distinguishing information at the beginning of
headings, paragraphs, lists, etc.

This is a "comprehension" checkpoint and it basically says that if
you don't use journalistic "inverted pyramid" style writing, then you
are in violation of this checkpoint and not compliant with Triple-A
WCAG 1.0.

This is clearly onerous as it assumes one model of writing.  And
from a strict perspective -- if I find one paragraph where the main
concept is in the second sentence and not the first, am I in violation?

How do you judge writing guidelines objectively?  Do you apply this
to forms of communication _besides_ simply news reports?  Granted,
this model makes sense for news sites, but what about other forms of
written expression?

By this checkpoint, you're unable to use any other model for writing
text -- "front-loading" is mandating, and if you violate it at all,
you are not Triple-A compliant.

Onerous.

13.9 Provide information about document collections (i.e., documents
comprising multiple pages.).

This seems rather simple at first glance, but then it quickly becomes
onerous because there is no limit or guidelines on how this should
be done.  Should the whole site be available as a tar or zip file?
If not, then how do you know if you are in violation?  What if the
site is updated regularly, as a new site?  Do you need to generate
zip files of the site whenever it is updated?

How big of zip files do you create to allow offline reading?  What if
your site is dependent upon server-side effects to function?  Do you
need to engineer a version of the site which is not thusly dependent?
Do you create javascript equivalents for your server-side scripting,
and if so, what do you do if those are not accessible?

Heading into the area of link tags and rel/rev elements, what do you
do about the fact that the tools provided in HTML are generally
insufficient for describing the relationships between your document
collection?  The attribute values given are not enough to completely
describe inter-site content relationships.  What then?

Does this checkpoint mandate a complete RDF map of your site?  Who
can tell?  It's vague enough, with no limits, that you never know when
you have met this checkpoint, and someone with a strict interpretation
can always decide that you haven't met it because you don't have
complete RDF graphs.

Onerous.

13.10 Provide a means to skip over multi-line ASCII art.

This faces the same problems as skipping over anything -- there is no
way, beyond resorting to a very inappropriate hack, to allow ASCII
art to be skipped by screenreaders while still providing a decent,
usable, non-confusing interface to visual users.  (Well, no way if
you are using a single interface model.  In Reef's Edapta structure,
this problem becomes trivial.)

Slightly onerous, mainly just tacky.

14.2 Supplement text with graphic or auditory presentations where
they will facilitate comprehension of the page. 

Aha!  Here is the "Anne Pemberton" checkpoint!  I was waiting for
this to come up.

Note to Anne:  While I agree with you that this is important, I
also feel that the checkpoint above is very, very vague and not
properly worded to allow for conformance claims.

Here's the problem.  First off, "where they will facilitiate the
comprehension" is clearly vague beyond belief.  As with many other
checkpoints, there is no way to know, beyond just making your own
best guess, whether or not you have complied.

And whenever a web designer is relying on her own judgment, that
opens her up to the claim that she "hasn't done enough" because
someone can easily adopt a stricter viewpoint and thus disqualify
the site from Triple-A compliance.

In other words, she may feel that she included "enough" graphics,
but I may say "no, if you had done <this> over <here>, then you
would have made comprehension easier, and thus it is demanded by
this checkpoint that you do this."

Secondly, while cheap clip-art is freely available and easy to
come by, professional-quality illustrations and sound enhancements
are not cheap or easy at all.  Adding well-done graphics to a
professionally done, commercial site is a major undertaking and
may requiring hiring additional staff in most cases.

Thirdly, without any standards on how to present graphical
information, this checkpoint becomes very hard for a web designer
to meet.  There are no universal icons which represent the scope of
all data, and any choices made will be subject to second-guessing
after the fact.

Conclusion:  Onerous, as written.  (Although I do believe strongly
in the concept, just not in this specific way of expressing that
concept.)

14.3 Create a style of presentation that is consistent across pages.

Someone define "consistent"?  How consistent must you be?  What does
it relate to?  If you change colors for different sections, is that
consistent or not consistent?  Across how many pages must you be
consistent?  What if different groups of pages are controlled by
different people?

I worked at Claremont Graduate University as the web communications
manager for almost a year.  Each department within the school was
allowed to create their own style for their web pages -- and we didn't
do any checking to make sure that they were consistent within those
styles, by the way.  We just asked that they link back to CGU's main
site using the CGU graphic, and we supplied a "default look" for the
main site which they were welcome to use.

Did this go far enough?  Is this Triple-A compliant?  Or is it not?
The W3C's site itself is notorious for having 57314786173803 different
styles; each technical release seems to have its own stylesheet!  
(Compare, for example, the HTML 3.2 and the HTML 4.0 documents.)
The WAI homepage and the W3C homepage are different.  Is this an
accessibility violation?  Or because they all have a link to the W3C
home page, with the W3C logo on it, is that enough?

In short:  Good intent, poor checkpoint, and thus onerous.

And if you use images and image maps (Priority 3)
1.5 Until user agents render text equivalents for client-side image
map links, provide redundant text links for each active region of a
client-side image map.

This isn't too hard.  Except, of course, for the "until user agents"
which means that it's effectively impossible for most people to
know when they are in compliance and not.

Slightly onerous.

And if you use tables (Priority 3)
5.5 Provide summaries for tables.

Could be difficult when dealing dynamically generated content, but
in general this is not very hard at all.

5.6 Provide abbreviations for header labels.

Not onerous.

10.3 Until user agents (including assistive technologies) render
side-by-side text correctly, provide a linear text alternative
(on the current page or some other) for all tables that lay out
text in parallel, word-wrapped columns.

Onerous.  Uses the "until user agents" clause which requires full
knowledge of all assistive technologies, plus it requires you to
duplicate content or else provide some sort of coding (which is
not standard on web servers) to unstack tables.  And this may not
even be necessary!

And if you use forms (Priority 3)
10.4 Until user agents handle empty controls correctly, include
default, place-holding characters in edit boxes and text areas.

Somewhat onerous just from the "until user agents" phrase.


Hope this analysis helps!

--Kynn

-- 
Kynn Bartlett  <kynn@idyllmtn.com>                    http://kynn.com/
Director of Accessibility, Edapta               http://www.edapta.com/
Chief Technologist, Idyll Mountain Internet   http://www.idyllmtn.com/
AWARE Center Director                      http://www.awarecenter.org/
What's on my bookshelf?                         http://kynn.com/books/
Received on Wednesday, 20 December 2000 13:39:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:50 GMT