RE: Extensive forms & tables accessibility question

Eugenia,

I can't let this thread die without raising two more radical approaches.

It is important that we get the individual data entry fields to be
self-explanatory, as we have discussed.  On the other hand, the tabular
organization, and working within the limitations of HTML Forms technology are
not necessarily the best way to solve this particular application.

** Narrative workbook:

First, consider taking the text of the instructions for the form, and
distributing the entry fields in that.  This will give you a workbook
which, on
submittal, can be in the form of the summary table for confirmation.  The
example you give is a typical Government form where despite our best attempts
at built-in documentation, the question asked for each input field is not
understandable without reference to the instructions.  In a narrative workbook
form, it would be easy to use LABEL for the edit boxes which is reasonably
well
supported per the  report of Kelly Ford.
<<http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/0303.html>http:
//lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/0303.html>
Putting the data entry opportunities in a tabular array is a cultural legacy
from when we were doing things on paper.  If we are doing this data entry on a
computer, it makes as much sense to blend the entries with the instructions as
it does to collect them.  Advanced data collection applications will retain a
local data object and allow editing in either view.  But let's just presume we
are doing it one way at a time, here.

** Schema-driven automated reporting.

The second level of reform has to do with documenting the questions in
machinable form.  The fact that this form is a web form to be filled in by a
person is a cost savings at the Department of Education and a major cost adder
at the educational institutions required to provide the reports.  There
will be
a significant net savings to the educational institutions collectively and
hence to the taxpayers and students, when this system is successfully migrated
to a system like XForms where there is a machine-comprehensible model of the
questions so that the educational institutions can keep records that match an
Education Department published schema and then run this report
automatically by
a query processor.

"Workflow" situations, like this example of partially aggregated fiscal
reporting between management levels, are not economically well served by the
HTML forms in HTML 4.01 (equivalently XHTML 1.1).  So we should all be looking
forward to the next step of migrating these reporting activities to
schema-based forms.

I have been assuming that you are a web contractor in this situation and do
not
have an easy path to take either of these more radical approaches.  But given
the example we have looked at, people should be aware that there is no
fundamental reason why the table should be there at the point of data entry,
and that there are advantages to other ways of doing things.

Al

At 02:15 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)
>
>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 
>>  
>

Received on Friday, 4 May 2001 07:07:46 UTC