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

Re: Gaps: (1) Language Readability

From: Al Gilman <asgilman@access.digex.net>
Date: Sun, 25 Oct 1998 11:38:00 -0500 (EST)
Message-Id: <199810251638.LAA03915@access2.digex.net>
To: nir.dagan@econ.upf.es
Cc: w3c-wai-gl@w3.org
What follows is a speech I have given before, but I can see
already I will have to give it again, even after this time.

The differences involved here are a question of balance and
proportion.  They are not something we can prove by deductive
logic.  This tends to generate strong feelings, because we are
dealing in judgement above and beyond reasoning.  So please
excuse me if a little of my strong feelings leak through.  I
really do want the group to come to a reasonable consensus.

1. Assessment of the situation

What has made the WWW phenomenally popular is a trait that it
shares with the Microsoft success story: it gets the job done
with a minimum intrusion of technicalities.  In hypertext, most
of the job is done with natural language, with minimal
perturbations of added formalism.  This is a) what makes the Web
great; and b) what makes a purely technical solution to
accessibility problems impossible.

The determining conditions for effective communication with
people with disabilities through the medium of the WWW include
both natural-language and document-structure issues shared with
all users, and technical factors peculiar to robustness with
regard to diverse user interfaces.  While the technical factors
alone can guarantee failure, only the combination of natural and
technical factors can guarantee success.

While the technical factors should properly take the lion's share
of the page budget in the guidelines document, the story line
presented must encompass both natural and technical aspects or we
have set up the following failure scenario.  We have committed
ourselves to a Pyrrhic victory: we can easily declare victory for
the document, and lose the war as a result.


2. Failure scenario

Step 1: The WAI-GL group decides that the job of the Page Author
Guidelines is only to document the technical fixes to the pieces
of the problem that have technical fixes.

Step 2: The WAI-EO group decides its job is only to educate people
to what is in the Page Author Guidelines; and the WAI-AU group
decides its job is just to get authoring tools to produce HTML
which satisfies what is in the Page Author guidelines.

Step 3: The tools and authors observe the technicalities and miss
the natural-language side of the issue.  Web content is technically
flawless, but systematically useless unless browsed without 
disabilities or adaptive user interfaces.

Step 4: The battle to secure effective web communication for 
people with disabilities moves to lawsuits in the courts.


3. Recommendation for implementation.

Page Author Guidelines:

Abstract sets the context: the mission is effective communication,
the obstacle is user interface diversity, the solution is universal
design.  This document explains the technical side, but success
requires both planning and testing (see para XXX).  Further help
is on the way as the User Agent and Authoring Tool guidelines gain
acceptance.

Guidelines dealing with "use the structuring features of HTML"
i.e. headers, lists, etc. mention that it is particularly
important that these structuring parts be clear and well written.
Similarly (as is already done) for link text.


EO group:

Present the technical provisions of the Page Authoring Guidelines
as mechanisms for reaching the broadest possible audience.  The
legal mandate in the U.S., for example, is for effective
communcation.  Don't overlook the natural language tools of
effective communication when you address the special needs of
people with disabilities.  The author is better off putting their
energies first into the areas that make the web content clearer
and more effective for everyone, and second into special features.
And, surprise!  The user with disability is better off that way,
too.

AU group:

The task is "how can tools help authors compose web content which
retains its effectiveness under diverse UI conditions," not "how
can tools enforce the technical provisions of the Page Author
Guidelines."  The tool builder has an opportunity to do more than
the Page Author Guidelines have the capability to specify.  We
should be going for the full potential of the tools.  And and we
should be capitalizing on the ability of problems encountered by
people with disabilities to point out soft spots in our content
creation techniques that affect message effectiveness for the
general audience.
Received on Sunday, 25 October 1998 11:37:21 GMT

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