Re: XForms Myths Exposed - By Ian Hixie (Opera)

Right enough, I guess there is an issue with the accessibility of IT as 
a discipline, as opposed to the accessibility of what we are creating: 
the more accessible the fruits of a our labour, the cleverer the person 
has to be to create it.

Mind you, it's maybe not all as bad you make out, maybe we just need a 
good WYSIWG XForms tool for the masses. I would argue that scripting is 
more arbitrary in nature, whereas XForms is more capable of being 
accessible. It can't be as cut and dried as saying that any script can 
be accessible so we don't really need XForms.

I still don't get how script helps with accessibility, ok maybe you can 
build an html form were accessibility is not hindered, but is it helped? 
Scripting by its very nature is arbitrary, whereas XForms is using 
markup to convey some additional meaning to the user that scripting 
can't do.

There's ubiquitous nature of dreamweaver rollovers or javascript 
repositories for doing this and doing that. A lot of the people that use 
scripts can't write any javascript even. This could be the case for 
XForms too, a nice tool or sample form to drop into your site. This time 
the form is more accessible but achieves the same objectives. I take 
your point that accessibility may suffer, but will it not be better? At 
least XForms can be validated, so these errors (or inaccessiblities) can 
be ironed out.

As for using tables for layout, I think that so long as there is 
linearity then accessibility is not affected. I don't think there is an 
accessible convention for using scripting, other than to minimise its 
implications and plan as if the script can't be invoked by the user agent.

Andy



Ian Hickson wrote:
> On Fri, 11 Mar 2005, Andy Harrison wrote:
> 
>>"Scripting is bad for accessibility. False."
>>
>>I'm not so sure that was a correction. I thought it to be a bit of an 
>>outburst to be honest. Don't get me wrong, I'm learning to use XForms 
>>myself right now, so I don't have strong opinions either way, but it 
>>strikes me that there is a definite progression in terms of 
>>accessibility with XForms vs HTML and I was quite surprised at your 
>>remark.
> 
> 
> The progression, IMHO, is really between the generally high skill set of 
> your average XForms author and the comparatively low skill set of your 
> average HTML author. It is quite possible to write highly accessible HTML 
> (even if it uses scripting) and quite possible to write highly 
> _in_accessible XForms. In both cases, the author is violating either best 
> practice guidelines or actual rules of the language.
>  
> HTML is a media-independent, device-neutral semantic markup language at 
> its core. Most accessibility problems with HTML pages come from people 
> abusing APIs that aren't even standardised (such as .innerHTML) or using 
> standard APIs in illegal ways (for example, using document.write() on 
> documents that were not created via document.open()).
> 
> The reason, IMHO, that most XForms now is better in terms of accessibility 
> is simply that the authors writing it are learning how to do it right. If 
> XForms reaches a critical mass where authors from the "copy paste" line of 
> work become prevalent, then accessibility will suffer as it did with HTML.
> 
> (Take the recent XForms calculator as an example. It uses tables for 
> layout, a highly inaccessible way of presenting an interface.)
>

Received on Friday, 11 March 2005 17:22:21 UTC