Thread Subject: Thoughts on Current Web Proposal

Return to this mailing list's archives

From: Barrett, Don
Date: Sun, Mar 25 2007 9:35 AM
Subject: Thoughts on Current Web Proposal

Some Loose Ends I Have Been Thinking About with Regard to the Current
Iteration of the Web Standards per Andy's post on the WIKI

1. We have deferred 1194.22(b) to the AV group. by deferring this, the
web standards lose their property of being self-contained. Each set of
standards was developed by the Board so they could stand alone; so, for
example, both the software standards and the web standards had a
requirement for forms accessibility. Since captioning on the web is
critical, we might consider keeping that standard in the web group. If
the AV subcommittee can make a recommendation to enhance it, we can
adopt it, but it still belongs in the web standards in whatever form it
takes.

2. I have had some concern about the lack of clarity and specificity in
the term "programmatically determined" when used alone in any given
standard. It looks like the term is defined as part of the proposed
22(d) standard. This is very helpful, and I would like to suggest that
whenever the phrase is used as an object in a standard such as in the
proposed standard, its definition always follow it. I think this will
provide the same level of clarification as do the table-specific
examples in the proposed 22(g). However, when the term is used as an
adjective as in "2.4.4 The purpose of each link can be determined from
the link text and its programmatically determined link context," it
probably doesn't require expansion, since by reference, it will mean
what it means as fleshed out when used as the object in other standards.


3. in the proposed replacement for 22(e) and 22(f) and 21(a),
* 2.1.1 "All functionality of the content is operable through a keyboard
interface without requiring specific timings for individual keystrokes,
except where the underlying task requires analog, time-dependent input,"
the phrase "analog, time-dependent input" has been a sticking point for
some of us. How do people feel about something like this:
"All functionality of the content is operable through a keyboard
interface without requiring specific timings for individual keystrokes,
except where the underlying task requires a level of control
unattainable through a keyboard interface."

4. In the above-mentioned standard, "2.4.4 The purpose of each link can
be determined from the link text and its programmatically determined
link context," I am wondering if we should change the "and" to "or." I
think it may be tough to mandate that both the link text "and" the link
context determine the purpose of a given link. Either the link text
"or" its context must define its purpose, but not both. A good example
of this is the infamous "click here" link. If it can be understood in
context, it would be allowable though of course undesirable; the
standard in its present form would actually disallow the use of links
such as this, something we can't realistically mandate.

5. I am wondering if we should delete the frames requirement 1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

From: rmshah@starpower.net
Date: Sun, Mar 25 2007 3:30 PM
Subject: Re: Thoughts on Current Web Proposal

Hi Don,

In your below message, you write:
> 5. I am wondering if we should delete the frames requirement 1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

RS: I agree with this aspect for screen readers, however, I would think, without seeming to be an expert on this, that individuals with dyslexia would find intuitive frame names as 1helpful navigational aids.

Regards,

Rajiv


-----Original Message-----
.From: "Barrett, Don"< = EMAIL ADDRESS REMOVED = >
.Sent: 3/25/07 12:31:50 PM
.To: " = EMAIL ADDRESS REMOVED = "< = EMAIL ADDRESS REMOVED = >
.Subject: [teitac-websoftware] Thoughts on Current Web Proposal
.
.Some Loose Ends I Have Been Thinking About with Regard to the Current
.Iteration of the Web Standards per Andy's post on the WIKI
.
.1. We have deferred 1194.22(b) to the AV group. by deferring this, the
.web standards lose their property of being self-contained. Each set of
.standards was developed by the Board so they could stand alone; so, for
.example, both the software standards and the web standards had a
.requirement for forms accessibility. Since captioning on the web is
.critical, we might consider keeping that standard in the web group. If
.the AV subcommittee can make a recommendation to enhance it, we can
.adopt it, but it still belongs in the web standards in whatever form it
.takes.
.
.2. I have had some concern about the lack of clarity and specificity in
.the term "programmatically determined" when used alone in any given
.standard. It looks like the term is defined as part of the proposed
.22(d) standard. This is very helpful, and I would like to suggest that
.whenever the phrase is used as an object in a standard such as in the
.proposed standard, its definition always follow it. I think this will
.provide the same level of clarification as do the table-specific
.examples in the proposed 22(g). However, when the term is used as an
.adjective as in "2.4.4 The purpose of each link can be determined from
.the link text and its programmatically determined link context," it
.probably doesn't require expansion, since by reference, it will mean
.what it means as fleshed out when used as the object in other standards.
.
.
.3. in the proposed replacement for 22(e) and 22(f) and 21(a),
.* 2.1.1 "All functionality of the content is operable through a keyboard
.interface without requiring specific timings for individual keystrokes,
.except where the underlying task requires analog, time-dependent input,"
.the phrase "analog, time-dependent input" has been a sticking point for
.some of us. How do people feel about something like this:
."All functionality of the content is operable through a keyboard
.interface without requiring specific timings for individual keystrokes,
.except where the underlying task requires a level of control
.unattainable through a keyboard interface."
.
.4. In the above-mentioned standard, "2.4.4 The purpose of each link can
.be determined from the link text and its programmatically determined
.link context," I am wondering if we should change the "and" to "or." I
.think it may be tough to mandate that both the link text "and" the link
.context determine the purpose of a given link. Either the link text
."or" its context must define its purpose, but not both. A good example
.of this is the infamous "click here" link. If it can be understood in
.context, it would be allowable though of course undesirable; the
.standard in its present form would actually disallow the use of links
.such as this, something we can't realistically mandate.
.
.5. I am wondering if we should delete the frames requirement 1194.22(i).
.At least for screen readers, definitive frame naming is helpful, but no
.longer a major issue in terms of site navigation and comprehension.
.
.

From: Barrett, Don
Date: Sun, Mar 25 2007 5:40 PM
Subject: Re: Thoughts on Current Web Proposal

Only problem is that the names we are talking about don't show up on the
screen; they are read by the sc4een reader but not displayed, so unless
a person with a learning disability is using a screen reader, they won't
help. I stand by my original suggestion to remove this standard.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Sunday, March 25, 2007 6:25 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Hi Don,

In your below message, you write:
> 5. I am wondering if we should delete the frames requirement
1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

RS: I agree with this aspect for screen readers, however, I would
think, without seeming to be an expert on this, that individuals with
dyslexia would find intuitive frame names as 1helpful navigational aids.

Regards,

Rajiv


