E-mail List Archives
Thread: Re: Foreign:Re: textbox in table cell
Number of posts in this thread: 2 (In chronological order)
Chris Hoffman wrote:
> Is that a limitation of the assistive technologies' capabilities?
> Because it certainly isn't a violation of the HTML4 spec:
> "Each LABEL element is associated with exactly one form control."
> "More than one LABEL may be associated with the same control by
> creating multiple references via the for attribute."
Patrick Lauke replied:
I'd say it's a limitation of current AT...to a certain extent, as the
spec doesn't actually clarify the use cases for multiple labels. Does it
allow multiple labels under the tacit understanding that those labels
would really all mean the same thing, or does it intend to offer a
mechanism for situations like the one discussed here? It's unclear...and
therefore AT is inconsistent in that regard.
Mike Moore adds:
Even if AT supported multiple labels for a single input it would not
resolve the situation described. In this situation, placing data in a
table, the labels (table headers) and the inputs have a many to many
relationship. Each label/header would need to be associated with all of
the inputs in the corresponding row or column. This is not possible due
to the need for unique ids on the inputs and the inability to place
either multiple for attributes, or multiple values within a single for
attribute in a label.
The example that Jukka posted on this thread, where the inputs were
placed within fieldsets with legends, would be the "ideal" solution in
terms of web standards and accessibility. Unfortunately though,
customer/client/manager demands frequently dictate the visual layout of
the page and like it or not we are frequently required to create web
interfaces/forms that mimic the appearance of paper forms or
spreadsheets. We can advise, but unless we own the site we usually
cannot dictate the solution.
Moore, Michael wrote:
> The example that Jukka posted on this thread, where the inputs were
> placed within fieldsets with legends, would be the "ideal" solution in
> terms of web standards and accessibility.
It's also simplest to create.
> Unfortunately though,
> customer/client/manager demands frequently dictate the visual layout
> of the page and like it or not we are frequently required to create
> web interfaces/forms that mimic the appearance of paper forms or
> spreadsheets. We can advise, but unless we own the site we usually
> cannot dictate the solution.
Fair enough, but then it would also be fair to tell them that there is
not much one can achieve in terms of accessibility. I'm afraid
accessibility specialists, if they work under such conditions, will just
help to create the impression that accessibility has been improved and
is fairly good. It's like helping with a completely messed-up site with
all the possible design mistakes by adding ALT texts to images (and to
images that mostly shouldn't be there in the first place).
They are of course very incompetent in designing web pages and services
if they insist on their visual layout on a _form_ and require it to
mimic paper forms. You don't need to tell them that (and they wouldn't
believe you), but you should take this into account: the functionality
is crappy anyway, and putting some "accessibility enhancements" there is
more or less absurd.
Jukka K. Korpela ("Yucca")