E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 12 (In chronological order)

From: D A
Date: Tue, Oct 26 2010 11:39AM
Subject: Accessible conditional form fields
No previous message | Next message →

I have the following form structure for a set of fields. It consists
of a radio button list where certain radio buttons may require
additional content:

radio button 1
radio button 2
conditional field for radio button 2
radio button 3
conditional field for radio button 3

The interaction for the above is that we do not show the conditional
fields unless the related radio button is selected. If radio button 2
is selected, then the conditional field appears below.

This works visually as an interaction. I'm not trying to decide what's
the preferred way to make this accessible.

My impression is that one would want to read all 3 radio buttons
without the conditional fields. Upon selected one of the radio
buttons, THEN read the conditional fields.

At the moment, we're using jQuery to hide the conditional fields until
the radio button is selected. To hide it, jQuery sets them to
'display:none'.

My understanding is that should prevent the field fun being read
within a screen reader. Is that correct? Should we also set the
conditional fields to disabled?

Once the conditional fields are exposed (display: block) would they
automatically be then read via the screen reader (given they are next
in the tab order)?

Any thoughts/gotchas?

-DA

From: adam solomon
Date: Tue, Oct 26 2010 12:45PM
Subject: Re: Accessible conditional form fields
← Previous message | Next message →

From our experience with JAWS 9, the jquery functions should be picked up by
Jaws so that if it is display:none the reader should not read it. (We have
found rare situations where display none content was in fact read by Jaws,
but this is a bug. Best to test it out if you have access to a screen
reader). In any event, as long as the conditional field comes after the
associated radio button (in the html sequence) you shouldn't have a problem,
since the conditional content will appear after the user's selection and
will not be missed. Don't forget fieldset/legend.

On Tue, Oct 26, 2010 at 7:37 PM, D A < = EMAIL ADDRESS REMOVED = > wrote:

> I have the following form structure for a set of fields. It consists
> of a radio button list where certain radio buttons may require
> additional content:
>
> radio button 1
> radio button 2
> conditional field for radio button 2
> radio button 3
> conditional field for radio button 3
>
> The interaction for the above is that we do not show the conditional
> fields unless the related radio button is selected. If radio button 2
> is selected, then the conditional field appears below.
>
> This works visually as an interaction. I'm not trying to decide what's
> the preferred way to make this accessible.
>
> My impression is that one would want to read all 3 radio buttons
> without the conditional fields. Upon selected one of the radio
> buttons, THEN read the conditional fields.
>
> At the moment, we're using jQuery to hide the conditional fields until
> the radio button is selected. To hide it, jQuery sets them to
> 'display:none'.
>
> My understanding is that should prevent the field fun being read
> within a screen reader. Is that correct? Should we also set the
> conditional fields to disabled?
>
> Once the conditional fields are exposed (display: block) would they
> automatically be then read via the screen reader (given they are next
> in the tab order)?
>
> Any thoughts/gotchas?
>
> -DA
>

From: D A
Date: Tue, Oct 26 2010 2:15PM
Subject: Re: Accessible conditional form fields
← Previous message | Next message →

> In any event, as long as the conditional field comes after the
> associated radio button (in the html sequence) you shouldn't have a problem,
> since the conditional content will appear after the user's selection and
> will not be missed.

Good to know. Thanks!

> Don't forget fieldset/legend.

oof. Well, now that you've opened that can of worms... ;o)

In my previous research, the opinion of the fieldset/legend for
radiobutton lists seems to end up with hung juries.

I've opted to go for h3 instead of a legend for a few reasons:

1. Legends are really hard to deal with via CSS
2. My understanding is that fieldsets are read prior to each
radiobutton option and that for many folks, that, itself, can be
annoying and lead to accessibility issues--especially when the the
fieldset would be a complete sentence (or group of sentences).

I'm still open to being convinced one way or the other, of course.

-DA

From: adam solomon
Date: Tue, Oct 26 2010 10:12PM
Subject: Re: Accessible conditional form fields
← Previous message | Next message →