-----Original Message-----
.From: "Barrett, Don"< = EMAIL ADDRESS REMOVED = >
.Sent: 3/25/07 12:31:50 PM
.To:
" = EMAIL ADDRESS REMOVED = "< = EMAIL ADDRESS REMOVED = >
.Subject: [teitac-websoftware] Thoughts on Current Web Proposal
.
.Some Loose Ends I Have Been Thinking About with Regard to the Current
.Iteration of the Web Standards per Andy's post on the WIKI
.
.1. We have deferred 1194.22(b) to the AV group. by deferring this, the
.web standards lose their property of being self-contained. Each set of
.standards was developed by the Board so they could stand alone; so, for
.example, both the software standards and the web standards had a
.requirement for forms accessibility. Since captioning on the web is
.critical, we might consider keeping that standard in the web group. If
.the AV subcommittee can make a recommendation to enhance it, we can
.adopt it, but it still belongs in the web standards in whatever form it
.takes.
.
.2. I have had some concern about the lack of clarity and specificity in
.the term "programmatically determined" when used alone in any given
.standard. It looks like the term is defined as part of the proposed
.22(d) standard. This is very helpful, and I would like to suggest that
.whenever the phrase is used as an object in a standard such as in the
.proposed standard, its definition always follow it. I think this will
.provide the same level of clarification as do the table-specific
.examples in the proposed 22(g). However, when the term is used as an
.adjective as in "2.4.4 The purpose of each link can be determined from
.the link text and its programmatically determined link context," it
.probably doesn't require expansion, since by reference, it will mean
.what it means as fleshed out when used as the object in other
standards.
.
.
.3. in the proposed replacement for 22(e) and 22(f) and 21(a),
.* 2.1.1 "All functionality of the content is operable through a
keyboard
.interface without requiring specific timings for individual keystrokes,
.except where the underlying task requires analog, time-dependent
input,"
.the phrase "analog, time-dependent input" has been a sticking point for
.some of us. How do people feel about something like this:
."All functionality of the content is operable through a keyboard
.interface without requiring specific timings for individual keystrokes,
.except where the underlying task requires a level of control
.unattainable through a keyboard interface."
.
.4. In the above-mentioned standard, "2.4.4 The purpose of each link can
.be determined from the link text and its programmatically determined
.link context," I am wondering if we should change the "and" to "or." I
.think it may be tough to mandate that both the link text "and" the link
.context determine the purpose of a given link. Either the link text
."or" its context must define its purpose, but not both. A good example
.of this is the infamous "click here" link. If it can be understood in
.context, it would be allowable though of course undesirable; the
.standard in its present form would actually disallow the use of links
.such as this, something we can't realistically mandate.
.
.5. I am wondering if we should delete the frames requirement
1194.22(i).
.At least for screen readers, definitive frame naming is helpful, but no
.longer a major issue in terms of site navigation and comprehension.
.
.

From: Andrew Kirkpatrick
Date: Sun, Mar 25 2007 9:10 PM
Subject: Re: Thoughts on Current Web Proposal

> 1. We have deferred 1194.22(b) to the AV group. by deferring
> this, the web standards lose their property of being
> self-contained. Each set of standards was developed by the
> Board so they could stand alone; so, for example, both the
> software standards and the web standards had a requirement
> for forms accessibility. Since captioning on the web is
> critical, we might consider keeping that standard in the web
> group. If the AV subcommittee can make a recommendation to
> enhance it, we can adopt it, but it still belongs in the web
> standards in whatever form it takes.

No, I don't agree. The current standards address captions, but don't
include audio description in the web standards. I'm the current
standards if you want audio and video access you must look at 1194.24.

This is part of why I think that there needs to be a section in subpart
A that details what sections users need to look at for specific types of
E&IT. We will never succeed in being comprehensive in each section -
developers may need to look to multiple sections and we need to provide
better guidance.

> 3. in the proposed replacement for 22(e) and 22(f) and 21(a),
> * 2.1.1 "All functionality of the content is operable through
> a keyboard interface without requiring specific timings for
> individual keystrokes, except where the underlying task
> requires analog, time-dependent input,"
> the phrase "analog, time-dependent input" has been a sticking
> point for some of us. How do people feel about something like this:
> "All functionality of the content is operable through a
> keyboard interface without requiring specific timings for
> individual keystrokes, except where the underlying task
> requires a level of control unattainable through a keyboard
> interface."

That sounds like an open invitation for developers to feign ignorance...

> 5. I am wondering if we should delete the frames requirement
> 1194.22(i).
> At least for screen readers, definitive frame naming is
> helpful, but no longer a major issue in terms of site
> navigation and comprehension.

I still think that this could be lumped under a web standard similar to
21d - I'm not convinced that frames are important enough to call out
individually either, but if we had a generalized and non-HTML specific
standard that spoke to providing identify information for components of
web pages and content, we could still cover it.

AWK

From: Gregg Vanderheiden
Date: Sun, Mar 25 2007 10:40 PM
Subject: Re: Thoughts on Current Web Proposal

See GV: Below



Gregg

-- ------------------------------

Gregg C Vanderheiden Ph.D.







> -----Original Message-----

> From: = EMAIL ADDRESS REMOVED =

> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf

> Of Andrew Kirkpatrick

> Sent: Sunday, March 25, 2007 11:06 PM

> To: TEITAC Web/Software Subcommittee

> Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

>

> > 1. We have deferred 1194.22(b) to the AV group. by deferring this,

> > the web standards lose their property of being

> self-contained. Each

> > set of standards was developed by the Board so they could

> stand alone;

> > so, for example, both the software standards and the web

> standards had

> > a requirement for forms accessibility. Since captioning on

> the web is

> > critical, we might consider keeping that standard in the

> web group.

> > If the AV subcommittee can make a recommendation to enhance

> it, we can

> > adopt it, but it still belongs in the web standards in

> whatever form

> > it takes.

>

> No, I don't agree. The current standards address captions,

> but don't include audio description in the web standards.

> I'm the current standards if you want audio and video access

> you must look at 1194.24.

>

> This is part of why I think that there needs to be a section

> in subpart A that details what sections users need to look at

> for specific types of E&IT. We will never succeed in being

> comprehensive in each section - developers may need to look

> to multiple sections and we need to provide better guidance.

>



GV: There are many different technologies and more coming into existence.
If we try to list them in Subpart A it will be inaccurate overnight.



But I see the problem. I think we need to qualify the provisions so that
it is clear which ones apply. Then a filter like the one in the filter tool
can be used to make it easy for others to see. The access board can
maintain it.







> > 3. in the proposed replacement for 22(e) and 22(f) and 21(a),

> > * 2.1.1 "All functionality of the content is operable through a

> > keyboard interface without requiring specific timings for

> individual

> > keystrokes, except where the underlying task requires analog,

> > time-dependent input,"

> > the phrase "analog, time-dependent input" has been a sticking point

> > for some of us. How do people feel about something like this:

> > "All functionality of the content is operable through a keyboard

> > interface without requiring specific timings for individual

> > keystrokes, except where the underlying task requires a level of

> > control unattainable through a keyboard interface."

>

> That sounds like an open invitation for developers to feign

> ignorance...

>



GV: Yes. It needs to be objective. "unattainable" is likely to be
abused and is a judgement.

The subgroup is closing on something. Hope to have it to you all soon.



> > 5. I am wondering if we should delete the frames requirement

> > 1194.22(i).

> > At least for screen readers, definitive frame naming is

> helpful, but

> > no longer a major issue in terms of site navigation and

> comprehension.

>

> I still think that this could be lumped under a web standard

> similar to 21d - I'm not convinced that frames are important

> enough to call out individually either, but if we had a

> generalized and non-HTML specific standard that spoke to

> providing identify information for components of web pages

> and content, we could still cover it.



GV: It seems that this should be covered by a provision requiring names on
interface components or visible structures.

In WCAG it would be 1.3.1 and 4.1.2.





>

> AWK

>

