W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2001

Re: A PROPOSAL TO SPLIT THE WCAG IN THREE. Please read this. I'm serious.

From: Al Gilman <asgilman@iamdigex.net>
Date: Mon, 20 Aug 2001 15:11:24 -0400
Message-Id: <200108201458.KAA6004685@smtp2.mail.iamworld.net>
To: "WAI Guidelines WG" <w3c-wai-gl@w3.org>
At 07:45 AM 2001-08-20 , Anne Pemberton wrote:
>Chas,
>
>         As it is, we have four guidelines 1) accessibility, 2) 
>navigability, 3)comprehensibility, and 4) technology
>
>         You suggest moving the technology checkpoints under which?
>
>         Why not simplify further ---- two guidelines: 1) insure that all 
>content is accessible and comprehensible
>and 2) insure that users can navigate the page/site.  

AG::

Disclaimer:  How not to make these remarks sound conclusive?  I wish to share
some bias and some background without presuming what I say is the right answer
for the group.

For the moment, I would tilt toward separating cognitive barriers from sensory
and actuation barriers as major forks in the development of our message.  The
objective to maximize what the user can get out of the Web, and I mean the
whole Web, is shared, but the gotchas that break the achievement of this goal
involving sensory-motor and cognitive issues are sufficiently separately to be
treated separately in detail with supporting connecting threads.  I don't
believe that we can remove cross-linking between any two of Chas's proposed
three foci, but this doesn't mean that it doesn't make sense to give the
developments in each area a measure of autonomy.

Part of our problem is that we are still trapped in legacy-think concerning
what is _a document_ and what is _normative_.  There has to be a bit of
promotion in every engineering specification; mostly by linking but partly
inline.  That is just because you can't entirely trust readers to read the
glossary or to follow hyperlinks, etc.  Our expository style has to have a
measured dose of both-and; both indication and evocation, both words and
pictures, both extract the essence and illustrate the application.  In an
ideal
world already adapted to the Web we would not be talking about one document
vs.
three.  We would know that our product is a web of Web content, and we
would be
working on site organization, in which these four areas are our working
definition of centers of accumulation that have a measure of autonomy, or
principal-parts standing relative to the whole.  And that the whole WCAG only
has that limited degree of autonomy from the whole web of wisdom that the WAI
publishes, and the WAI only a limited  degree of autonomy from what the W3C
technology community and the HCI community and so forth publish.

The point is that each of Chas's proposed triple is a major, semi-separable
subtopic dealing with HCI -- making it work for people.  The fourth area,
technology, is making what works for people automatable by machines.  It's
almost like 'comprehension' and 'navigation' are the two functional outcomes
that we support and 'sensation and actuation' and 'automation' are the two
instrumentalities that we have to work through to accomplish these.

In regards to comprehension, I don't think that we will ever get past the fact
that "Your Mileage May Vary."  There is a diversity of cognitive constraints
and preferences, and you cannot reach all of the people all of the time.  In
the particular case of people with disabilities which mean that alphabetically
encoded words just don't work, I believe the highest and best answer we can
come up with is to enable these users to navigate and actuate, and that
"comprehending all the information" is beyond what we can come up with in
terms
of readily achievable techniques.

But retail merchandising on the Web can probably be made to work with just the
pictures and the controls, so long as the navigation mechanisms to get to the
pictures of the individual products offered for sale is recognizable without
the words.  And that is probably achievable.

At times we used to say "text is king" and I think we have [as a consensus]
recognized the problems with that summary.  But there is still a sense in
which
"navigation is the queen" of web actions.  The great thing about the Web is
how
it _gives people alternatives_ by the common mode of access to myriad
resources
on the Internet.  The trick is to make browsing and user-driven selection of
what one choses to work on comprehending really slick, really facile.  Because
comprehension is such a hit-or-miss thing, browsing is a key component of our
strategy to improve performance against cognitive obstacles.  Skimming and
drilling down.  Those are the coordinates of browsing.  This makes our
achievements relative to 'cognitive' objectives heavily dependent on the
'ensure navigation works, well' nap of our solution strategy.

Oh, I said 'nap' there.  This raises an image that I think we can perhaps
express by a 3D visualization of the soap-bubble structures that we in
physical
chemistry call phase diagrams.

In the review of a draft for the ISO/IEC Handbook 71, Gregg pointed out that
they had butchered the gross shape of the problem/solution connection by
lumping all visual disabilities together.  The key here is that the phase
boundary of tipping point in what kinds of strategies work comes not between
normal vision and impaired vision but between some vision and no usable
vision.  Working with a screen magnifier it is clear that incremental changes
in the visual presentation are essential.  Working with a screen reader, they
are immaterial.  The deeper access to the textual code for text-to-speech or
text-to-touch transformation is what is key at this point.

