Thread Subject: Recall: Group D: 21 (l) and 22(n) accessibleforms

Return to this mailing list's archives

From: Gani, Dewi
Date: Tue, Nov 28 2006 4:50 AM
Subject: Recall: Group D: 21 (l) and 22(n) accessibleforms

Gani, Dewi would like to recall the message, "[teitac-websoftware] Group D: 21 (l) and 22(n) accessible forms".

From: Gani, Dewi
Date: Tue, Nov 28 2006 4:55 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

Dear All,

I apologize for sending wrong emails out. Please just disregard these
emails.

Thank you for your understanding.

Regards,

Dewi

From: Bailey Bruce
Date: Tue, Nov 28 2006 5:25 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

Andi asked:
> Does anyone know why the Access Board thought that the other
> provisions were insufficient for the special case of forms?

Here is what was said in the NPRM:
http://www.access-board.gov/sec508/nprm.htm

<blockquote>

Paragraph (b)(10) requires that people with disabilities have access to electronic forms. Electronic forms are a popular method used by many agencies to gather information or permit a person to apply for services, benefits, or employment. The 1998 Government Paperwork Elimination Act requires that Federal agencies make electronic versions of their forms available online and allows individuals and business to use electronic signatures to file these forms electronically. This provision requires that when an agency uses a form that cannot be read and manipulated by assistive technology, an alternative form must also be provided that is accessible. An example of a form which is not accessible is one which is graphical in nature and cannot be translated into meaningful text by assistive technology. This provision is consistent with the recommendations of the advisory committee.

</blockquote>

Here is what was said in the final rule:
http://www.access-board.gov/sec508/preamble.htm#Section

<blockquote>

Paragraph (n) requires that people with disabilities have access to interactive electronic forms. Electronic forms are a popular method used by many agencies to gather information or permit a person to apply for services, benefits, or employment. The 1998 Government Paperwork Elimination Act requires that Federal agencies make electronic versions of their forms available on-line when practicable and allows individuals and businesses to use electronic signatures to file these forms electronically. (See §1194.23(b)(10) in the NPRM.) At present, the interaction between form controls and screen readers can be unpredictable, depending upon the design of the page containing these controls. Some developers place control labels and controls in different table cells; others place control labels in various locations in various distances from the controls themselves, making the response from a screen reader less than accurate many times.

Comment. Adobe Systems expressed concern that completing some forms requires a script or plug-in and interpreted the proposed rule as prohibiting such items. They pointed out that there are other methods of completing a form that would not require scripts or plug-ins, but those methods require the constant transfer of information between the client and server computers. Adobe noted that that method can be extremely inefficient and can pose a security risk for the individual's personal data.

Response. This provision does not forbid the use of scripts or plug-ins and many of the existing products support these features. If a browser does not support these features, however, paragraphs (l) and (m) require that some other method of working with the web page must be provided. As assistive technologies advance, it is anticipated that the occasions when the use of scripts and plug-ins are not supported will diminish significantly. No substantive changes have been made to this provision in the final rule.

</blockquote>

I would also point out that while the 508 provisions 1194.22 (a) - (k) are consistent with eleven WCAG 1.0 Priority 1 Checkpoints, there are no Priority 1 WCAG 1.0 Checkpoints that address forms.
http://www.w3.org/TR/WCAG10/full-checklist.html

From: Jim Tobias
Date: Tue, Nov 28 2006 5:45 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

> -----Original Message-----
> From: Bailey Bruce [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Tuesday, November 28, 2006 7:24 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n)
> accessible forms
>
> Andi asked:
> > Does anyone know why the Access Board thought that the other
> > provisions were insufficient for the special case of forms?

I think this was all about PDF at the time. Agencies were moving to PDF for
publishing documents and creating online forms. Some felt that an
accessible alternative could be demanded for the former, but not as easily
for the latter.

Note for how narrow a time window this "special" federal regulation was
actually needed: less than a year, certainly. We should make an effort to
present-proof as well as future-proof our recommendations.

From: Hoffman, Allen
Date: Tue, Nov 28 2006 7:50 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

Whether this was intended for PDF(s) or not, forms were a special case
in the HTML world, as they provide all the means of interaction for the
end-user. I think we can do better regarding interaction. Provisions
more like software provisions, but with specific web equivalents seem
like the way to go, and we have lots more information to use now. For
example, basic pure HTML forms are much more rare now, and most forms I
see these day are coded using scripting languages, have combinations of
.css that can change the interaction drastically, for example hiding
part of a form until needed, and more. The general purpose forms
provisions are only helpful as a catch all, similar to functional
performance criteria.

