E-mail List Archives

Search E-mail List Archives for

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

From: Kevin White
Date: Wed, Sep 01 2010 9:26PM
Subject: Forms as lists
No previous message | Next message →

Hi All,

I am starting to see forms being presented as lists on a more regular basis but I am struggling to find the rationale for this. Some recent testing with an experienced JAWS user highlighted this as a slight issue for him. My opinion is that this is not an accurate use of semantic markup, however, I am aware that some have argued that a form is a list of questions.

Does anyone have any experience of this? How do screen reader users find this sort of form?

Thanks for any input,

Kevin

From: Rakesh.Paladugula
Date: Thu, Sep 02 2010 11:43AM
Subject: Re: Forms as lists
← Previous message | Next message →

Hi Kevin,
Can you provide with a scenario where a list is used for forms. I can
verify the same.
Regards
Rak

From: Chris Price
Date: Thu, Sep 02 2010 12:03PM
Subject: Re: Forms as lists
← Previous message | Next message →

On 2 September 2010 11:26, Kevin White < = EMAIL ADDRESS REMOVED = > wrote:


> My opinion is that this is not an accurate use of semantic markup, however,
> I am aware that some have argued that a form is a list of questions.
>

Sorry I can't be of practical help here but I can't see how anyone can say
that a form can be semantically described as a list. Almost anything can be
a list if you wish to represent it that way but isn't that more conceptual
than semantic? You could build your form in a table saying it was a matrix
but that wouldn't make it tabular.

Just my penny's worth.

--
Chris Price
0777 629 0227

follow me at http://twitter.com/hypergossip_uk
and http://facebook.com/chris.t.price

From: Kevin White
Date: Thu, Sep 02 2010 12:34PM
Subject: Re: Forms as lists
← Previous message | Next message →

Hi Rak,

