IBM comments to the November 19, 2004 Public Draft of WCAG 2.0 Scripting Techniques

IBM comments to the November 19, 2004 Public Draft of WCAG 2.0 Client-Side 
Scripting Techniques

1.1     Form URI?s
In the 2 deprecated examples, recommend a better explanation of  why these 
examples will not work. 
Perhaps the text ?Setting the action attribute in a form to a JavaScript: 
URI causes non-script-capable browsers to fail silently.? needs to be 
better explained. Is it the developers responsibility to account for 
browsers that have scripting disabled? I do understand the purpose of not 
using the Javascript:URI?s?

1.2      Images as submit buttons
Again, suggest that we do a better job of explaining why we cant use 
images as submit buttons. The text says, ?A submit button is a submit 
button, and an image is an image. There is no need to mix the two. 
However, it is very common to see the following code, which leaves users 
of screen readers and people who can't use a mouse completely unable to 
submit their form:?   This text doesn?t explain why someone without a 
mouse can?t submit their forms. Need to explain that they won?t be able to 
receive focus on the image. 

2.1 Javascript:URI?s
Text says ?Avoid Javascript:URI?s.? To be consistent the language in 
section 1.1, we should say ?Avoid Javascript:URI?s in links?.
In the editorial note, its mentioned that JavaScript is assumed to exist 
in the client. In that case, would Form URI?s (1.1) be acceptable?

2.2 Dynamic content generation
Suggest adding a technique surrounding placement of the dynamic text on 
the page. For example, the content should appear after the current cursor 
location, so it is read by screen readers without having to read all the 
way to the top. 
Suggest changing focus to the new content ? (see comments for Section 2.3 
also)

2.3 Changing focus
A good example to use for this would be an online loan calculator. After a 
user fills in a rate, loan amount, and term, they click on a ?calculate my 
monthly payment? button which launches a new page. The focus is then set 
to this new page. In that example, I would think it is ok to change the 
focus, since it is intuitive. Or alternatively, you can just inform the 
user that pressing ?calculate? button will take them to a new window. I 
think more guidance is needed, rather than just saying ?Avoid changing 
focus on the user.? There have to be other instances where it is 
acceptable and even preferable to change the users focus. 

General Comments 
We should address the scripting turned off issue more completely. Are 
users required to code for this scenario if they want to be compliant?