RE: 10.4 Re: Checkpoints 10.4 and 10.5

Steve,

I am baffled. I was able to reproduce the problem with JFW 3.7U. It seems to
be the missing name attribute on your example. Yours is the third edit field
in http://jimthatcher.com/forms060401.htm (I moved it to third to be sure
being first wasn't causing the problem). Unfortunately, I removed the name
attribute from case 2 in my sample, and the prompt IS spoken by JFW. If I
add a name attribute to your example, then the prompt IS spoken. I removed
tabindex from your example with no effect on the speaking.

I don't know what the problem is, but it seems to be a JFW problem since at
least two other AT's (HPR and Window-Eyes) seem to have no problem.

Jim
jim@jimthatcher.com
Accessibility Consulting
http://jimthatcher.com
512-306-0931

-----Original Message-----
From: Steven McCaffrey [mailto:SMCCAFFR@MAIL.NYSED.GOV]
Sent: Monday, June 04, 2001 8:49 AM
To: asgilman@iamdigex.net; jim@jimthatcher.com
Cc: w3c-wai-ig@w3.org
Subject: RE: 10.4 Re: Checkpoints 10.4 and 10.5


Hi Jim etal:

     My screen reader speaks the prompt in all of Jim's cases, but does not
using the snipet I gave,


 First name:

<INPUT type="text" id="firstname" tabindex="1">

Jim's input element varies from mine by more
than one factor (attribute), so we still do not know if there is a
single critical factor
we could state in a checkpoint.
We can say "Do it like this..." but how "like" is "like".
In other words, what can I safely vary and still have the prompt spoken?
The only way to determine this is to vary one factor at a time.

Steve


>>> Jim Thatcher <jim@jimthatcher.com> 06/01/01 02:48PM >>>
I tried the variations suggested so far. I am using the most recent versions
of Window-Eyes, JFW and HPR.

ALL speak the prompt in ALL the cases that have been suggested. Actually HPR
seems to have a bug and likes to spell "name" - don't know why.

One sees the value of the LABEL attribute in the last case which AL
suggested, selecting out some text from the string that precedes the input
element. I cannot explain why Stephen couldn't get JFW to speak the prompt
in case 1.

I don't understand this testing. If you use label for= these AT's will pick
it up. If you put the prompt close to the input element (left or above for
text boxes) they will pick it up.

Here's the HTML (attached for Stephen and Al). of course 1 and 2 are
identical. First name is spoken when tabbing in all cases with all AT's that
I tried.
<FORM>
<P>Case 1</P>
<P>
First Name:
<Input type="text" size="20" id="FN" name="fn">
</P>
<P>Case 2</P>
<P>
First Name: <Input type="text" size="20" id="FN" name="fn">
</P>
<P>Case 3</P>
<P>
<label for="fn">First Name:</label>
<Input type="text" size="20" id="FN" name="fn">
</P>
<P>Case 4</P>
<P>
Please enter your <Label for="FN">
First Name</Label> in the text entry field below.<BR>
<Input type="text" size="20" id="FN" name="fn">
</P>
</Form>

Jim
jim@jimthatcher.com
Accessibility Consulting
http://jimthatcher.com
512-306-0931

-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
Behalf Of Steven McCaffrey
Sent: Friday, June 01, 2001 12:57 PM
To: asgilman@iamdigex.net; jim@jimthatcher.com
Cc: w3c-wai-ig@w3.org
Subject: RE: 10.4 Re: Checkpoints 10.4 and 10.5


Hi Al:


     I used the empty label tags
just to see if JFW was reading the for attribute text.

     Thanks for the variation.  Interesting,  I hear "first name edit".
So, it seems to read only text between the label tags.
Would this be a safe conclusion?

Steve


>>> Al Gilman <asgilman@iamdigex.net> 06/01/01 01:25PM >>>
New stuff starts at AG:: below

At 11:47 AM 2001-06-01 -0400, Steven McCaffrey wrote:
>Hi Jim etal:
>
>     Could you clarify with the snipet below?
>   <LABEL for="firstname">First name: </LABEL>
>
>   <INPUT type="text" id="firstname" tabindex="1">
>
>What do you vary and what do you hold constant?
>
>1. Keep the text between the label tags, drop the label tags
>First name:
>
>   <INPUT type="text" id="firstname" tabindex="1">
>
>or
>
>2. Keep the label tags and drop the text between tags.
>   <LABEL for="firstname"></LABEL>
>
>   <INPUT type="text" id="firstname" tabindex="1">
>
>If I use 1 above and use the tab key, JFW 3.31
>skips over the First name: text
>which is still there and just says "Edit"
>so it is looking for some tag at least, although another tag besides the
label
tag might work.
>Adjacency has no effect.
>That is, I tried
>First name: <INPUT type="text" id="firstname" tabindex="1">
>JFW 3.31 still skipped over the First name: text.
>
>If I use 2 above, again I just hear "Edit"
>Now, at this point, I'm not considering complicating factors like tables
etc.
>I want to vary one component at a time to determine what causes what.
>
>Am I varying factors incorrectly?
>

AG:: You are varying things usefully.

It's not clear what the empty LABEL tag proves, but at least it acts as one
would expect.  And the negative result for the unmarked label wannabe text
is
dead on.

There is another case you could try.  Here we put more interference between
the
label and the edit field, without going to TABLE lengths:

<SPAN CLASS="example fragment">
 Please enter your
  <LABEL for="firstname">first name</LABEL>
 here:
  <INPUT type="text" id="firstname" tabindex="1">
</SPAN>

What does your setup tell you if you make that variation and tab to the edit
field?

Al

>Steve
>
>>>> thatch@attglobal.net 05/31/01 05:13PM >>>
>Hi all,
>
>The label (first name) works because it is adjacent to the text input
field,
>not because of the LABEL element. Screen readers have been picking up
>prompts like this since they were born. Label-for is only interesting when
>the actual text of the prompt is some distance from the INPUT element. That
>happens, for example, in a table of INPUT elements, and then LABEL-for is
>inadequate!
>
>I know this has gotten far off the track of the original question but I
>could no longer resist.
>
>BTW, GWMicro uses Frames correctly. They are well "named" for both screen
>readers and Lynx. If I were them, I would not have used the NOFRAME
content,
>but so be it.
>
>Jim
>jim@jimthatcher.com
>Accessibility Consulting
><http://jimthatcher.com/>http://jimthatcher.com
>512-306-0931
>
>-----Original Message-----
>From: w3c-wai-ig-request@w3.org
[<mailto:w3c-wai-ig-request@w3.org%5DOn>mailto:w3c-wai-ig-request@w3.org]On
>Behalf Of Steven McCaffrey
>Sent: Thursday, May 31, 2001 1:24 PM
>To: asgilman@iamdigex.net
>Cc: w3c-wai-ig@w3.org
>Subject: Re: 10.4 Re: Checkpoints 10.4 and 10.5
>
>
>Hello Al:
>
>     Yes, I agree completely.  My screen reader and browser are fixed, so
>this is why I emphasized that I did not want to generalize.  For my
versions
>of screen reader and browser, it appears the label in the example I gave
>works.  As for other screen readers I can't say.
>Even for other codings of the form, I can't say.  I never know what is a
>safe
>generalization.
>
>
>An examnple that doesn't work for me
>is on the wired article page from a previous message
>(JFW 3.31 IE 5.0)
>
><http://www.wired.com/news/politics/0,1283,44062,00.html>http://www.wired.
com/news/politics/0,1283,44062,00.html>
>I hear (skipping some links)
>"Slash news slash image map link" then I tab and hear
>"Edit"
>then I tab and hear
>"Combo box"
>then I tab and hear
>"Go button"
>
>If I hit enter on the Combo box to go into forms mode,
>then I hear
>"Look for combo box Wired news"
>(a pull down list)
>
>I think the "Look for" is supposed to be associated with the edit field and
>not the Combo box, right?
>This had me confused for some time.
>I'll try to find an example of what works.
>
>
>Steve
>
>
>
>
>>>> Al Gilman <asgilman@iamdigex.net> 05/31/01 12:29PM >>>
>
>
>Both good news and bad news are informative.  It would help to have
>examples of
>what works and also of what doesn't work.  You and David seem to believe
>that
>we still need explanatory text, or at least some text, in the edit boxes
for
>best practice at the moment.  This is an "until user agents" provision in
>the
>WCAG.  So for objectivity and consensus, it helps to know what the actual
>user
>agents do with actual pages.
>
>To sell this to web authors as the general rule of what to do, it helps to
>have
>chapter and verse documentation explaining in what situations alternatives
>don't work.  Target page, OS, Browser, Screen reader with versions.  It
>helps.
>
>Al
>
>At 11:15 AM 2001-05-31 -0400, you wrote:
>>Hello Charles:
>>
>>     Good question.  I don't want to generalize, so let me just give an
>example that does work.  The example in section 11.2 of the
>>HTML Techniques for Web Content Accessibility Guidelines 1.0 works fine.
I
>hear
>>"First name colon edit"
>>then I hit tab and hear:
>>"Last name colon edit"
>>which is fine.
>>The snipet for the first name is:
>>
>>   <LABEL for="firstname">First name: </LABEL>
>>   <INPUT type="text" id="firstname" tabindex="1">
>>
>>Note my comments above are not about grouping form controls which is the
>main
>point of 11.2.  I am just commenting on the label element.
>>
>>
>>Steve
>>
>>
>>>>> Charles McCathieNevile <charles@w3.org> 05/31/01 09:50AM >>>
>>If they have labels (using the label element) does this improve things?
>>
>>Charles McCN
>>
>>On Thu, 31 May 2001, Steven McCaffrey wrote:
>>
>>  Hi Charles:
>>
>>
>>       I'm using JFW 3.31.  I will just hear "edit".
>>
>>  Steve
>>
>>  >>> Charles McCathieNevile <charles@w3.org> 05/31/01 08:43AM >>>
>>  Thanks Steven, Dave.
>>
>>  Can you please explain what software you're using, and what happens?
>>
>>  cheers
>>
>>  Chaals
>>
>>  On Thu, 31 May 2001, Steven McCaffrey wrote:
>>    Hello:
>>         I agree with David in that it is still an issue.  The consequence
>is
>>    that I will hear only "Edit" but will not know what type of
>information is
>requested.
>>
>>    Steve McCaffrey
>>    Information Technology Services
>>    NYSED
>>    >>> "David Poehlman" <poehlman1@home.com> 05/31/01 07:49AM >>>
>>    it is still an issue although many have solved it.  even though you
>have
>>    to rub the text out, it is best to have something telling you where to
>>    write because some renderings still confuse labels with edit boxes.
>>
>>    ----- Original Message -----
>>  ...
>>
>>    the rationale for this one was that there were assistive technology
and
>>    browser combinations that would skip over empty form controls. I am
not
>>    certain, but I believe that this is no longer an issue. I will ask the
>>    Web Content Accessibility Guidelines group to address this question as
>>    fast as possible.
>>
>>
>>
>>--
>>Charles McCathieNevile
><<http://www.w3.org/People/Charles>http://www.w3.org/People/Charles><http:
//www.w3.org/People/Charles>http://www.w3.org/People/Charles  phone:
>+61
>409 134 136
>>W3C Web Accessibility Initiative
><<http://www.w3.org/WAI>http://www.w3.org/WAI>h" is supposed to be
associated
with th<http://www.w3.org/WAI>http://www.w3.org/WAI    fax: +1 617 258 5999
>>Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
>>(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
>France)
>>
>

Received on Monday, 4 June 2001 21:53:57 UTC