I think something specific that indicates how "pure" HTML-based form
elements must function, something indicating how scripted interaction
elements are to function, and something relating use of "stylesheets"
and interaction elements must be available.
Also, it might be worth considering what would we want to say related to
use of interaction elements in tabular "layouts". This is a thorny
issue now as how the standards are applied. I don't think lumping form
elements as nontext elements is very helpful, even if they often are
nontext elements.

> From: Bailey Bruce [mailto: = EMAIL ADDRESS REMOVED = ]
> forms
>
> Andi asked:
> > Does anyone know why the Access Board thought that the other
> > provisions were insufficient for the special case of forms?

I think this was all about PDF at the time. Agencies were moving to PDF
for publishing documents and creating online forms. Some felt that an
accessible alternative could be demanded for the former, but not as
easily for the latter.

Note for how narrow a time window this "special" federal regulation was
actually needed: less than a year, certainly. We should make an effort
to present-proof as well as future-proof our recommendations.

allen hoffman
DHS Office on Accessible systems & Technology

From: Andrew Kirkpatrick
Date: Tue, Nov 28 2006 9:30 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

> I think something specific that indicates how "pure"
> HTML-based form elements must function, something indicating
> how scripted interaction elements are to function, and
> something relating use of "stylesheets"
> and interaction elements must be available.

This strikes me as too detailed and too technology-specific. I agree
that we need to be able to address everything that you mention, but not
specifically in the context of forms -- I'm not convinced that there is
a need to use the term "forms" and for this reason I don't think that
both 21(d) and 21(l) are necessary - 21(d) covers 21(l).

> Also, it might be worth considering what would we want to say
> related to use of interaction elements in tabular "layouts".

Can you give an example? If you're talking about elements within a tab
navigator-like bar, I really don't think we can get that specific. WE
need to be able to have a general standard that addresses this.

AWK

From: Jonathan Avila
Date: Tue, Nov 28 2006 10:45 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

I believe 22(n) should be changed to something similar to 21(d) and then add
language concerning instruction/error/cue text.

Jonathan

From: Barrett, Don
Date: Tue, Nov 28 2006 12:40 PM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

Yes, the nice thing about .22[n] now is that it is so general, it simply
specifies an outcome which must happen while allowing the details of the
specific technology in use to be worked out by the developer.

From: Jim Thatcher
Date: Wed, Nov 29 2006 9:15 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

Jim Tobias wrote:
> > Andi asked:
> > > Does anyone know why the Access Board thought that the other
> > > provisions were insufficient for the special case of forms?

> I think this was all about PDF at the time.

I disagree with the idea that the requirement on forms can be drawn from
other aspects of the 508 Standards. There is nothing in 508 outside of 22(n)
{and 21(l)} that requires that prompting information be available to screen
reader users.

Correct labeling of form elements is relatively rare on the web in part
because often, even usually, the labeling is not necessary and screen
readers pick up the correct prompts. For forms, however, "often" or
"usually" is not good enough. From controls must be correctly labeled so
that screen reader users can be absolutely confident that the prompt they
hear is in fact the intended prompt for each control, not a screen reader's
best guess.

WCAG20 SC 1.3.1 does address this issue:

"Information and relationships conveyed through presentation can be
programmatically determined, and notification of changes to these is
available to user agents, including assistive technologies"

However, I think the wording of 1.3.1 is too far removed from this very
serious problem and I think it should be addressed directly.

So Proposal:

22(n) For any interactive object, prompting information that is visually
evident can be programmatically determined.

The nature of the objects, their name, role and state, must be available
through other parts of the standards; this deals only with the "prompts" or
"cues".

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Tuesday, November 28, 2006 6:39 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n) accessible forms


> -----Original Message-----
> From: Bailey Bruce [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Tuesday, November 28, 2006 7:24 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n)
> accessible forms
>
> Andi asked:
> > Does anyone know why the Access Board thought that the other
> > provisions were insufficient for the special case of forms?

I think this was all about PDF at the time. Agencies were moving to PDF for
publishing documents and creating online forms. Some felt that an
accessible alternative could be demanded for the former, but not as easily
for the latter.

Note for how narrow a time window this "special" federal regulation was
actually needed: less than a year, certainly. We should make an effort to
present-proof as well as future-proof our recommendations.