From: Barrett, Don
Date: Mon, Mar 26 2007 3:45 AM
Subject: Re: Thoughts on Current Web Proposal

"No, I don't agree. The current standards address captions, but don't
include audio description in the web standards."

Andrew: Sorry, but I think the present standard in referring to any
multi-media includes audio description and has been quite sufficient
thus far. "(b) Equivalent alternatives for any multimedia presentation
shall be synchronized with the presentation."

"We will never succeed in being comprehensive in each section -
developers may need to look to multiple sections and we need to provide
better guidance."

I must vehemently oppose cross-standard applicability. We have listened
to hundreds of developers over the years who are overwhelmed and have to
be taught the one set of standards which applies to their product, let
alone the complex inter-relationships that cross standard applicability
would inject into the process. Again, this has been working very very
well in government testing situations I know about. I am not aiming for
over simplification, but simplicity and clarity if it can be achieved.
You mention later on your concern about developers being given the
opportunity to "feign ignorance." Give them multiple sets of standards
with which they must comply and you'll see more ignorance than we know
what to do about.

I am curious to see what GV comes up with regarding a replacement for
time-dependent analog input. If its simple, clear, and protects
disabled people in Federal jobs, it will get my vote.

Don




-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Monday, March 26, 2007 12:06 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

> 1. We have deferred 1194.22(b) to the AV group. by deferring
> this, the web standards lose their property of being
> self-contained. Each set of standards was developed by the
> Board so they could stand alone; so, for example, both the
> software standards and the web standards had a requirement
> for forms accessibility. Since captioning on the web is
> critical, we might consider keeping that standard in the web
> group. If the AV subcommittee can make a recommendation to
> enhance it, we can adopt it, but it still belongs in the web
> standards in whatever form it takes.

No, I don't agree. The current standards address captions, but don't
include audio description in the web standards. I'm the current
standards if you want audio and video access you must look at 1194.24.

This is part of why I think that there needs to be a section in subpart
A that details what sections users need to look at for specific types of
E&IT. We will never succeed in being comprehensive in each section -
developers may need to look to multiple sections and we need to provide
better guidance.

> 3. in the proposed replacement for 22(e) and 22(f) and 21(a),
> * 2.1.1 "All functionality of the content is operable through
> a keyboard interface without requiring specific timings for
> individual keystrokes, except where the underlying task
> requires analog, time-dependent input,"
> the phrase "analog, time-dependent input" has been a sticking
> point for some of us. How do people feel about something like this:
> "All functionality of the content is operable through a
> keyboard interface without requiring specific timings for
> individual keystrokes, except where the underlying task
> requires a level of control unattainable through a keyboard
> interface."

That sounds like an open invitation for developers to feign ignorance...

> 5. I am wondering if we should delete the frames requirement
> 1194.22(i).
> At least for screen readers, definitive frame naming is
> helpful, but no longer a major issue in terms of site
> navigation and comprehension.

I still think that this could be lumped under a web standard similar to
21d - I'm not convinced that frames are important enough to call out
individually either, but if we had a generalized and non-HTML specific
standard that spoke to providing identify information for components of
web pages and content, we could still cover it.

AWK

From: Fratkin, Mike
Date: Mon, Mar 26 2007 4:25 AM
Subject: Re: Thoughts on Current Web Proposal

Don, could you please explain why you think that providing meaningful
frame names is merely helpful and no longer a major issue in terms of
site navigation and comprehension. We are seeing commercial applications
using 10-15 frames, many of them just for background processing, and
others with names that do not make sense at all while navigating with a
screen reader. Users tend to get completely lost when there are so many
frames, if the frame names are not meaningful it just confounds the
understanding.

If anything the requirement needs to clarified to include direction on
limiting the numbers of frames and making navigation more
understandable.

Mike Fratkin

[Don wrote:]
Only problem is that the names we are talking about don't show up on the
screen; they are read by the sc4een reader but not displayed, so unless
a person with a learning disability is using a screen reader, they won't
help. I stand by my original suggestion to remove this standard.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Sunday, March 25, 2007 6:25 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Hi Don,

In your below message, you write:
> 5. I am wondering if we should delete the frames requirement
1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

RS: I agree with this aspect for screen readers, however, I would
think, without seeming to be an expert on this, that individuals with
dyslexia would find intuitive frame names as 1helpful navigational aids.

Regards,

Rajiv


-----Original Message-----
.From: "Barrett, Don"< = EMAIL ADDRESS REMOVED = >
.Sent: 3/25/07 12:31:50 PM
.To:
" = EMAIL ADDRESS REMOVED = "< = EMAIL ADDRESS REMOVED = >
.Subject: [teitac-websoftware] Thoughts on Current Web Proposal .
.Some Loose Ends I Have Been Thinking About with Regard to the Current
.Iteration of the Web Standards per Andy's post on the WIKI .
.1. We have deferred 1194.22(b) to the AV group. by deferring this, the
.web standards lose their property of being self-contained. Each set of
.standards was developed by the Board so they could stand alone; so, for
.example, both the software standards and the web standards had a
.requirement for forms accessibility. Since captioning on the web is
.critical, we might consider keeping that standard in the web group. If
.the AV subcommittee can make a recommendation to enhance it, we can
.adopt it, but it still belongs in the web standards in whatever form it
.takes.
.
.2. I have had some concern about the lack of clarity and specificity in
.the term "programmatically determined" when used alone in any given
.standard. It looks like the term is defined as part of the proposed
.22(d) standard. This is very helpful, and I would like to suggest that
.whenever the phrase is used as an object in a standard such as in the
.proposed standard, its definition always follow it. I think this will
.provide the same level of clarification as do the table-specific
.examples in the proposed 22(g). However, when the term is used as an
.adjective as in "2.4.4 The purpose of each link can be determined from
.the link text and its programmatically determined link context," it
.probably doesn't require expansion, since by reference, it will mean
.what it means as fleshed out when used as the object in other
standards.
.
.
.3. in the proposed replacement for 22(e) and 22(f) and 21(a),
.* 2.1.1 "All functionality of the content is operable through a
keyboard .interface without requiring specific timings for individual
keystrokes, .except where the underlying task requires analog,
time-dependent input,"
.the phrase "analog, time-dependent input" has been a sticking point for
.some of us. How do people feel about something like this:
."All functionality of the content is operable through a keyboard
.interface without requiring specific timings for individual keystrokes,
.except where the underlying task requires a level of control
.unattainable through a keyboard interface."
.
.4. In the above-mentioned standard, "2.4.4 The purpose of each link can
.be determined from the link text and its programmatically determined
.link context," I am wondering if we should change the "and" to "or." I
.think it may be tough to mandate that both the link text "and" the link
.context determine the purpose of a given link. Either the link text
."or" its context must define its purpose, but not both. A good example
.of this is the infamous "click here" link. If it can be understood in
.context, it would be allowable though of course undesirable; the
.standard in its present form would actually disallow the use of links
.such as this, something we can't realistically mandate.
.
.5. I am wondering if we should delete the frames requirement
1194.22(i).
.At least for screen readers, definitive frame naming is helpful, but no
.longer a major issue in terms of site navigation and comprehension.
.
.

