[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interesting coverage of our project on the SQL-Ledger-users list



On Tue, 17 Jun 2008, Chris Travers wrote:

> On Tue, Jun 17, 2008 at 11:32 AM, Luke <..hidden..> wrote:
> > On Tue, 17 Jun 2008, Chris Travers wrote:
> >
> >> see non-JS usability as a requirement for being able to reasonably do
> >> accessibility QA.
> >
> > Agreed, mostly, but given what I proposed a few days ago as the JS
> > implementation for this, where do you see the accessibility effects?  It
> > changes the UI not in the slightest.
> 
> Actually, the simple JS fixes do change the UI.  Remember that the
> textual labels rather than the submission values are entered, so you
> either have to change the button.innerText (and thus change the UI) or
> you have to build a parallel form and submit that.

Limited JS knowledge alert...

I was thinking of a function, which swaps the innertext and the value of a 
given button.

It would be called when the button is clicked only.

For that matter, if the form is being submitted, it may be easier to have 
a function which when called, upon click of a given button, adds a hidden 
input element to the form, containing the necessary data for the button, 
with the proper name, and does not actually pass the button back to the 
server at all.

This is assuming that JS can delete elements prior to form submission.

Disappear the button from the post stream, and substitute it with (1) 
another button which the user never sees, but which submits the proper 
content; or (2) a <input type="hidden" name="submitbutton" value="save"> 
sort of form field, replacing the buttons entirely.

The same solution would cause IE6 to work as well, if JS can have that 
level of control over form submissions via the onclick instruction.

Regards,

Luke