W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2002

Re: *Complex* Tables, Forms, Labeling, I'm still confused

From: Al Gilman <asgilman@iamdigex.net>
Date: Thu, 14 Nov 2002 10:06:21 -0500
Message-Id: <5.1.0.14.2.20021114094450.02348ec0@pop.iamdigex.net>
To: <w3c-wai-ig@w3.org>

Summary:

1. Put a TITLE on each INPUT.

2. How can we educate your customer?  What they are insisting on is "eyes
and paper bigotry."  Assuming that everyone has working eyes is unfeeling;
but being hidebound about the way it works best on paper is costing them
money somewhere.  Being able to change items in the input *both* in an editable
summary *and* through step-by-step worksheets is a Best Current Practice that
is everywhere in retail 'clicks' eCommerce and tax preparation software etc.
An interactive medium makes it possible to make the transaction more usable
than is feasible on paper; not to do so is leaving money on the table.

At 11:03 PM 2002-11-13, Leanne Phillips wrote:

>Hi all,
>
>I've skimmed over a quick search for the topics since early March, looking
>for topics about forms presented as tables.  I only found 3-4 dealing
>obviously (in their subject lines) with the issue, and none of those threads
>really hit on the problem I'm currently having.

You have done a great job of recapping the issue.

>We have what I can only call a complex table.  The data has to be entered in
>the same format it'll be displayed in (customer requirement) - that is, the
>appearance of the entry form has to look like the output form.  Which is
>*definitely* a complex table.
>
>So, I have the two-logical-column-headers problem, and am doing all the
>right
>stuff with scope/id+headers, because it's a table.
>
>However, I can't put the labels for the entry fields into their table cells,
>in any way that is obvious to visual users.  My understanding of <label> is
>that it is displayed as text on the screen for visual users, and is supposed
>to be read as the prompt for a given element.  If I'm right about that, then
>I can't use the label idea, I think.
>
>If I could rely on JAWS (in particular) and others to read the row and
>column
>headers I would be (almost; it's a very complex form) all set.  However, my
>user who uses JAWS on a daily basis wasn't able to get both - I don't want
>those users to have to switch between forms mode and regular, table-handling
>mode.  Or whatever they're called.  That's obviously Not Good for usability
>even if you can call it accessible.

At the FedStats workshop on complex tables it was reported that there
is a Jaws command which will inspect a table cell and when it is invoked
the headers that are listed in the HEADERS attribute are read.  I am
sorry I can't give you precise information about this command.

But it probably involves leaving forms mode, and you can't expect that most
users will know about it.

>So, how should I go about doing these?  I don't think I can use multiple
>labels
>for a single entry field, nor re-use the label for multiple fields, as I'd
>need
>to do (each cell would need two labels; each label would have to be used for
>a minimum of 3, and more usually 5 or 15, cells).
>
>Should I use the title attribute for each of those cells?

Actually, you should us the TITLE for the INPUT, not the TITLE for the TD cell.

>Will JAWS read
>that
>properly?  Is there another workaround?

Nothing as effective under your circumstances.

>I'm looking for both 'what's right' - how *should* it be marked up - and
>'how
>does it actually work' - what'll make it work given that markup
>implementation
>isn't always as complete.

Hope that the uptake of XForms is quicker.

Al

>If I haven't described my table problem clearly enough, let me know and I'll
>try to provide useful clarification.  It seems that the major problem is
>that
>most forms-in-tables are in tables for layout only, not for data, and thus
>can be handled thoroughly different from tables-for-data.

Your analysis of the situation is completely correct so far as I know.

What you can do in terms of presently deployed assistive technology
in the context of a layout optimized for visual review of the summary
when it is all there is to embed field help in the form of the TITLE
attribute on the INPUT element.

What you can to do enhance usability would be to provide worksheets in
an expanded format in addition to interaction with the summary layout.

Al

>Thanks for any help,
>-Leanne
Received on Thursday, 14 November 2002 10:07:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:07 GMT