This article from A List Apart talks about it (http://www.alistapart.com/articles/prettyaccessibleforms) and this is an example that they provide http://www.alistapart.com/d/prettyaccessibleforms/example_1/

Kevin

On 2 Sep 2010, at 11:33, < = EMAIL ADDRESS REMOVED = > < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Kevin,
> Can you provide with a scenario where a list is used for forms. I can
> verify the same.
> Regards
> Rak
>
>

From: Steve Green
Date: Thu, Sep 02 2010 12:42PM
Subject: Re: Forms as lists
← Previous message | Next message →

Unfortunately this is becoming very common, and the UK's largest website
design company does it on every project. There is no rationale for it and we
flag it as a WCAG non-compliance every time we test a website.

It adds lots of noise for screen reader users and it makes the form less
understandable when viewed without styles.

Steve Green
Director
Test Partners Ltd

From: Rakesh.Paladugula
Date: Thu, Sep 02 2010 5:21PM
Subject: Re: Forms as lists
← Previous message | Next message →

Kevin,
I do agree with Steve's comment. As a screen reader user I too feel
that it will be extra junk of noise out of screen reader which is not
required.

Thanks & regards
Rak

From: Andrew Kirkpatrick
Date: Thu, Sep 02 2010 5:25PM
Subject: Re: Forms as lists
← Previous message | Next message →

Steve,
I'm not sure that I agree that it is a WCAG compliance issue. What's your reasoning?

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems

= EMAIL ADDRESS REMOVED =
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility

From: Steve Green
Date: Thu, Sep 02 2010 12:53PM
Subject: Re: Forms as lists
← Previous message | Next message →

The rationale in the article is incorrect. The appropriate containers for
form controls are <form> and <fieldset> elements, not list elements. A form
isn't a list of form controls any more than a paragraph is a list of
sentences or a page is a list of paragraphs.

The use of ordered lists in his example suggests that he doesn't understand
semantics, because the order of the form controls is not relevant - the
meaning would be the same regardless of their order.

I am disappointed that ALA would publish an article like this.

Steve Green
Director
Test Partners Ltd

From: E.J. Zufelt
Date: Thu, Sep 02 2010 5:35PM
Subject: Re: Forms as lists
← Previous message | Next message →

I have to agree with Andrew here. Some forms are lists of questions, like a survey, others really aren't.

I don't really see any WCAG success criteria that is violated by placing each form question within a list item. That being said I really can't think of many scenarios where I would do this myself.

HTH,
Everett Zufelt
http://zufelt.ca

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



On 2010-09-02, at 7:51 AM, Andrew Kirkpatrick wrote:

> Steve,
> I'm not sure that I agree that it is a WCAG compliance issue. What's your reasoning?
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
>
>
>

From: Julie Romanowski
Date: Thu, Sep 02 2010 5:40PM
Subject: Re: Forms as lists
← Previous message | Next message →

To be fair, the article was published in 2006. ALA's article now are much better when it comes to accessibility.

From: Steve Green
Date: Thu, Sep 02 2010 1:13PM
Subject: Re: Forms as lists
← Previous message | Next message →

My rationale is F43: Failure of Success Criterion 1.3.1 due to using
structural markup in a way that does not represent relationships in the
content - http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F43

Unfortunately the WCAG focus almost entirely on the addition of appropriate
structural markup. Apart from F43 very little is said about the prevention
of superfluous or inappropriate structural markup. For instance we are
starting to see nonsense such as breadcrumbs being marked up as definition
lists or fieldsets around Submit buttons. F43 appears to be the only means
we have of fighting back against these things.

Regards,
Steve

From: Kevin White
Date: Thu, Sep 02 2010 1:20PM
Subject: Re: Forms as lists
← Previous message | Next message →

That is pretty much the rationale that I adopt.

It is good to get the input of other screenreader users as I only really had the one sample to draw upon. He did say much the same as others here have.

I suppose I would question the inclusion of list items less if they were being visually represented as well, but they are not. The list bullet or list number is suppressed in all the examples I have seen of this. This suggests that these are not really lists, and the developers are not thinking of them as lists since they do not present them as lists. If screenreader users are saying that this simply adds clutter then drop them and use non-semantic elements such as div.

Thanks

Kevin

On 2 Sep 2010, at 13:13, Steve Green wrote:

> My rationale is F43: Failure of Success Criterion 1.3.1 due to using
> structural markup in a way that does not represent relationships in the
> content - http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F43
>
> Unfortunately the WCAG focus almost entirely on the addition of appropriate
> structural markup. Apart from F43 very little is said about the prevention
> of superfluous or inappropriate structural markup. For instance we are
> starting to see nonsense such as breadcrumbs being marked up as definition
> lists or fieldsets around Submit buttons. F43 appears to be the only means
> we have of fighting back against these things.
>
> Regards,
> Steve
>
> Address list messages to = EMAIL ADDRESS REMOVED =

From: Jason Kiss
Date: Fri, Sep 03 2010 12:29AM
Subject: Re: Forms as lists
← Previous message | Next message →

Interesting discussion.

Take the following text as an example.

When you apply, you will have to answer the following questions:

1. What is your name?
2. Why do you want to join our organization?
3. Are you currently employed?

If I were to mark this up as regular HTML text, I would certainly mark
up the three questions as a list, likely an ordered list.

If I were instead presenting these questions in a form, why wouldn't I
equally want to mark up these three questions using a list, ordered or
unordered? Isn't there a clear structural relationship between each
question and the form control provided for its answer? Can't this
relationship be identified by placing each question/answer pair within a
list item?

The <fieldset> element is for grouping "thematically related controls
and labels", so a <fieldset> around the list of three questions would
seem to be appropriate since together they form a thematic group,
namely, the three questions one needs to answer before applying.
Additionally, one might want to wrap the third question, which could
take "yes" and "no" radio buttons for the answer, in its own nested
<fieldset>.

What other semantic elements might be appropriate for identifying the
question and answer relationships in this example, and of the grouping
of three questions as a whole?

Bullets and other list item markers are often not applied for various
presentational reasons. This does not necessarily obviate their
structural list semantics. Part of the beauty of HTML is that we can
programmatically identify semantically related content by applying
appropriate structural elements, all the while presenting the content
visually in a number of different ways, be it for better or for worse.

Jason Kiss
accessibleculture.org

On 03/09/10 00:20, Kevin White wrote:
> That is pretty much the rationale that I adopt.
>
> It is good to get the input of other screenreader users as I only really had the one sample to draw upon. He did say much the same as others here have.
>
> I suppose I would question the inclusion of list items less if they were being visually represented as well, but they are not. The list bullet or list number is suppressed in all the examples I have seen of this. This suggests that these are not really lists, and the developers are not thinking of them as lists since they do not present them as lists. If screenreader users are saying that this simply adds clutter then drop them and use non-semantic elements such as div.
>
> Thanks
>
> Kevin
>
> On 2 Sep 2010, at 13:13, Steve Green wrote:
>
>> My rationale is F43: Failure of Success Criterion 1.3.1 due to using
>> structural markup in a way that does not represent relationships in the
>> content - http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F43
>>
>> Unfortunately the WCAG focus almost entirely on the addition of appropriate
>> structural markup. Apart from F43 very little is said about the prevention
>> of superfluous or inappropriate structural markup. For instance we are
>> starting to see nonsense such as breadcrumbs being marked up as definition
>> lists or fieldsets around Submit buttons. F43 appears to be the only means
>> we have of fighting back against these things.
>>
>> Regards,
>> Steve
>>
>> Address list messages to = EMAIL ADDRESS REMOVED =
>
>

From: Simius Puer
Date: Thu, Sep 02 2010 1:37PM
Subject: Re: Forms as lists
← Previous message | Next message →

I'd have to agree with Steve.

Using mark-up structurally is always one of those areas where debate could
exist as to what each element *could* be, but I'd tend to agree that a list
of questions still does not in most instances justify the use of the list
element - ordered or not.

This is a similiar scenario to legal documents where paragraphs/headings are
numbered. Some people argue that as the paragraphs/headings are numbered
then they must be an ordered list which simply is not the case. Doing so
leads to an huge amount of additional code and a reduction in accessibility.

There are other (some might argue - more marginal) reasons that I concur
with your approach. It all comes down to minimal mark-up which has the
benefit of being:

- less cluttered for screen readers
- easier to manage
- better for SEO (mark-up vs content balance)
- improved loading and rendering times

...whilst they might all sound like tiny things in themselves their value is
greater than the simple sum of their parts.

From: Jason Kiss
Date: Fri, Sep 03 2010 12:49AM
Subject: Re: Forms as lists
← Previous message | Next message →

Indeed, the topic of HTML semantics is always good for getting debate
going :)

