RE: Extensive forms & tables accessibility question

I checked out Eugenia's page and found a curious phenomena...
In IE 5.5 when I put the mouse over an INPUT the tool tip does pop up but
FLASHES on and off. This was very distracting. (seems to flash at 2 times
the speed of the cursor blink, it flashes when the cursor is in an INPUT or
when no INPUT as a cursor in it).
In Netscape 4.7 nothing is displayed
In Opera 5.1 nothing is displayed.
Jim Allan, Webmaster & Statewide Technical Support Specialist
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"I see the Earth. It is so beautiful."--
first words spoken by human in space.
[Yuri Alekseevich Gagarin, from the Vostok 1, April 12, 1961.]


  -----Original Message-----
  From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On
Behalf Of Al Gilman
  Sent: Wednesday, April 25, 2001 2:58 PM
  To: w3c-wai-gl@w3.org
  Subject: RE: Extensive forms & tables accessibility question


  Contrary to what I previously thought, I now have evidence that the ALT
attribute on INPUT will not show up using IE 5.5 and Window-Eyes 4.0.

  So as of now it would appear that the technique that looks best is to use
TITLE on the INPUT, at very least where, as in Eugenia's case, there is no
suitable LABEL content already showing somewhere on the page.  And Thatch's
advice is to ignore LABEL and just TITLE it anyway.

  Al

  At 11:11 AM 2001-04-23 -0400, Slaydon, Eugenia wrote:
  >I've added in Jim's suggestion of using SCOPE with a combination of TITLE
in
  >fields 1-3 and Al's suggestion of using SCOPE with ALT in fields 4-5.
Please
  >look at <http://12.28.168.103/formtest.asp> and let me know what is the
best
  >solution for screen readers. I agree that using a title attribute on an
  >input field versus label would be a cleaner solution. If the readers
already
  >support this, then it makes sense to use this now.
  >
  >thanks,
  >Eugenia
  >
  >-----Original Message-----
  >From: Jim Thatcher [mailto:thatch@attglobal.net]
  >Sent: Sunday, April 22, 2001 10:06 PM
  >To: w3c-wai-gl@w3.org
  >Cc: Al Gilman; Slaydon, Eugenia
  >Subject: RE: Extensive forms & tables accessibility question
  >
  >
  >I would like to throw a monkey wrench into this discussion of accessible
  >forms. We are down to trying to label form elements with the headers
  >attribute for complex tables. I think  the tables are not complex. So
screen
  >readers are probably able to pick up the row and column headers as well
as
  >the content developers!
  >
  >But the problem to my mind is what does a screen reader user know to look
  >for when the come to something, in this case, an edit field.
  >
  >The best solution is to place the prompt in the edit field, for example,
  >"number of borrowers not in repayment status" for 3 b in
  ><http://12.28.168.103/formtest.asp>.
  >
  >Web content developers are generally not willing to do this for several
  >reasons, which I'm not going into here. But there is a simple equivalent.
  >Place that prompt as the title attribute of the input element. Currently
  >Window-Eyes reads the title attribute of input elements by default. I
have
  >been told the HPR will read the title attribute on command and I
encourage
  >them to read it automatically. I have talked to the JFW developers and
they
  >agree that supporting the title attribute for input elements makes a lot
of
  >sense.
  >
  >The label element has the fundamental flaw that it is prescribing one
piece
  >of text as the label for one input element, whereas, in the example under
  >discussion, two text areas label one input element. If the content
provider
  >used the title attribute on each input element (they know which is which)
it
  >reduces the complexity of implementation for them; it simplifies the work
  >for the assistive technology.
  >
  >I advocate the using title attribute on input elements instead of using
the
  >label element.
  >
  >Jim
  >jim@jimthatcher.com
  >Accessibility Consulting
  >http://jimthatcher.com
  >512-306-0931
  >
  >-----Original Message-----
  >From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On
  >Behalf Of Al Gilman
  >Sent: Saturday, April 21, 2001 11:25 PM
  >To: Slaydon, Eugenia
  >Cc: w3c-wai-gl@w3.org
  >Subject: RE: Extensive forms & tables accessibility question
  >
  >
  >At 02:37 PM 2001-04-20 -0400, Slaydon, Eugenia wrote:
  > >Hi,
  > >
  > >Okay - let's use this for point of reference.
  > ><http://12.28.168.103/formtest.asp>http://12.28.168.103/formtest.asp
  > >(Gregory - I sent you a different link earlier, refer to this one
instead)
  > >
  >
  >AG::
  >
  >Have a look at the attached <crossing fingers about attachment>.
  >
  >Here I have used ALT on the INPUT as opposed to TITLE on the TD.
  >
  >I hope some people can comment on the screen reader access to this
  >documentation.
  >
  >That is the principal accessibility change.  Do note the summary.