From: Andrew Kirkpatrick
Date: Mon, Mar 26 2007 5:10 AM
Subject: Re: Thoughts on Current Web Proposal

Mike,
22b only requires that equivalents be synchronized. Captions are required from 22a- audio descriptions are not mentioned in 22 at all, explicitly or implicitly.
Awk


---
Andrew Kirkpatrick

Corporate Accessibility Engineering Lead

Adobe Systems

= EMAIL ADDRESS REMOVED =

617.219.2209

-----Original Message-----
From: Barrett, Don [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Monday, March 26, 2007 03:44 AM Pacific Standard Time
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

"No, I don't agree. The current standards address captions, but don't
include audio description in the web standards."

Andrew: Sorry, but I think the present standard in referring to any
multi-media includes audio description and has been quite sufficient
thus far. "(b) Equivalent alternatives for any multimedia presentation
shall be synchronized with the presentation."

"We will never succeed in being comprehensive in each section -
developers may need to look to multiple sections and we need to provide
better guidance."

I must vehemently oppose cross-standard applicability. We have listened
to hundreds of developers over the years who are overwhelmed and have to
be taught the one set of standards which applies to their product, let
alone the complex inter-relationships that cross standard applicability
would inject into the process. Again, this has been working very very
well in government testing situations I know about. I am not aiming for
over simplification, but simplicity and clarity if it can be achieved.
You mention later on your concern about developers being given the
opportunity to "feign ignorance." Give them multiple sets of standards
with which they must comply and you'll see more ignorance than we know
what to do about.

I am curious to see what GV comes up with regarding a replacement for
time-dependent analog input. If its simple, clear, and protects
disabled people in Federal jobs, it will get my vote.

Don




-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Monday, March 26, 2007 12:06 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

> 1. We have deferred 1194.22(b) to the AV group. by deferring
> this, the web standards lose their property of being
> self-contained. Each set of standards was developed by the
> Board so they could stand alone; so, for example, both the
> software standards and the web standards had a requirement
> for forms accessibility. Since captioning on the web is
> critical, we might consider keeping that standard in the web
> group. If the AV subcommittee can make a recommendation to
> enhance it, we can adopt it, but it still belongs in the web
> standards in whatever form it takes.

No, I don't agree. The current standards address captions, but don't
include audio description in the web standards. I'm the current
standards if you want audio and video access you must look at 1194.24.

This is part of why I think that there needs to be a section in subpart
A that details what sections users need to look at for specific types of
E&IT. We will never succeed in being comprehensive in each section -
developers may need to look to multiple sections and we need to provide
better guidance.

> 3. in the proposed replacement for 22(e) and 22(f) and 21(a),
> * 2.1.1 "All functionality of the content is operable through
> a keyboard interface without requiring specific timings for
> individual keystrokes, except where the underlying task
> requires analog, time-dependent input,"
> the phrase "analog, time-dependent input" has been a sticking
> point for some of us. How do people feel about something like this:
> "All functionality of the content is operable through a
> keyboard interface without requiring specific timings for
> individual keystrokes, except where the underlying task
> requires a level of control unattainable through a keyboard
> interface."

That sounds like an open invitation for developers to feign ignorance...

> 5. I am wondering if we should delete the frames requirement
> 1194.22(i).
> At least for screen readers, definitive frame naming is
> helpful, but no longer a major issue in terms of site
> navigation and comprehension.

I still think that this could be lumped under a web standard similar to
21d - I'm not convinced that frames are important enough to call out
individually either, but if we had a generalized and non-HTML specific
standard that spoke to providing identify information for components of
web pages and content, we could still cover it.

AWK

From: Andrew Kirkpatrick
Date: Mon, Mar 26 2007 5:15 AM
Subject: Re: Thoughts on Current Web Proposal

Sorry, my last response was to don, even though I addressed mike...


---
Andrew Kirkpatrick

Corporate Accessibility Engineering Lead

Adobe Systems

= EMAIL ADDRESS REMOVED =

617.219.2209

-----Original Message-----
From: Barrett, Don [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Monday, March 26, 2007 03:44 AM Pacific Standard Time
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

"No, I don't agree. The current standards address captions, but don't
include audio description in the web standards."

Andrew: Sorry, but I think the present standard in referring to any
multi-media includes audio description and has been quite sufficient
thus far. "(b) Equivalent alternatives for any multimedia presentation
shall be synchronized with the presentation."

"We will never succeed in being comprehensive in each section -
developers may need to look to multiple sections and we need to provide
better guidance."

I must vehemently oppose cross-standard applicability. We have listened
to hundreds of developers over the years who are overwhelmed and have to
be taught the one set of standards which applies to their product, let
alone the complex inter-relationships that cross standard applicability
would inject into the process. Again, this has been working very very
well in government testing situations I know about. I am not aiming for
over simplification, but simplicity and clarity if it can be achieved.
You mention later on your concern about developers being given the
opportunity to "feign ignorance." Give them multiple sets of standards
with which they must comply and you'll see more ignorance than we know
what to do about.

I am curious to see what GV comes up with regarding a replacement for
time-dependent analog input. If its simple, clear, and protects
disabled people in Federal jobs, it will get my vote.

Don




-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Monday, March 26, 2007 12:06 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

> 1. We have deferred 1194.22(b) to the AV group. by deferring
> this, the web standards lose their property of being
> self-contained. Each set of standards was developed by the
> Board so they could stand alone; so, for example, both the
> software standards and the web standards had a requirement
> for forms accessibility. Since captioning on the web is
> critical, we might consider keeping that standard in the web
> group. If the AV subcommittee can make a recommendation to
> enhance it, we can adopt it, but it still belongs in the web
> standards in whatever form it takes.

No, I don't agree. The current standards address captions, but don't
include audio description in the web standards. I'm the current
standards if you want audio and video access you must look at 1194.24.

This is part of why I think that there needs to be a section in subpart
A that details what sections users need to look at for specific types of
E&IT. We will never succeed in being comprehensive in each section -
developers may need to look to multiple sections and we need to provide
better guidance.

> 3. in the proposed replacement for 22(e) and 22(f) and 21(a),
> * 2.1.1 "All functionality of the content is operable through
> a keyboard interface without requiring specific timings for
> individual keystrokes, except where the underlying task
> requires analog, time-dependent input,"
> the phrase "analog, time-dependent input" has been a sticking
> point for some of us. How do people feel about something like this:
> "All functionality of the content is operable through a
> keyboard interface without requiring specific timings for
> individual keystrokes, except where the underlying task
> requires a level of control unattainable through a keyboard
> interface."

That sounds like an open invitation for developers to feign ignorance...

> 5. I am wondering if we should delete the frames requirement
> 1194.22(i).
> At least for screen readers, definitive frame naming is
> helpful, but no longer a major issue in terms of site
> navigation and comprehension.

I still think that this could be lumped under a web standard similar to
21d - I'm not convinced that frames are important enough to call out
individually either, but if we had a generalized and non-HTML specific
standard that spoke to providing identify information for components of
web pages and content, we could still cover it.

AWK

From: David Poehlman
Date: Mon, Mar 26 2007 6:05 AM
Subject: Re: Thoughts on Current Web Proposal

I wwant to know how it is no longer an issue? When I find frames
with meaningless names, they still have meaningless names. When I
use older technologies, I still need to apply the implementation they
provide.

On Mar 25, 2007, at 8:34 PM, Barrett, Don wrote:

Only problem is that the names we are talking about don't show up on the
screen; they are read by the sc4een reader but not displayed, so unless
a person with a learning disability is using a screen reader, they won't
help. I stand by my original suggestion to remove this standard.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Sunday, March 25, 2007 6:25 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Hi Don,

In your below message, you write:
> 5. I am wondering if we should delete the frames requirement
1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

RS: I agree with this aspect for screen readers, however, I would
think, without seeming to be an expert on this, that individuals with
dyslexia would find intuitive frame names as 1helpful navigational aids.

Regards,

Rajiv


-----Original Message-----
.From: "Barrett, Don"< = EMAIL ADDRESS REMOVED = >
.Sent: 3/25/07 12:31:50 PM
.To:
" = EMAIL ADDRESS REMOVED = "< = EMAIL ADDRESS REMOVED = >
.Subject: [teitac-websoftware] Thoughts on Current Web Proposal
.
.Some Loose Ends I Have Been Thinking About with Regard to the Current
.Iteration of the Web Standards per Andy's post on the WIKI
.
.1. We have deferred 1194.22(b) to the AV group. by deferring this, the
.web standards lose their property of being self-contained. Each set of
.standards was developed by the Board so they could stand alone; so, for
.example, both the software standards and the web standards had a
.requirement for forms accessibility. Since captioning on the web is
.critical, we might consider keeping that standard in the web group. If
.the AV subcommittee can make a recommendation to enhance it, we can
.adopt it, but it still belongs in the web standards in whatever form it
.takes.
.
.2. I have had some concern about the lack of clarity and specificity in
.the term "programmatically determined" when used alone in any given
.standard. It looks like the term is defined as part of the proposed
.22(d) standard. This is very helpful, and I would like to suggest that
.whenever the phrase is used as an object in a standard such as in the
.proposed standard, its definition always follow it. I think this will
.provide the same level of clarification as do the table-specific
.examples in the proposed 22(g). However, when the term is used as an
.adjective as in "2.4.4 The purpose of each link can be determined from
.the link text and its programmatically determined link context," it
.probably doesn't require expansion, since by reference, it will mean
.what it means as fleshed out when used as the object in other
standards.
.
.
.3. in the proposed replacement for 22(e) and 22(f) and 21(a),
.* 2.1.1 "All functionality of the content is operable through a
keyboard
.interface without requiring specific timings for individual keystrokes,
.except where the underlying task requires analog, time-dependent
input,"
.the phrase "analog, time-dependent input" has been a sticking point for
.some of us. How do people feel about something like this:
."All functionality of the content is operable through a keyboard
.interface without requiring specific timings for individual keystrokes,
.except where the underlying task requires a level of control
.unattainable through a keyboard interface."
.
.4. In the above-mentioned standard, "2.4.4 The purpose of each link can
.be determined from the link text and its programmatically determined
.link context," I am wondering if we should change the "and" to "or." I
.think it may be tough to mandate that both the link text "and" the link
.context determine the purpose of a given link. Either the link text
."or" its context must define its purpose, but not both. A good example
.of this is the infamous "click here" link. If it can be understood in
.context, it would be allowable though of course undesirable; the
.standard in its present form would actually disallow the use of links
.such as this, something we can't realistically mandate.
.
.5. I am wondering if we should delete the frames requirement
1194.22(i).
.At least for screen readers, definitive frame naming is helpful, but no
.longer a major issue in terms of site navigation and comprehension.
.
.

From: Andi Snow-Weaver
Date: Mon, Mar 26 2007 6:50 AM
Subject: Re: Thoughts on Current Web Proposal

To Don's concern about 22 (d) being deferred to the A/V subcommittee...

"Deferring" it doesn't mean there won't be a provision in 1194.22
addressing multimedia captions and audio descriptions. It just means we are
deferring to the A/V subcommittee to decide what it should be.

To Andrew's point about reducing duplication of the multimedia standards
and adding a section that guides developers to all the sections that apply
to what they are doing and to Don's point that the Web section needs to be
complete...

I agree with both of you. <grin>

Everyone would like to have one list of requirements that are relevant to
what they are doing. But since the standard must be a fixed document, not
an interactive tool, and since technologies are changing faster than the
standard can keep up with them, I think our best approach is to follow the
lead of the international standards (WCAG 2.0 and ISO 9241-171). Then at
least the US will not be out of step with what the rest of the world is
doing. WCAG 2.0 does include provisions addressing multimedia so I support
keeping this in the Web part of Section 508.

I also think we need something like "applicability guidelines" such as
Andrew suggests but it probably should be external to the standard itself
so that it can be modified as new convereged products evolve that we
haven't thought of yet. We have something similar in IBM for our developers
that guides them on which checklist(s) they have to complete.

To the disagreement between Andrew and Don over whether the current 1194.22
(d) covers audio descriptions, I agree with Don. "Equivalent alternatives"
can be either captions as equivalents for the audio information or audio
descriptions as equivalents for the visual information. And this is one
thing that is clear in the Access Board's guide to the standards. [1]

To the keyboard provision discussion, let's table that until the keyboard
sub-team comes back with their proposal.

To the frame titles issue ....

I think frames should be titled but I don't like this sort of technology
specific provision in the standard. Gregg made a good suggestion - to add
1.3.1 and 4.1.2 from WCAG 2.0 that cover frame titles. In the proposal for
harmonizing with WCAG 2.0 [2], we already have 1.3.1 proposed as 1194.22
(g) and 4.1.2 proposed as 1194.22 (k).

To Mike's point about limiting the number of frames and making navigation
more understandable, I'd like to hear more about this and hopefully a
proposal from Mike. <smile>

[1] http://www.access-board.gov/sec508/guide/1194.22.htm#(b)
[2] http://teitac.org/wiki/Web_and_Software:_Web_Like_WCAG_2_0

Andi

From: Andrew Kirkpatrick
Date: Mon, Mar 26 2007 7:35 AM
Subject: Re: Thoughts on Current Web Proposal

> To the disagreement between Andrew and Don over whether the
> current 1194.22
> (d) covers audio descriptions, I agree with Don. "Equivalent
> alternatives"
> can be either captions as equivalents for the audio
> information or audio descriptions as equivalents for the
> visual information. And this is one thing that is clear in
> the Access Board's guide to the standards. [1]

I also agree that 22b means that all types of equivalents need to be
synchronized. However, 22a is where captions are required, there is no
place that requires the addition of audio descriptions. If you have
them 22b says that they need to be synchronized - let me know where in
22 audio/video descriptions are required. They are called out
explicitly in 24 along with captions, so the standards are aware of
them, but they aren't mentioned. Are we to assume that audio
descriptions are far more obvious to include than captions and image
equivalents which needed to be mentioned explicitly?

AWK

From: Barrett, Don
Date: Mon, Mar 26 2007 7:50 AM
Subject: Re: Thoughts on Current Web Proposal

Not an easy task Mike. I personally don't view the confusion of screen
reader users as an accessibility issue; ease of use is usability, not
accessibility, but I can't prove that. I just think that requiring that
information be available is one thing, and we should do it; requiring
that it be easy to navigate and utilize is quite another and outside the
scope of 508. There is a very subtle message here about "dummying down"
a site for those struggling screen reader users that concerns me. Just
go to amazon.com with a screen reader and order something; it's not for
the faint of heart, but I do it because I can and that's what is out
there. I've tried the simplified versions of Amazon and they always
lack some feature I need, so I end up back at the monster site as it is
and I manage. It's just very hard to objectify usability into an
accessibility paradigm, and believe me, I don't think naming frames is a
terrible thing at all, so if it stays, so be it.


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
Fratkin, Mike
Sent: Monday, March 26, 2007 7:22 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Don, could you please explain why you think that providing meaningful
frame names is merely helpful and no longer a major issue in terms of
site navigation and comprehension. We are seeing commercial applications
using 10-15 frames, many of them just for background processing, and
others with names that do not make sense at all while navigating with a
screen reader. Users tend to get completely lost when there are so many
frames, if the frame names are not meaningful it just confounds the
understanding.

If anything the requirement needs to clarified to include direction on
limiting the numbers of frames and making navigation more
understandable.

Mike Fratkin

[Don wrote:]
Only problem is that the names we are talking about don't show up on the
screen; they are read by the sc4een reader but not displayed, so unless
a person with a learning disability is using a screen reader, they won't
help. I stand by my original suggestion to remove this standard.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Sunday, March 25, 2007 6:25 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Hi Don,

In your below message, you write:
> 5. I am wondering if we should delete the frames requirement
1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

RS: I agree with this aspect for screen readers, however, I would
think, without seeming to be an expert on this, that individuals with
dyslexia would find intuitive frame names as 1helpful navigational aids.

Regards,

Rajiv


-----Original Message-----
.From: "Barrett, Don"< = EMAIL ADDRESS REMOVED = >
.Sent: 3/25/07 12:31:50 PM
.To:
" = EMAIL ADDRESS REMOVED = "< = EMAIL ADDRESS REMOVED = >
.Subject: [teitac-websoftware] Thoughts on Current Web Proposal .
.Some Loose Ends I Have Been Thinking About with Regard to the Current
.Iteration of the Web Standards per Andy's post on the WIKI .
.1. We have deferred 1194.22(b) to the AV group. by deferring this, the
.web standards lose their property of being self-contained. Each set of
.standards was developed by the Board so they could stand alone; so, for
.example, both the software standards and the web standards had a
.requirement for forms accessibility. Since captioning on the web is
.critical, we might consider keeping that standard in the web group. If
.the AV subcommittee can make a recommendation to enhance it, we can
.adopt it, but it still belongs in the web standards in whatever form it
.takes.
.
.2. I have had some concern about the lack of clarity and specificity in
.the term "programmatically determined" when used alone in any given
.standard. It looks like the term is defined as part of the proposed
.22(d) standard. This is very helpful, and I would like to suggest that
.whenever the phrase is used as an object in a standard such as in the
.proposed standard, its definition always follow it. I think this will
.provide the same level of clarification as do the table-specific
.examples in the proposed 22(g). However, when the term is used as an
.adjective as in "2.4.4 The purpose of each link can be determined from
.the link text and its programmatically determined link context," it
.probably doesn't require expansion, since by reference, it will mean
.what it means as fleshed out when used as the object in other
standards.
.
.
.3. in the proposed replacement for 22(e) and 22(f) and 21(a),
.* 2.1.1 "All functionality of the content is operable through a
keyboard .interface without requiring specific timings for individual
keystrokes, .except where the underlying task requires analog,
time-dependent input,"
.the phrase "analog, time-dependent input" has been a sticking point for
.some of us. How do people feel about something like this:
."All functionality of the content is operable through a keyboard
.interface without requiring specific timings for individual keystrokes,
.except where the underlying task requires a level of control
.unattainable through a keyboard interface."
.
.4. In the above-mentioned standard, "2.4.4 The purpose of each link can
.be determined from the link text and its programmatically determined
.link context," I am wondering if we should change the "and" to "or." I
.think it may be tough to mandate that both the link text "and" the link
.context determine the purpose of a given link. Either the link text
."or" its context must define its purpose, but not both. A good example
.of this is the infamous "click here" link. If it can be understood in
.context, it would be allowable though of course undesirable; the
.standard in its present form would actually disallow the use of links
.such as this, something we can't realistically mandate.
.
.5. I am wondering if we should delete the frames requirement
1194.22(i).
.At least for screen readers, definitive frame naming is helpful, but no
.longer a major issue in terms of site navigation and comprehension.
.
.

From: Debbie Cook
Date: Mon, Mar 26 2007 7:55 AM
Subject: Re: Thoughts on Current Web Proposal

Don wrote:
5. I am wondering if we should delete the frames requirement 1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

DC: Ironic that we've been concerned about accommodating people who are
deaf-blind but would unintentially toss out the much larger population of
people with both vision and learning limitations. No, I wouldn't make more
of this standard than it is, but I most certainly wouldn't drop it. It
definitely provides meaningful orientation until screen readers become smart
enough to stop reading this invisible text altogether. Wish we could
actually prohibit the use of frames, but of course that's way out of bounds.

From: Bekure, Blene W.
Date: Mon, Mar 26 2007 8:00 AM
Subject: Re: Thoughts on Current Web Proposal

I couldn't agree anymore! I do not think it should be dropped.


Blene W. Bekure


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie
Cook
Sent: Tuesday, March 27, 2007 10:48 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Don wrote:
5. I am wondering if we should delete the frames requirement 1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

DC: Ironic that we've been concerned about accommodating people who are
deaf-blind but would unintentially toss out the much larger population
of people with both vision and learning limitations. No, I wouldn't make
more of this standard than it is, but I most certainly wouldn't drop it.
It definitely provides meaningful orientation until screen readers
become smart enough to stop reading this invisible text altogether. Wish
we could actually prohibit the use of frames, but of course that's way
out of bounds.

From: Fratkin, Mike
Date: Mon, Mar 26 2007 9:55 AM
Subject: Re: Thoughts on Current Web Proposal

Don, there are several issues here. There is the issue of meaningful
names, and there is the number of frames (which can hamper navigation
and thus productivity and comparable access). Yes, it could be argued
that if a frame is not named or named incorrectly, that it can still be
accessed but not be usable, as it may not be understandable. At the
same time, I will continue to argue for trying to maximize comparable
access. It is much easier to bring up a frames list that is specific to
the function of the frame rather than saying, "main, left, right or
system frame".

Additionally, if there are 10 or more frames on a screen, navigation for
a keyboard user is even more difficult than a screen reader user who at
least normally knows when they are in a new frame. A recent application
had the following frame names:

Loading application. Please wait.
Content
Graphic content
Learning Point Text
Hidden frame
8 separate system frames

Some may be considered meaningful but also serve no purpose and can be
totally confusing. The "please wait" frame is completely deceptive as
there is no reason to wait and the frame serves no purpose. A mouse
user would never have a problem here. A keyboard user may be in this
frame and not know where they are. A screen reader user could land here
and just wait and nothing will ever happen. We need to retain the frame
requirement and should be able to do better in explaining this
requirement.

Mike Fratkin
Contractor for SSA

[Don wrote:]
Not an easy task Mike. I personally don't view the confusion of screen
reader users as an accessibility issue; ease of use is usability, not
accessibility, but I can't prove that. I just think that requiring that
information be available is one thing, and we should do it; requiring
that it be easy to navigate and utilize is quite another and outside the
scope of 508. There is a very subtle message here about "dummying down"
a site for those struggling screen reader users that concerns me. Just
go to amazon.com with a screen reader and order something; it's not for
the faint of heart, but I do it because I can and that's what is out
there. I've tried the simplified versions of Amazon and they always
lack some feature I need, so I end up back at the monster site as it is
and I manage. It's just very hard to objectify usability into an
accessibility paradigm, and believe me, I don't think naming frames is a
terrible thing at all, so if it stays, so be it.


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
Fratkin, Mike
Sent: Monday, March 26, 2007 7:22 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Don, could you please explain why you think that providing meaningful
frame names is merely helpful and no longer a major issue in terms of
site navigation and comprehension. We are seeing commercial applications
using 10-15 frames, many of them just for background processing, and
others with names that do not make sense at all while navigating with a
screen reader. Users tend to get completely lost when there are so many
frames, if the frame names are not meaningful it just confounds the
understanding.

If anything the requirement needs to clarified to include direction on
limiting the numbers of frames and making navigation more
understandable.

Mike Fratkin

[Don wrote:]
Only problem is that the names we are talking about don't show up on the
screen; they are read by the sc4een reader but not displayed, so unless
a person with a learning disability is using a screen reader, they won't
help. I stand by my original suggestion to remove this standard.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Sunday, March 25, 2007 6:25 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Hi Don,

In your below message, you write:
> 5. I am wondering if we should delete the frames requirement
1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

RS: I agree with this aspect for screen readers, however, I would
think, without seeming to be an expert on this, that individuals with
dyslexia would find intuitive frame names as 1helpful navigational aids.

Regards,

Rajiv


-----Original Message-----
.From: "Barrett, Don"< = EMAIL ADDRESS REMOVED = >
.Sent: 3/25/07 12:31:50 PM
.To:
" = EMAIL ADDRESS REMOVED = "< = EMAIL ADDRESS REMOVED = >
.Subject: [teitac-websoftware] Thoughts on Current Web Proposal .
.Some Loose Ends I Have Been Thinking About with Regard to the Current
.Iteration of the Web Standards per Andy's post on the WIKI .
.1. We have deferred 1194.22(b) to the AV group. by deferring this, the
.web standards lose their property of being self-contained. Each set of
.standards was developed by the Board so they could stand alone; so, for
.example, both the software standards and the web standards had a
.requirement for forms accessibility. Since captioning on the web is
.critical, we might consider keeping that standard in the web group. If
.the AV subcommittee can make a recommendation to enhance it, we can
.adopt it, but it still belongs in the web standards in whatever form it
.takes.
.
.2. I have had some concern about the lack of clarity and specificity in
.the term "programmatically determined" when used alone in any given
.standard. It looks like the term is defined as part of the proposed
.22(d) standard. This is very helpful, and I would like to suggest that
.whenever the phrase is used as an object in a standard such as in the
.proposed standard, its definition always follow it. I think this will
.provide the same level of clarification as do the table-specific
.examples in the proposed 22(g). However, when the term is used as an
.adjective as in "2.4.4 The purpose of each link can be determined from
.the link text and its programmatically determined link context," it
.probably doesn't require expansion, since by reference, it will mean
.what it means as fleshed out when used as the object in other
standards.
.
.
.3. in the proposed replacement for 22(e) and 22(f) and 21(a),
.* 2.1.1 "All functionality of the content is operable through a
keyboard .interface without requiring specific timings for individual
keystrokes, .except where the underlying task requires analog,
time-dependent input,"
.the phrase "analog, time-dependent input" has been a sticking point for
.some of us. How do people feel about something like this:
."All functionality of the content is operable through a keyboard
.interface without requiring specific timings for individual keystrokes,
.except where the underlying task requires a level of control
.unattainable through a keyboard interface."
.
.4. In the above-mentioned standard, "2.4.4 The purpose of each link can
.be determined from the link text and its programmatically determined
.link context," I am wondering if we should change the "and" to "or." I
.think it may be tough to mandate that both the link text "and" the link
.context determine the purpose of a given link. Either the link text
."or" its context must define its purpose, but not both. A good example
.of this is the infamous "click here" link. If it can be understood in
.context, it would be allowable though of course undesirable; the
.standard in its present form would actually disallow the use of links
.such as this, something we can't realistically mandate.
.
.5. I am wondering if we should delete the frames requirement
1194.22(i).
.At least for screen readers, definitive frame naming is helpful, but no
.longer a major issue in terms of site navigation and comprehension.
.
.

From: Sailesh Panchang
Date: Mon, Mar 26 2007 10:10 AM
Subject: Re: Thoughts on Current Web Proposal

About Frames:
I support Mike and agree with his views. Yet as Andrew pointed out, it may
not be necessary to separate the requirement for frames into a specific
standard if it can be covered with a requirement for naming UI components
as suggested by GV.

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: Lybarger, Barbara (MOD)
Date: Mon, Mar 26 2007 11:35 AM
Subject: Re: Thoughts on Current Web Proposal

Just a reminder. The core goal of Section 508 is that systems be as
easy to use for folks with disabilities as they are for people without
disabilities. Although we have discussed the impossibility of achieving
that goal for all types of disabilities (and at all times and with
current technology), it sometime looks like we are getting into
usability because it is necessary to provide equal access. That is not
a negative, and it is certainly not off limits.

Barbara Lybarger

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Barrett, Don
Sent: Monday, March 26, 2007 10:48 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Not an easy task Mike. I personally don't view the confusion of screen
reader users as an accessibility issue; ease of use is usability, not
accessibility, but I can't prove that. I just think that requiring that
information be available is one thing, and we should do it; requiring
that it be easy to navigate and utilize is quite another and outside the
scope of 508. There is a very subtle message here about "dummying down"
a site for those struggling screen reader users that concerns me. Just
go to amazon.com with a screen reader and order something; it's not for
the faint of heart, but I do it because I can and that's what is out
there. I've tried the simplified versions of Amazon and they always
lack some feature I need, so I end up back at the monster site as it is
and I manage. It's just very hard to objectify usability into an
accessibility paradigm, and believe me, I don't think naming frames is a
terrible thing at all, so if it stays, so be it.


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
Fratkin, Mike
Sent: Monday, March 26, 2007 7:22 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Don, could you please explain why you think that providing meaningful
frame names is merely helpful and no longer a major issue in terms of
site navigation and comprehension. We are seeing commercial applications
using 10-15 frames, many of them just for background processing, and
others with names that do not make sense at all while navigating with a
screen reader. Users tend to get completely lost when there are so many
frames, if the frame names are not meaningful it just confounds the
understanding.

If anything the requirement needs to clarified to include direction on
limiting the numbers of frames and making navigation more
understandable.

Mike Fratkin

[Don wrote:]
Only problem is that the names we are talking about don't show up on the
screen; they are read by the sc4een reader but not displayed, so unless
a person with a learning disability is using a screen reader, they won't
help. I stand by my original suggestion to remove this standard.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Sunday, March 25, 2007 6:25 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Hi Don,

In your below message, you write:
> 5. I am wondering if we should delete the frames requirement
1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

RS: I agree with this aspect for screen readers, however, I would
think, without seeming to be an expert on this, that individuals with
dyslexia would find intuitive frame names as 1helpful navigational aids.

Regards,

Rajiv


-----Original Message-----
.From: "Barrett, Don"< = EMAIL ADDRESS REMOVED = >
.Sent: 3/25/07 12:31:50 PM
.To:
" = EMAIL ADDRESS REMOVED = "< = EMAIL ADDRESS REMOVED = >
.Subject: [teitac-websoftware] Thoughts on Current Web Proposal .
.Some Loose Ends I Have Been Thinking About with Regard to the Current
.Iteration of the Web Standards per Andy's post on the WIKI .
.1. We have deferred 1194.22(b) to the AV group. by deferring this, the
.web standards lose their property of being self-contained. Each set of
.standards was developed by the Board so they could stand alone; so, for
.example, both the software standards and the web standards had a
.requirement for forms accessibility. Since captioning on the web is
.critical, we might consider keeping that standard in the web group. If
.the AV subcommittee can make a recommendation to enhance it, we can
.adopt it, but it still belongs in the web standards in whatever form it
.takes.
.
.2. I have had some concern about the lack of clarity and specificity in
.the term "programmatically determined" when used alone in any given
.standard. It looks like the term is defined as part of the proposed
.22(d) standard. This is very helpful, and I would like to suggest that
.whenever the phrase is used as an object in a standard such as in the
.proposed standard, its definition always follow it. I think this will
.provide the same level of clarification as do the table-specific
.examples in the proposed 22(g). However, when the term is used as an
.adjective as in "2.4.4 The purpose of each link can be determined from
.the link text and its programmatically determined link context," it
.probably doesn't require expansion, since by reference, it will mean
.what it means as fleshed out when used as the object in other
standards.
.
.
.3. in the proposed replacement for 22(e) and 22(f) and 21(a),
.* 2.1.1 "All functionality of the content is operable through a
keyboard .interface without requiring specific timings for individual
keystrokes, .except where the underlying task requires analog,
time-dependent input,"
.the phrase "analog, time-dependent input" has been a sticking point for
.some of us. How do people feel about something like this:
."All functionality of the content is operable through a keyboard
.interface without requiring specific timings for individual keystrokes,
.except where the underlying task requires a level of control
.unattainable through a keyboard interface."
.
.4. In the above-mentioned standard, "2.4.4 The purpose of each link can
.be determined from the link text and its programmatically determined
.link context," I am wondering if we should change the "and" to "or." I
.think it may be tough to mandate that both the link text "and" the link
.context determine the purpose of a given link. Either the link text
."or" its context must define its purpose, but not both. A good example
.of this is the infamous "click here" link. If it can be understood in
.context, it would be allowable though of course undesirable; the
.standard in its present form would actually disallow the use of links
.such as this, something we can't realistically mandate.
.
.5. I am wondering if we should delete the frames requirement
1194.22(i).
.At least for screen readers, definitive frame naming is helpful, but no
.longer a major issue in terms of site navigation and comprehension.
.
.

From: Barrett, Don
Date: Mon, Mar 26 2007 12:25 PM
Subject: Re: Thoughts on Current Web Proposal

Well, if we do cover frames as GV suggests, then we should definitely
name frames as examples within the standard in the same way we name
tables in the proposed 22(g). That way, there is no doubt.


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 Sailesh
Panchang
Sent: Monday, March 26, 2007 1:06 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

About Frames:
I support Mike and agree with his views. Yet as Andrew pointed out, it
may not be necessary to separate the requirement for frames into a
specific standard if it can be covered with a requirement for naming UI
components as suggested by GV.

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: Hoffman, Allen
Date: Tue, Mar 27 2007 5:40 AM
Subject: Re: Thoughts on Current Web Proposal

I don't feel we should drop the frames requirement, it is testable,
workable, and not so difficult to meet. It is one that actually works.
While there could be overlap from another item that requires UI elements
to be named, specificity isn't a bad thing now and then.




Allen Hoffman -- 202-447-0303
DHS Office on Accessible Systems & Technology

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bekure,
Blene W.
Sent: Monday, March 26, 2007 10:58 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

I couldn't agree anymore! I do not think it should be dropped.


Blene W. Bekure


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie
Cook
Sent: Tuesday, March 27, 2007 10:48 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

Don wrote:
5. I am wondering if we should delete the frames requirement 1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

DC: Ironic that we've been concerned about accommodating people who are
deaf-blind but would unintentially toss out the much larger population
of people with both vision and learning limitations. No, I wouldn't make
more of this standard than it is, but I most certainly wouldn't drop it.
It definitely provides meaningful orientation until screen readers
become smart enough to stop reading this invisible text altogether. Wish
we could actually prohibit the use of frames, but of course that's way
out of bounds.

From: Hoffman, Allen
Date: Tue, Mar 27 2007 6:10 AM
Subject: Re: Thoughts on Current Web Proposal

With all respect, why should we make people reach for this simple
concept?
Why don't we have a simple clear statement that audio descriptions are
required for interactive user interface elements, or access to the
information provided for AT in a nonclosed condition.



Allen Hoffman -- 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Monday, March 26, 2007 10:31 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Thoughts on Current Web Proposal

> To the disagreement between Andrew and Don over whether the current
> 1194.22
> (d) covers audio descriptions, I agree with Don. "Equivalent
> alternatives"
> can be either captions as equivalents for the audio information or
> audio descriptions as equivalents for the visual information. And this

> is one thing that is clear in the Access Board's guide to the
> standards. [1]

I also agree that 22b means that all types of equivalents need to be
synchronized. However, 22a is where captions are required, there is no
place that requires the addition of audio descriptions. If you have
them 22b says that they need to be synchronized - let me know where in
22 audio/video descriptions are required. They are called out
explicitly in 24 along with captions, so the standards are aware of
them, but they aren't mentioned. Are we to assume that audio
descriptions are far more obvious to include than captions and image
equivalents which needed to be mentioned explicitly?

AWK

From: David Poehlman
Date: Wed, Mar 28 2007 12:15 PM
Subject: Re: Thoughts on Current Web Proposal

Thanks Much!

On Mar 27, 2007, at 10:47 AM, Debbie Cook wrote:

Don wrote:
5. I am wondering if we should delete the frames requirement 1194.22(i).
At least for screen readers, definitive frame naming is helpful, but no
longer a major issue in terms of site navigation and comprehension.

DC: Ironic that we've been concerned about accommodating people who are
deaf-blind but would unintentially toss out the much larger
population of
people with both vision and learning limitations. No, I wouldn't make
more
of this standard than it is, but I most certainly wouldn't drop it. It
definitely provides meaningful orientation until screen readers
become smart
enough to stop reading this invisible text altogether. Wish we could
actually prohibit the use of frames, but of course that's way out of
bounds.