E-mail List Archives

Search E-mail List Archives for

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

From: Ritz, Courtney L. (GSFC-7500)
Date: Mon, Aug 01 2011 2:36PM
Subject: 508 compliant checkbox form controls
No previous message | Next message →

Hi all,

I know that there are times when 'accessible" and "Section 508 compliant" don't always mean the same thing.
A colleague and I are arguing over this regarding checkbox form controls.

When I talk to people about making form controls Section 508 compliant, I often refer them to
http://webaim.org/techniques/forms/controls
for accessible code examples for various types of controls.
And I think of the example there, for pizza toppings, as the best way to set up checkboxes, since the question text is associated with each checkbox control.

My colleague has a checkbox on a form, and though there is a LABEL for each of the checkbox items, the question text is not associated with them. For instance, if we had the pizza toppings example, tabbing through the boxes would give me "Ham," "Pepperoni," "Mushrooms," ETC, without hearing "Select your pizza toppings:" (I'm a JAWS user.)

So my question is, could my colleague's checkbox still be considered to be Section 508 compliant, even though it's not as accessible as it could be?

Courtney

From: Jared Smith
Date: Mon, Aug 01 2011 2:45PM
Subject: Re: 508 compliant checkbox form controls
← Previous message | Next message →

In the example you cite
(http://webaim.org/techniques/forms/controls#checkbox), the question
text is associated to the group of checkboxes due to the fieldset and
legend. In other words, the fieldset legend "Select your pizza
toppings:" is applied to the grouping of checkboxes. Each checkbox has
its own label ("Ham", "Pepperoni", etc.). JAWS *should* read the
fieldset legend and the label for each checkbox.

Based on the explanation you have given, I assume that your colleague
has associated labels, but has not provided a fieldset and legend for
the checkbox grouping.

Jared

From: YOUNGV5
Date: Mon, Aug 01 2011 2:57PM
Subject: Re: 508 compliant checkbox form controls
← Previous message | Next message →

I believe Courtney is asking if providing checkboxes without a
legend/fieldset would still be 508 compliant.

The paragraph in question reads:

(n) When electronic forms are designed to be completed on-line, the form
shall allow people using assistive technology to access the information,
field elements, and functionality required for completion and submission
of the form, including all directions and cues.

The last bit, "including all directions and cues" is associated with the
example you presented. However, it seems it would be difficult to claim
the inaccessibility of a form based on this case alone as a direct
violation of Section 508. Weigh in from others?

Vincent Young
User Experience, Web Accessibility Specialist
Nationwide Corporate Marketing
Nationwide®
o | 614·677·5094
c | 614·607·3400
e | = EMAIL ADDRESS REMOVED =




From:
Jared Smith < = EMAIL ADDRESS REMOVED = >
To:
WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Date:
08/01/2011 04:44 PM
Subject:
Re: [WebAIM] 508 compliant checkbox form controls
Sent by:
= EMAIL ADDRESS REMOVED =



In the example you cite
(http://webaim.org/techniques/forms/controls#checkbox), the question
text is associated to the group of checkboxes due to the fieldset and
legend. In other words, the fieldset legend "Select your pizza
toppings:" is applied to the grouping of checkboxes. Each checkbox has
its own label ("Ham", "Pepperoni", etc.). JAWS *should* read the
fieldset legend and the label for each checkbox.

Based on the explanation you have given, I assume that your colleague
has associated labels, but has not provided a fieldset and legend for
the checkbox grouping.

Jared

From: Bevi Chagnon
Date: Mon, Aug 01 2011 3:24PM
Subject: Re: 508 compliant checkbox form controls
← Previous message | Next message →

The difference between "accessible" and "Section 508 compliant":

"Accessible" refers to "generally accepted standards and guidelines." They
are neither laws nor regulations but instead are voluntary guidelines that
governments, entities, individuals, corporations, and institutions choose to
follow. These guidelines were developed and are maintained by the W3C's WAI
which produces WCAG.

"Section 508 compliant" refers to the U.S. legislation that requires all
federal ICT (information communication technology) be accessible to federal
employees and the U.S. general public. U.S. federal agencies must produce
accessible ICR: it is not voluntary but mandatory.

Sec. 508 does not affect these entities:
1. State and local governments unless they choose to adopt the federal
standards.
2. Corporations, educational institutions, and other entities unless they
choose to adopt the federal standards.
3. Individuals, private businesses, and organizations unless they choose to
adopt the federal standards.
4. Non-U.S. governments and entities, institutions, businesses, and
individuals. They are governed by their country's accessibility guidelines,
not the U.S. federal guidelines.

Current U.S. guidelines for Sec. 508 accessibility are outdated so they do
not match the international WCAG 2.0 guidelines. (Shame on us!) But the U.S.
Access Board is in the process of "refreshing" the U.S. requirements to
bring them up to date and match WCAG 2.0. Hopefully we'll have new
guidelines by the end of this year. See the Access Board's website
http://www.access-board.gov/sec508/refresh/draft-rule.htm for the latest
draft of the revised guidelines.

Summary:
If something is Section 508 compliant, it is accessible according to the
current 508 standards, but not might be accessible according to the better
international WCAG 2.0 standards.

However, if something meets the current WCAG 2.0 standards, it will be
Section 508 accessible too.

WebAIM promotes the better WCAG 2.0 standards, so when in doubt trust their
guidance as you did regarding forms. I can't recall any techniques they
recommend that conflict with Section 508's federal requirements.

Hope this helps.

- Bevi Chagnon
(A Washington D.C. inside-the-Beltway type
who has to explain this distinction several times a day)

--
Bevi Chagnon | = EMAIL ADDRESS REMOVED =
PubCom - Trainers, consultants, designers, and developers
Print, Web, Acrobat, XML, and Federal Section 508
--
* It's our 30th Year! *

From: Jared Smith
Date: Mon, Aug 01 2011 3:51PM
Subject: Re: 508 compliant checkbox form controls
← Previous message | Next message →

On Mon, Aug 1, 2011 at 2:55 PM, < = EMAIL ADDRESS REMOVED = > wrote:

>  The last bit, "including all directions and cues" is associated with the
> example you presented.  However, it seems it would be difficult to claim
> the inaccessibility of a form based on this case alone as a direct
> violation of Section 508.  Weigh in from others?

It is my opinion that it would typically be a violation of Section 508
for a grouping of checkboxes or radio buttons to not have its higher
level description/question in a fieldset legend. In other words, when
a screen reader is navigating through the form, if the form controls
do not make sense without the description/question being read, this is
certainly problematic and likely a violation of 508 (n). This
important "direction or cue" should be associated to the controls via
<fieldset> and <legend>. Suggesting otherwise would be no different
than saying that form control label text doesn't need to be associated
via the <label> element because it happens to be in close proximity to
its related form control.

Jared

From: YOUNGV5
Date: Tue, Aug 02 2011 9:03AM
Subject: Re: 508 compliant checkbox form controls
← Previous message | Next message →

Jared, I agree. I think if you got down to the nitty gritty in court, you
could probably argue and win the 508 violation case.

Vincent Young
User Experience, Web Accessibility Specialist
Nationwide Corporate Marketing
Nationwide®
o | 614·677·5094
c | 614·607·3400
e | = EMAIL ADDRESS REMOVED =

From: Ritz, Courtney L. (GSFC-7500)
Date: Tue, Aug 02 2011 9:33AM
Subject: Re: 508 compliant checkbox form controls
← Previous message | Next message →

Thanks all.
Personally, I didn't think my colleague's form control could be considered Section 508 compliant as/is. With the valuable feedback that I've gotten from you all here, I hope to be able to persuade this individual to add the fieldset to those checkboxes.

Thanks so much.

Courtney

From: Hoffman, Allen
Date: Tue, Aug 02 2011 1:06PM
Subject: Re: 508 compliant checkbox form controls
← Previous message | Next message →

DHS would fail for Section 508 compliance a checkbox if it didn't
include the question also. the rationale is that the 36 CFR 1194.22(n)
requirement says all directions and cues etc. It is quite verbose about
"all". this is a difference between a standard and a guideline to some
extent--standards should be as clear as is feasible to eliminate
unclarity. One more usability caveat of this is that such items should,
as is feasible, put the answer first, so that the screen reader user can
hit the stop speech key if they don't need the question re-read, but
that is strictly usability, not something the standard documents in
text/requirement. I think this is a misconception driven by screen
reader testing, which is not what the standard says.

From: Hoffman, Allen
Date: Tue, Aug 02 2011 1:15PM
Subject: Re: 508 compliant checkbox form controls
← Previous message | No next message

My opinion regarding some of the comments below about 508 and WCAG is
that while WCAG 2.0 contains additional detailed requirements, for the
most part, they are refinements, and alternatives which fall under the
original WCAG 1.0 guidance, and the associated Section 508 standards
existing today. For example, for nontext alternatives, WCAG has nine
items broken down--this is nice guidance, but really does not change the
overall requirement, but does make reading a lot longer process. Such
guidance was developed as a natural response to questions and answers
practitioners have encountered over time, but ITS kind of like a
frequently asked question section rather than a more terse standard.
I'm not knocking WCAG 2.0, but taken along with the sufficient
techniques, it is a steep learning curve. I don't believe there are
many sites which will become noncompliant when they are reassessed for
compliance with WCAG 2.0 vs. old 508 standards, at least for the
refinements of existing standards, but such things as delineation of
natural language will cause sites to do some remediation work. In
addition, I foresee a lot of remediation work for some sites to address
unfocused error messages, and a huge set of work to address document
content.