And even though I think I disagree on the list of questions issue, I do
really like your example of numbered headings and paragraphs in legal
and similarly structured documents, and have argued the same point in
the past: Definitely *not* a case for list markup.

Jason Kiss
accessibleculture.org


On 03/09/10 00:37, Simius Puer wrote:
> I'd have to agree with Steve.
>
> Using mark-up structurally is always one of those areas where debate could
> exist as to what each element *could* be, but I'd tend to agree that a list
> of questions still does not in most instances justify the use of the list
> element - ordered or not.
>
> This is a similiar scenario to legal documents where paragraphs/headings are
> numbered. Some people argue that as the paragraphs/headings are numbered
> then they must be an ordered list which simply is not the case. Doing so
> leads to an huge amount of additional code and a reduction in accessibility.
>
> There are other (some might argue - more marginal) reasons that I concur
> with your approach. It all comes down to minimal mark-up which has the
> benefit of being:
>
> - less cluttered for screen readers
> - easier to manage
> - better for SEO (mark-up vs content balance)
> - improved loading and rendering times
>
> ...whilst they might all sound like tiny things in themselves their value is
> greater than the simple sum of their parts.
>
>
>

From: Steve Green
Date: Thu, Sep 02 2010 1:55PM
Subject: Re: Forms as lists
← Previous message | Next message →

Certainly those three items should be grouped in a list if they appear as
text. However, if they are in a form, they are already grouped by the <form>
element and the <fieldset> element if it is present. The questions and
corresponding form controls are related by means of the <label> element. No
further structural elements are needed.

A <fieldset> element is not necessary for the radio buttons because they are
explicitly grouped by their 'name' attributes. There is a case for using a
<fieldset> element to group checkboxes because they are not explicitly
grouped by default.

It seems that designers are falling over each other to see who can add the
most structural markup to their pages, and beyond a certain point this
reduces the accessibility rather than improve it. Semantic structure only
has value to the extent that the author and reader agree on its meaning.
Adding superfluous or inappropriate structural markup adds no value for
anyone.

