WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Legend wrap (or not)

for

From: Moore, Michael
Date: Aug 31, 2007 9:20AM

Jukka wrote:

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.

Mike's response:

Yes, however there is a cost in terms of usability and efficiency for
screen reader users. Typical behavior among screen reader users that I
have talked to, including those who train other JAWS users, is to
attempt to complete the form by moving through it in forms mode without
exiting. When they think that they may have missed something they exit
and move back up the form line by line. They find forms where
information is not included in the tab ring difficult to use, not
inaccessible.

Jukka:

This avoids the problem of lengthy legends.

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.

Mike:

There are a number of other alternatives, admittedly these are all hacks
and each method represents a trade off with other potential issues:

1. Use spans and styling to make the visual presentation of labels and
legends look as if intervening text was coded structurally. Cost:
Reduction in non-visual semantic or structural meaning within the form.
2. Place the intervening text inside of the label for the first input
following the intervening text through the use of alt text within a
transparent gif. Cost: redundant information for screen readers users
who are not in forms mode, possible visual rendering issues if images
are not downloaded.
3. Break up the form into a series of interfaces so that the intervening
text can be placed prior to the first form input on each page of the
interface. Cost: Increased programming complexity and potential loss of
efficiency for users waiting for pages to download. Potential added
benefit: reduced scrolling for all users.

In an "ideal" world, screen reading software would include paragraph and
heading elements within the tab ring when in forms mode. However, not
being an expert on the inner workings of this software I do not know if
it is technologically feasible at this time. It certainly does not
appear to be a priority for any of the screen reader vendors.

In the "real" world, intervening text poses a real problem for screen
reader users. As an industry, we have made many changes to improve the
usability of applications based upon the way the people actually use
computers rather than the way the they "should" use computers. The
result is that most people can now open a new application, or visit a
new web site, with no training at all. Working in an agency that serves
a large community of users who are blind, I am biased toward providing
that same consideration to those users. In my opinion, form design on
the web is unimaginative and poorly implemented, and fails to take
advantage of the medium in which these forms are delivered. As designers
we are making progress in moving away from simply rendering good paper
designs on a computer monitor, however, very little progress has been
made with forms resulting in the use of unnecessary intervening text and
lost opportunities to break up the interface into logical user friendly
chunks. A few typical examples follow:

1. Please answer yes or no to the following questions: (Radio buttons or
select boxes make this obvious).
2. If you answered no to question 5 skip down to question 14, otherwise
complete the following questions. (Great opportunity for branching
logic).
3. In this section please... (Opportunity to break up the form into
multiple sections).

That's my two cents worth anyway.

Mike Moore