Re: Deploying (accessible) XForms today?

Erik Bruchez ha scritto:
> 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.

It's not the same thing, XForms relevance is a declarative (i.e. much more easily statically analyzed) way to have stuff disappear from your page, while a "dynamic HTML DOM update changing a CSS property" is by definition something that requires a dynamic engine noticing that stuff may be subject to disappearing no earlier than at run-time.

I might be wrong or inaccurate here but I think this is the reason why you are not allowed to have an XForms edit itself by setvalueing stuff freely in its own host document but you can setvalue stuff only in instances, which are treated as separate docs even when they are embedded in the form doc. 

Why would the debate about attribute value templates ever happen otherwise? Why not allowing folks to inject random vaues at random places in the form host document?

I might be wrong or inaccurate here but I think this is why Hixie once said XForms is just one step away from being yet another scriping engine (can't find a link to that right now sorry) instead of saying XForms is yet another scripting engine.

Luckily steps missing still are more than one.
 
> 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.

Yup, this is exactly the concern I tried to express in the mail you replied to earlier in this thread. There must be some level of scripted-only functionality considered accessible or server-side XForms implementations wouldn't get W3C blessing very easily. 

It is still unclear to me if WCAG 1 did allow that already or if we need to wait until new Recommendations obsolete them and national laws get updated, perhaps I should have added this to my original questions and made the second one there dependant on this one here but the lack of an authoritative position from the WAI in this thread makes me think it was not too incorrect to frame the debate as I originally did.

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

Nope, Victor is correct here, as John Boyer very clearly put earlier in this thread: even if you can express an infinitude of meanings both in XForms and in JS/AJAX, it's like the difference between infinitude of integers and infinitude of irrational numbers, intuitively, which one makes you work less and gives you the more guarrantees of predictability of your implementation?

I was the one who was wrong when I replied everybody had gotten that by now, so here's my take at it, admittedly much less well put than how he and Victor explained it but who knows, it might work better:

as stated everywhere from the XForms design goals to all over this and many other threads about XForms vs. script, it's supposed to be much easier for implementors (be them of screen readers or of visual browsers) and for everybody else too (authors, users) to deal with statically declared markup (be it HTML or XForms) rather than with dynamically, imperatively and much more arbitrarily generated stuff, which could be directly DOM nodes but that could well be other script tags then generating other DOM nodes and so on recursively, for example.
 
>> 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.

This is totally unrelated to the static-declarative vs. dynamic-imperative issue. Anyway, agreed that not only range controls but all XForms controls (repeats for example) that have no direct equivalent in HTML require some extra special care when implemented as HTML+script widgets.
 
ciao
ste

> -Erik
>

Received on Wednesday, 10 May 2006 20:06:06 UTC