So there is a both-and in our message: both make each thing you do to
communicate as robust and flexible as you can, and also incorporate redundancy
that crosses the major mode boundaries.  What we haven't convinced
ourselves we
know, is what all the major modes are.  The failure we face is if the
alternatives provided, taken together with the flexibility embodied in each
alternative major mode, don't reach all the corners of our demographic
space of
human and device abilities.

In the cognitive arena, taking reading-affecting disabilities as an example, I
believe the 'operating point' we can reach is where a) incremental techniques
are used to level and minimize the linguistic challenges of the verbal
content,
b) alternatives in non-visual media and non-verbal modes of expression are
also
used to convey the same message or content and c) metadata and other
navigation
facilitators are used to aid in finding an expression that works around a
particular sensory, motor, language or background-driven obstacle.  How
much of
each is 'enough' may be unanswerable, other than some diversity or
distribution
of approaches is required and the methods to apply in each approach are laid
out.

In the User Agent guidelines we rely on the argument that "in the end, only
the
user knows for sure" what works for them and what doesn't to argue for
algoritms of content control which give the user the last word.

In the content guidelines, for cognitive effectiveness, we face the same
fact. 
Only the user knows for sure what is working for them and what is not
[educational testing aside].  Here the result is a both-and distribution
requirement.  Both make your message as multimode as you reasonably can, and
cooperate in web-wide strategies to facilitate the user's search and browse
process to find equivalents and or adjuncts that work for them or make your
bit
of Web work for them, drawing not only on what you have provided but on what
others have provided.

My own 'modest proposal' on document scopes has been that the next round of
documents should unify work across the areas that we divided out as document
topics in the previous round.  Rather than dividing by author tool, content
model and encoding, and user tool divisions, we should attack specific
functional areas where we feel the technology and our advice as to how to use
it is under-performing, and address them on an end-to-end basis giving
coordinated suggestions in all of the above areas as a bundle.

Particularly, in the UAAG we felt that the current format definitions give
inadequate support for cues as to what constitutes the principal parts of a
web
page, suitable for automatic extraction of a Table of Navigation such as used
in the digital talking book specifications.  In the XMLGL we are exploring the
hope that with the new language-building technologies particularly
schema-based
syntaxes, that we can do better on this score.  But it won't work without
suitable authoring-time interactive methods being applied, IMHO.  So
navigation
remains a central area where we could do well to take an integrated look at
what the notation, the author tool, the author, the baseline browser and
assistive add-ons to the browser should all do to make this work better under
more circumstances of "delivery context" as the Device Independence working
group would say.

Coping with the increasingly dynamic and interactive nature of web content is
yet another area where our grip is weak.  This deserves focused attention, and
cross-old-document-boundaries integrated work.  There are incremental
techniques that can be applied in the domain of writing in HTML+ECMASCRIPT and
there are more radical approaches extending the outcome-schema strategy
exemplified by X-Forms.  It is impractical to think that we can just pick one
of these strategies to pursue; advances in either direction will make a
contribution, no matter how well we do on the other.

As Chas and Anne are agreed, dealing with cognitive challenges is another
under-performing area.  Perhaps we can agree to disagree, or defer
decision, on
the ultimate algebra of document scopes, while we agree we agree that this is
an area where we have miles to go yet, and it deserves focused attention in a
semi-detached or encapsulated work item.  At the moment, we have a 'WCAG'
scoped group which has position and momentum to take this on, so we don't have
to wait for a more radical reorganization of the groupings to get going on
this.

Al