Steve Green
Director
Test Partners Ltd

From: Andrew Kirkpatrick
Date: Thu, Sep 02 2010 6:16AM
Subject: Re: Forms as lists
← Previous message | Next message →

There's not going to be any resolution to the semantic debate on this (or many other topics) anytime soon, but unless that debate is resolved this technique will be difficult to connect with F43, which relies on the evaluator making a determination as to whether markup is incorrectly expressing relationships in the content.

The debate is good - it would be good for some of the debate to make it into the ALA discussion list, since designers implementing the technique are more likely to read the comments there than on WebAIM, and then they can make their own judgment with all of the facts.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems

= EMAIL ADDRESS REMOVED =
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility

From: Simius Puer
Date: Thu, Sep 02 2010 3:04PM
Subject: Re: Forms as lists
← Previous message | Next message →

Now now Andrew, you will be upsetting the nice folk of the WAI who spent so
much time making sure every last guideline in the WCAG was entirely
"objective and measurable" ;]

From: adam solomon
Date: Thu, Sep 02 2010 6:08PM
Subject: Re: Forms as lists
← Previous message | Next message →

It's pretty clear that a form has to be in a fieldset, strictly speaking.
If the list is intended to replace the fieldset then we have non-compliance.
However, if the list is placed inside the fieldset, then we do not
necessarily have non-compliance. It is inadvisable because of the excess
noise issue.
In the case of a list of multiple choice questions, how would you all react
to placing the questions in a definition list, where the question is in a dt
and the answer set in a dd. That might be a case where a list helps inside a
form?

On Thu, Sep 2, 2010 at 5:04 PM, Simius Puer < = EMAIL ADDRESS REMOVED = >wrote:

> Now now Andrew, you will be upsetting the nice folk of the WAI who spent so
> much time making sure every last guideline in the WCAG was entirely
> "objective and measurable" ;]
>
>
>

From: Dean Hamack
Date: Thu, Sep 02 2010 8:12AM
Subject: Re: Forms as lists
← Previous message | Next message →

This has been an interesting discussion. I'm in the process of completely
redesigning the cars.com mobile website, which is primarily just a bunch of
forms, and I've been marking the elements up in lists. After reading this, I
think I'll reconsider doing so.

Let's take this one step further: should a group of links (such as "home",
"about", and "contact") be grouped in an unordered list?

Additionally, I've been grouping the result of forms in definition lists,
like so:

<dl>
<dt>Name:</dt>
<dd>Dean</dd>
<dt>Email:</dt>
<dd> = EMAIL ADDRESS REMOVED = </dd>
<dl>

Is this also completely unnecessary? Would it be better to put each <dt> and
<dd> in an unordered list item?

Dean Hamack

From: Jared Smith
Date: Thu, Sep 02 2010 9:51AM
Subject: Re: Forms as lists
← Previous message | Next message →

On Thu, Sep 2, 2010 at 9:08 AM, adam solomon
< = EMAIL ADDRESS REMOVED = > wrote:
> It's pretty clear that a form has to be in a fieldset, strictly speaking.

No. Because the fieldset legend is announced for each form element
within the fieldset, placing all forms in a fieldset is likely to
cause much more overhead and noise than placing form items in lists. A
fieldset is intended "to group thematically related controls and
labels". There certainly is no requirement that they be used for all
forms. They should generally only be reserved for when a higher level
legend is necessary for the grouping to be understandable. This should
be used for groups of checkboxes and radio buttons, and a few other
less common cases.

Jared Smith

From: Steve Green
Date: Thu, Sep 02 2010 6:59PM
Subject: Re: Forms as lists
← Previous message | Next message →

I would react badly to placing multiple choice questions in a definition
list - I don't see that is appropriate in any way. A group of radio buttons
or checkboxes is all that is needed, possibly in a fieldset.

There are countless types of content for which there is not an appropriate
or obvious HTML construction. In these cases it is often best to omit any
structural markup rather than abuse the few HTML elements that we have.

If you are constructing something for which there is not an obviously
correct semantic construction, you should consider what sematic markup will
be useful to people. As a rule, definition lists are useless because they
have such poor support by user agents. By all means use them for their
intended purpose, but there is no value in using them in other ways (e.g.
breadcrumbs, navigation or forms) because no one at all will benefit.

