E-mail List Archives
Thread: More fun with forms and JAWS
Number of posts in this thread: 3 (In chronological order)
From: Moore, Michael
Date: Wed, Aug 23 2006 3:30PM
Subject: More fun with forms and JAWS
No previous message | Next message →
Good afternoon accessible world,
I am currently writing a set of procedures for creating accessible
forms. One of the issues that I am grappling with is the best method
for dealing with intervening text and questions related to a group of
inputs.
The solution that I have used, and recommended for a couple of years, is
to place the question in the legend for a fieldset. Example follows:
<bit o code>
<fieldset>
<legend>What do you want done with your paycheck?</legend>
<input type="radio" name="pay" id="p1" value="bank" />
<label for="p1">Please deposit it in my bank.</label><br />
<input type="radio" name="pay" id="p2" value="charity" />
<label for="p2">Please donate it to charity.</label><br />
<input type="radio" name="pay" id="p3" value="keep" />
<label for="p3">Please keep it, I have plenty of
money.</label><br />
</fieldset>
</bit o code>
Issue One:
When testing the section of code above I came across the following
issue. If verbosity settings are set to advanced with JAWS 6.1 the
legend text is not read when in forms mode.
Radio buttons and check boxes will function when not in forms mode,
however how would a user who cannot see the screen know to exit forms
mode? The situation seems to be that JAWS users are forced to enter and
exit forms mode throughout most forms to find all of the instructions
and prompts. This is very inefficient.
Issue Two:
It is not always possible to place the full text for instructions within
a legend due to the fact that we are limited in how we can style the
legend. Text wrapping cannot be effectively implemented to my knowledge.
At times I have used the <br /> element as a compromise but this is not
an optimal solution for aesthetic and reflow purposes.
Issue Three:
If I place the question within the title attribute and do not explicitly
associate the legend with input. I can reliably make JAWS read the
title attribute but this creates problems for other users, particularly
those using screen magnifiers because of the behavior of tool tips.
My proposed procedure is to do the following:
1. When the question or instruction is short, place it in the legend,
(this assumes that JAWS users with verbosity set to advanced will also
have the skills to deal with entering and exiting forms mode to find the
question).
2. If the answer text is short consider placing the answers within a
<select> although this is probably not optimal for the replacement
checkboxes because of usability issues related to multiple select.
Example:
<another bit o code>
<label for="o1">
The conference presented meaningful information in a format that I found
to be both useful and accessible.
</label>
<select id="o1">
<option value="1">Totally Agree</option>
<option value="2">Somewhat Agree</option>
<option value="3">Neutral</option>
<option value="4">Somewhat Disagree</option>
<option value="5">Totally Disagree</option>
</select>
</another bit o code>
3. When forms need to be divided by headings, or sections require more
extensive instructions, break the form into multiple forms.
These three strategies seem to cover most situations, but I would like
to hear your opinions, and suggestions for possible alternative
strategies.
Finally, is the behavior of JAWS 6.1 typical of other screen readers.
Does anyone have experience with Window Eyes, HAL, JAWS 7.1 etc.
Mike Moore
Accessibility Specialist
Department of Assistive and Rehabilitative Services (DARS)
(512) 424-4159
From: sean keegan
Date: Thu, Aug 24 2006 4:50PM
Subject: RE: More fun with forms and JAWS
← Previous message | Next message →
Hi Mike,
> Finally, is the behavior of JAWS 6.1 typical of other screen readers.
> Does anyone have experience with Window Eyes, HAL, JAWS 7.1 etc.
I can answer a bit with Window-Eyes 5.5. By default, Window-Eyes seems to
not read the <legend> information unless you go into the Verbosity and tell
it to insert a beginning/end message for fieldsets. Then, W-E only reads
when you are entering the fieldset or exiting the fieldset - it does not
appear to read as you move from radio button to radio button whether or not
you are in forms mode.
Also, it seems that W-E truncates the legend text length such that you have
to manually navigate line-by-line to listen to the full <legend> text again.
This seems to happen with a legend length greater than 80 characters.
I tried a few other variations of using <ul> or <dl> structure as these were
suggested methods in books on Web standards. Interestingly, when I set up a
definition list and navigated to each form field with the "F" hotkey in JAWS
5.x and 7.0, the content within the <dl> tag was read followed by the answer
(content in the <dd>), much like you would expect for the <legend> element.
This worked for JAWS 5.x and 7.0, but now it does not work for JAWS 7.1. I
love it when JAWS changes how it works from version to version...
In any case, as soon as you turned on the "forms mode", only the
fieldset/legend combination was recognized with JAWS. Sorry, I don't have
any info on Supernova/HAL right now.
Take care,
sean
Sean Keegan
Web Accessibility Instructor
High Tech Center Training Unit, California Community Colleges
From: Moore, Michael
Date: Fri, Aug 25 2006 7:10AM
Subject: RE: More fun with forms and JAWS
← Previous message | No next message
Thanks Sean,
This is good info, I am not sure if it will change our standards here,
at least for internal, but I definitely think that we should encourage
the use of <select> over radio whenever practical to achieve the best
compromise. Its too bad that there is not a way get line wrapping into
the individual <option>s. Of course if we could do that, then we could
accomplish it with fieldsets too.
We have the same problems with the changes from version to version of
JAWS too. We are still on 6.1 because of the incompatibility between
JAWS 7.x and ZoomText, many members of our staff use both. We are
really nervous about what is going to happen when Vista comes along.
Our best information is that Freedom Scientific is struggling to be
ready, GW Micro is the closest of the screen reader builders, and that
the new interface is a major pain with any screen magnifier because of
the 3D.
Mike
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of sean keegan
Sent: Thursday, August 24, 2006 5:48 PM
To: 'WebAIM Discussion List'
Subject: RE: [WebAIM] More fun with forms and JAWS
Hi Mike,
> Finally, is the behavior of JAWS 6.1 typical of other screen readers.
> Does anyone have experience with Window Eyes, HAL, JAWS 7.1 etc.
I can answer a bit with Window-Eyes 5.5. By default, Window-Eyes seems
to not read the <legend> information unless you go into the Verbosity
and tell it to insert a beginning/end message for fieldsets. Then, W-E
only reads when you are entering the fieldset or exiting the fieldset -
it does not appear to read as you move from radio button to radio button
whether or not you are in forms mode.
Also, it seems that W-E truncates the legend text length such that you
have to manually navigate line-by-line to listen to the full <legend>
text again.
This seems to happen with a legend length greater than 80 characters.
I tried a few other variations of using <ul> or <dl> structure as these
were suggested methods in books on Web standards. Interestingly, when I
set up a definition list and navigated to each form field with the "F"
hotkey in JAWS 5.x and 7.0, the content within the <dl> tag was read
followed by the answer (content in the <dd>), much like you would expect
for the <legend> element.
This worked for JAWS 5.x and 7.0, but now it does not work for JAWS 7.1.
I love it when JAWS changes how it works from version to version...
In any case, as soon as you turned on the "forms mode", only the
fieldset/legend combination was recognized with JAWS. Sorry, I don't
have any info on Supernova/HAL right now.
Take care,
sean
Sean Keegan
Web Accessibility Instructor
High Tech Center Training Unit, California Community Colleges
Address list
messages to = EMAIL ADDRESS REMOVED =