>...There will be too 
>many cross links between accessible and comprehensible, and they both have 
>a common goals -- for the user to be able to use the content.
>
>                                                         Anne
>
>At 04:30 AM 8/20/01 -0700, Charles F. Munat wrote:
>> From a previous post:
>>
>>"If it were up to me, I would break out [navigability] and
>>[comprehensibility] and make three guidelines: WCAG, WCNG, WCCG, for
>>Accessibility, Navigability, and Comprehensibility respectively. If we did
>>this, I expect that WCAG would be slightly smaller, WCNG would be of
>>moderate size, and WCCG would be as large or larger than the current
>>guidelines."
>>
>>I continue:
>>
>>I don't expect to convince many, but I'm going to state this for the record.
>>The best we're going to do on the WCAG if we try to include navigability and
>>comprehension in with accessibility (strict sense meaning ability to "get
>>to" the data) is half-assed. More likely quarter-assed. It's just too much
>>for one document.
>>
>>IF (big IF) we split the documents:
>>
>>1. We could have the WCAG 2.0 ready to go in a week (and with almost NO
>>quarrelling over the details -- this stuff is mostly old hat).
>>
>>2. The Web Content Navigability Guidelines could be done fairly quickly, I'd
>>imagine. A few months?
>>
>>3. The Web Content Comprehensibility Guidelines would take a while. At least
>>a year, I'd think. BUT (big BUT): We could issue a temporary set containing
>>the comprehensibility checkpoints currently in WCAG 2.0 (including the
>>dreaded 3.3 and 3.4). They would be without official status (whatever that's
>>worth) but would be enough to get people thinking about it. We could also
>>promote them and try to get people thinking more about comprehensibility.
>>
>>THINK OF THE BENEFITS:
>>
>>1. We get access out of the way. This would refocus our goal. No longer
>>would there be the tug of war between access advocates and comprehensibility
>>advocates.
>>
>>2. A new, small, fast-working group could be formed to handle the
>>navigability guidelines. Without the burden of having to figure out
>>comprehensibility (a much more difficult proposition) or simple access,
>>these guidelines could be produced quickly.
>>
>>3. COMPREHENSIBILITY IS NO LONGER ACCESSIBILITY'S UGLY HALF-SISTER, VYING
>>FOR ATTENTION. This group could morph into the Comprehensibility WG, minus
>>those people who are more interested in access or navigation. The group
>>would be focused on ONE goal. Better still, we could PROMOTE this idea more
>>effectively because comprehensibility is more *comprehensible* when were not
>>trying to call it accessibility. Finally, we could go out and actively seek
>>experts on comprehension (and cognitive disabilities) to join the experts
>>already in this group, bringing in fresh blood and new ideas and
>>rejuvenating the group. Who knows, maybe without the drag of constant access
>>vs. comprehensibility wars, the WCCG could be completed in record time.
>>
>>The only detriments I see are these:
>>
>>1. It takes longer to get the comprehensibility guidelines out. As I see it,
>>this delay would be more than compensated for by the MUCH clearer nature of
>>the WCCG guidelines. And, when users looked to the WCCG, there would be no
>>doubt about what they were trying to accomplish (e.g., a person who just
>>wants to ensure access to users with visual disabilities will not look
>>there). Another mitigating factor would be the temporary stop-gap measure of
>>an "unofficial" release of "methods to aid comprehensibility while waiting
>>for the release of the WCCG 2.0."
>>
>>2. Without the "accessibility" angle, comprehensibility might lose some
>>leverage. Solution: Define accessibility twice (as we already have, I
>>think). GENERAL accessibility includes SPECIFIC accessibility, navigability,
>>and comprehensibility. PUT THIS IN THE INTRODUCTION TO ALL THREE SETS OF
>>GUIDELINES, thus:
>>
>>"There are three parts to ensuring an accessible Web site. First, users must
>>be able to access the site. Second, they must be able to navigate the site,
>>to find the data they're looking for. Finally, they must be able to
>>comprehend -- to understand -- the data once they've found it. The W3C
>>provides three sets of guidelines related to Web site accessibility: the Web
>>Content Accessibility Guidelines (WCAG), the Web Content Navigability
>>Guidelines (WCNG), and the Web Content Comprehensibility Guidelines (WCCG).
>>All three sets of guidelines are necessary to ensure accessibility on the
>>Web."
>>
>>This gets us out of the "usability" trap. It clarifies (and actually
>>simplifies) the guidelines. It refocuses the guidelines by allowing each set
>>to concentrate on one area.
>>
>>There could be overlap. A checkpoint that affected access and navigability,
>>for example, could appear in both. The non-normative data could explain how
>>it affected access in the WCAG version and how it affected navigability in
>>the WCNG version.
>>
>>Another option is to reorganize the current guidelines into access,
>>navigability, and comprehensibility sections, but this is much less
>>desirable. I envision a significant expansion of the comprehensibility (and,
>>to a lesser extent, the navigability) portion. This is going to take some
>>time. If we keep them in one document, we will delay the access portion by
>>quite some time. Why? Let's get it out of the way. Then let's create a set
>>of comprehensibility guidelines that will blow the lid off this subject and
>>will focus everyone's attention on the need to make sites comprehensible to
>>everyone. (Note to Anne: this puts the needs of people with cognitive
>>disabilities front and center.)
>>
>>I ask everyone in this group to think seriously about this idea. WE CAN DO
>>THIS. IT IS NOT TOO LATE. WCAG 2.0, stripped of nav and comp can sail
>>through to recommendation status and we can give the remaining two aspects
>>of accessibility the attention they truly deserve.
>>
>>Since the current draft is scheduled to go public in the next 48 hours, if
>>you think that this is worth at least a telecon, please SPEAK NOW.
>>
>>Chas. Munat
>
>Anne Pemberton
>apembert@erols.com
>
><http://www.erols.com/stevepem>http://www.erols.com/stevepem
><http://www.geocities.com/apembert45>http://www.geocities.com/apembert45
>  
Received on Monday, 20 August 2001 10:58:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:11 GMT