Otherwise
  >the edits are motivated by HTML validity and my taste more than outright
  >access
  >musts.
  >
  >Al
  >
  >
  > >I'm using headers currently. Do screen readers not handle these? That
was
  > >the whole reason I put them in. I find that being unable to associate
LABEL
  > >with more than one INPUT is frustrating. I'm interested in the concept
of
  > >TITLE in a TD. Does a screen reader handle this well. If so, would a
  > >combination of SCOPE and TITLE work? Only issue with this is that if
you
  >run
  > >BOBBY against the page it will fail to validate due to lack of LABEL
tags.
  > >
  > >I'm willing to make changes as quickly as possible to the above listed
page
  > >and have everyone use it as a testing environment to determine a usable
  > >solution. Thank you for your assistance.
  > >
  > >Eugenia
  > >
  > >-----Original Message-----
  > >From: Al Gilman
  >[<mailto:asgilman@iamdigex.net%5D>mailto:asgilman@iamdigex.net]
  > >Sent: Friday, April 20, 2001 1:54 PM
  > >To: Slaydon, Eugenia; w3c-wai-gl@w3.org
  > >Cc: jongund@staff.uiuc.edu; ij@w3.org; dde@w3.org
  > >Subject: Re: Extensive forms & tables accessibility question
  > >
  > >
  > >Eugenia,
  > >
  > >Would you be willing to offer a sample table-structured form as a
baseline
  > >for
  > >comparing remedies?  We could nominate examples but it would be better
to
  >be
  > >working with an example you gave us.
  > >
  > >Until we have your example, I will talk in terms of the example that
  > >springs to
  > >my mind.  This is a "designation of beneficiary" clause for life
insurance.
  > >Here the person completing the form is to associate shares in the
proceeds
  > >of
  > >the insurance to as many individuals as they wish.  For each
individual,
  > >they
  > >must provide, in addition to a designated share in the proceeds,
  > >identification
  > >in the form of several identifying characteristics of the individual
being
  > >made
  > >a beneficiary.  There is no way for the writer of the form to provide
in
  >the
  > >text of the form individual unique labels for all the possible entries
in
  > >the
  > >form.  The list length is unbounded; the unique identification of the
  > >beneficary is what the person filling out the form provides, not the
form
  > >itself.
  > >
  > >With the current definition of HTML there is no way to make LABEL work
for
  >a
  > >two-dimensional array of questions where the unique explanation for
each
  > >entry
  > >field is provided by combining row and column heads.  Neither the row
head
  > >nor
  > >the column head is associated with a unique form control, and we don't
have
  > >the
  > >language to say "the unique, understandable explanation of this form
  > >control is
  > >[some pattern of references]."
  > >
  > >The following are experimental concepts.  I don't have the resources to
see
  > >how
  > >they play in screen readers so I am offering the sketches so I hope the
  > >group
  > >can do more than I can do.
  > >
  > >Fix concept #1: TITLE on TD elements containing text entry form
controls:
  > >
  > >Reiterate (possibly briefly) the identification of the question to be
  > >answered
  > >from the applicable headers in a TITLE element on the table cell
containing
  > >the
  > >form control.
  > >
  > >This version may be the most compatible with screen readers but we need
to
  > >make
  > >sure it doesn't interfere with reviewing what you have put in the form
  > >field.
  > >It satisfies the spirit if not the letter of the "explicitly associate"
  > >checkpoint.
  > >
  > >Fix concept #2: De-tabularize the form.
  > >
  > >In this case, the beneficiary information is formatted as a tree, not a
  > >table.
  > >There is a separate set of entry fields for each beneficiary, with
tailored
  > >labels for each entry field.  Following the third
beneficiary-information
  > >block
  > >there is an option that invokes a script and gets you a form with more
  > >spaces
  > >for beneficiaries.
  > >
  > >Aside:  I am concerned that X-Forms may be like the 'headers' attribute
in
  > >that
  > >it captures the required information well but isn't recognized by the
  >screen
  > >reader.  This is some missionary work to be done with the assistive
  > >technology
  > >folks.
  > >
  > >Al
  > >
  > >At 10:01 AM 2001-04-20 -0400, Slaydon, Eugenia wrote:
  > > >Hi,
  > > >
  > > >I'm trying to make my pages that are very heavy in forms accessible
and
  > > >understandable
  > > >by screen readers. I've used label where I can but I have text fields
  >that
  > > >are associated
  > > >with multiple labels. For example I have a question in the first
column
  >and
  > > >they have to
  > > >enter a answer in the next 4 columns. The 4 columns have a header row
of
  > > >titles.
  > > >Currently, I have assigned id and headers to the td's. But since the
  >label
  > > >is missing the
  > > >page will fail on a compliance check. Any suggestions on how to
handle
  > > >complex forms
  > > >that are inside of tables so that it meets section 508 compliance?
  > > >
  > > >Thanks,
  > > >Eugenia
  > > >
  > >
  >