Re: Accessible road maps

> orthogonal to disability. These things are out of our scope, and 

You are using the narrow definition of accessibility.  Several people here
(and I suspect the founders of the web - have a look at TBL's original
proposal for the web) have a broader definition of accessibility,
which means accessibilty to the whole of humanity, even if they are
constrained by finance, bandwidth, security policies, software that they
cannot control, etc.

The narrower definition tends to be easier to sell to businessmen,
as they can identify themselves and their family as potentially
becoming the people needing that accessibilty.

> techniques for WCAG 2. The end product will consist of techniques for 
> keeping JavaScript from causing accessibility problems, and producing 

I assume you mean document and browser object models, possibly using
EcmaScript.  JavaScript is, by tight definition, more or less EcmaScript
and by broad definition also adds Netscape's proprietary, and
obsolete, object model.

> how we got into the mess we're in, and our ideas on a way out. Other 

The main reason people have got into a mess is because they have been
using tools developed from HTML, an information communication language
intended for broad definition accessibility, rather than using its
contemporaries, and predecessors, designed with advertising and other
commercial requirements in mind (PDF and various animated presentation
tools), but are trying to do the job of the latter.

You mention compound documents.  In practice many internet accessed
sites[1] as a whole are one compound document, which very much goes
against the concept of the web as being made of lots of individually
addressible pages interlinked in complex ways.

Using the proper tools could tend to reduce accessibilty, as those
tools were designed to meet requirements that didn't include 
accessibilty.  However, one of the contributions of HTML has been
that those tools now do cover accessibility.  In fact, I would say that
tagged PDF provides a better compromise between commercial requirements
and accessibility, because it starts from the physical form, but then
adds fully detailed structural information, whereas the HTML/CSS route
starts from the structural form and then just hints at the physical
form.  Moreover, trying to do things in HTML for which it was not
designed, means that most "HTML" doesn't use its accessibilty features.

That tagged PDF is not used for sites is, interestingly, a broad 
definition accessibility issue.  It's done because it is assumed that
users won't all have installed the reader.  (It's also, I think, because
designers don't really understand what PDF is (as well as not understanding
what HTML is - which you can tell by the near universal use of invalid
HTML).)

> papers[3], at least all of those that I've read, say the same thing: 
> declarative code cancels out scripting, and we need declarative 
> languages to build these user interfaces we've been building all these 

Certainly some things that are currently done using object model 
manipulation should be done declaritively.  However, one of the reasons
that people use scripting is to re-instate features that were deliberately
not provided declaritively.  Possibly the most common example of this
is using scripting to force new windows - which is also the most common
reason for sites becoming inaccessible without scripting.

> We have to take this on. There is no alternative. Script is here to 
> stay, and if the WCAG document fails to recognize it, it will fail to 
> be adopted.

It's already a problem that accessibility conflicts with perceived [2]
commercial requirements and is not adopted, except when forced by
law.  That's true in a far wider area than the web.  People need the
laws because the market favours companies that don't spend money on
accessibility, so all companies have to forced to provide accessibility,
to create a level playing field.

As I'm sure that you will still want to go ahead with supporting
commercial wants, please make sure that you analyse things in terms
of the fundamental requirements, like branding, pre-selection of high
value customers, intellectual property protection, lock-in to the site,
creation of emotional and other associations that cannot be justified
by the nature of the product, etc. rather than in terms of techniques,
like popups, etc., even though people will not want the markup to make
many of these reasons explicit, so will still want to markup in terms
of techniques.

[1] I prefer "internet accessed site" to "web sites" as typical sites
do not have the characteristics that would make them web sites, namely
inward links at all levels and extensive links to many other 
web sites.

[2] However, although not based on a scientific study, it is surprising
how large a proportion of web users not in the web site industry, find
the flashy features of web sites an obstacle to use.  These are the sorts
of site that designers believe they need to create and which create the
demand for "browsers" being application program platforms, rather than
document browsers - also, there is little money in document viewers.

Received on Tuesday, 1 June 2004 02:17:41 UTC