W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2004

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

From: David Woolley <david@djwhome.demon.co.uk>
Date: Thu, 3 Jun 2004 09:24:48 +0100 (BST)
Message-Id: <200406030824.i538On601250@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org

> 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 06:17:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:32 UTC