Re: [w3c-wai-gl] <none>

----- Original Message -----
From: "Gregg Vanderheiden" <gv@trace.wisc.edu>
> How do we handle writing guidelines so that pages that are written today
> will be accessible with the browsers available today without creating
> rules that perpetuate restrictions that will not be needed in the
> future?
[...]
> C) Write the guidelines to work in the near future.  Bearing in mind
> that the guidelines are renewed every year or two, separate those
> technologies which are likely to be supported by AT in the short run
> (one or two years) from those that are not likely to be supported for
> two or more years.  Then, write the guidelines to assume that the
> technologies that will soon be available are legal to assume when
> writing your web pages.  Those that are not likely to be available soon
> would not be mentioned as "potential future solutions," since it isn't
> likely to be true for the life of the document.
[...]
> The last approach has the advantage of being straightforward,
> unambiguous and not requiring that people look up data in a second
> document.  It also doesn't require maintenance of a second document.  It
> has the disadvantage, however, that at least initially it allows
> techniques to be used on web pages that would not yet be supported by
> assistive technologies.

I believe this approach is the most reasonable. I think we're going to
experience diminishing returns both with carrying the baggage of old
technologies around, and holding back on newer ones, nearly all of which
hold the promise of better accessibility.


(Part One: The Socratic Method, or Zen and the Art of Consensus-Seeking)

With new technologies, if it is technically feasible to design accessible
Brand New XML Language (or BNXL) documents, even before a user agent or
assistive technology supports BNXL, can BNXL be called accessible? According
to XMLGL, the answer is yes.

Here, we have a Zen tree-falling-in-the-forest question to ask ourselves: If
the language is accessible, but there are no user agents that support it, is
content written in the language accessible? My answer here is also yes,
provided the same functionality couldn't be achieved in a more
widely-supported language. In the case of XML-based grammars, that content
may be transformed with XSLT. I'm not prepared to answer who would be
responsible for doing that transformation, so this is left as an exercise to
the reader.

(Part Two: JavaScript and its Legacy, or Where Matt Goes Off on a Tangent)

This discussion also relates somewhat to browser legacies and some other
issues we've touched on in passing, such as browser baseline and support for
script. I think the following rant is an argument for the third option, but
it may just have been a chance for me to vent on JavaScript and its place in
the world. Either way, you should read it, because I wrote it instead of
doing any actual work today. <grin/>

If the guidelines are to support access in the long term, they shouldn't
burden content providers
with user-agent-specific implementation issues. In the case of current
technologies where UA implementation is a stumbling block, those being the
combination of
HTML/CSS/DOM/JavaScript, I think there should be space in the techniques to
detail how to
accommodate certain UA issues (e.g., JAWS or Netscape 4 zigs where the rest
zag, or relevant to this topic, UAs that do not support technologies which
are accessible in some other fashion), but that should be informational in
nature. (And as a plug
for the techniques format I designed, there is actually room to do just
that...)

JavaScript is a moving target. Most commonly, accessible techniques
involving JavaScript center around not around enhancing accessibility, but
in keeping JavaScript from hindering it. This has to do with preventing
JavaScript from hiding textual content from the user in the myriad ways the
language does so. Still, JavaScript has a role in modern browser development
as a rudimentary evaluator of browser capabilities, for example, which
cannot be overlooked. It can also provide good usability gains: most search
engines use it to focus on the search text input.

But at the same time, JavaScript touches so many user agents and
technologies (HTML, CSS, DOM, objects...) that any attempt to create "the
rules" for backward-compatible, cross-platform, cross-browser, accessible
JavaScript is bound to be obsolete (and incomplete) on publication. Also,
unlike the other languages and technologies we're covering, it is an actual
programming language (okay, for some value of "actual"). And like human
language, many programming languages interact poorly with concrete rules.
Perl partisans know the old adage "there's more than one way to do it," and
I believe the scripts used today are far too diverse both in purpose and
composition to allow us to state authoritatively that for all web content,
developers should or shouldn't do technique x. And, similar to my opinions
on rules for human language, I feel that if you can't do that, you can't
make it normative. Which I believe was agreed upon at the September f2f.

Developers should not need to dance around UA idiosyncrasies
in an effort to make things capital-A Accessible. It seems the division of
labor here
dictates the solution: there are dozens of UA and assistive technology
vendors, and millions of content providers. I think it stands to reason that
where the pressure should be brought to bear with respect to compliance is
with the vendors. Leaving it to the millions to learn the arcana of
implementation-specific accessibility design is a waste of time,
particularly where it dilutes the goal of adherence to published standards
(4.2).

I feel we should be telling developers what they should be doing to meet
halfway with
products that comply with ATAG/UAAG. If the vendors don't comply,
they're the ones who should fall in line. If implementation details are cast
as requirements for the future, and issues of whether or how well a user
agent supports a technology cause long-term changes in what developers need
to do, we will forever trip over land mines we've laid for ourselves.
Already we have situations where one user agent's needs are at odds with
another. This would only get worse if it were codified (again) in WCAG 2.

-
m


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Received on Monday, 24 September 2001 23:59:55 UTC