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

Received on Friday, 5 May 2006 22:28:37 UTC