Re: Deploying (accessible) XForms today?

> I agree this is what Eric said. I am not at all sure this is what the 
spec says.

When the spec says less scripting, it is talking about scripting by people 
who write XForms
versus people who write web applications without the benefit of XForms. 
The spec does 
not come out and say that it isn't talking about the implementation never 
using script because
neither XForms nor any other W3C spec ever talks about limiting 
implementations in this way.

> This is what XForms says. I am not at all sure this is what the WCAG 
say.

The needs of the accessibility community and those of the 
archival/security context have
something in common:  Because scripting can be used to bad things, they 
require that
'accessible' or 'archival' solutions have scripting turned off.  Pretty 
sure this is the kind
of thing that WCAG 1.0 says, which is bad for server-side XForms 
processors, but which
WCAG 2.0 does not seem to persist  (as of not that long ago anyway).

This is good for XForms processors that do their business by way of script 
in the browser.

XForms has a lot of constructs that help support accessibility, and script 
in support of those
constructs should not be disabled. Of course, it's very hard to tell what 
a script is really up
to, so the only thing we really know for sure is that the sweeping 
statement of script is bad
does not really solve the accessibility problem, so it's best not to make 
the sweeping statement.

> Er, but you still can create arbitrary spaghetti logic with XForms, I 
hope too.

You can create spaghetti logic with java and c++ too, but those languages 
are considered
superior to basic or assembly language because they strongly discourage 
the use of goto
and global variables in favor of higher order constructs.

> I mean: I don't understand your arguments in this discussion, I am no 
whatwg fan.

To be honest, I had a very hard time understanding why your response to 
Erik meant that
he was wrong somehow.  So I had to make some guesses about what you might 
have meant.
Sounds like some of my guesses were inaccurate.

> I don't see any guarrantee of accessibility nor of ease of analyzability 
here.

When you've got one line of code to say insert or delete a node, and that 
cause an entire row
of a repeat table to appear or disappear along with proper updates of 
subtotals, taxes, totals, etc.,
it is a far cry easier to determine what's going on and write appropriate 
accessibility messaging.
With hundreds of lines of code, form authors get it wrong, or they tinker 
with it when it gets generated
for them.  Makes it impossible to wrap a lasting design experience around 
it.

For what it's worth though, I do think that XForms would benefit from 
being able to set an accessibility
message that is more comprehensive than the 'label', which also typically 
drives visual presentation.
The issue is that sighted users have two dimensions of information 
available, so we want a way to
maintain that high-fidelity experience with a one dimensional information 
stream.  This is a capability 
you can exercise now with XFDL+XForms, and it can be deployed to today's 
web browsers using 
html+javascript+ajax-- as long as scripting is allowed to run!

Now, I'm going home for dinner... which, by the way, will be spaghetti :-)

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 03:28 PM

To
John Boyer/CanWest/IBM@IBMCA
cc
Erik Bruchez <ebruchez@orbeon.com>, www-forms@w3.org, 
www-forms-request@w3.org
Subject
Re: Deploying (accessible) XForms today?







John Boyer ha scritto:
> 
> 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).

I agree this is what Eric said. I am not at all sure this is what the spec 
says.
 
> An implementation of XForms is free to use as much javascript (and Ajax)
> as is needed to provide the semantics of XForms.

This is what XForms says. I am not at all sure this is what the WCAG say.

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

Even if some may find these analogies not very accurate just as much as I 
find them well-chosen and fascinating, few people interested in XForms 
still haven't understood the concept you are expressing here as of today, 
I hope.
 
> With javascript/AJAX, you can create arbitrary spaghetti logic, whereas
> XForms stays focused on the broader strokes of what you're doing. 

Er, but you still can create arbitrary spaghetti logic with XForms, I hope 
too.

I mean: I don't understand your arguments in this discussion, I am no 
whatwg fan.

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

I don't see any guarrantee of accessibility nor of ease of analyzability 
here.

For example it might be specific (and still arbitrary, isn't it?) code 
written by folks not caring much about accessibility, taking advantage of 
the XForms name even if they are not paying much attention to actual 
XForms design goals.

Well, nothing really new here, that's a pattern which seems to be 
returning over and over and that has historically happened on even way 
more important things than IT.

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

Cool, but I totally fail to see how can such non-surjectivity be relevant 
with respect to accessibility, just like I fail to see how your mail is 
relevant to the discussion we are having except for the fact that it 
mentioned spaghetti a couple of times ;-)

ciao
ste

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