Re: Deploying (accessible) XForms today?

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

This is your interpretation of the spec. This is not what the spec says.

Other points of the design goals are more clear in specifying who is expected to benefit from them, this one was intentionally left generic in my opinion.

There is no way to confirm that the spec is saying this for authors only because it ain't saying so.

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

I didn't say that the XForms spec is prohibiting script. I did say limiting script was one of its stated goals though. Or is the spec not meaning to say "less scripting" as it does?

I just argued on top of it that common interpretation of WCAG is limiting use of script a lot, going very close to prohibiting it.
 
>> 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

Aaaaaaah so you do agree 100% with what I am saying!

Then what are we discussing here? For the sake of marketing? I thought the W3C had been created for the purpose of making it at least hard for marketing departments to take value away from the web [1] but if geeks pass on the other side then all hope is lost.

> WCAG 2.0 does not seem to persist  (as of not that long ago anyway).

Clearly yours is not strong enough of a statement by the W3C to make people go against their national laws, is it?

My original questions were exactly about this. While we hope and wait for a more realistic set of WCAG, what is the status of screenreaders WRT XForms? What is the status of real-world, effectiveness-based tools like Bobby, Leigh Klotz added?

As leigh Klots put it: "Success in this area is a legal pre-requesite for adoption into many products, and it is critically
important XForms gets these implementations made available."

If those pieces of the puzzle were there we could already have accessibility experts happily supporting XForms even today.

And server-side implementors could happily go on playing the wild HTML+JS crazyness game as long as they were able of sending pure XForms to clients requiring them. After this discussion it seems clear that they do not want to do so because they have built a business model of adding value to XForms, exactly because they were subtracting value to it under other aspects.

Otherwise why would they go as far as trying to make people believe that the spec says something it simply doesn't say?

Why would they ignore that the topic of the thread is accessibility and focus on polarizing with what I say even when I say I do agree with their generic arguments in favor of a more agreed upon accessibility?

I'm not against server-side implementations, I am just trying to explain to them they would build better value if they played the XForms game all over the camp: instead of fearing that client-side implementations would take away money from them, they should support them and add value by transforming XForms into other XForms, not into something we all recognized as broken, at least as far as development and authoring theory goes. Implementations that are both fully server-side and fully client-side are obviously building better value than the ones that aren't, or what?

They are of course free not to understand this but they are not making me believe the spec says what it doesn't say.
 
> This is good for XForms processors that do their business by way of
> script in the browser.

I fully agree and wish what you foresee was already true.

Doing business by way of script (or declarative transformations, for that matter) on the browser means that control is on the user side. This is not the same thing as keeping control on the server-side, it's nonsense or biased to claim this is irrelevant.

I remember people surprised at finding out XML+CSS on the browser had been possible for so long without them knowing about it and I remember people arguing it was because content providers were afraid too many user-controlled transformations would break their business model. 

Semantic web is still considered to be "the future" even if technology has been around for a while now, are we sure this has nothing to do with what we are discussing here?

What does accessibility mean in broader terms? Does it mean users are more in control of their web experience or does it mean that users are better off when someone does a one-size-fits-all or even worse a one-to-one decision about what they should get?
 
> 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.

I didn't make that sweeping statement. I just said accessibility experts are very often making it on the basis of laws spawned by WCAG 1.

On the other hand, I have heard many times the argument that if the users were receiving declarative markup instead of a bunch of HTMLForms+script they would have been more in control of what was going on with their browsers and with their browsing experience in general. 

Regardless of what your interpretation of the spec design goals is, I full agree with all of your arguments pro-declarativeness because they go in the direction of proving that this control is lost for the user when they receive HTML+script generated for the server-side implementation benefit, not theirs.
 
>> 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.

Yes, you assumed I was saying Erik was wrong while I had gone to great lengths in trying not to polarize and in sympathizing with his general remarks, even if I was disagreeing on the specific point you are ambiguously defending too.

We all agree here that declarative is higher-level and imperative is lower-level, I only don't understand why would one argue that if declarativeness is lost for the user then it's just as good as if it was not. Only likely reason must be a broken business model and/or understanding.
 
>> 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.

You totally missed my argument here. Again: I totally agree XForms is making it easier for authors.

I only argue that while server-side implementations reintroduce the HTML+JS wild imperativeness and send it to the users, it only takes a slightly different or differently configured JS implementation for the users to get totally stuck with no clue (as they most likely will never get access to the nicely declarative XForms definition) other than examining the totally arbitrary imperative code they got and figuring out if it is wrong or of it is their JS configuration or if it is a bug in the JS implementation of the browser they are using or if it is a mismatch between the JS code and the HTML markup or the instance data and the only way to do this is by learning at least DOM, which we know it's not even near to what the spec says in all browsers.

Users don't even have no guarrantee XML will ever get sent to them. They are doomed to tag-soup.

I argue that this has happened a lot in the past before XForms and that this is going to happen again with server-side implementations and that this was exactly one of the things XForms promised to get rid of: tag-soup powered imperative crazyness running on users browsers for doing no matter what, mandating that the user becomes an imperative programmer with cross-platform zen-like knowledge if they want to understand what's going on. 
 
> 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!

See: it only takes that js is disabled to ruin the party. FYI testing things with disabled js is one of accessibility gurus mantras.

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

Consider yourself lucky I'm not cooking ;-)

ciao
ste

[1] http://www.cafeconleche.org/quotes2002.html#quote2002July9


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

Received on Saturday, 6 May 2006 11:21:40 UTC