Re: Deploying (accessible) XForms today?

  Stefano Debenedetti wrote:

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

Your XForms engine follows a certain processing model. At a certain
point, a Model Item Property (MIP) will change and be evaluated. Upon
XForms refresh, the XForms engine will be in charge of reflecting the
change of the MIP in the model to a change in the visible user
interface controls. Some code, somewhere, will translate this
declarative MIP into a piece of code saying "please, hide this stuff
on screen".

This is exactly the same that will happen with the HTML DOM and CSS
properties when a piece of Javascript code says "please, hide this
stuff on screen".

If I was to implement a smart (i.e. integrated with a browser,
XForms-enabled or not) screen reader, I would probably use the hooks
that IE and Firefox doubtless provide in their DOM to detect such
visibility changes. Whether the XForms engine tells me "hide this
stuff" or whether I have to detect a CSS property change doesn't seem
to make much of a difference.

I think the above supports the opinion that "declarative" and
"script-less" are primarily important for the developer, but not so
much at the implementation level.

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

This is not an issue if you don't look at the world with the ideas
that "scripting is evil" and therefore "XForms cannot be said to do
scripting or we are in big trouble" ;-)

We know that XForms has great features for the developer. It not only
formalizes, using declarative markup, some user interface patterns
that are often done with Javascript, but it also provides us with a
declarative event and actions system, an XML-based data model, a
powerful submission mechanism; etc.

But here is where Ian Hickson is right: at some point, you will write
something like this:

<xf:action ev:event="xforms-value-changed">
   <xf:setvalue ref="my/node/a">Hello</xf:setvalue>
   <xf:send submission="my-submission"/>
   <xf:setvalue ref="my/node/b" value="instance('some-instance')/node-b"/>
   <xf:toggle case="ok-case"/>
</xf:action>

The above clearly *is* scripting. It doesn't use Javascript as far as
the developer is concerned, and it uses a level of semantics above
what you usually do with Javascript, but it's imperative scripting
nonetheless: it gives the XForms engine instructions that must be
executed in a sequential order.

Now I for one don't see anything wrong with that. The set of actions
provided by XForms is simple, well thought-out, and the small number
of them actually allows you to accomplish, by combination, an amazing
number of tasks. Instead of learning hundreds or thousands of
Javascript APIs (without talking about the language itself), you get
by in a very large number of cases just with those few actions that
XForms defines.

This just shows that XForms is not just about declarative
vs. imperative: it's also about ease of use for developers, and about
removing the temptation to use confusing Javascript.

It also shows that the declarative vs. imperative debate is not
necessarily a key to discuss XForms accessibility.

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

But in the end, there is one main thing that matters: the user
interface changes, and that's done through DOM updates. Hook-up your
screen reader at that level.

Best,

-Erik

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

Received on Wednesday, 10 May 2006 20:41:03 UTC