Re: Deploying (accessible) XForms today?

Victor Engmark wrote:

 > 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.

A very good point. But I fail to see how the issue of scannability is
only related to Ajax-based XForms. It is IMO also an issue for
client-side XForms. In either case, you can dynamically update regions
of a HTML page with repeats, switches, but also using relevance.

Sure, if the XForms semantics is available to the client, it may help
an accessibility tool, but I don't see any difference between saying,
through XForms relevance, that a control or an area of a page become
invisible, and doing the same with a dynamic HTML DOM update changing
a CSS "visibility: hidden" property. If I was a screen reader
implementor, both scenarios would seem equally easy or equally
hard to handle.

Also, and this is an important point, if you do not go the way of
incremental page updates (through client-side XForms or Ajax), you may
end up doing complete page reloads anyway to present new data. The
argument that you need to rescan an entire page has to be put in this
context. Many web applications (pre-Ajax at least) will simply reload
a page entirely when, for example, adding a row to a table. This is
just to say that "pure HTML without script" does not guarantee good
accessibility either from the perspective of accessibility. On the
contrary, I would argue that XForms and Ajax both have the potential
to improve accessibility.

 > 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.

This is incorrect. In Ajax applications, Javascript typically ends up
updating the HTML DOM. This means that Javascript can produce, and
actually produces the exact same constructs you have in static HTML,
including using accessible markup.

The above regards many uses of Javascript done in Ajax-based XForms
implementations, in particular, on top of my head, handling repeat,
displaying alerts, handling switch, handling relevance. All of those
can be performed just by updating an HTML DOM and, therefore, not making
any difference whatsoever, in theory at least, with producing that
same HTML statically.

 > 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.

Now for Javascript-based widgets, I agree: accessibility is likely to
be diminished. But note that with XForms, the only place where this
would be an issue would be in the exact case you mention:
xforms:range, AKA sliders. Server-side implementations using widgets
should provide an rendering option that uses more accessible constructs
instead of Javascript-based widgets whenever possible.

-Erik

-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/

Received on Wednesday, 10 May 2006 18:06:05 UTC