You have provided some sound reasoning, however wcag specs on the fieldset
issue <http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H82.html>;do
specify that related or logically grouped form fields should have a fieldset
around them (there are also the condtional fields) - how is your example
different?

On Tue, Oct 26, 2010 at 10:08 PM, D A < = EMAIL ADDRESS REMOVED = > wrote:

> > In any event, as long as the conditional field comes after the
> > associated radio button (in the html sequence) you shouldn't have a
> problem,
> > since the conditional content will appear after the user's selection and
> > will not be missed.
>
> Good to know. Thanks!
>
> > Don't forget fieldset/legend.
>
> oof. Well, now that you've opened that can of worms... ;o)
>
> In my previous research, the opinion of the fieldset/legend for
> radiobutton lists seems to end up with hung juries.
>
> I've opted to go for h3 instead of a legend for a few reasons:
>
> 1. Legends are really hard to deal with via CSS
> 2. My understanding is that fieldsets are read prior to each
> radiobutton option and that for many folks, that, itself, can be
> annoying and lead to accessibility issues--especially when the the
> fieldset would be a complete sentence (or group of sentences).
>
> I'm still open to being convinced one way or the other, of course.
>
> -DA
>

From: Jim Allan
Date: Wed, Oct 27 2010 8:42AM
Subject: Re: Accessible conditional form fields
← Previous message | Next message →

H3 are only read when not in forms mode, i.e. when using the arrow key
to read through the document or using the say all command. when in
forms mode (Jaws 10 and before) everything other than form controls is
skip. Even in Jaws 11+ most users will navigate using the tab key to
navigate between form controls again skipping H3.
Fieldset/Legend will be read by Jaws if you move into a group of
controls that has them. The controls will be explicitly associated
with the fieldset/legend that contains them.

Jim

On Tue, Oct 26, 2010 at 11:10 PM, adam solomon
< = EMAIL ADDRESS REMOVED = > wrote:
> You have provided some sound reasoning, however wcag specs on the fieldset
> issue <http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H82.html>;do
> specify that related or logically grouped form fields should have a fieldset
> around them (there are also the condtional fields) - how is your example
> different?
>
> On Tue, Oct 26, 2010 at 10:08 PM, D A < = EMAIL ADDRESS REMOVED = > wrote:
>
>> > In any event, as long as the conditional field comes after the
>> > associated radio button (in the html sequence) you shouldn't have a
>> problem,
>> > since the conditional content will appear after the user's selection and
>> > will not be missed.
>>
>> Good to know. Thanks!
>>
>> > Don't forget fieldset/legend.
>>
>> oof. Well, now that you've opened that can of worms... ;o)
>>
>> In my previous research, the opinion of the fieldset/legend for
>> radiobutton lists seems to end up with hung juries.
>>
>> I've opted to go for h3 instead of a legend for a few reasons:
>>
>> 1. Legends are really hard to deal with via CSS
>> 2. My understanding is that fieldsets are read prior to each
>> radiobutton option and that for many folks, that, itself, can be
>> annoying and lead to accessibility issues--especially when the the
>> fieldset would be a complete sentence (or group of sentences).
>>
>> I'm still open to being convinced one way or the other, of course.
>>
>> -DA
>>

From: D A
Date: Tue, Nov 02 2010 3:12PM
Subject: Re: Accessible conditional form fields
← Previous message | Next message →

> H3 are only read when not in forms mode, i.e. when using the arrow key
> to read through the document or using the say all command. when in
> forms mode (Jaws 10 and before) everything other than form controls is
> skip.

Interesting.

That raises some other questions. Many of the forms we create have
non-form text intermingled within the form itself. For instance, a
text field may have a label, and then also some 'help' text
afterwords. Or a section of the form may have a paragraph of
explanatory text for that section.

A common scenario I see often is a paragraph or two of text that is a
legal disclaimer along the lines of 'by submitting this form you are
certifying that...'