At risk of being inflammatory, I believe a lot of designers are narcissistic
- they they mark up code to please themselves. I think they should be far
more focused on writing code that is useful to people who consume the
content. Of course that's much more difficult and it means understanding and
balancing the needs of groups with varying and maybe conflicting needs. But
that's the job they have chosen.

Steve Green
Director
Test Partners Ltd

From: adam solomon
Date: Thu, Sep 02 2010 9:57PM
Subject: Re: Forms as lists
← Previous message | Next message →

To Jared:
The spirit of WCAG is to use markup to convey the relevance and
relationships in web content. Form elements need to be in a fieldset in
order to convey to the user that he is in an area of the page which requires
user input and has multiple related input fields. I strongly disagree with
you on two points: The first is our considering the behavior of the screen
reader where it conflicts with wcag. If wcag suggests markup of a particular
nature in order to convey meaning, and the screen reader manifests this
markup in a bothersome fashion, the developer should absolutely not have to
consider screen reader quirks in development. Otherwise, there is
effectively no standard. Where wcag is ambiguous, there may be room to be
practical and realistic and limit ourselves as is relevant to screen reader
behavior.
The second point, related to the first, is that you suggest we don't always
have to follow wcag markup suggestions, though not in those words. If wcag
tells us that fieldset conveys a certain meaning, then I think it should
always be used, except in very extreme and rare cases. In a situation where
you really think the legend would bother the user, maybe we should use a
fieldset without a legend. That would be less of a non-conformance than not
using a fieldset at all. Html 4 does not require a legend for each fieldset.

As regards multiple choice questions and defintion list, it may be overkill.
But I can't for the life of me get it out of my head that I once saw that as
an example of dl implementation in a w3c document. I haven't been able to
find it since. Maybe I was dreaming. But really guys, isn't better to marup
to much than too little as long as there is conformance and relevance?




On Thu, Sep 2, 2010 at 8:59 PM, Steve Green < = EMAIL ADDRESS REMOVED = >wrote:

> I would react badly to placing multiple choice questions in a definition
> list - I don't see that is appropriate in any way. A group of radio buttons
> or checkboxes is all that is needed, possibly in a fieldset.
>
> There are countless types of content for which there is not an appropriate
> or obvious HTML construction. In these cases it is often best to omit any
> structural markup rather than abuse the few HTML elements that we have.
>
> If you are constructing something for which there is not an obviously
> correct semantic construction, you should consider what sematic markup will
> be useful to people. As a rule, definition lists are useless because they
> have such poor support by user agents. By all means use them for their
> intended purpose, but there is no value in using them in other ways (e.g.
> breadcrumbs, navigation or forms) because no one at all will benefit.
>
> At risk of being inflammatory, I believe a lot of designers are
> narcissistic
> - they they mark up code to please themselves. I think they should be far
> more focused on writing code that is useful to people who consume the
> content. Of course that's much more difficult and it means understanding
> and
> balancing the needs of groups with varying and maybe conflicting needs. But
> that's the job they have chosen.
>
> Steve Green
> Director
> Test Partners Ltd
>
>
>
>

From: Steve Green
Date: Thu, Sep 02 2010 8:23PM
Subject: Re: Forms as lists
← Previous message | Next message →

If your client commissions you to produce a standards-compliant website, you
don't need to worry about how screen readers or any other ATs work. You
don't need to do any browser compatibility testing either. It's anyone's
guess how accessible the resulting website will be.

If your client commissions you to produce an accessible website, you do need
to take into consideration how screen readers and other ATs work. The user
experience is what counts, especially if you are in the UK where the DDA
refers solely to 'actual outcomes' and not at all to standards-compliance.

With regard to fieldsets, I would only use them if two or more are needed. I
don't see any value in using a single fieldset - it is merely duplicating
what the <form> element is already doing.

Steve Green
Director
Test Partners Ltd

From: Jared Smith
Date: Thu, Sep 02 2010 1:26PM
Subject: Re: Forms as lists
← Previous message | Next message →