From: Hoffman, Allen
Date: Wed, Nov 29 2006 9:25 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

Jim Thatcher wrote:
"The nature of the objects, their name, role and state, must be
available through other parts of the standards; this deals only with the
"prompts" or "cues"."

I agree, but wonder if some language stating that the other requirements
are associated would be a good idea. leaving vendors to, for example,
indicate that they met N but didn't meet another part would be
problematic for actually representing if the form "interactive elements"
really are usable.

but, I agree that "cuing" information and identity, operation, and state
are separate items. to be honest I believe cuing information is really
content, but lets not go there!

Allen Hoffman

From: Hoffman, Allen
Date: Wed, Nov 29 2006 9:30 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

the "cuing" information is, for example, "enter the tax year you last
filed", which may not be the name. A name for something like that is
often just "tax year". Of course this can be debated that the name
wasn't fully qualified, but in the web one would probably use a label,
and optionally the title attribute to accomplish "tax year" and "enter
the last year you filed". In software, the "enter last year you filed"
would be in the dialogue box. Am I making sense here?

From: Fratkin, Mike
Date: Wed, Nov 29 2006 9:35 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

We also need to consider the "assistive technology" portion of this
standard. Speech engines are being incorporated into electronic forms
to speak elements on the screen seemingly replacing the need for screen
readers. This typically is not equivalent to the functionality of
screen readers and normally does not interface with refreshable Braille
displays. The implementation of speech engines in meeting Section 508
compliance needs to be explored.

Mike Fratkin
SSA

Jim Thatcher wrote:
"The nature of the objects, their name, role and state, must be
available through other parts of the standards; this deals only with the
"prompts" or "cues"."

I agree, but wonder if some language stating that the other requirements
are associated would be a good idea. leaving vendors to, for example,
indicate that they met N but didn't meet another part would be
problematic for actually representing if the form "interactive elements"
really are usable.

but, I agree that "cuing" information and identity, operation, and state
are separate items. to be honest I believe cuing information is really
content, but lets not go there!

Allen Hoffman

From: Andrew Kirkpatrick
Date: Wed, Nov 29 2006 9:40 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

I'm not sure whether you're replying to me or someone else. I do
understand what we mean by the cues (I usually think of a label that is
"phone number" and the cue being "omit all punctuation and spaces").

We will need to figure out how to deal with this appropriately - it
seems that it is better to add it into a consolidated 21(d)/21(l) than
to keep 21(l) just for cues.

AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Wednesday, November 29, 2006 11:27 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n)
> accessible forms
>
> the "cuing" information is, for example, "enter the tax year
> you last filed", which may not be the name. A name for
> something like that is often just "tax year". Of course this
> can be debated that the name wasn't fully qualified, but in
> the web one would probably use a label, and optionally the
> title attribute to accomplish "tax year" and "enter the last
> year you filed". In software, the "enter last year you filed"
> would be in the dialogue box. Am I making sense here?
>
>
>
>

From: Andrew Kirkpatrick
Date: Wed, Nov 29 2006 9:45 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

> I disagree with the idea that the requirement on forms can be
> drawn from other aspects of the 508 Standards. There is
> nothing in 508 outside of 22(n) {and 21(l)} that requires
> that prompting information be available to screen reader users.

I agree with you for 22n, but not for 21(l). In 21(d) the "identify,
state, and operation" cover what you're talking about.

> 22(n) For any interactive object, prompting information that
> is visually evident can be programmatically determined.
>
> The nature of the objects, their name, role and state, must
> be available through other parts of the standards; this deals
> only with the "prompts" or "cues".

You don't view the label as the name for a control?

AWK

From: Peter Korn
Date: Wed, Nov 29 2006 10:00 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

Hi Jim,

> I disagree with the idea that the requirement on forms can be drawn from
> other aspects of the 508 Standards. There is nothing in 508 outside of 22(n)
> {and 21(l)} that requires that prompting information be available to screen
> reader users.
>

I think this should be addressed directly, and the ISO language that
Andi circulated is a good start. Andi's forwarded ISO language was:

ISO: Software shall provide assistive technology with information about
individual user interface elements, using methods compatible with 8.6.3,
except elements that only serve as an integral portion of a larger element,
taking no input and conveying no information of their own.


The key for me is that when we say "individual user interface elements",
that includes text labels (or "prompting information" as Jim terms it).

Also, in the ISO language that Andi quotes (in "Note 1"), it says:

User interface element information includes, but is not limited to:
... relationships between user interface elements (such as when one user
interface element contains, names, describes, or affects another).


We explicitly have a "labeling relationship" in the Java and UNIX
accessibility APIs, and I believe that this is alos the case in the
Macintosh OS X Accessibility API and Microsoft's UI Automation.


None of this is to say that in the Web portions of our guidelines we
shouldn't explicitly reinforce this, noting at least a "sufficient
technique" for exposing the prompting information to browsers, and from
there to AT.

Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Jim Thatcher
Date: Wed, Nov 29 2006 10:15 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

No the "prompt or cue" is not the name. It is information that is available
to a sighted user that says what to do with the form control. Sometimes
there is no text, like when position provides the cue (second field of zip
code), sometimes the text is not contiguous.

I am not distinguishing between "prompt" and "cue". I mean the any (visual)
information required in order to know what to do with the control, what to
enter, what you are agreeing to or what you are signing up for.

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Wednesday, November 29, 2006 10:35 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n) accessible forms

I'm not sure whether you're replying to me or someone else. I do
understand what we mean by the cues (I usually think of a label that is
"phone number" and the cue being "omit all punctuation and spaces").

We will need to figure out how to deal with this appropriately - it
seems that it is better to add it into a consolidated 21(d)/21(l) than
to keep 21(l) just for cues.

AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Wednesday, November 29, 2006 11:27 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n)
> accessible forms
>
> the "cuing" information is, for example, "enter the tax year
> you last filed", which may not be the name. A name for
> something like that is often just "tax year". Of course this
> can be debated that the name wasn't fully qualified, but in
> the web one would probably use a label, and optionally the
> title attribute to accomplish "tax year" and "enter the last
> year you filed". In software, the "enter last year you filed"
> would be in the dialogue box. Am I making sense here?
>
>
>
>

From: Andi Snow-Weaver
Date: Wed, Nov 29 2006 10:30 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

<Mike wrote>

Speech engines are being incorporated into electronic forms
elements on the screen seemingly replacing the need for screen
This typically is not equivalent to the functionality of
normally does not interface with refreshable Braille
implementation of speech engines in meeting Section 508
be explored.

<end of Mike's comment>

Mike,

Are you saying that some vendors are claiming equivalent facilitation if
their forms are self-voicing?

This seems like a general issue rather than something specific to the
detailed provisions we are discussing at the moment. Okay if we table this
for now and I will add this to the general issues list so we don't forget
about it?

Andi

From: Fratkin, Mike
Date: Wed, Nov 29 2006 10:35 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

Yes, several vendors are doing this. I wasn't sure where this topic
should go but wanted to mention it, so that I would not forget. Adding
it to the general issues is fine. Thanks.

Mike


[Andi wrote}
Mike,

Are you saying that some vendors are claiming equivalent facilitation if
their forms are self-voicing?

This seems like a general issue rather than something specific to the
detailed provisions we are discussing at the moment. Okay if we table
this for now and I will add this to the general issues list so we don't
forget about it?

Andi

From: Gregg Vanderheiden
Date: Wed, Nov 29 2006 12:00 PM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

Hmmmm

I think there is a crossed something here.

I'm not sure if the CURRENT 508 covers all form elements, but a good set of
requirements should. There is nothing on a form that doesn't also appear in
other web content (and software too for that matter). So those elements or
components need to be accessible wherever they are. Fields, labels, prompts,
cues, whatever. So forms should end up being accessible and a special forms
provision should not be needed.

If all the aspects of forms are not covered in current 508 language - then
we need to fix the language.

