Thread Subject: Re: Suggested update to 6.1.I so we canremove6.1.B and 6.1.C (forms & scripting)

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Barrett, Don
Date: Wed, Jun 06 2007 2:35 PM

Andrew,

21(d) Sufficient information about a user interface element including
the identity, operation and state of the element shall be available to
assistive technology. . . . ."

The main problem with this applying to forms is that it is too general
and non-specific. For example, if I tab to an edit box, and just hear
"edit," I know it is focusable; I know it is empty; and I know it is an
edit box. It has met D as prescribed above. If however, if its label
isn't programmatically associated with the edit box, I have no idea what
to type into it. Meeting D isn't enough.
Don Barrett
Section 508 Coordinator
U.S. Department of Education
(202)-205-8245
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Wednesday, June 06, 2007 4:23 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Suggested update to 6.1.I so we
canremove6.1.B and 6.1.C (forms & scripting)

Allen,

> What we don't have is something that states what standard must be met
> for interface elements delivered that are not coded in HTML, or pure
> software. PDF forms are not addressed directly to my knowledge,
> neither would forms in Microsoft Word .doc format--or open-document
> format for that matter.

In the current standard? Sure they are! You can debate whether PDF
forms are a 1194.21 or 1194.22 item, but currently 21(d) would cover PDF
form controls:

21(d) Sufficient information about a user interface element including
the identity, operation and state of the element shall be available to
assistive technology. When an image represents a program element, the
information conveyed by the image must also be available in text.

22(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.

22(n) was replaced with something more like 21d, and since 22(n) is
replacable with 21(d) it makes sense to remove 21(l) altogether, rather
than keep the redundnacy.

> I think we still need an overarching statement (somewhere) that says
> content must meet (x,y,z). We have it for HTML and generalized
> audio/video content, but not for anything else.

Where do you see it for HTML specifically?

> I propose that this be the first item in
> information/documentation/support, or included in functional
> performance criteria, and forms should be explicitly mentioned to
> eliminate any ambiguity about them.

I disagree. This is not about documentation, this is about web and
software applications and their controls. The documentation section
already refers to support of the relevant sections.

> Question is as I read this, this requirement below is for web, not web

> and software both right?

Yes, but there is a nearly identical standard in software.

AWK

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University