How to folks that use JAWS deal with complex forms that intermingle
non-form content like that?

-Darrel

From: D A
Date: Tue, Nov 02 2010 4:06PM
Subject: Re: Accessible conditional form fields
← Previous message | Next message →

> For non-form control text between form controls (I have heard it
> called 'intervening text')
> you would add a <p tabindex="0">a bunch of text</p> this forces the
> element to be in the tab order exactly in the place it occurs in the
> source code. When a user tabs from a form control the intervening
> paragraph will get a visual focus box to call attention to it, and
> Jaws reads the paragraph.
> Using Jaws 10 (you mileage may vary depending on the version of Jaws)
> the paragraph will always be spoken. Using a <div tabindex="0"> make
> Jaws 'beep' but nothing else

Good info.

Would you happen to know how <h# tabindex="0"> would work? If that is
read, then it seems that would then be an OK alternative to the legend
tag (in the sense that'd it be read).

-DA

From: Jim Allan
Date: Tue, Nov 02 2010 4:12PM
Subject: Re: Accessible conditional form fields
← Previous message | Next message →

For non-form control text between form controls (I have heard it
called 'intervening text')
you would add a <p tabindex="0">a bunch of text</p> this forces the
element to be in the tab order exactly in the place it occurs in the
source code. When a user tabs from a form control the intervening
paragraph will get a visual focus box to call attention to it, and
Jaws reads the paragraph.
Using Jaws 10 (you mileage may vary depending on the version of Jaws)
the paragraph will always be spoken. Using a <div tabindex="0"> make
Jaws 'beep' but nothing else (if you down arrow you can hear the
content of the <div>.
using <ul tabindex="0">, makes Jaws 'beep' and say "List". you then
have to arrow down through the list.

<P> seems to work the best. I have used this for instructions.

simple html form

<form id="form1" name="form1" method="post" action="">
<p>
<label for="w">name</label>
<input type="text" name="w" id="w" />
</p>
<p tabindex="0">this is a paragraph with tabindex="0"</p>
<p tabindex="0">this is a another paragraph with tabindex="0"</p>
<div tabindex="0">this is a div with tabindex="0"</div>
<div tabindex="0">this is a div with tabindex="0"
<p>this is paragraph without tabindex="0" inside the div</p>
</div>
<div tabindex="0">
<p>this is a paragraph inside the second div with tabindex="0"</p>
<p>this is another paragraph inside the div</p>
</div>
<ul tabindex="0">
<li>item one </li>
<li> item 2</li>
</ul>
<p>
<label for="x">foo</label>
<input type="text" name="x" id="x" />
</p>
</form>

Jim

On Tue, Nov 2, 2010 at 4:10 PM, D A < = EMAIL ADDRESS REMOVED = > wrote:
>> H3 are only read when not in forms mode, i.e. when using the arrow key
>> to read through the document or using the say all command. when in
>> forms mode (Jaws 10 and before) everything other than form controls is
>> skip.
>
> Interesting.
>
> That raises some other questions. Many of the forms we create have
> non-form text intermingled within the form itself. For instance, a
> text field may have a label, and then also some 'help' text
> afterwords. Or a section of the form may have a paragraph of
> explanatory text for that section.
>
> A common scenario I see often is a paragraph or two of text that is a
> legal disclaimer along the lines of 'by submitting this form you are
> certifying that...'
>
> How to folks that use JAWS deal with complex forms that intermingle
> non-form content like that?
>
> -Darrel
>

From: Jim Allan
Date: Tue, Nov 02 2010 4:54PM
Subject: Re: Accessible conditional form fields
← Previous message | Next message →

Just tested, H# work fine.
FYI, I am using Jaws 11.
Jim


On Tue, Nov 2, 2010 at 5:06 PM, D A < = EMAIL ADDRESS REMOVED = > wrote:
>> For non-form control text between form controls (I have heard it
>> called 'intervening text')
>> you would add a <p tabindex="0">a bunch of text</p> this forces the
>> element to be in the tab order exactly in the place it occurs in the
>> source code. When a user tabs from a form control the intervening
>> paragraph will get a visual focus box to call attention to it, and
>> Jaws reads the paragraph.
>> Using Jaws 10 (you mileage may vary depending on the version of Jaws)
>> the paragraph will always be spoken. Using a <div tabindex="0"> make
>> Jaws 'beep' but nothing else
>
> Good info.
>
> Would you happen to know how <h# tabindex="0"> would work? If that is
> read, then it seems that would then be an OK alternative to the legend
> tag (in the sense that'd it be read).
>
> -DA
>

From: Michael.Moore
Date: Wed, Nov 03 2010 7:54AM
Subject: Re: Accessible conditional form fields
← Previous message | Next message →

Getting to intervening text within a form has always been a bit tricky.

Using tabindex=0 is well supported but the instructions are not programmatically bound to the correct input, and it adds extra tab stops to a form. If you navigate directly to a form field using a form field list you will miss the instruction. Also if the instruction comes after the form field you will read it too late if you are tabbing through the interface. This is a common design pattern for password rules.

A promising new technique is the aria-describedby attribute.

The aria-describedby attribute points to the id of another element that provides additional information about another element. Andy Bryant has a good example of using the attribute in a sign up form on his LessFuss Design blog.

<http://www.lessfussdesign.com/blog/2010/08/using-aria-describedby-for-form-help-text/>;

His code looks like this:

<form name="signUp">
<fieldset>
<legend>Sign up now!</legend>
<label for="username">Choose a username</label>
<input type="text" id="username" />
<label for="password">Choose a password.</label>
<input type="password" id="password" aria-describedby="passwordDescriber" />
<p id="passwordDescriber">Your password needs to be at least 8 characters long, including at least one number or special character.</p>
<label for="email">Email address</label>
<input type="text" id="email" />
<label for="confirmEmail">Confirm email address</label>
<input type="text" id="confirmEmail" />
</fieldset>
<input id="submit" type="image" alt="Sign up for updates" value="Sign up" src="submitButton.gif"/>
</form>

There is also live test case here: <http://codetalks.org/source/enhanced-html-forms/describedby.html>;

We have tested this with JFW 10, 11, and 12 and NVDA 2010.2 beta 1 using FF 3.6 and it worked flawlessly. We also tested it successfully with Voiceover on IOS 4.1. The attribute was not supported in JFW 9 or with any version of JAWS or NVDA on IE7 or IE8.

In JAWS the paragraph that was pointed to by the aria-described attribute was read after the label and in voiceover it was read before.

Mike Moore

From: Jukka K. Korpela
Date: Wed, Nov 03 2010 11:33AM
Subject: Re: Accessible conditional form fields
← Previous message | Next message →

= EMAIL ADDRESS REMOVED = wrote:

> Using tabindex=0 is well supported

Using tabindex for a <p> element, for example, is invalid markup when using
document types defined in current HTML recommendations. And since its
assumed meaning is just to confirm the default, I really do not see the
point.

> A promising new technique is the aria-describedby attribute.

A fundamental feature of new techniques is that they are new, i.e. not
supported by old browsers - actually, they typically start with _no_ support
worth mentioning. But that's not the only problem.

> <input type="password" id="password"
> aria-describedby="passwordDescriber" />
> <p id="passwordDescriber">Your password needs to be at least 8
> characters long, including at least one number or special
> character.</p>

This techniques seems to let the author postpone an essential description so
that it is presented _after_ the input field. This makes it a bad idea.

Even if we assume that all special accessibility-oriented software supported
the feature, and all of their users knew how to use it - and both
assumptions surely fail, the latter more permanently - such an arrangement
would mean that for the vast majority of users, essential information comes
too late. People who can glimpse over a page don't do that when filling out
a form. They expect it to be filled out in order.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

From: Kroon.Kurtis
Date: Wed, Nov 03 2010 1:30PM
Subject: Re: Accessible conditional form fields
← Previous message | No next message