On Thu, Sep 2, 2010 at 12:57 PM, adam solomon wrote:
> To Jared:
> The spirit of WCAG is to use markup to convey the relevance and
> relationships in web content. Form elements need to be in a fieldset in
> order to convey to the user that he is in an area of the page which requires
> user input and has multiple related input fields.

This is precisely what the <form> element already does.

I think you're very much misunderstanding the function of fieldset.
Where does WCAG require or even suggest that all form elements must be
within fieldsets?

In just a few minutes of perusal I found many WCAG documentation code
examples that include form elements that are not within fieldsets. The
only references I found that suggest the use of fieldsets are
http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H71 and
http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H82.html, both of
which only recommend it when a logical grouping occurs *WITHIN* the
form (e.g., checkboxes, radio buttons, and a few other cases).

> The second point, related to the first, is that you suggest we don't always
> have to follow wcag markup suggestions, though not in those words.

No, I'm simply saying (as does WCAG) that you should use the fieldset
markup where it is appropriate. Nowhere does WCAG suggest you must
always have <form><fieldset> ... </fieldset></form>.

Jared

From: adam solomon
Date: Thu, Sep 02 2010 11:29PM
Subject: Re: Forms as lists
← Previous message | Next message →

I misunderstood you, Jared. I was not at all referring to the form element
per se, rather to a user input form, i.e. user input controls. You are
obviously correct that a fieldset should not be used in every form element,
especially given the common use of form as a wrapper for the whole page, as
occurs in most asp.net apps. In any event, after reviewing the links you
sent me, I admit that the specs are not as tight as I had previously read.
For clarity's sake, let us consider a sample web page which consists of two
sections: a search bar which contains dropdownlists and textboxes with which
the user can filter the search results; second, a results table. I propose
that the first section, which contains all the filter controls, even though
they are not radio or checkboxes, should be inside a fieldset, since they
are related in their common purpose, namely to filter a particular search.
The legend might read simply, "search filter", or something of that nature.
Would you agree? Another point is hidden legends. In these cases the analyst
will often refuse to allow a visual legend. Should a hidden legend
(accessible to the screen reader) then be implemented?

On Thu, Sep 2, 2010 at 10:26 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Thu, Sep 2, 2010 at 12:57 PM, adam solomon wrote:
> > To Jared:
> > The spirit of WCAG is to use markup to convey the relevance and
> > relationships in web content. Form elements need to be in a fieldset in
> > order to convey to the user that he is in an area of the page which
> requires
> > user input and has multiple related input fields.
>
> This is precisely what the <form> element already does.
>
> I think you're very much misunderstanding the function of fieldset.
> Where does WCAG require or even suggest that all form elements must be
> within fieldsets?
>
> In just a few minutes of perusal I found many WCAG documentation code
> examples that include form elements that are not within fieldsets. The
> only references I found that suggest the use of fieldsets are
> http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H71 and
> http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H82.html, both of
> which only recommend it when a logical grouping occurs *WITHIN* the
> form (e.g., checkboxes, radio buttons, and a few other cases).
>
> > The second point, related to the first, is that you suggest we don't
> always
> > have to follow wcag markup suggestions, though not in those words.
>
> No, I'm simply saying (as does WCAG) that you should use the fieldset
> markup where it is appropriate. Nowhere does WCAG suggest you must
> always have <form><fieldset> ... </fieldset></form>.
>
> Jared
>

From: Donald Evans
Date: Thu, Sep 02 2010 4:52PM
Subject: Re: Forms as lists
← Previous message | Next message →

Does anyone know of a Music Markup language that will render images of
musical scores in a web browser while at the same time making the music
accessible to the screen reader user?

--
Donald F. Evans
Deque Systems
Email: = EMAIL ADDRESS REMOVED =
Cell: (703) 608-8890
Does your website meet Section 508 Standards? http://www.deque.com

From: adam solomon
Date: Fri, Sep 03 2010 12:22AM
Subject: Re: Forms as lists
← Previous message | Next message →

Regarding forms and fieldsets, once again, please have a look at this W3C
memebership application <http://www.w3.org/Consortium/application>;. They do
not have a fieldset, only a form. Also, they are using definition lists in
parts of their form to connect header and paragraph content. Also, they are
using a layout table for the form controls. Is this the way it's supposed to
be?
On Thu, Sep 2, 2010 at 11:52 PM, Donald Evans < = EMAIL ADDRESS REMOVED = >wrote:

