W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

Re: Fwd: Re: [TECHS] Sample Scripting Techniques with baseline information (fwd)

From: Isofarro <lists@isofarro.uklinux.net>
Date: Mon, 20 Jun 2005 21:05:38 +0100
Message-ID: <42B72192.3050502@isofarro.uklinux.net>
To: Joe Clark <joeclark@joeclark.org>
CC: WAI-GL <w3c-wai-gl@w3.org>

Joe Clark wrote:
> I ran this posting--
> <http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0767.html>
> -- by Peter-Paul Koch <http://Quirksmode.org/>, who, along with Jeremy 
> Keith <http://adactio.com/>, is a leading proponent of responsible 
> JavaScript usage. He writes:

Great idea!

>> Example 1:
>> - JavaScript and CSS available and enabled
>>> "With JavaScript, the onchange event can be used on each individual 
>>> from control to validate the data as it is entered or changed.  A 
>>> JavaScript alert can notify the user of the error.  CSS can be used 
>>> to style the label for the input field to indicate the field in 
>>> error. See the code example below. "
>> Bad practice! Sure, this can be done, but it's better to
>> a) check the form onsubmit, because the user wouldn't like to get all 
>> sorts of alerts while he busy filling out a form

This is simpler to implement, although I'm not sure how usable alert 
boxes are for non-visual users. I'd guess some of the practical problems 
would be similar to pop-up windows, except these alert boxes are modal. 
Are there any known user-related accessibility problems regarding alert 

>> b) not use alerts; it's far more user friendly to write the error 
>> messages next to the form fields 
>> (http://www.quirksmode.org/dom/error.html)

User-friendly, yes. Visually its good. Its probably is going to be quite 
difficult for a screen reader user to realise there's an error on the 
page. The focus switches back to the first field in error, its only 
after going past that field (in non-forms mode) that the error message 
will be read out. (Just ran this through JAWS5.1, forms mode skips the 
error message)

If we could link the actual error message to the field, this example can 
be made accessible. How best to do that? Two ideas come to mind:

1.) Dynamically add a title attribute to the input field in error, 
providing the same error message. Is the title attribute on an input 
element going to be picked up by a screen reader while in forms mode?
2.) Using the label element for the error message and setting the for 
attribute to the input field id. What happens when a screen reader has 
two labels for one form element, will both be read out?

I've got two similar ideas involving internal anchors which could make 
PPK's concept more accessible - if anyone is interested, I'd be happy to 
flesh out a testpage for a decent accessibility test.

If we can sort out the accessibility aspects here, I'm also happy to 
take that back to PPK and improve his method in terms of accessibility.

Received on Monday, 20 June 2005 20:06:56 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:07:40 UTC