Re: Deploying (accessible) XForms today?

Hi Stefano,

Eric did not say that XForms didn't have the design goal of less 
scripting.
He is saying that the design goal of less scripting is less scripting for 
authors of XForms (developers).

An implementation of XForms is free to use as much javascript (and Ajax) 
as is needed to provide the semantics of XForms.
Javascript and Ajax are low-level plumbing-- assembly language for the 
web, so to speak-- whereas XForms communicates higher order constructs.

This is important because "less scripting" for authors also quite 
literally means fewer scripting *patterns* are used.

One can express an infinitude of meaning in XForms.
One can express an infinitude of meaning in javascript/ajax.

But the difference is like the difference between the infinitude of 
integers (XForms) and the infinitude of irrational numbers 
(javascript/Ajax) 
in the sense that Cantor expressed.

With javascript/AJAX, you can create arbitrary spaghetti logic, whereas 
XForms stays focused on the broader strokes of what you're doing. 
So, when an XForm is "compiled" into javascript/Ajax by a server-side 
XForms implementation, it isn't any arbitrary javascript/AJAX, but
rather specific code that achieves the higher order intent.  In other 
words, the translation from XForms to javascript/Ajax is not surjective
because the vast bulk of spaghetti scripting patterns have no XForms 
equivalent.

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Stefano Debenedetti <ste@demaledetti.net> 
Sent by: www-forms-request@w3.org
05/05/2006 12:37 PM

To
Erik Bruchez <ebruchez@orbeon.com>
cc
www-forms@w3.org
Subject
Re: Deploying (accessible) XForms today?







Erik Bruchez ha scritto:
> 
> Stefano Debenedetti wrote:
> 
>> Very good question, I was wondering why wouldn't this come up
>> considering that one of the main goals of XForms was to improve
>> accessibility, in particular by introducing new markup that was
>> reducing the need for clients to deal with HTML+JS hacks and quirks.
> 
> I think the most important part here is that *developers* don't have
> to deal with HTML+JS hacks. Certainly, I don't care that my browser
> has to deal with a C library or graphics API to render a page when I
> write HTML. In the same way, an XForms author doesn't have to deal
> with Javascript as much (if at all). It doesn't matter much in the end
> that the implementation is using Javascript or not.

Well, yes and no. End-users are also exposed to a technology in many ways, 
especially on the web, where the view-source feature always played a very 
important role. 

I think people who have been experiencing (not necessarily being aware of 
them) javascript errors while browsing the web in the past years are more 
than (or at least nearly as many as) people who haven't and that this was 
one of the main issues that drove XForms design: make it easier for 
developers so users would get a better experience, namely by reducing the 
amount of HTML+JS crazyiness around for doing even simplemost stuff.

It's hard to argue that this is not a design goal of XForms given that it 
is mentioned in the spec, see:

http://www.w3.org/TR/xforms/slice2.html

"Less use of scripting

    By defining XML-based declarative event handlers that cover common use 
cases, the majority of XForms documents can be statically analyzed, 
reducing the need for imperative scripts for event handlers."

It's hard to argue that server-side implementations aren't taking this 
power away from the hands of the users (and authors) and confining it to 
the hands of the server-side developers and system administrators.

It's still very hard but probably easier to work so that one's server-side 
implementation does not make the problem worse by at least acknowledging 
the problem exists.
 
>>> /me steps aside and hopes for some good answers from the server-side
>>> crowd :)
>>
>> Considering that the interpretation commonly given to WCAG1.0-based
>> accessibility laws, at least in italy, is that you cannot provide
>> functionality via script unless same functionality is provided
>> without script too, I wonder how can server-side implementations
>> ever comply, let alone without requiring an insane number of page
>> reloads, thus completely defeating another stated goal of XForms,
>> which was also helping accessibility under another aspect.
> 
> You will have to excuse my ignorance here, but it may be useful if
> people in the know would help us implementors understand better
> accessibility questions as they relate to XForms and script. 

I do sympathize, associate and concur with your apologies and wish, I feel 
pretty much in the same way as you, given that I have worked on at least 
two fully client-side, fully scripted XForms implementations and I still 
don't know when will I be able to use them without being dubbed of 
inaccessibility by design.

>For
> example, I have to admit that we have not paid much attention to
> accessiblity with Orbeon PresentationServer, but that is mainly out of
> ignorance of the subject.

This sounds like it's very unlikely that OPS can currently be used for 
building PA websites in countries where law mandates accessibility. In my 
experience, accessibility requires a lot of work, especially where 
enforced by law, there is an industry of specialists out there.
 
> Generally, why would script prevent accessibility in any way? After
> all, with most Ajax web apps, Javascript ends up modifying an HTML
> DOM, which in the end should not be more or less accessible than
> static HTML, assuming a certain number of conventions are respected.

I fully agree! Unfortunately this doesn't seem to be the case if I am to 
trust many accessibility specialists...
 
> Requirements of national laws aside, it seems to me, and please
> correct me if this is an incorrect assumption, that an Ajax-based
> XForms implementations, which clearly targets regular HTML browsers
> like Internet Explorer, Firefox, Safari and Opera, can in theory be as
> accessible as any HTML web application.

I wish you were right. Unfortunately I don't think it's possible to set 
requirements of national laws aside any more when discussing accessibility 
since many countries adopted, misunderstood and/or extended the WCAG and 
made them mandatory for PA websites at least.

http://www.w3.org/TR/WCAG10-HTML-TECHS/#scripts

There isn't much room (if any at all) for scripted-only functionality 
there and as a consequence there isn't much either in common 
interpretation of italian law about PA websites.

The W3C is coordinating many international accessibility experts in 
developing WCAG 2, I wonder if any of them is reading this list or has any 
contact with the XForms WG, do they consider XForms a success or a failure 
in terms of accessibility?

I hope they will step up and explain to us what the roadmap is.

As I wrote in my previous mail, I am really surprised to find out that 
effectiveness of XForms with respect to accessibility  is still an 
unexplored territory as it's one of the goals stated on the spec and in my 
experience one of its main selling points too, so much for the 
relationship between what people need and what people buy, in case anybody 
was still believing there's any.
 
ciao
ste