Re: "intro"

At 08:32 AM 9/7/2000 , Al Gilman wrote:
>1.  You have made a reasonable case that there is a problem.  Do you have a
>rough estimate of a solution?  What audience(s) do you think the WCAG we
>are developing should target, i.e. should serve or should focus on?

Good question, sometimes it's important to call me on specifics
or else I just prattle on. :)

My concern is the following, as expressed in email sent by the
WCAG co-chair on August 19:

>One of the most difficult aspects of our current work can be described as
>follows.
>
>The guidelines are heavily constrained and must meet many requirements
>simultaneously:
>- some content developers want immediate, practical and verifiable
>requirements relative to today's technologies;
>- others want to be able to apply the guidelines to emerging standards;
>- technology designers want from them a set of criteria to provide guidance
>as to what "accessible" design requires in the creation of new formats,
>protocols etc.;
>- policy advocates, likewise, want a definition of, and criteria for,
>accessibility;
>- and the W3C process imposes a fundamental demand for stability in the
>document that is supposed to become a W3C Recommendation.
>- Add to this the blurring of the distinction between the content developer
>and the language designer which results from the "extensibility" of most of
>the newer W3C formats, combined with the emergence of XML as the predominant
>markup language,

I feel that with these constraints and requirements, it will be
-impossible- to meet these goals with a single or even two 
documents.  I think that too much is required, to the point that
no one core document (or one core document plus a derivative
techniques document) can exist which meets the goals above, in any
way that's accessible.

I've spoken to people at <some big company, involved with WAI and
W3C activities>, who said flat-out that WCAG 1.0 was too "everything
for all audiences" to be useful within their company, so they had
to basically start from scratch (from the same source material as
WCAG) and make their own guidelines for internal use.

My practical solution is to prioritize as follows:

>- some content developers want immediate, practical and verifiable
>requirements relative to today's technologies;

This should be considered a core audience and goal.

>- policy advocates, likewise, want a definition of, and criteria for,
>accessibility;

This should be considered a core audience and goal, with the caveat
that we are defining _accessibility of web content_.  I believe that
a generic document describing accessibility itself -- a "principles"
or "concept" document -- should be created by the W3C which covers
not only WCAG but ATAG, UAAG, ERT, and others.  _Defining accessibility
itself_ is too large a project for _this working group_ if we are
also tasked with creating a WCAG document, which I believe we are.

>- others want to be able to apply the guidelines to emerging standards;
>- technology designers want from them a set of criteria to provide guidance
>as to what "accessible" design requires in the creation of new formats,
>protocols etc.;
>- Add to this the blurring of the distinction between the content developer
>and the language designer which results from the "extensibility" of most of
>the newer W3C formats, combined with the emergence of XML as the predominant
>markup language,

I think that XML accessibility is going to be fundamentally different
from application accessibility (such as the application of XML as
XHTML or SVG), because it is going to be one meta-level up and is
going to be a different conceptual audience, working on an entirely
different level.  I feel that meta-accessibility _is_ important but
may be best addressed by either a second core document from this
group, or by another working group entirely.

The issues related to meta-accessibility are -not- well understood,
and are -still- items up for debate in the Protocols and Formats
working group.  I don't feel that the WCAG working group is equipped
to deal with these issues at this time, without drawing the process
out further and making it near impossible to complete the task of
generating a new WCAG version.  By tying this issue too closely
with the issue of HTML/XHTML/CSS/SVG/SMIL accessibility, we will
produce a workload that will be too difficult to meet in a timely
manner with far too many factors in the mix.

>- and the W3C process imposes a fundamental demand for stability in the
>document that is supposed to become a W3C Recommendation.

If the W3C process is truly a hindrance to our activities (and I
do -not- feel that it needs to be), then we should address our
concerns to the W3C advisory committee, staff, and director, and
see if we can get this changed.  The purpose of the W3C process is
to facilitate and organize the process of creating standards in a
responsible manner, not prevent us from accomplishing that task.

However, in my opinion, the W3C process requirements have been
overstated in discussions on this topic.

Summary:  I think the WCAG document should concentrate on the _WC_
itself -- on web content, on accessibility specifically of "languages
which someone sets down in front of you, the designer" not of
"languages which you the designer choose to create."  The latter is
a valid and good topic, but I think it is a topic for another day,
another group, and another audience.


-- 
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/
Vote for Liz for N. Am. ICANN Nominee!        http://www.khyri.com/icann/

Received on Thursday, 7 September 2000 12:10:38 UTC