E-mail List Archives
Thread: Alternatives to LEGEND for a radio button?
Number of posts in this thread: 36 (In chronological order)
From: D A
Date: Mon, Aug 24 2009 2:35PM
Subject: Alternatives to LEGEND for a radio button?
No previous message | Next message →
I'm trying to get a form formatted so that LABELS and nested LEGENDS
look the same. An example scenario:
Legend1
label1 | [textbox1]
label2 | [textbox2]
nested legend | () radioButtonLabel1 () radioButtonLabel2
The goal is to have a form with labels on the left, fields on the
right formatted via CSS.
Because labels apply to the form field itself, it appears one should
use a legend to style a group of radiobutton lists (or checkboxes).
The problem is the buggy browser support of the legend tag, especially
in Firefox.
The (seemingly) accepted workaround is to wrap the legend content in a
span and then style the span.
The catch with that is if you are using percentage widths. The problem
is that the span's percentage width is based on the width of the
legend's content, which obviously will vary depending on the content.
So, my questions:
1) From an accessibility standpoint, it nesting a legend like this acceptable?
if so,
2) Anyone know of legend content CSS fix that will accommodate a
percentage width?
if not.
3) Would there be another tag that is acceptable in this scenario?
I've read that some have just abandoned use of the legend tag due to
all the styling issues and instead use a header tag of some sort.
Opinions?
-Darrel
From: D A
Date: Wed, Aug 26 2009 12:40PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
> 3) Would there be another tag that is acceptable in this scenario?
> I've read that some have just abandoned use of the legend tag due to
> all the styling issues and instead use a header tag of some sort.
Well, that's what I did. Fighting the legend tag was just too much. So
I'm swapping in an H2. Any comments on the following markup exampe?
<form>
<fieldset>
<legend>Fieldset Legend</legend>
<ol>
<li>
<label for="name">Name</label>
<input type="text" id="name" />
</li>
<li>
<label for="address1">Address<em>*</em></label>
<input type="text" id="address1" />
</li>
<li>
<h2>formatted as label for group elements</h2>
<div class="radioButtonGroup">
<label><input type="radio"
name="invoice-address" />Yes</label>
<label><input type="radio"
name="invoice-address" />No</label>
</div>
</li>
</ol>
</fieldset>
</form>
-Darrel
From: Steven Henderson
Date: Thu, Aug 27 2009 2:05AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
Darrel,
I'm just curious as to why you're using an ordered list as opposed to an
unordered list?
Steven
From: D A
Date: Thu, Aug 27 2009 8:35AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
> I'm just curious as to why you're using an ordered list as opposed to an
> unordered list?
I think it came down to 'well, it's a form you fill out in order, so
ordered lists makes a tad more sense than unordered'.
I'm not married to the OL, though. Are there some good arguments for
making it a UL? Or maybe not a list at all? The primary purpose was to
create block level elements (LI) so we could format the items via CSS.
Going back to the legend vs. header issue, I haven't really found much
in the way of strong opinions either way.
-Darrel
From: Geof Collis
Date: Thu, Aug 27 2009 8:40AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
>Hi Darrel
>
>Personally I find using lists in a situation like this more useless
>chatter that I dont need from my screen reader.
>
>
>cheers
>
>Geof
Editor
Accessibility News
www.accessibilitynews.ca
Accessibility News International
www.accessibilitynewsinternational.com
From: ben morrison
Date: Thu, Aug 27 2009 8:50AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
On Thu, Aug 27, 2009 at 3:30 PM, D A< = EMAIL ADDRESS REMOVED = > wrote:
> Going back to the legend vs. header issue, I haven't really found much
> in the way of strong opinions either way.
"screenreaders ignore headings, paragraphs and other non-forms
elements when in forms mode, so text in headings might not be read out
once a screenreader user starts to fill out the form." [0]
Ben
http://www.accessifyforum.com/viewtopic.php?p=62196
--
Ben Morrison
From: D A
Date: Thu, Aug 27 2009 8:55AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
>>Personally I find using lists in a situation like this more useless
>>chatter that I dont need from my screen reader.
Geof:
Interesting! Do you hear chatter with both UL and OL? If so, would you
suggest we use a generic wrapper instead, such as a DIV?
As a screen reader user, did you have an opinion on using legend vs.
h2 to identify a group of check boxes or radio buttons?
-Darrel
From: D A
Date: Thu, Aug 27 2009 9:00AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
> "screenreaders ignore headings, paragraphs and other non-forms
> elements when in forms mode, so text in headings might not be read out
> once a screenreader user starts to fill out the form." [0]
Now why would a screen reader do that? Ugh!
I'm tempted to consider this an issue and figure out a way to deal
with the inability to style Legend tags properly. However, this seems
to maybe be more of a bug/oversight of the screen readers themselves.
If a screen reader ignores any non-form element, I assume that also
means it's not picking things up like tips (additional text, often a
paragraph) next to form elements to help the user.
Of course, that same thread mentions the following:
"To complicate matters further, there are also bugs with some versions
of Jaws and nested fieldset legends."
Anyone know if these issues (ignoring headers in a form, bug with
nested fieldsets) are primarily limited to JAWS or is it a more
universal issue with screen readers in general?
-Darrel
From: Geof Collis
Date: Thu, Aug 27 2009 9:05AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
>Hi Darrel
>
>I suppose if you need to style it I would use a div, like many I go
>through a form first because too many times I'll miss stuff inn forms mode.
>
>cheers
>
>Geof
Editor
Accessibility News
www.accessibilitynews.ca
Accessibility News International
www.accessibilitynewsinternational.com
From: ben morrison
Date: Thu, Aug 27 2009 9:25AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
On Thu, Aug 27, 2009 at 3:56 PM, D A< = EMAIL ADDRESS REMOVED = > wrote:
> I'm tempted to consider this an issue and figure out a way to deal
> with the inability to style Legend tags properly. However, this seems
> to maybe be more of a bug/oversight of the screen readers themselves.
Thats front end web development for ya!
Stick with the span technique, using display block, relative/absolute
positioning etc you should be able to achieve any layout required
Ben
--
Ben Morrison
From: D A
Date: Thu, Aug 27 2009 9:40AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
> Stick with the span technique, using display block, relative/absolute
> positioning etc you should be able to achieve any layout required
Ben:
Alas, that just doesn't work with the Legend tag. There are some major
bugs--especially in firefox--that prevent various styling and
positioning options for Legend.
The visual issue, in our case, is that titles groups of checkboxes or
radio buttons visually need to be shown just like standard
label/textbox fields. Label in the left column, field in the right.
Off the top of my head (I haven't tested these yet) I see a couple of options:
Option 1:
<legend>This is the group title (display: none)</legend>
<h2>This is the group title</h2>
Idea behind that option is that screen readers would read the legend,
everyone else would see the h2. But it's ugly as we're repeating
content in the markup.
Option 2:
<h2>This is the group title</h2>
<label><span position: off screen>This is the group title</span>
option 1 <checkbox></label>
<label><span>option 2 <checkbox></label>
Again, ugly repeating of content.
And in both cases, it seems that things would get redundant for folks
like Goef who scan through a form twice in both forms mode and
non-forms mode.
-Darrel
From: ben morrison
Date: Thu, Aug 27 2009 9:50AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
On Thu, Aug 27, 2009 at 4:39 PM, D A< = EMAIL ADDRESS REMOVED = > wrote:
>> Stick with the span technique, using display block, relative/absolute
>> positioning etc you should be able to achieve any layout required
>
> Ben:
>
> Alas, that just doesn't work with the Legend tag. There are some major
> bugs--especially in firefox--that prevent various styling and
> positioning options for Legend.
>
> The visual issue, in our case, is that titles groups of checkboxes or
> radio buttons visually need to be shown just like standard
> label/textbox fields. Label in the left column, field in the right.
Can you provide an example of how it is supposed to look - with header
will do....
> Off the top of my head (I haven't tested these yet) I see a couple of options:
>
> Option 1:
>
> <legend>This is the group title (display: none)</legend>
> <h2>This is the group title</h2>
>
> Idea behind that option is that screen readers would read the legend,
> everyone else would see the h2. But it's ugly as we're repeating
> content in the markup.
Display:none will not be read by a screenreader and it is duplicate content
ben
--
Ben Morrison
From: Moore,Michael
Date: Thu, Aug 27 2009 10:20AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
Darrel wrote:
"Anyone know if these issues (ignoring headers in a form, bug with
nested fieldsets) are primarily limited to JAWS or is it a more
universal issue with screen readers in general?"
I am most familiar with JAWS but have seen the same behavior in Window Eyes. I will use JAWS behavior in my examples.
First a bit of background on how JAWS works. This is similar to other screen readers.
JAWS has two basic modes for working with HTML a reading mode and a forms mode. (I will leave out the JAWS cursor for simplicity) In reading mode (PC cursor) JAWS loads the HTML content into a buffer and allows quick navigation within the content through a variety of keyboard commands. Thus I can navigate to the next heading using just the "H" key or find a form with the "F" key. This works great for most content but what happens when I need to complete a form? If I am trying to enter "Happy Friday" into a text field in normal reading mode JAWS will send me to the next heading then to the next form field. Not what I want at all. Thus the reason for a forms mode. When forms mode is turned on "Insert + numpad /" The keyboard will act as a normal input device to the form and I can happily type "Happy Friday" into the form field. However I no longer have access to my quick navigation keys. However I can move from form input to form input with the Tab key. In my experience this i
s typical behavior for most screen reader users. Get to a text field, enter forms mode then navigate with Tab navigation.
The problem with this approach is that using Tab navigation I only hear the items that are included in the tab ring. Thus form instructions, and questions at the beginning of a group of multiple choice selections are frequently missed when they are coded using heading or paragraph markup. If these items are included in a legend element, they are announced for every item within that fieldset. This can be a bit tedious too. Consider listening to "What is your favorite color, red radio button unchecked, what is your favorite color, blue radio button not checked, what is your favorite color..."
Next to the issue of nested fieldsets and legends. JAWS announces the legend that is closest within the hierarchy. So you might have a legend "Personal Information section" followed by name and address inputs, then a nested subsection for telephone numbers where the legend is phone numbers and the inputs are for home, work and cell phone numbers" JAWS would repeat the first legend for the name and address, then the second for home work and cell. Personally when using fieldsets and legends I like to just avoid nesting, this is not the most correct method semantically but it works well and is very predictable.
Legend elements are very difficult to style reliably cross browser and cross platform, particularly when they get long. Headings and paragraph elements offer an arguably better semantic and stylable approach for questions and instructions within a form. But how to get them within the tab ring. My friend Jim Allan has come up with a possible solution. Wrapping these within a div then setting the tab index on the div to 0 will place them in the tab ring and allow them to be found in the proper order with a screen reader. The cost is a couple of extra tab stops which may increase the burden for physically disabled users.
Mike Moore
From: Chris Pearce
Date: Thu, Aug 27 2009 4:25PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
> "screenreaders ignore headings, paragraphs and other non-forms
> elements when in forms mode, so text in headings might not be read out
> once a screenreader user starts to fill out the form." [0]
Also I work with ASP.NET websites which require the entire HTML body to be wrapped in a form tag unless of course you use MVC which I'm fighting for!
From: Chris Pearce
Date: Thu, Aug 27 2009 4:40PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
> Stick with the span technique, using display block, relative/absolute
> positioning etc you should be able to achieve any layout required
The span technique is limited especially when the legend needs to be positioned to the left and inputs to the right, I believe this can't be done. Using absolute positioning in most cases isn't suitable as it's taken out of the normal flow of the document. I've given up on trying to achieve this. At the end of the day legends are extremely limited in terms of styling.
solutions for a digital world
----------------------------------------
Introducing Dimensions...The end-to-end enterprise ecommerce solution.
Start, grow and manage your online business with Dimensions.
----------------------------------------
level 1, 11 albany street
st leonards nsw 2065
----------------------------------------
p: 02 9467 2500
d: 02 9467 25
f: 02 9431 5999
e: = EMAIL ADDRESS REMOVED =
w: www.bluearcgroup.com
----------------------------------------
Privileged - Private & Confidential
This email and files transmitted with it are intended solely for the use of the addressee(s) and may contain information which is confidential or privileged. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this email or any attachment is prohibited. If you receive this email and you are not the addressee, or you have received this email in error, please disregard the contents of the email, delete the email and notify the author immediately.
Please consider the environment before printing this e-mail
From: Chris Hoffman
Date: Thu, Aug 27 2009 9:00PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
For Firefox at least (I don't have copies of IE or Safari on hand
right now to play with), you could repeat the legend in the title
attribute of the fieldset itself (easy enough to do with a CMS
template), and then display it, with whatever style you want, with
generated CSS content. For example:
Markup:
<fieldset title="Personal Info">
<legend><span>Personal Info</span></legend>
<!-- form elements -->
</fieldset>
CSS:
fieldset:before {
content: attr(title);
display: block;
/* other styles */
}
/* Hide the actual legend off screen */
legend {
padding: 0;
}
legend span {
position: absolute;
left: -9999px;
}
This would avoid the repeated content problem of the heading solution
(as long as you don't consider the title attribute to be "content"),
and would arguably be a legitimate use for the title attribute.
Conditional comments can be used to target alternative styles to
browsers that don't support generated content (IE 7 and below, e.g.).
Chris
On Thu, Aug 27, 2009 at 6:36 PM, Chris
Pearce< = EMAIL ADDRESS REMOVED = > wrote:
>> Stick with the span technique, using display block, relative/absolute
>> positioning etc you should be able to achieve any layout required
>
> The span technique is limited especially when the legend needs to be positioned to the left and inputs to the right, I believe this can't be done. Using absolute positioning in most cases isn't suitable as it's taken out of the normal flow of the document. I've given up on trying to achieve this. At the end of the day legends are extremely limited in terms of styling.
>
>
> solutions for a digital world
> ----------------------------------------
>
> Introducing Dimensions...The end-to-end enterprise ecommerce solution.
> Start, grow and manage your online business with Dimensions.
> ----------------------------------------
> level 1, 11 albany street
> st leonards nsw 2065
> ----------------------------------------
> p: 02 9467 2500
> d: 02 9467 25
> f: 02 9431 5999
> e: = EMAIL ADDRESS REMOVED =
> w: www.bluearcgroup.com
> ----------------------------------------
> Privileged - Private & Confidential
> This email and files transmitted with it are intended solely for the use of the addressee(s) and may contain information which is confidential or privileged. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this email or any attachment is prohibited. If you receive this email and you are not the addressee, or you have received this email in error, please disregard the contents of the email, delete the email and notify the author immediately.
>
> Please consider the environment before printing this e-mail
>
>
>
From: D A
Date: Fri, Aug 28 2009 3:25PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
> Also I work with ASP.NET websites which require the entire HTML body to be wrapped in a form tag unless of course you use MVC which I'm fighting for!
I don't have JAWS, but did grab the new OS NVDA reader. It seems to do
the same as JAWS in that it only reads the LABELS of the form fields
one tabs into.
I can't speak to JAWS, but I did try it on some .net pages (as I had
the same thought as that could be an issue with .net's 'every page is
a form' model) and I didn't have that issue.
So I wonder if 'forms mode' is more or less just activated once you
start tabbing into form fields.
Mike...EXCELLENT info on the 'tab ring' concept. I didn't get a chance
to get back into this project this week but will give your suggestion
of giving the header a tab index of 0 within the form next week.
Fingers crossed that that will work as it sounds like a nice
compromise!
-Darrel
From: Geof Collis
Date: Fri, Aug 28 2009 4:50PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
>So I wonder if 'forms mode' is more or less just activated once you
>start tabbing into form fields.
*Forms mode is activate when I want it to,
although JAWS 6.0 sometimes automatically goes int forms mode.
>Mike...EXCELLENT info on the 'tab ring' concept. I didn't get a chance
>to get back into this project this week but will give your suggestion
>of giving the header a tab index of 0 within the form next week.
>Fingers crossed that that will work as it sounds like a nice
>compromise!
*I'm getting really confused with all the "hacks"
people on this list are speaking of. If I as a
JAWS user tab through a form and memorize the
order of the form fields and then you use
"tabindex" to change the order, how does that
help? Does it go against the following
F44: Failure of Success Criterion 2.4.3 due to
using tabindex to create a tab order that does
not preserve meaning and operability
Perhaps I missed something, but why are you using
headings in a form? Again I dont need useless
chatter when filling out forms. What I need is to
go into forms mode, be able to tab from one field
to another complete the task and then finish the
task, I dont need someone making the form look
good at the expense of a screen reader user.
cheers
Geof
Editor
Accessibility News
www.accessibilitynews.ca
Accessibility News International
www.accessibilitynewsinternational.com
From: Moore,Michael
Date: Mon, Aug 31 2009 6:50AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
Historically forms mode has been something controlled by the user, at least until JAWS 10. In JAWS 10 forms mode is activated automatically when a user enters a text field, it is not needed for radio buttons or check boxes. This "auto forms mode" feature can be turned off by the user. In testing we have found that auto forms mode has some issues, particularly when there is a bit of client side scripting running. The latest patches for JAWS 10 work better but it still is a little buggy.
Mike Moore
From: D A
Date: Fri, Sep 04 2009 12:20PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
> Perhaps I missed something, but why are you using
> headings in a form? Again I dont need useless
> chatter when filling out forms.
Well, I really hope it's not useless chatter. The reason we're using
them is in the scenario where you have a group of checkboxes or radio
buttons inside a fieldset.
Example:
Fieldset
Legend
Label | field
Label | field
H2 for checkboxes
label | checkbox
label | checkbox
label | checkbox
The issue is that the group of checkboxes will often need some sort of
'group heading'.
The problem with using a legend is two fold (it seems):
1) legends are nearly impossible to visual style with CSS with any
consistency in most browsers.
2) nested legends appear to add to the chatter issue.
I still haven't gotten a chance to try out Michael's suggestion of
using a tab index of 0, though. But I hope it work.
-Darrel
From: Geof Collis
Date: Fri, Sep 04 2009 4:10PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
Hi Darrel
First off I'm not sure who decided that I as a screen reader need the
"legend" tag. When I have used it in the past I found it annoying to
be subjected to the same phrase in front of every option, be it radio
button or checkbox, for example
what is your favourite colour checkbox not checked blue
what is your favourite colour checkbox not checked red
what is your favourite colour checkbox not checked green
what is your favourite colour checkbox not checked yellow
and so on. Imagine if you had to listen to that inn a very complex
form. Would you consider it useless chatter?
Perhaps I'm an oddball but i rarely use forms mode any more because
of the garbage coding that I run into. I can activate a radio
buttonor checkbox without going into forms mode, when I need to enter
a text field I'll use forms mode, fill in the text then exit it
because I'm never sure where it will take me next. I'm never sure if
using the enter button or spacebar will activate it either that's
how bad it is out there.
I just want the form to be a form, not something cooked up to make
it look good for the sighted or pass some suspect guideline and I
want the least amount of chatter from JAWS. I dont want my form
broken up by headings either. Then again maybe I'm asking to much.
cheers
Geof
Editor
Accessibility News
www.accessibilitynews.ca
Accessibility News International
www.accessibilitynewsinternational.com
From: Bevi Chagnon | PubCom
Date: Fri, Sep 04 2009 5:45PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
Geoff wrote:
> First off I'm not sure who decided that I as a screen reader need the
> "legend" tag.
From what I can tell, the "decision makers" appear to be sighted,
non-disabled folks who mean well but often take things to an absurd level.
I wish our guidelines could be written by screen-reader users like you,
Geoff.
And I wish our software developers would listen to you, too.
I joined this list (I lurk A LOT) because I wanted to hear what blind,
low-vision, and disabled users have to say. But what I hear from listmates
often conflicts with accessibility guidelines.
How do we change this?
--Bevi Chagnon
(trainer and consultant to federal govt publishers and web developers)
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . .
Bevi Chagnon | = EMAIL ADDRESS REMOVED = | www.PubCom.com
Government and non-profit publishing specialists for print, web, marketing,
Acrobat, & 508
PublishingDC Group Co-Moderator |
http://groups.yahoo.com/group/PublishingDC
Bevi blogs on Facebook |
www.facebook.com/pages/Takoma-Park-MD/PubCom/139231069223
And she tweets on Twitter | www.twitter.com/pubcom
. . . . . . . . . . . . . . . . . . . . . . . . . .
. .
From: Steve Green
Date: Fri, Sep 04 2009 7:05PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
How do we change this? Easy. All the so-called accessibility experts need to
start doing some user testing with disabled participants and assistive
technologies. It is shocking how many have no experience of this kind at
all. A few might have downloaded a screen reader and played with it (which
will teach them nothing) but almost no one is doing user testing and even
fewer are doing pure research.
I participate in the Web Standards Group (WSG) email list, and most members
are naturally in favour of adherence to standards. But you would not believe
the hostility towards the idea that designers should take into account
people's differing needs when designing websites. There is a large body of
opinion that says designers should code to standards and users should look
after themselves. If their assistive technologies don't play nicely with the
website, the user should complain to the AT vendor not the website designer.
And these are the enlightened designers. The vast majority don't even care
about standards compliance.
The fact is it's easy to do standards-compliant design, and that's what
those designers want to do. If the HTML Validator says the site is compliant
then the job is done. But they then want to pretend that this equates to
accessible design, which it in no way does.
Accessible design is much harder and there is usually no right answer - we
are always balancing conflicting requirements. That's what makes it a
profession rather than a trade, and it's what makes it interesting. We
discuss our experiences and slowly move towards better compromises. Sadly
there are very few of us doing it right now.
Rant over.
Steve Green
Director
Test Partners Ltd
From: Geof Collis
Date: Sat, Sep 05 2009 7:20AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
>
>How do we change this?
Hi Bevi
I suppose the only thing we can do it speak out, although some might
be well meaning, just because we haven't written books or articles on
the matter doesn't make our view any less important, in fact I'd
argue we are more important because we have to live the garbage code
every single minute we are on our computers, from web sites to web
applications to desktop software programs. There is no end to the frustration
cheers
Geof
Editor
Accessibility News
www.accessibilitynews.ca
Accessibility News International
www.accessibilitynewsinternational.com
From: Jukka K. Korpela
Date: Sat, Sep 05 2009 11:15AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
Geof Collis wrote:
> First off I'm not sure who decided that I as a screen reader need the
> "legend" tag.
I don't know, but you seem to be complaining about bad implementations
rather than specifications or pages.
> When I have used it in the past I found it annoying to
> be subjected to the same phrase in front of every option, be it radio
> button or checkbox,
The legend element is heading-like and specifies a common "heading" for a
set of fields that belong together. An author could use a heading element
like h2 or just use text before the fields, but legend is specifically
related to grouping fields.
If a screen reader repeats the legend for every field, then that's a bad
idea, though it would be useful to give a user an optional access to legend.
In a long sequence of fields, the user might loose track of what the
question was.
> for example
>
> what is your favourite colour checkbox not checked blue
> what is your favourite colour checkbox not checked red
That's bad, at least a default behavior. It would be equally bad, and rather
comparable, if a browser repeated the text in an h2 heading before each
paragraph that follows it.
> I just want the form to be a form, not something cooked up to make
> it look good for the sighted or pass some suspect guideline and I
> want the least amount of chatter from JAWS.
If this is a JAWS problem, then JAWS, or maybe settings, need fixing. After
all, more than 99% of web users are not using JAWS, so it would be
disproportionate to remove a reasonably designed element from HTML
specifications or stop using it. Besides, authors won't stop using it and
won't modify existing pages and software to remove legend and fieldset
elements.
> I dont want my form
> broken up by headings either. Then again maybe I'm asking to much.
You are, since the "headings" are in this case important texts that indicate
what the question is or what topic some questions relate to. They are not
supposed break a form up any more than subheadings break a document -
rather, they help in grouping things and giving a group an understandable
identity.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
From: Geof Collis
Date: Sat, Sep 05 2009 11:55AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
>Hi Yucca
>
>
>
>I don't know, but you seem to be complaining about bad implementations
>rather than specifications or pages.
>Geof:
>I like how some people always refer to it as complaining, I get
>that a lot when trying to advocate for accessibility issues. :O)
> > When I have used it in the past I found it annoying to
> > be subjected to the same phrase in front of every option, be it radio
> > button or checkbox,
>
>The legend element is heading-like and specifies a common "heading" for a
>set of fields that belong together. An author could use a heading element
>like h2 or just use text before the fields, but legend is specifically
>related to grouping fields.
>
>If a screen reader repeats the legend for every field, then that's a bad
>idea, though it would be useful to give a user an optional access to legend.
>In a long sequence of fields, the user might loose track of what the
>question was.
>Geof:
>Perhaps it would be just as easy to put one question per page in
>that case, all one would need is the heading at the beginning, I am
>using a program right now that allows you to create tests and it
>gives me the option of 1 question per page. I like it very much.
>
> > for example
> >
> > what is your favourite colour checkbox not checked blue
> > what is your favourite colour checkbox not checked red
>
>That's bad, at least a default behavior. It would be equally bad, and rather
>comparable, if a browser repeated the text in an h2 heading before each
>paragraph that follows it.
>
> > I just want the form to be a form, not something cooked up to make
> > it look good for the sighted or pass some suspect guideline and I
> > want the least amount of chatter from JAWS.
>
>If this is a JAWS problem, then JAWS, or maybe settings, need fixing. After
>all, more than 99% of web users are not using JAWS, so it would be
>disproportionate to remove a reasonably designed element from HTML
>specifications or stop using it. Besides, authors won't stop using it and
>won't modify existing pages and software to remove legend and fieldset
>elements.
>Geof:
>Personally I dont run into very many sites that use the fieldset and
>legend elements anyway. Again I refer to this program I am using
>ATutor, it has many forms in it, the fieldset and legend elements
>are used at the beginning of the formbut it does not create extra chatter
> > I dont want my form
> > broken up by headings either. Then again maybe I'm asking to much.
>
>You are, since the "headings" are in this case important texts that indicate
>what the question is or what topic some questions relate to. They are not
>supposed break a form up any more than subheadings break a document -
>rather, they help in grouping things and giving a group an understandable
>identity.
>
>Geof:
>
>Again as I said above, putting questions on separate pages might
>also be an option. I find it interesting that in the past I have
>filled out many forms without headings and other semantic markup and
>had no problems. One of the first things I was taught in the JAWS
>manual on using web forms was to go through the whole form first
>before filling it out, that way I got a better understanding of the
>contents. But hey,that's just me complainig and asking too much. :O)
>
>cheers
>
>Geof
Editor
Accessibility News
www.accessibilitynews.ca
Accessibility News International
www.accessibilitynewsinternational.com
From: E.J. Zufelt
Date: Sat, Sep 05 2009 12:00PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
I haven't really followed this conversation, but being a web developer
and JAWS (and various other screen-readers) user I have to say that I
have no real concerns about the use of the legend element. I would
like it if JAWS provided an option to only speak the heading once when
entering a fieldset, and then provided a keystroke to access the
legend at any other point in time, but this is a JAWS implementation
problem, and not a deficit in fieldset / legend being semantically
correct markup.
HTH,
Everett
Follow me on Twitter
http://twitter.com/ezufelt
View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt
On 5-Sep-09, at 1:51 PM, Geof Collis wrote:
>
>> Hi Yucca
>>
>>
>>
>> I don't know, but you seem to be complaining about bad
>> implementations
>> rather than specifications or pages.
>> Geof:
>> I like how some people always refer to it as complaining, I get
>> that a lot when trying to advocate for accessibility issues. :O)
>>> When I have used it in the past I found it annoying to
>>> be subjected to the same phrase in front of every option, be it
>>> radio
>>> button or checkbox,
>>
>> The legend element is heading-like and specifies a common "heading"
>> for a
>> set of fields that belong together. An author could use a heading
>> element
>> like h2 or just use text before the fields, but legend is
>> specifically
>> related to grouping fields.
>>
>> If a screen reader repeats the legend for every field, then that's
>> a bad
>> idea, though it would be useful to give a user an optional access
>> to legend.
>> In a long sequence of fields, the user might loose track of what the
>> question was.
>> Geof:
>> Perhaps it would be just as easy to put one question per page in
>> that case, all one would need is the heading at the beginning, I am
>> using a program right now that allows you to create tests and it
>> gives me the option of 1 question per page. I like it very much.
>>
>>> for example
>>>
>>> what is your favourite colour checkbox not checked blue
>>> what is your favourite colour checkbox not checked red
>>
>> That's bad, at least a default behavior. It would be equally bad,
>> and rather
>> comparable, if a browser repeated the text in an h2 heading before
>> each
>> paragraph that follows it.
>>
>>> I just want the form to be a form, not something cooked up to make
>>> it look good for the sighted or pass some suspect guideline and I
>>> want the least amount of chatter from JAWS.
>>
>> If this is a JAWS problem, then JAWS, or maybe settings, need
>> fixing. After
>> all, more than 99% of web users are not using JAWS, so it would be
>> disproportionate to remove a reasonably designed element from HTML
>> specifications or stop using it. Besides, authors won't stop using
>> it and
>> won't modify existing pages and software to remove legend and
>> fieldset
>> elements.
>> Geof:
>> Personally I dont run into very many sites that use the fieldset and
>> legend elements anyway. Again I refer to this program I am using
>> ATutor, it has many forms in it, the fieldset and legend elements
>> are used at the beginning of the formbut it does not create extra
>> chatter
>>> I dont want my form
>>> broken up by headings either. Then again maybe I'm asking to much.
>>
>> You are, since the "headings" are in this case important texts that
>> indicate
>> what the question is or what topic some questions relate to. They
>> are not
>> supposed break a form up any more than subheadings break a document -
>> rather, they help in grouping things and giving a group an
>> understandable
>> identity.
>>
>> Geof:
>>
>> Again as I said above, putting questions on separate pages might
>> also be an option. I find it interesting that in the past I have
>> filled out many forms without headings and other semantic markup and
>> had no problems. One of the first things I was taught in the JAWS
>> manual on using web forms was to go through the whole form first
>> before filling it out, that way I got a better understanding of the
>> contents. But hey,that's just me complainig and asking too much. :O)
>>
>> cheers
>>
>> Geof
>
> Editor
> Accessibility News
> www.accessibilitynews.ca
> Accessibility News International
> www.accessibilitynewsinternational.com
>
>
>
From: Geof Collis
Date: Sat, Sep 05 2009 12:10PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
HiYucca
You wrote:
If this is a JAWS problem, then JAWS, or maybe settings, need fixing. After
all, more than 99% of web users are not using JAWS, so it would be
disproportionate to remove a reasonably designed element from HTML
specifications or stop using it. Besides, authors won't stop using it and
won't modify existing pages and software to remove legend and fieldset
Geof:
Had to reply to this again, you seem to be saying that since JAWS
users are only 1% of web users then it doesn't seem appropriate to
change it just for 1%, but on the other hand yousay it is necessary
which seems to suggest that it is a visual thing so why not just use
css to create the grouping effect?
cheers
Geof
Editor
Accessibility News
www.accessibilitynews.ca
Accessibility News International
www.accessibilitynewsinternational.com
From: deblist
Date: Sat, Sep 05 2009 7:05PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
On Sat, 5 Sep 2009, Steve Green wrote:
> How do we change this? Easy. All the so-called accessibility experts need to
> start doing some user testing with disabled participants and assistive
> technologies. It is shocking how many have no experience of this kind at
> all. A few might have downloaded a screen reader and played with it (which
> will teach them nothing) but almost no one is doing user testing and even
> fewer are doing pure research.
I cannot second this enough. I am a disabled Web developer who
uses accessibility technology, and it astonishes me how many
people I talk to defend themselves with "but I followed a
standard" when I tell them "but I can't use your page."
The open source project I work on has an active accessibility
community in which the developers responsible for design come in
to talk to the disabled user community every time they have
questions about design, and listen to the feedback from the
disabled community. Two of the developers on the project are
disabled ourselves. Moreover, just because we're disabled we
don't think we have all the answers. For example, sometimes I
will give standards-based answers about screen readers (I am a
NaturallySpeaking user), and one of our actual blind users will
come in and tell me that I'm wrong about the way JAWS gets used
in the real world, as opposed to according to the documentation.
It's incredible design and I wish more projects get it.
-deborah
From: D A
Date: Tue, Sep 08 2009 9:00AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
> First off I'm not sure who decided that I as a screen reader need the
> "legend" tag. When I have used it in the past I found it annoying to
> be subjected to the same phrase in front of every option, be it radio
> button or checkbox, for example
>
> what is your favourite colour checkbox not checked blue
> what is your favourite colour checkbox not checked red
> what is your favourite colour checkbox not checked green
> what is your favourite colour checkbox not checked yellow
This is exactly why I'd like to use a header to group the checkboxes
rather than a legend. Or, at least half of the reason.
But in terms of the larger group of form fields, Legend seems to be
the de-facto standard (both in terms of web standards and habit).
That said, if JAWS reads the header before each field, yea, I'd say
that'd be annoying, useless chatter.
So I guess that raises the question as to what is the culprit: Bad web
standards? Bad decision by Freedom Scientific? Verbose JAWS
preferences set by the user?
I agree that there needs to be pragmatic testing for accessibility, as
'standards' aren't any sort of magic bullet. That said, I'm also not a
fan of going against web standards because of one particular software
company's web browser (be it Microsoft, Freedom Scientific, or any
other particular developer).
I do appreciate the insights, though!
Geof, you mentioned the following:
> I just want the form to be a form, not something cooked up to make
> it look good for the sighted or pass some suspect guideline and I
> want the least amount of chatter from JAWS. I dont want my form
> broken up by headings either. Then again maybe I'm asking to much.
In your opinion, how would you prefer that a group of checkboxes be
identified? For instance, if this were a list of checkboxes with
labels:
cheese
eggs
onions
How would you prefer they be grouped? It seems to me that there needs
to be some sort of way to identify those three form fields and their
labels as "Choose your omelet ingredients" but I'm not entirely sure
what I should be using mark-up wise to accomplish that. Legend seemed
like the standard answer per web standards but due to both visual
rendering and verbose audio rendering, it seems like the worst option.
An H2 sounds like it might be OK as it should only be read once. The
key is to make sure it *is* read at least once in most screen readers
(rather that skipped over when in forms mode).
-Darrel
From: Geof Collis
Date: Tue, Sep 08 2009 10:45AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
Hi Darrel
In the case of radio buttons JAWS tells me how
many to choose from, checkboxes aren't but it is
just as easy to tab over them, out of JAWS mode
and hit the space bar to select which ones I
want. I personally just need text in front of the
list of items telling me to make my choice as follows:
1)What are your favourite foods,please check all that apply:
chees
eggs
onions
2)What are your favourite colours, please check all that apply:
blue
red
green
and so on.
It seems to me that forms are changing to the
point of being noisy, or too much information
that I dont need to hear, I'm of the mindset of
keeping it simple. Perhaps I'm alone on this but
I understand breaking up information into
paragraphs headings and lists but forms are
different because of the intricacy of them, it'd
be like anouncing a new paragraph or line everytime I read an article.
Having said that, if I had to choose the lesser
of 2 evils I'd use headings instead of legend.
I'm not aware that JAWS announces a heading the same way it does legend.
cheers
Geof
>Geof, you mentioned the following:
>
> > I just want the  form to be a form, not something cooked up to make
> > it look good for the sighted or pass some suspect guideline and I
> > want the least amount of chatter from JAWS. I dont want my form
> > broken up by headings either. Then again maybe I'm asking to much.
>
>In your opinion, how would you prefer that a group of checkboxes be
>identified? For instance, if this were a list of checkboxes with
>labels:
>
>cheese
>eggs
>onions
>
>How would you prefer they be grouped? It seems to me that there needs
>to be some sort of way to identify those three form fields and their
>labels as "Choose your omelet ingredients" but I'm not entirely sure
>what I should be using mark-up wise to accomplish that. Legend seemed
>like the standard answer per web standards but due to both visual
>rendering and verbose audio rendering, it seems like the worst option.
>An H2 sounds like it might be OK as it should only be read once. The
>key is to make sure it *is* read at least once in most screen readers
>(rather that skipped over when in forms mode).
>
>-Darrel
>
From: Andrew Kirkpatrick
Date: Tue, Sep 08 2009 10:55AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
Geoff,
Are you aware that you can turn off the voicing of the legend for controls contained in the fieldset?
I think that Evan said it best earlier - that the legend with the fieldset is currently the best way to establish a semantic association between the radios or checkboxes and the group label, and how it is voiced is up to the screen reader application.
Even if all web developers decided that they would all skip fieldset and legend and would all use an HTML heading before a set of radio buttons, you still would need to deal with how any given assistive technology supports that convention. If you don't like the way JAWS reads HTML, you should absolutely raise the issue with Freedom Scientific.
Thanks,
AWK
Andrew Kirkpatrick
Senior Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
From: Geof Collis
Date: Tue, Sep 08 2009 11:30AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
Hi Andrew
I wasn't aware of that, the only thing I can see
is element access, would that be it? I dont like
to turn anything off since I need to hear
everything that is going on because I do accessibility audits and hand code.
cheers
Geof
At 12:50 PM 9/8/2009, you wrote:
>Geoff,
>Are you aware that you can turn off the voicing
>of the legend for controls contained in the fieldset?
>
>I think that Evan said it best earlier - that
>the legend with the fieldset is currently the
>best way to establish a semantic association
>between the radios or checkboxes and the group
>label, and how it is voiced is up to the screen reader application.
>
>Even if all web developers decided that they
>would all skip fieldset and legend and would all
>use an HTML heading before a set of radio
>buttons, you still would need to deal with how
>any given assistive technology supports that
>convention. If you don't like the way JAWS
>reads HTML, you should absolutely raise the issue with Freedom Scientific.
>
>Thanks,
>AWK
>
>Andrew Kirkpatrick
>
>Senior Product Manager, Accessibility
>
>Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
>
>
>
From: Andrew Kirkpatrick
Date: Tue, Sep 08 2009 11:40AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
Geoff,
From the JAWS help file:
If you do not wish to hear the "fieldset" legend information, disable it in Configuration Manager, Verbosity Options. Select the button for the verbosity level you are using. In the Speech Output Types list, move to the Control Group Name check box and press SPACEBAR to clear the check mark. Select Ok to accept your changes, select Ok again, then save the open configuration file to save your settings. For more information, refer to Verbosity Options.
Thanks,
AWK
Andrew Kirkpatrick
Senior Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
From: Geof Collis
Date: Tue, Sep 08 2009 11:55AM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | Next message →
Hi Andrew
I dont have anything for fieldset and legend, I'm
using JAWS 6.0, but as I said I dont want to turn
them off as it will interfere with my ability to
test foraccessibility and useability.
cheers
Geof
At 01:37 PM 9/8/2009, you wrote:
>Geoff,
>
> >From the JAWS help file:
>If you do not wish to hear the "fieldset" legend
>information, disable it in Configuration
>Manager, Verbosity Options. Select the button
>for the verbosity level you are using. In the
>Speech Output Types list, move to the Control
>Group Name check box and press SPACEBAR to clear
>the check mark. Select Ok to accept your
>changes, select Ok again, then save the open
>configuration file to save your settings. For
>more information, refer to Verbosity Options.
>
>Thanks,
>AWK
>
>Andrew Kirkpatrick
>
>Senior Product Manager, Accessibility
>
>Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
>
>
>
From: Andrew Kirkpatrick
Date: Tue, Sep 08 2009 12:15PM
Subject: Re: Alternatives to LEGEND for a radio button?
← Previous message | No next message
I believe that the legend preference used to be in the HTML settings in the configuration manager, but I'm not sure what version this setting was added.
Thanks,
AWK
Andrew Kirkpatrick
Senior Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =