WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Legend wrap (or not)

for

From: Andrew Kirkpatrick
Date: Aug 31, 2007 8:50AM

> So this means that if we design a form logically, using
> explanatory texts as needed for filling out the form, using
> legend (or heading) elements as short heading-like captions,
> and using concise labels associated with input elements via
> markup, the form will be generally accessible, though with
> some need for mode switching to some users. And I would
> expect those users to be or to get familiar with mode
> switching, since the vast majority of forms - perhaps
> excluding very simple and intuitive search forms - on web
> pages have not been designed to suit the specifics of the
> software they use.

Yep, that's all fair to say. It is desireable for forms to be simple
enough so that explanatory text (and therefore mode switching) is not
needed, but this isn't always possible.

> This avoids the problem of lengthy legends.

Maybe. One situation where legends are almost always beneficial is for a
radio group. The screen reader will guess at the prompt for a radio
group since at least some AT don't read a second label that references
all of the members of a radio group in the way that legend text wrapping
a radio group is voiced. It would be great to be able to have
explanatory text or radio group prompts be labels that refer to multiple
id's, but that isn't working now as far as I know.

> The alternative of designing forms so that all the
> information in it is wrapped in legend and label elements
> would mean serious accessibility problems. For example, if
> some question really needs a lengthy explanation before it
> can be asked and answered, should all that appear inside a
> legend element, resulting in a rather odd rendering on normal
> graphic browsers? What would you do with explanatory texts
> containing links to additional information, for people who
> may need it? And putting all the explanations and links
> _before_ the form is not reasonable at all if the form is
> relatively long and the explanations and links relate to
> specific parts there.

This problem is not unique to the web. I can't find the reference, but
I recall reading a microsoft guidelines document that indicated for
desktop appls that it was necessary to put the extra text necessary for
comprehension of a dialog/form/application into the tab order so that it
could be read when interacting with the form. In desktop apps there is
only forms mode (well, there's also a "mouse emulation mode" but that's
not a good analog to the HTML reading modes in SR's), so the user either
eneds to get the info by it being in the tab order, or they can request
that the full window be read and piece it together themselves. In
application use, as with HTML forms, users rely on a variety of
strategies to be certain of what they are doing.

In HTML, the extra text could be put into the tab order also, but that
opens up a whole other can of worms. One could also add links (which
are tabbable in forms mode) in a form that would open javascript alerts
or open a separate page with explanatory information, or even that would
modify the DOM to add the explanatory text into the tab order. These
all would either be regarded as moving toward application-like
functionality or as hacks (or both), but as you point out, form access
is not trivially easy once form complexity increases.

AWK