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 19:37:26 UTC