That being said - I don't have any objection to keeping a special provision
that talks just about forms, even if that provision is redundant. Forms
are so important, and people purchasing are not able to even understand some
of the software access provisions, that I think having a single provision on
forms that they can point to and say "do you meet that" can be very
important.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Thatcher
> Sent: Wednesday, November 29, 2006 10:12 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n)
> accessible forms
>
> Jim Tobias wrote:
> > > Andi asked:
> > > > Does anyone know why the Access Board thought that the other
> > > > provisions were insufficient for the special case of forms?
>
> > I think this was all about PDF at the time.
>
> I disagree with the idea that the requirement on forms can be
> drawn from other aspects of the 508 Standards. There is
> nothing in 508 outside of 22(n) {and 21(l)} that requires
> that prompting information be available to screen reader users.
>
> Correct labeling of form elements is relatively rare on the
> web in part because often, even usually, the labeling is not
> necessary and screen readers pick up the correct prompts. For
> forms, however, "often" or "usually" is not good enough. From
> controls must be correctly labeled so that screen reader
> users can be absolutely confident that the prompt they hear
> is in fact the intended prompt for each control, not a screen
> reader's best guess.
>
> WCAG20 SC 1.3.1 does address this issue:
>
> "Information and relationships conveyed through presentation
> can be programmatically determined, and notification of
> changes to these is available to user agents, including
> assistive technologies"
>
> However, I think the wording of 1.3.1 is too far removed from
> this very serious problem and I think it should be addressed directly.
>
> So Proposal:
>
> 22(n) For any interactive object, prompting information that
> is visually evident can be programmatically determined.
>
> The nature of the objects, their name, role and state, must
> be available through other parts of the standards; this deals
> only with the "prompts" or "cues".
>
> Jim
>
> Accessibility Consulting: http://jimthatcher.com/
> 512-306-0931
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Tobias
> Sent: Tuesday, November 28, 2006 6:39 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n)
> accessible forms
>
>
> > -----Original Message-----
> > From: Bailey Bruce [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Tuesday, November 28, 2006 7:24 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n)
> accessible
> > forms
> >
> > Andi asked:
> > > Does anyone know why the Access Board thought that the other
> > > provisions were insufficient for the special case of forms?
>
> I think this was all about PDF at the time. Agencies were
> moving to PDF for publishing documents and creating online
> forms. Some felt that an accessible alternative could be
> demanded for the former, but not as easily for the latter.
>
> Note for how narrow a time window this "special" federal
> regulation was actually needed: less than a year, certainly.
> We should make an effort to present-proof as well as
> future-proof our recommendations.
>
>

From: Fratkin, Mike
Date: Wed, Nov 29 2006 12:10 PM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

The web requirements for Section 508 do not cover form elements. The
only reference is in 1194.22(n) which is specific to electronic forms.
When we see an issue with a form element we reference this standard and
the reply is typically that the application is not an electronic form.
So if 1194.22(n) is not clarified then form or interactive elements need
to be added.

Mike Fratkin
SSA


[Gregg wrote:]Hmmmm

I think there is a crossed something here.

I'm not sure if the CURRENT 508 covers all form elements, but a good set
of requirements should. There is nothing on a form that doesn't also
appear in
other web content (and software too for that matter). So those
elements or
components need to be accessible wherever they are. Fields, labels,
prompts, cues, whatever. So forms should end up being accessible and a
special forms provision should not be needed.

If all the aspects of forms are not covered in current 508 language -
then we need to fix the language.

That being said - I don't have any objection to keeping a special
provision that talks just about forms, even if that provision is
redundant. Forms are so important, and people purchasing are not able
to even understand some of the software access provisions, that I think
having a single provision on forms that they can point to and say "do
you meet that" can be very important.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
> Thatcher
> Sent: Wednesday, November 29, 2006 10:12 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n) accessible

> forms
>
> Jim Tobias wrote:
> > > Andi asked:
> > > > Does anyone know why the Access Board thought that the other
> > > > provisions were insufficient for the special case of forms?
>
> > I think this was all about PDF at the time.
>
> I disagree with the idea that the requirement on forms can be drawn
> from other aspects of the 508 Standards. There is nothing in 508
> outside of 22(n) {and 21(l)} that requires that prompting information
> be available to screen reader users.
>
> Correct labeling of form elements is relatively rare on the web in
> part because often, even usually, the labeling is not necessary and
> screen readers pick up the correct prompts. For forms, however,
> "often" or "usually" is not good enough. From controls must be
> correctly labeled so that screen reader users can be absolutely
> confident that the prompt they hear is in fact the intended prompt for

> each control, not a screen reader's best guess.
>
> WCAG20 SC 1.3.1 does address this issue:
>
> "Information and relationships conveyed through presentation can be
> programmatically determined, and notification of changes to these is
> available to user agents, including assistive technologies"
>
> However, I think the wording of 1.3.1 is too far removed from this
> very serious problem and I think it should be addressed directly.
>
> So Proposal:
>
> 22(n) For any interactive object, prompting information that is
> visually evident can be programmatically determined.
>
> The nature of the objects, their name, role and state, must be
> available through other parts of the standards; this deals only with
> the "prompts" or "cues".
>
> Jim
>
> Accessibility Consulting: http://jimthatcher.com/
> 512-306-0931
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
> Tobias
> Sent: Tuesday, November 28, 2006 6:39 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n) accessible