> Does anyone know of a Music Markup language that will render images of
> musical scores in a web browser while at the same time making the music
> accessible to the screen reader user?
>
> --
> Donald F. Evans
> Deque Systems
> Email: = EMAIL ADDRESS REMOVED =
> Cell: (703) 608-8890
> Does your website meet Section 508 Standards? http://www.deque.com
>

From: Jared Smith
Date: Thu, Sep 02 2010 3:27PM
Subject: Re: Forms as lists
← Previous message | Next message →

On Thu, Sep 2, 2010 at 2:29 PM, adam solomon wrote:

> I propose
> that the first section, which contains all the filter controls, even though
> they are not radio or checkboxes, should be inside a fieldset, since they
> are related in their common purpose, namely to filter a particular search.

These controls *may* be placed in a fieldset - there's nothing that
precludes this, but I don't believe they "should" be inside a
fieldset. WCAG certainly does not recommend doing so.

Again, using this same logic, you are suggesting that all forms
"should" be in a fieldset because they all are "related in their
common purpose". This would mean that even a simple search form with a
text box and a button would need a fieldset - something that would
provide no benefit to that form.

> The legend might read simply, "search filter", or something of that nature.
> Would you agree?

Sure, but I don't believe that it would be any more accessible than
without the fieldset. In this case, making it a heading would probably
be more appropriate.

Because the screen reader will repeat the legend for all of the form
controls within that fieldset, this would quickly become very
repetitive and potentially confusing. In your example, the user would
hear "Search filter" for every control within that form even though it
would already be very apparent what the form controls are for.

> Another point is hidden legends. In these cases the analyst
> will often refuse to allow a visual legend. Should a hidden legend
> (accessible to the screen reader) then be implemented?

If the form makes perfect sense without the fieldset, why would force
one upon only screen reader users? This very well makes my point - you
should only use a fieldset when a legend is necessary for the user to
determine the function of a group of controls within a form. If it's
accessible without the fieldset and legend, adding the fieldset and
legend will only make the form more time consuming and repetitive.

Jared

From: ckrugman
Date: Tue, Sep 07 2010 11:27PM
Subject: Re: Forms as lists
← Previous message | Next message →

I', not sure if that has been requested but an example of such a list/form
would be helpful to analyze. As a JAWS user I tend to deal with whatever is
there and not really think about it that much until I'm faced it. The
biggest issue seems to be forms that are not formatted properly in to PDF
files and are therefore unreadable or usable. Forms on web pages or as part
of a web site can be problemati c at times when there is an inconsistent
pattern in multiple pages or where there is generally a lack of uniformity
in design.
Chuck
----- Original Message -----
From: "Kevin White" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, September 02, 2010 3:26 AM
Subject: [WebAIM] Forms as lists


> Hi All,
>
> I am starting to see forms being presented as lists on a more regular
> basis but I am struggling to find the rationale for this. Some recent
> testing with an experienced JAWS user highlighted this as a slight issue
> for him. My opinion is that this is not an accurate use of semantic
> markup, however, I am aware that some have argued that a form is a list of
> questions.
>
> Does anyone have any experience of this? How do screen reader users find
> this sort of form?
>
> Thanks for any input,
>
> Kevin
>

From: ckrugman
Date: Wed, Sep 08 2010 12:28AM
Subject: Re: Forms as lists
← Previous message | No next message

I had no problem accessing this form using JAWS 11 and IE8.
Chuck
----- Original Message -----
From: "Kevin White" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, September 02, 2010 4:34 AM
Subject: Re: [WebAIM] Forms as lists


> Hi Rak,
>
> This article from A List Apart talks about it
> (http://www.alistapart.com/articles/prettyaccessibleforms) and this is an
> example that they provide
> http://www.alistapart.com/d/prettyaccessibleforms/example_1/
>
> Kevin
>
> On 2 Sep 2010, at 11:33, < = EMAIL ADDRESS REMOVED = >
> < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi Kevin,
>> Can you provide with a scenario where a list is used for forms. I can
>> verify the same.
>> Regards
>> Rak
>>
>>