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

Mike wrote:

<blockquote>
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?
</blockquote>

These are both good ideas, but they don't work with default settings of
JAWS. (I'm not sure about Window-Eyes or HAL).

JAWS does have a user option to speak both <label> and title when
they're different.  But with the default setting, the <label> trumps the
title.

Similarly, the spec allows more than one <label for> a given form
control, but JAWS only recognizes one of them.

Again, I'm not sure how Window-Eyes or HAL or any other screen reader
would handle these.

John


"Good design is accessible design." 
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Isofarro
Sent: Monday, June 20, 2005 3:06 pm
To: Joe Clark
Cc: WAI-GL
Subject: Re: Fwd: Re: [TECHS] Sample Scripting Techniques with baseline
information (fwd)



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 
boxes?


>> 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.



Mike

Received on Monday, 20 June 2005 20:18:28 UTC