RE: More scripting thoughts Pt. 2 (was RE: Accessible road maps)

Yes, UA's need, and have, their own guidelines.  I was referring to non
UA 'applications' in the thin client world.  To a user the end of a URI
is a 'page' regardless of what it does.  There are many examples of
applications that are served from URI's and as such fall within the WCAG
guidelines.  There is a grey line between a 'page' and a UA that is
beyond the scope of this thread but within the scope of the merits of
banning or allowing scripting I'll reiterate that we should be gearing
the guidelines to focus on _any_ technology used to create 'content' on
the web.  I've been interpreting that to mean that if it comes from a
URI and is processed by a UA then it is 'content'.  So an xml doc with
associated xsl/pi that yeilds html with script and css includes and has
client side script calling webservices that ... Is still 'content' and
must conform.

The guidelines establish experiential norms for access; whatever
technology is used to create your content the _result_ of that
technology must confrom to the guidelines.  If you author your own UA
then the UA guidelines gotcha covered.

.02
/m 

-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
Behalf Of David Woolley
Sent: Thursday, June 03, 2004 1:25 AM
To: w3c-wai-ig@w3.org
Subject: Re: More scripting thoughts Pt. 2 (was RE: Accessible road
maps)


> Which is precisely what I, and I believe Matt, are saying.  I'm seeing

> no difference between a doc or an interface that sits on a URI.  As 
> such we should be gearing toward accessibility recommendations that 
> provide guidance for both paradigms.

They need different rules.  For a start, the application is a user agent
not the document itself, but, more generally, the rules for applications
are the sorts of rules that would apply to a .NET thick client, Visual
Basic, Sun Java etc.   I can download the SETI@Home client using a
web browser, but I don't think that anyone has claimed that WCAG applies
to that.

The fundamental difference between a document and an application is that
a document makes all the information accessible to appropriate tools,
whereas an application only gives out what the application writer wants
to give out and only in the ways they chose to give it out.  Except to
the extent that you can sometimes see inside an application's code, to
embedded data, documents can be indexed by search engines, but an
application as the only access to a document does not support search
engines.

The confusion between documents and applications is partly because
authors assume that they will be directly interacting with a human (and
normally assume that they will be doing so on a high resolution raster
graphics device), whereas the benefit of something like HTML is that it
can pre-processed by a machine.

Note.  My impression is that Microsoft's main current interest with web
browsers as application platforms is for intranets, where there is some
control over the user agents used.  Even then, one of the main reasons
for businesses using client side scripts, rather than VB is that it
makes deployment of the code easy (most users don't realise that they
are having a program library effectively installed when a .js file is
linked into a page).  One of the primary reasons that deployment has
been a problem in the past is that two  PCs rarely have the same
configuration.  (Microsoft are clearly aware of that from the ways in
which they promote .NET as a partial solution.)

In an intranet environment, some accessibilty rules can be relaxed,
because you know your current user base, although you still need to be
able to adapt to changes in that user base.

My impression is that many businesses use "web browsers" mainly as a GUI
library that comes pre-installed, and which students have self trained
on, rather than as a document viewer.  HTML is actually a poor platform
for this, but it had the advantage that initial mockups could be done
simply and the programming department could be left with the problems of
making it work in the fully fledged form, after the user interfaces had
been agreed.  For most purposes, businesses using it in that way treat
the actual, branded, browser product as providing the platform, not an
abstract specification.

Most intranet web applications I've seen attempt to acheive a fixed
layout, so lose most of the accessibilty advantages that might have
resulted from
using HTML over VB or .NET.   They fall to pieces if people try to
override
font sizes.

Received on Thursday, 3 June 2004 14:33:22 UTC