W3C home > Mailing lists > Public > www-forms@w3.org > May 2006

Re: Deploying (accessible) XForms today?

From: Victor Engmark <victor.engmark@cern.ch>
Date: Wed, 10 May 2006 16:25:09 +0200
To: www-forms@w3.org
Message-ID: <20060510142509.GC24853@imap.cern.ch>

Stefano Debenedetti:
> Ulrich Nicolas Lissť ha scritto:
> > 
> > Allan,

> > So, to sum up: I don't think accessibility gets lost just by using
> > server-side technology. Though AJAX scripting makes it a bit harder to
> > build accessible web applications, it's not getting impossible just by
> > using that technology.
> In order to detach the discussion a bit from a religious (and
> business-model driven) controversy, do you have any evidence backing
> your claim?
> I mean something one could compare with careful exams of HTML+script
> solutions as opposed to what the WCAG says, such as this one [1]?

My 2 cents (sorry for the length):

As far as I can see, there are two issues which make one easily
accessible and the other one difficult or impossible: Scannability
(viewer abilities), and semantics.

Scannability boils down to the fact that sighted users very easily
detect page changes (as long as they are within the window), and context
is obvious from looking at the surrounding text / graphics. For audio or
braille browsers it's not obvious how to handle such changes
meaningfully: Reading the whole page again would mean a huge overhead
for the users (not to mention the problems with quickly changing
content), reading just the changed part probably won't provide enough
context to make out the meaning of the change, and reading the
surrounding text may provide too much or too little information.

Visual browsers allow for a graphical view of the data, making proper
semantics of content (sections, sub-sections, navigation) essentially
unnecessary - Unless the data is very badly structured, sighted users
won't have to read all the text to get to the useful information. This
has also resulted in table layouts, <blockquote>s for indentation, and
other accessibility horrors.

Non-visual browsers depend on the semantics of the data to be able to
provide a user experience close to that of sighted users. The semantics
of (X)HTML is clearly defined - <address> and <li> have specified
meanings, which should be respected. JavaScript doesn't have anything
like this (AFAIK), and I don't think it's possible to create such a
thing; there are infinite semantic possibilities.

For example, consider a JS slider which changes the background color -
It doesn't have any semantic meaning to a blind user. Then consider the
same slider used to provide a seed number to a sentence generator. It
definitely has a semantic meaning, but how could you provide that
meaning to the browser and user? Also consider that the same result could
be implemented in an infinite amount of ways with JS; if you were able
to extract useful semantic meaning from any piece of code, you'd be the
Einstein of computer science.


Victor Engmark
"a wealth of information creates a poverty of attention" - Herbert Simon
Received on Wednesday, 10 May 2006 14:25:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:17 UTC