Re: Form labeling and user agent support

Hello Adam,

I suspect you are exploring this for 508 compliance so please don't
consider this any sort of official opinion.  That said, I have a couple
comments.

Your present design doesn't strike me as all that bad and is quite common
from the perspective of what a user is used to.  Most check boxes on web
pages appear before the text of the check box.  I can actually make a case
that this is a better design as the appearance of the check box after the
prompt is likely to seem more confusing by comparison.

With JAWS in the Virtual PC mode, the default for web content, the user
would experience a check box, arrow down once and then the text.  If the
user presses enter (this is how you set focus to a check box or other form
control from the VPC mode) on the check box, the associated label text
will be read along with the fact that it is a check box.

Window-Eyes takes the label text and explicitly associates it with the
control in what it calls the MSAA mode.  This means that label location is
not critical for Window-Eyes because the user will experience the label
text on the same line as the control as well as in the original location.

Home Page Reader behavior is similar to JAWS.

All three of these screen readers use what I'll term
a buffered reading mode.  By that I mean they load the web content and
reformat into a decolumnized view among other items.

There's also the possibility of using a title tag directly on the input
control.  At present Window-Eyes is the only product I know will use this
information but I believe other products will in the future.  Nor it it
clear to me how Window-Eyes and other products will handle title and label
text being present for the same control.  I believe Window-Eyes defaults
to label text in such cases at present.




On Wed, 2 May 2001, ADAM GUASCH-MELENDEZ wrote:

> Question on user agent support -
>
> We're about to post a publications order form, allowing users to select from roughly 80 publications. The form as it exists right now uses checkboxes positioned to the left of the publication title (in a two-column table). Each publication title is labeled appropriately. Example:
>
>    <tr>
>    <td><input type="checkbox" name="publications" value="pub123" id="123"></td>
>    <td><label for="123">Sample publication</label></td>
>    </tr>
>
> However, according to checkpoint 10.2:
>
> "Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned."
>
> Which, of course, would require that the label precede the control on the same line, or on the preceding line, instead of the checkbox preceding the label, as it is in our draft form. This makes perfect sense to me - why present someone with a checkbox before telling them what it's for? However, a colleague prefers the layout of the draft form as it is - it's visually closer to most paper-based or web-based forms she's familiar with.
>
> So the question is, what about that "Until user agents support ..."? Do user agents (by which I specifically mean "typical" browser and screen reader combinations):
>
> a - currently provide enough support for form labels to handle this properly as it currently exists: checkbox first, then publication name, with proper HTML labels, or
>
> b - not provide enough support for form labels, in which case our form needs to be redone?
>
> I strongly suspect "b", and I plan to go ahead and redo the form, but I thought I'd ask here first, since I don't have the experience of someone who uses screen reader technology every day.
>
> Thanks!
>

Received on Wednesday, 2 May 2001 23:58:20 UTC