> forms
>
>
> > -----Original Message-----
> > From: Bailey Bruce [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Tuesday, November 28, 2006 7:24 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n)
> accessible
> > forms
> >
> > Andi asked:
> > > Does anyone know why the Access Board thought that the other
> > > provisions were insufficient for the special case of forms?
>
> I think this was all about PDF at the time. Agencies were moving to
> PDF for publishing documents and creating online forms. Some felt
> that an accessible alternative could be demanded for the former, but
> not as easily for the latter.
>
> Note for how narrow a time window this "special" federal regulation
> was actually needed: less than a year, certainly.
> We should make an effort to present-proof as well as future-proof our
> recommendations.
>
>

From: Andrew Kirkpatrick
Date: Wed, Nov 29 2006 12:15 PM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

> The web requirements for Section 508 do not cover form
> elements. The only reference is in 1194.22(n) which is
> specific to electronic forms.

What would be an example of a 1194.22 "form"?

AWK

From: Fratkin, Mike
Date: Wed, Nov 29 2006 12:20 PM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

According to Doug Wakefield, formerly from the Access Board and what SSA
has adopted, "anytime a webpage requests information from the user, the
user is interacting with a form. So, just entering a user name and
password is still a two line form at its minimum". Additionally, Doug
said that to be accessible a form must permit a user to read any
instructions, complete and submit the information.

Mike


[Andrew wrote:]What would be an example of a 1194.22 "form"?

AWK

From: Sailesh Panchang
Date: Wed, Nov 29 2006 2:45 PM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

> The web requirements for Section 508 do not cover form
> elements. The only reference is in 1194.22(n) which is
> specific to electronic forms.
>What would be an example of a 1194.22 "form"?
Sailesh:
In the current standard, I believe the wording "When electronic forms are
designed to be completed on-line", is used to distinguish such forms from
forms which are electronically available but are not meant for online
completion and submission. Like forms in a PDF file or where where one is
expected to print out a form from a Web page, fill it out and send it. Such
forms were more in vogue when these standards were first written and perhaps
the authors thought it fit to use the qualifier, " designed to be completed
on-line".
Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Wednesday, November 29, 2006 2:10 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n) accessible forms

> The web requirements for Section 508 do not cover form
> elements. The only reference is in 1194.22(n) which is
> specific to electronic forms.

What would be an example of a 1194.22 "form"?

AWK

From: Sailesh Panchang
Date: Wed, Nov 29 2006 3:30 PM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

>I'm not sure if the CURRENT 508 covers all form elements, but a good set of

>requirements should. There is nothing on a form that doesn't also appear
>in other web content (and software too for that matter). So those
>elements or components need to be accessible wherever they are. Fields,
>labels, prompts, cues, whatever.
Sailesh:
Well I cannot see the use of any of the above listed controls outside a form
or an interactive object as one might like to refer to it now. In plain old
HTML for instance which will still remain the lingua franca on the Web for
many more years, how does one use an INPUT or LABEL or SELECT etc. outside
a FORM element with no intent to present interactive content? The standards
should be usable, relatable to terms developers and others use commonly. So
why not call a form a form? And as Jim already pointed out, forms are so
ubiquitous, poorly coded, and their accurate interpretation by assistive
technology is important.
Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =

From: Andrew Kirkpatrick
Date: Wed, Nov 29 2006 9:55 PM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

Mike,
I'm sure I'm misunderstanding you, but originally you said:

> The web requirements for Section 508 do not cover form elements.

I interpreted that to mean that you felt that there couldn't be 1194.22
forms. Rereading it in the original it sounds like you mean that form
elements are not called out on their own, just within the "form" (22n)
standard and that has caused some confusion. Is this an accurate
reading?

AWK

From: Fratkin, Mike
Date: Thu, Nov 30 2006 5:10 AM
Subject: Re: Group D: 21 (l) and 22(n) accessible forms

Yes, it is an accurate reading. Thanks.

Mike

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Wednesday, November 29, 2006 11:49 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group D: 21 (l) and 22(n) accessible
forms

Mike,
I'm sure I'm misunderstanding you, but originally you said:

> The web requirements for Section 508 do not cover form elements.

I interpreted that to mean that you felt that there couldn't be 1194.22
forms. Rereading it in the original it sounds like you mean that form
elements are not called out on their own, just within the "form" (22n)
standard and that has caused some confusion. Is this an accurate
reading?

AWK