Thread Subject: Web Gaps - keyboard operation
Note
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
Return to this mailing list's archives
From: Andi Snow-Weaver
Date: Fri, Jan 12 2007 8:25 AM
Subject: Web Gaps - keyboard operation
In our discussion yesterday of the keyboard proposal, there were two
issues:
- concern that this may except devices that do not have a keyboard but
which do have keyboard interfaces that may be used by other devices or AT
software. For example, speech recognition software may use the keyboard
interface for voice navigation.
- confusion over the term "discerned textually". Most interpret this to
mean that free-form drawing functions do not need to be keyboard operable.
But drawing "objects" such as rectangles or circles can be described by the
attributes - length, width, radius, position on screen, etc. So these types
of drawing functions which are optimized for the mouse, do need to be
keyboard operable.
Here's one more attempt at a proposal for a keyboard requirement for Web:
For Web content or applications that are designed to run on a system that
has a keyboard interface, product functions shall be executable from a
keyboard interface where the function itself or the result of performing a
function can be described in words.
Andi
From: Robinson, Norman B - Washington, DC
Date: Fri, Jan 12 2007 10:55 AM
Subject: Re: Web Gaps - keyboard operation
Andi,
Sorry I missed the discussion.
I just wanted to point out there are programs that implement textual
equivalents of inherently visual actions used in drawing programs. The
CorelDraw Suite of programs (CorelDraw, CorelPaint) are pretty good
examples. The functions I would normally use with a mouse have text
equivalents through data fields. By example I can draw a circle and
resize it with the mouse or do so by typing in the values for radius or
size in a dialog box when the circle is selected. The same functions for
color, gradients, etc., all have dialog boxes for what one might assume
is inherently visual functions. A classic example where what we call
accessibility has actually increased usability; I can have better
control over design while others benefit from being able to use the
product at all.
I'm wondering about the proposed definition. With realization that many
people have interpreted language based on the semantics, might I ask how
you view the difference between "web content" or "applications"? They
are both software to me and I have to say with the exception of
"discerned textually" the existing 1194.21(a) is clearer.
This is one reason I advocate web content should be reorganized in the
refresh to be a clear subset of software applications. I might be wrong
but I see your definition having to be extended to cover everything
software already covers, and am interested in extending this discussion
in the context of your proposal.
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Friday, January 12, 2007 10:23 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] Web Gaps - keyboard operation
In our discussion yesterday of the keyboard proposal, there were two
issues:
- concern that this may except devices that do not have a keyboard but
which do have keyboard interfaces that may be used by other devices or
AT
software. For example, speech recognition software may use the keyboard
interface for voice navigation.
- confusion over the term "discerned textually". Most interpret this to
mean that free-form drawing functions do not need to be keyboard
operable.
But drawing "objects" such as rectangles or circles can be described by
the
attributes - length, width, radius, position on screen, etc. So these
types
of drawing functions which are optimized for the mouse, do need to be
keyboard operable.
Here's one more attempt at a proposal for a keyboard requirement for
Web:
For Web content or applications that are designed to run on a system
that
has a keyboard interface, product functions shall be executable from a
keyboard interface where the function itself or the result of performing
a
function can be described in words.
Andi
From: Peter Korn
Date: Fri, Jan 12 2007 11:05 AM
Subject: Re: Web Gaps - keyboard operation
Hi Andi,
I think this is a good draft of new language. I wonder about ending it
with "described succinctly in words", or "describe precisely in words",
or some such. My concerns are:
1. folks have been describing pictures for years, just not with
sufficient precision to completely and precisely reproduce them
2. anticipating questions I'll get from developers who need advice on
implementing 508 support, I foresee a lot of arguments about what is and
isn't describable in words (mind you, this is the same problem we have
now with "discernible textually").
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> In our discussion yesterday of the keyboard proposal, there were two
> issues:
>
> - concern that this may except devices that do not have a keyboard but
> which do have keyboard interfaces that may be used by other devices or AT
> software. For example, speech recognition software may use the keyboard
> interface for voice navigation.
> - confusion over the term "discerned textually". Most interpret this to
> mean that free-form drawing functions do not need to be keyboard operable.
> But drawing "objects" such as rectangles or circles can be described by the
> attributes - length, width, radius, position on screen, etc. So these types
> of drawing functions which are optimized for the mouse, do need to be
> keyboard operable.
>
> Here's one more attempt at a proposal for a keyboard requirement for Web:
>
> For Web content or applications that are designed to run on a system that
> has a keyboard interface, product functions shall be executable from a
> keyboard interface where the function itself or the result of performing a
> function can be described in words.
>
> Andi
>
>
From: Andi Snow-Weaver
Date: Fri, Jan 12 2007 11:30 AM
Subject: Re: Web Gaps - keyboard operation
Hi Norm,
In response to your question:
how you view the difference between "web content" or "applications"?
In the subcommittee, the issue of whether or not Web and Software should be
combined into one category has come up but we have not yet discussed it in
detail. It is on our list of general issues that we will get to soon. We
organized our discussions to first examine the existing provisions for
issues and gaps, keeping track of any bigger or related issues that came up
in the course of our discussions. We are now working through some of those
issues.
So for the time being we have been discussing the Web and Software
requirements as if we will continue to have two lists. There has been a
preference expressed to keep two separate lists because of the
infrastructure that industry, GSA, and some agencies have put in place. It
will be interesting to see if they turn out to be the same list in the end
though.
It is difficult to draw a bright line between content and applications. As
we are about to begin discussing content, which we were assigned by the
TEITAC, I invite you to contribute to the discussions. I expect they will
be lively!.
Andi
From: Barrett, Don
Date: Fri, Jan 12 2007 12:00 PM
Subject: Re: Web Gaps - keyboard operation
The problem with "described in words" is that even the results of
freehand drawing can be described in words. The idea behind discerned
textually was that anything which used or resulted in text had to be
keyboard available. Described on the other hand, could be misconstrued
to capture any action regardless of whether it used or resulted in text.
Am I misunderstanding?
From: Sean Hayes
Date: Fri, Jan 12 2007 12:10 PM
Subject: Re: Web Gaps - keyboard operation
I agree with Peter, I have some problems with this approach, and how to explain it to developers. Perhaps a better approach might be to limit the scope by giving some specific examples.
e.g.
..., product functions shall be executable from a keyboard interface except where the nature of the function requires continuous or analogue control (e.g. a pen or joystick), or other input which cannot be finitely described.
Sean Hayes
Standards and Policy Team
Accessible Technology Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: 12 January 2007 17:59
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
Hi Andi,
I think this is a good draft of new language. I wonder about ending it
with "described succinctly in words", or "describe precisely in words",
or some such. My concerns are:
1. folks have been describing pictures for years, just not with
sufficient precision to completely and precisely reproduce them
2. anticipating questions I'll get from developers who need advice on
implementing 508 support, I foresee a lot of arguments about what is and
isn't describable in words (mind you, this is the same problem we have
now with "discernible textually").
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
> In our discussion yesterday of the keyboard proposal, there were two
> issues:
>
> - concern that this may except devices that do not have a keyboard but
> which do have keyboard interfaces that may be used by other devices or AT
> software. For example, speech recognition software may use the keyboard
> interface for voice navigation.
> - confusion over the term "discerned textually". Most interpret this to
> mean that free-form drawing functions do not need to be keyboard operable.
> But drawing "objects" such as rectangles or circles can be described by the
> attributes - length, width, radius, position on screen, etc. So these types
> of drawing functions which are optimized for the mouse, do need to be
> keyboard operable.
>
> Here's one more attempt at a proposal for a keyboard requirement for Web:
>
> For Web content or applications that are designed to run on a system that
> has a keyboard interface, product functions shall be executable from a
> keyboard interface where the function itself or the result of performing a
> function can be described in words.
>
> Andi
>
>
From: Gregg Vanderheiden
Date: Fri, Jan 12 2007 4:15 PM
Subject: Re: Web Gaps - keyboard operation
Norman wrote:
> This is one reason I advocate web content should be
> reorganized in the refresh to be a clear subset of software
> applications.
This is a problem faced by a number of groups.
Not all web content is software. Web content includes pdf's, word docs,
plain html pages etc.
So sometimes it is, sometimes it isn't, sometimes parts are and aren't.
That's why most treat it separately.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
From: Gregg Vanderheiden
Date: Tue, Jan 16 2007 5:10 PM
Subject: Re: Web Gaps - keyboard operation
These are the same problems we came up with in WCAG, HFES AND ISO. Which is
why ALL 3 changed to "time-dependent analogue input". It gets at what the
issue is (those things that can't be done by keyboard) without introducing
tests like "can't be described in text" which are harder to figure and are
not the root cause of the problem - just a correlation.
WCAG
2.1.1 Keyboard: 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.
ISO
Unless the task requires time-dependent analogue input, software shall
provide users with the option to carry out all tasks using only non-time
dependent keyboard (or keyboard equivalent) input.
HFES
Unless the task requires time-dependent analogue input, software shall
provide users with the option to carry out all tasks using only non-time
dependent keyboard (or keyboard equivalent) input.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Sean Hayes
> Sent: Friday, January 12, 2007 1:04 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> I agree with Peter, I have some problems with this approach,
> and how to explain it to developers. Perhaps a better
> approach might be to limit the scope by giving some specific examples.
>
> e.g.
> ..., product functions shall be executable from a keyboard
> interface except where the nature of the function requires
> continuous or analogue control (e.g. a pen or joystick), or
> other input which cannot be finitely described.
>
> Sean Hayes
> Standards and Policy Team
> Accessible Technology Group
> Microsoft
> Phone:
> mob +44 7977 455002
> office +44 117 9719730
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: 12 January 2007 17:59
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Hi Andi,
>
> I think this is a good draft of new language. I wonder about
> ending it with "described succinctly in words", or "describe
> precisely in words", or some such. My concerns are:
> 1. folks have been describing pictures for years, just not
> with sufficient precision to completely and precisely
> reproduce them 2. anticipating questions I'll get from
> developers who need advice on implementing 508 support, I
> foresee a lot of arguments about what is and isn't
> describable in words (mind you, this is the same problem we
> have now with "discernible textually").
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > In our discussion yesterday of the keyboard proposal, there were two
> > issues:
> >
> > - concern that this may except devices that do not have a
> keyboard but
> > which do have keyboard interfaces that may be used by other
> devices or
> > AT software. For example, speech recognition software may use the
> > keyboard interface for voice navigation.
> > - confusion over the term "discerned textually". Most
> interpret this
> > to mean that free-form drawing functions do not need to be
> keyboard operable.
> > But drawing "objects" such as rectangles or circles can be
> described
> > by the attributes - length, width, radius, position on
> screen, etc. So
> > these types of drawing functions which are optimized for
> the mouse, do
> > need to be keyboard operable.
> >
> > Here's one more attempt at a proposal for a keyboard
> requirement for Web:
> >
> > For Web content or applications that are designed to run on
> a system
> > that has a keyboard interface, product functions shall be
> executable
> > from a keyboard interface where the function itself or the
> result of
> > performing a function can be described in words.
> >
> > Andi
> >
> >
From: Barrett, Don
Date: Tue, Jan 16 2007 5:10 PM
Subject: Re: Web Gaps - keyboard operation
Sorry, but I am not sure "time-dependent analogue input" really gets at
the issue. Actually, I think it avoids the issue by using an
intimidating arcane phrase which no developer I have ever worked with
will understand. And when they ask me what it means, I will have to use
phrases which should have been in the standard in the first place. It
confuses rather than clarifies.
I missed the call, but what's wrong with the standard as it exists now.
From: Gregg Vanderheiden
Date: Tue, Jan 16 2007 5:11 PM
Subject: Re: Web Gaps - keyboard operation
Hmmmm. It does sound a little arcane. However it is in fact the real
problem. We can create keyboard access except when the input required is
analog in nature (not a discreet item) and has a time dependent aspect to it
(so you can't just type in numbers to specify an analog number).
Finger painting is one example. Flying a helicopter in real time is
another.
CAD is not.
The problem with the existing text is that the problem isn't whether you can
describe the task or output in text. It is whether the action actually
requires input that cannot be done from a keyboard. I have had people
think we were talking about voice control or natural language control by
typing into the keyboard. That was really confusing to them. I also have
people saying that with enough words you can describe anything. And any
limit on words raises the question of why that number of words. So I don't
think the current wording does either.
Maybe we go with the new words and a good description to explain?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Barrett, Don
> Sent: Saturday, January 13, 2007 2:48 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Sorry, but I am not sure "time-dependent analogue input"
> really gets at the issue. Actually, I think it avoids the
> issue by using an intimidating arcane phrase which no
> developer I have ever worked with will understand. And when
> they ask me what it means, I will have to use phrases which
> should have been in the standard in the first place. It
> confuses rather than clarifies.
>
> I missed the call, but what's wrong with the standard as it
> exists now.
>
From: Jim Tobias
Date: Tue, Jan 16 2007 5:11 PM
Subject: Re: Web Gaps - keyboard operation
The part I don't get is the "time-dependent" part. Let me explain with
an example. In a typical graphic program, drawing a line with a spraycan
tool, the longer you spend going from one point to another, the denser your
line, so that is clearly time-dependent. But it needn't be: you could be
allowed to specify the beginning and end points and the density by keyboard.
The distinction is between classic "draw" and "paint": the former is more
purely
geometrical and thus easier to describe in words, while the latter is
free-form
and harder to describe in words, because the "line" is not straight -- it
would
have to be explained in terms of perhaps dozens of short line segments at
slight
angles to each other. (Try converting a "painting" to a "drawing" and you
will
see one object become a hundred!)
But I don't see the time element coming into it.
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias
-----Original Message-----
From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, January 13, 2007 10:39 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
Hmmmm. It does sound a little arcane. However it is in fact the real
problem. We can create keyboard access except when the input required is
analog in nature (not a discreet item) and has a time dependent aspect to it
(so you can't just type in numbers to specify an analog number).
Finger painting is one example. Flying a helicopter in real time is
another.
CAD is not.
The problem with the existing text is that the problem isn't whether you can
describe the task or output in text. It is whether the action actually
requires input that cannot be done from a keyboard. I have had people
think we were talking about voice control or natural language control by
typing into the keyboard. That was really confusing to them. I also have
people saying that with enough words you can describe anything. And any
limit on words raises the question of why that number of words. So I don't
think the current wording does either.
Maybe we go with the new words and a good description to explain?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Barrett, Don
> Sent: Saturday, January 13, 2007 2:48 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Sorry, but I am not sure "time-dependent analogue input"
> really gets at the issue. Actually, I think it avoids the issue by
> using an intimidating arcane phrase which no developer I have ever
> worked with will understand. And when they ask me what it means, I
> will have to use phrases which should have been in the standard in the
> first place. It confuses rather than clarifies.
>
> I missed the call, but what's wrong with the standard as it exists
> now.
>
From: Gregg Vanderheiden
Date: Tue, Jan 16 2007 5:13 PM
Subject: Re: Web Gaps - keyboard operation
Interesting. Yes - that is a good point. Using that approach you could do
watercolor painting from the keyboard as well. And it would also be
covered.
Which raises the question, do we want to include anything beyond analog,
time dependent input (that can't be done by keyboard)? That is, do we want
to put in an exception for things that can be done from the keyboard but
where it would be extremely tedious to do so.
One way would be to say - if they standard mode of input is analog time
dependent -- but that would mean any mouse with acceleration would fall into
this. (thought it could also be controlled with analog non-time
dependent.....
Boy - our current wording would clearly NOT except watercolor painting per
Jim's comment.
Do we want to draw the bar somewhere else?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Tobias
> Sent: Sunday, January 14, 2007 6:42 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> The part I don't get is the "time-dependent" part. Let me
> explain with an example. In a typical graphic program,
> drawing a line with a spraycan tool, the longer you spend
> going from one point to another, the denser your line, so
> that is clearly time-dependent. But it needn't be: you could
> be allowed to specify the beginning and end points and the
> density by keyboard.
>
> The distinction is between classic "draw" and "paint": the
> former is more purely geometrical and thus easier to describe
> in words, while the latter is free-form and harder to
> describe in words, because the "line" is not straight -- it
> would have to be explained in terms of perhaps dozens of
> short line segments at slight angles to each other. (Try
> converting a "painting" to a "drawing" and you will see one
> object become a hundred!)
>
> But I don't see the time element coming into it.
>
>
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Saturday, January 13, 2007 10:39 PM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Hmmmm. It does sound a little arcane. However it is in fact
> the real problem. We can create keyboard access except when
> the input required is analog in nature (not a discreet item)
> and has a time dependent aspect to it (so you can't just type
> in numbers to specify an analog number).
>
> Finger painting is one example. Flying a helicopter in real time is
> another.
>
> CAD is not.
>
> The problem with the existing text is that the problem isn't
> whether you can describe the task or output in text. It is
> whether the action actually
> requires input that cannot be done from a keyboard. I have
> had people
> think we were talking about voice control or natural language
> control by typing into the keyboard. That was really
> confusing to them. I also have people saying that with
> enough words you can describe anything. And any limit on
> words raises the question of why that number of words. So I
> don't think the current wording does either.
>
>
> Maybe we go with the new words and a good description to explain?
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Barrett, Don
> > Sent: Saturday, January 13, 2007 2:48 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
> >
> > Sorry, but I am not sure "time-dependent analogue input"
> > really gets at the issue. Actually, I think it avoids the issue by
> > using an intimidating arcane phrase which no developer I have ever
> > worked with will understand. And when they ask me what it means, I
> > will have to use phrases which should have been in the
> standard in the
> > first place. It confuses rather than clarifies.
> >
> > I missed the call, but what's wrong with the standard as it exists
> > now.
> >
From: Lybarger, Barbara (MOD)
Date: Tue, Jan 16 2007 5:16 PM
Subject: Re: Web Gaps - keyboard operation
How about adding "or numbers" at the end. Otherwise, I like it.
Barbara Lybarger
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Friday, January 12, 2007 10:23 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] Web Gaps - keyboard operation
In our discussion yesterday of the keyboard proposal, there were two
issues:
- concern that this may except devices that do not have a keyboard but
which do have keyboard interfaces that may be used by other devices or
AT software. For example, speech recognition software may use the
keyboard interface for voice navigation.
- confusion over the term "discerned textually". Most interpret this to
mean that free-form drawing functions do not need to be keyboard
operable.
But drawing "objects" such as rectangles or circles can be described by
the attributes - length, width, radius, position on screen, etc. So
these types of drawing functions which are optimized for the mouse, do
need to be keyboard operable.
Here's one more attempt at a proposal for a keyboard requirement for
Web:
For Web content or applications that are designed to run on a system
that has a keyboard interface, product functions shall be executable
from a keyboard interface where the function itself or the result of
performing a function can be described in words.
Andi
From: Robinson, Norman B - Washington, DC
Date: Thu, Jan 18 2007 9:35 AM
Subject: Re: Web Gaps - keyboard operation
Gregg,
But the current implementation of Section 508 doesn't really
deal with content either. With the exception of HTML content, there
isn't much about specific file formats or content; it is about the
*applications* themselves. Neither PDF nor Word documents fall under web
provisions, nor does the many other document formats that might be
linked via a HTML web page.
Most treat it separately not because content is or is not
software or web. They treat is separately because the Section 508
Technical Standards make the distinction between "Software applications
and operating systems" and "web-based intranet and internet information
and applications".
All web content _should_ fall under software technical
references, as web browsers (software) are used to view the content.
There are plug-in issues currently addressed by pointing to the software
standards. Where there isn't a plug-in and an application is launched by
clicking on a hypertext link that downloads the document and the
operating system starts the proper application, that is software too.
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, January 12, 2007 6:10 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
Norman wrote:
> This is one reason I advocate web content should be
> reorganized in the refresh to be a clear subset of software
> applications.
This is a problem faced by a number of groups.
Not all web content is software. Web content includes pdf's, word
docs,
plain html pages etc.
So sometimes it is, sometimes it isn't, sometimes parts are and aren't.
That's why most treat it separately.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
From: Hoffman, Allen
Date: Thu, Jan 18 2007 9:50 AM
Subject: Re: Web Gaps - keyboard operation
My two cents worth are:
1. Only applying the software standard won't get to accessibility of
content as it won't tell us if the underlying format has the minimum
capacities of encoding specific accessibility information for
presentation by the user-agent.
2. We should define what an accessible format means for documents,
multimedia, and other various presentation types, and then the process
for compliance would look like:
is the item encoded using a format that has the capacity for
accessibility?
Is the user-agent accessible--e.g.. meeting software standards?
If the answers to these are "yes", then if accessibility isn't
achieved it is the authors fault for not using the correct attributes in
the accessible format.
3. Just as HTML requires coding to be accessible, and the browser has
to be accessible, any other encoding format and user-agent has the same
set of requirements. I think we can set a broad-based minimum
accessibility definition for various document types, and then allow that
to be applied to multiple formats specifically, and in fact, can require
this application approach to alleviate the never ending question of does
this standard apply to that format.
Norman Robinson wrote:
" Gregg,
But the current implementation of Section 508 doesn't really
deal with content either. With the exception of HTML content, there
isn't much about specific file formats or content; it is about the
*applications* themselves. Neither PDF nor Word documents fall under web
provisions, nor does the many other document formats that might be
linked via a HTML web page.
Most treat it separately not because content is or is not
software or web. They treat is separately because the Section 508
Technical Standards make the distinction between "Software applications
and operating systems" and "web-based intranet and internet information
and applications".
All web content _should_ fall under software technical
references, as web browsers (software) are used to view the content.
There are plug-in issues currently addressed by pointing to the software
standards. Where there isn't a plug-in and an application is launched by
clicking on a hypertext link that downloads the document and the
operating system starts the proper application, that is software too.
Regards,"
Allen Hoffman -- DHS Office on Accessible Systems & Technology
From: Robinson, Norman B - Washington, DC
Date: Thu, Jan 18 2007 10:10 AM
Subject: Re: Web Gaps - keyboard operation
Gregg,
I have to say I like the existing language used in software and
operating systems as well, so I agree with Don.
For the benefit of the new readers that language is: (a) When
software is designed to run on a system that has a keyboard, products
functions shall be executable from a keyboard where the function itself
or the result of the function can be discerned textually.
I would like to understand your examples. Finger painting isn't
electronic & information technology (E&IT). Flying a helicopter
real-time isn't E&IT. Computer aided design (CAD) is E&IT. I could
design a system that would allow electronic finger painting using a
touch pad. I could design it such as there are text equivalents for all
the functions and provide it accessibly. I can design a system to fly a
helicopter via E&IT. I can make it accessible. I can make CAD functions
accessible. Please help me understand your example and thus your
arguments.
Finally, do you think the existing preamble is a good example? I
note the recommendation for a explanation. Perhaps in the refresh it
would be useful to have clearer direction to consult the preamble during
the interpretation of the technical standards. On that note, I would
like to specifically recommend that the preamble eliminate discussion in
the response justifying inaccessibility; software exists that allows
"selection of a paintbrush, picking a color, and drawing a design". The
difficulty is not what is important, that is a value judgment I don't
want to see continued in the refresh. (See Preamble discussion on
1194.21(a) via
http://www.access-board.gov/sec508/preamble.htm#Subpart%20B for more
information).
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Saturday, January 13, 2007 10:39 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
Hmmmm. It does sound a little arcane. However it is in fact the real
problem. We can create keyboard access except when the input required
is
analog in nature (not a discreet item) and has a time dependent aspect
to it
(so you can't just type in numbers to specify an analog number).
Finger painting is one example. Flying a helicopter in real time is
another.
CAD is not.
The problem with the existing text is that the problem isn't whether you
can
describe the task or output in text. It is whether the action actually
requires input that cannot be done from a keyboard. I have had people
think we were talking about voice control or natural language control by
typing into the keyboard. That was really confusing to them. I also
have
people saying that with enough words you can describe anything. And any
limit on words raises the question of why that number of words. So I
don't
think the current wording does either.
Maybe we go with the new words and a good description to explain?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Barrett, Don
> Sent: Saturday, January 13, 2007 2:48 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Sorry, but I am not sure "time-dependent analogue input"
> really gets at the issue. Actually, I think it avoids the
> issue by using an intimidating arcane phrase which no
> developer I have ever worked with will understand. And when
> they ask me what it means, I will have to use phrases which
> should have been in the standard in the first place. It
> confuses rather than clarifies.
>
> I missed the call, but what's wrong with the standard as it
> exists now.
>
From: David Poehlman
Date: Thu, Jan 18 2007 12:20 PM
Subject: Re: Web Gaps - keyboard operation
If I use the smudge tool in photoshop to blend colors, how do we do
this effectively without the visual component?
On Jan 18, 2007, at 12:08 PM, Robinson, Norman B - Washington, DC wrote:
Gregg,
I have to say I like the existing language used in software and
operating systems as well, so I agree with Don.
For the benefit of the new readers that language is: (a) When
software is designed to run on a system that has a keyboard, products
functions shall be executable from a keyboard where the function itself
or the result of the function can be discerned textually.
I would like to understand your examples. Finger painting isn't
electronic & information technology (E&IT). Flying a helicopter
real-time isn't E&IT. Computer aided design (CAD) is E&IT. I could
design a system that would allow electronic finger painting using a
touch pad. I could design it such as there are text equivalents for all
the functions and provide it accessibly. I can design a system to fly a
helicopter via E&IT. I can make it accessible. I can make CAD functions
accessible. Please help me understand your example and thus your
arguments.
Finally, do you think the existing preamble is a good example? I
note the recommendation for a explanation. Perhaps in the refresh it
would be useful to have clearer direction to consult the preamble during
the interpretation of the technical standards. On that note, I would
like to specifically recommend that the preamble eliminate discussion in
the response justifying inaccessibility; software exists that allows
"selection of a paintbrush, picking a color, and drawing a design". The
difficulty is not what is important, that is a value judgment I don't
want to see continued in the refresh. (See Preamble discussion on
1194.21(a) via
http://www.access-board.gov/sec508/preamble.htm#Subpart%20B for more
information).
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Saturday, January 13, 2007 10:39 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
Hmmmm. It does sound a little arcane. However it is in fact the real
problem. We can create keyboard access except when the input required
is
analog in nature (not a discreet item) and has a time dependent aspect
to it
(so you can't just type in numbers to specify an analog number).
Finger painting is one example. Flying a helicopter in real time is
another.
CAD is not.
The problem with the existing text is that the problem isn't whether you
can
describe the task or output in text. It is whether the action actually
requires input that cannot be done from a keyboard. I have had people
think we were talking about voice control or natural language control by
typing into the keyboard. That was really confusing to them. I also
have
people saying that with enough words you can describe anything. And any
limit on words raises the question of why that number of words. So I
don't
think the current wording does either.
Maybe we go with the new words and a good description to explain?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Barrett, Don
> Sent: Saturday, January 13, 2007 2:48 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Sorry, but I am not sure "time-dependent analogue input"
> really gets at the issue. Actually, I think it avoids the
> issue by using an intimidating arcane phrase which no
> developer I have ever worked with will understand. And when
> they ask me what it means, I will have to use phrases which
> should have been in the standard in the first place. It
> confuses rather than clarifies.
>
> I missed the call, but what's wrong with the standard as it
> exists now.
>
From: Sean Hayes
Date: Thu, Jan 18 2007 12:45 PM
Subject: Re: Web Gaps - keyboard operation
Defining that Photoshop, Corel Paint and similar tools are not E&IT and therefore exempt is certainly an interesting approach, but probably one that is too easily open to abuse?
I am certainly interested to hear how one could type a set of instructions to create a painting with a watercolour brush.
Another interesting example ocurred to me after the call yesterday. In music one can play most western music scores using just 12 notes and 8 octaves. We could map these notes to a keyboard; and define a text notation for duration and separation of notes - many music systems (more non E&IT?) have notation systems just like this.
However a player using such a system while possibly producing interesting music, will never sound functionally equivalent to a live player on a full midi keyboard, who in turn will not be functionally equivalent to a live performance on a Steinway piano. If we chose a continuous (analog) instrument like the trombone the differences would be even more dramatic, since the range of notes is now effectively infinite.
Similarly while it might be possible to define text controls for all the tools in Photoshop, it will not necessarily make a user who is unable to use a mouse or pen able to do the same job as a user that can.
I think we really need to get clear on what this provision is intended to enforce before we can really articulate its wording.
Sean Hayes
Standards and Policy Team
Accessible Technology Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of David Poehlman
Sent: 18 January 2007 19:15
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
If I use the smudge tool in photoshop to blend colors, how do we do this effectively without the visual component?
On Jan 18, 2007, at 12:08 PM, Robinson, Norman B - Washington, DC wrote:
Gregg,
I have to say I like the existing language used in software and operating systems as well, so I agree with Don.
For the benefit of the new readers that language is: (a) When software is designed to run on a system that has a keyboard, products functions shall be executable from a keyboard where the function itself or the result of the function can be discerned textually.
I would like to understand your examples. Finger painting isn't electronic & information technology (E&IT). Flying a helicopter real-time isn't E&IT. Computer aided design (CAD) is E&IT. I could design a system that would allow electronic finger painting using a touch pad. I could design it such as there are text equivalents for all the functions and provide it accessibly. I can design a system to fly a helicopter via E&IT. I can make it accessible. I can make CAD functions accessible. Please help me understand your example and thus your arguments.
Finally, do you think the existing preamble is a good example? I note the recommendation for a explanation. Perhaps in the refresh it would be useful to have clearer direction to consult the preamble during the interpretation of the technical standards. On that note, I would like to specifically recommend that the preamble eliminate discussion in the response justifying inaccessibility; software exists that allows "selection of a paintbrush, picking a color, and drawing a design". The difficulty is not what is important, that is a value judgment I don't want to see continued in the refresh. (See Preamble discussion on
1194.21(a) via
http://www.access-board.gov/sec508/preamble.htm#Subpart%20B for more information).
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg Vanderheiden
Sent: Saturday, January 13, 2007 10:39 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
Hmmmm. It does sound a little arcane. However it is in fact the real problem. We can create keyboard access except when the input required is analog in nature (not a discreet item) and has a time dependent aspect to it (so you can't just type in numbers to specify an analog number).
Finger painting is one example. Flying a helicopter in real time is
another.
CAD is not.
The problem with the existing text is that the problem isn't whether you can describe the task or output in text. It is whether the action actually
requires input that cannot be done from a keyboard. I have had people
think we were talking about voice control or natural language control by typing into the keyboard. That was really confusing to them. I also have people saying that with enough words you can describe anything. And any limit on words raises the question of why that number of words. So I don't think the current wording does either.
Maybe we go with the new words and a good description to explain?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Barrett, Don
> Sent: Saturday, January 13, 2007 2:48 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Sorry, but I am not sure "time-dependent analogue input"
> really gets at the issue. Actually, I think it avoids the issue by
> using an intimidating arcane phrase which no developer I have ever
> worked with will understand. And when they ask me what it means, I
> will have to use phrases which should have been in the standard in the
> first place. It confuses rather than clarifies.
>
> I missed the call, but what's wrong with the standard as it exists
> now.
>
From: Robinson, Norman B - Washington, DC
Date: Thu, Jan 18 2007 1:45 PM
Subject: Re: Web Gaps - keyboard operation
I don't know in how to tell you to do such a thing in Photoshop. What I
can tell you is that it is possible (perhaps not with Photoshop). If you
want an example of something to work with and debate, what about
Script-fu and The Gimp
(http://www.seul.org/~grumbel/gimp/script-fu/script-fu-tut.html#intro)?
This is a scripting extension that allows you to manipulate graphic
images. It has been used on web sites to automatically perform image
functions. Perhaps a better example would be a working script that
performs red-eye removal technique:
http://www.linuxjournal.com/article/6567
My point being that I don't have to be specific to insist the Section
508 standards allow such a thing (but hopefully I provided useful
examples for your consideration).
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of David
Poehlman
Sent: Thursday, January 18, 2007 2:15 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
If I use the smudge tool in photoshop to blend colors, how do we do
this effectively without the visual component?
On Jan 18, 2007, at 12:08 PM, Robinson, Norman B - Washington, DC wrote:
Gregg,
I have to say I like the existing language used in software and
operating systems as well, so I agree with Don.
For the benefit of the new readers that language is: (a) When
software is designed to run on a system that has a keyboard, products
functions shall be executable from a keyboard where the function itself
or the result of the function can be discerned textually.
I would like to understand your examples. Finger painting isn't
electronic & information technology (E&IT). Flying a helicopter
real-time isn't E&IT. Computer aided design (CAD) is E&IT. I could
design a system that would allow electronic finger painting using a
touch pad. I could design it such as there are text equivalents for all
the functions and provide it accessibly. I can design a system to fly a
helicopter via E&IT. I can make it accessible. I can make CAD functions
accessible. Please help me understand your example and thus your
arguments.
Finally, do you think the existing preamble is a good example? I
note the recommendation for a explanation. Perhaps in the refresh it
would be useful to have clearer direction to consult the preamble during
the interpretation of the technical standards. On that note, I would
like to specifically recommend that the preamble eliminate discussion in
the response justifying inaccessibility; software exists that allows
"selection of a paintbrush, picking a color, and drawing a design". The
difficulty is not what is important, that is a value judgment I don't
want to see continued in the refresh. (See Preamble discussion on
1194.21(a) via
http://www.access-board.gov/sec508/preamble.htm#Subpart%20B for more
information).
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Saturday, January 13, 2007 10:39 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
Hmmmm. It does sound a little arcane. However it is in fact the real
problem. We can create keyboard access except when the input required
is
analog in nature (not a discreet item) and has a time dependent aspect
to it
(so you can't just type in numbers to specify an analog number).
Finger painting is one example. Flying a helicopter in real time is
another.
CAD is not.
The problem with the existing text is that the problem isn't whether you
can
describe the task or output in text. It is whether the action actually
requires input that cannot be done from a keyboard. I have had people
think we were talking about voice control or natural language control by
typing into the keyboard. That was really confusing to them. I also
have
people saying that with enough words you can describe anything. And any
limit on words raises the question of why that number of words. So I
don't
think the current wording does either.
Maybe we go with the new words and a good description to explain?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Barrett, Don
> Sent: Saturday, January 13, 2007 2:48 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Sorry, but I am not sure "time-dependent analogue input"
> really gets at the issue. Actually, I think it avoids the
> issue by using an intimidating arcane phrase which no
> developer I have ever worked with will understand. And when
> they ask me what it means, I will have to use phrases which
> should have been in the standard in the first place. It
> confuses rather than clarifies.
>
> I missed the call, but what's wrong with the standard as it
> exists now.
>
From: Sean Hayes
Date: Thu, Jan 18 2007 2:15 PM
Subject: Re: Web Gaps - keyboard operation
Yes Photoshop allows scripting, albeit not with LISP.
So, if you are saying that:
(define (my-make-new-image)
(let* ((image (car (gimp-image-new 256 256 RGB)))
(layer (car (gimp-layer-new image 256 256
RGB-IMAGE "foobar" 100 NORMAL-MODE))))
(gimp-drawable-fill layer BG-IMAGE-FILL)
(gimp-image-add-layer image layer 0)
(gimp-display-new image)
image))
[extracted from GIMP-FU ]
Is an acceptable keyboard replacement for drawing a word on a grey background then the argument is going in a direction I had not anticipated, and in that case yes I accept it is possible to provide keyboard access to all functions of software.
I still assert however, that it is not possible to recreate the nuance of a human performance using such a system. If this aspect is not a requirement, and it is not intended that this provision imply that the features necessarily be usable to facilitate equal performance using the software (or even usable at all except by programmers) then I'm happy to continue with the existing text.
[I note that the red-eye removal script does require the user to select the red pupils first, btw]
Sean Hayes
Standards and Policy Team
Accessible Technology Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robinson, Norman B - Washington, DC
Sent: 18 January 2007 20:43
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
I don't know in how to tell you to do such a thing in Photoshop. What I can tell you is that it is possible (perhaps not with Photoshop). If you want an example of something to work with and debate, what about Script-fu and The Gimp (http://www.seul.org/~grumbel/gimp/script-fu/script-fu-tut.html#intro)?
This is a scripting extension that allows you to manipulate graphic images. It has been used on web sites to automatically perform image functions. Perhaps a better example would be a working script that performs red-eye removal technique:
http://www.linuxjournal.com/article/6567
My point being that I don't have to be specific to insist the Section
508 standards allow such a thing (but hopefully I provided useful examples for your consideration).
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of David Poehlman
Sent: Thursday, January 18, 2007 2:15 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
If I use the smudge tool in photoshop to blend colors, how do we do this effectively without the visual component?
On Jan 18, 2007, at 12:08 PM, Robinson, Norman B - Washington, DC wrote:
Gregg,
I have to say I like the existing language used in software and operating systems as well, so I agree with Don.
For the benefit of the new readers that language is: (a) When software is designed to run on a system that has a keyboard, products functions shall be executable from a keyboard where the function itself or the result of the function can be discerned textually.
I would like to understand your examples. Finger painting isn't electronic & information technology (E&IT). Flying a helicopter real-time isn't E&IT. Computer aided design (CAD) is E&IT. I could design a system that would allow electronic finger painting using a touch pad. I could design it such as there are text equivalents for all the functions and provide it accessibly. I can design a system to fly a helicopter via E&IT. I can make it accessible. I can make CAD functions accessible. Please help me understand your example and thus your arguments.
Finally, do you think the existing preamble is a good example? I note the recommendation for a explanation. Perhaps in the refresh it would be useful to have clearer direction to consult the preamble during the interpretation of the technical standards. On that note, I would like to specifically recommend that the preamble eliminate discussion in the response justifying inaccessibility; software exists that allows "selection of a paintbrush, picking a color, and drawing a design". The difficulty is not what is important, that is a value judgment I don't want to see continued in the refresh. (See Preamble discussion on
1194.21(a) via
http://www.access-board.gov/sec508/preamble.htm#Subpart%20B for more information).
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg Vanderheiden
Sent: Saturday, January 13, 2007 10:39 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
Hmmmm. It does sound a little arcane. However it is in fact the real problem. We can create keyboard access except when the input required is analog in nature (not a discreet item) and has a time dependent aspect to it (so you can't just type in numbers to specify an analog number).
Finger painting is one example. Flying a helicopter in real time is
another.
CAD is not.
The problem with the existing text is that the problem isn't whether you can describe the task or output in text. It is whether the action actually
requires input that cannot be done from a keyboard. I have had people
think we were talking about voice control or natural language control by typing into the keyboard. That was really confusing to them. I also have people saying that with enough words you can describe anything. And any limit on words raises the question of why that number of words. So I don't think the current wording does either.
Maybe we go with the new words and a good description to explain?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Barrett, Don
> Sent: Saturday, January 13, 2007 2:48 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Sorry, but I am not sure "time-dependent analogue input"
> really gets at the issue. Actually, I think it avoids the issue by
> using an intimidating arcane phrase which no developer I have ever
> worked with will understand. And when they ask me what it means, I
> will have to use phrases which should have been in the standard in the
> first place. It confuses rather than clarifies.
>
> I missed the call, but what's wrong with the standard as it exists
> now.
>
From: Barrett, Don
Date: Thu, Jan 18 2007 3:05 PM
Subject: Re: Web Gaps - keyboard operation
In all my testing over the years, I have never come across a situation
in which a blind persons's career was negatively affected because
drawing capacity wasn't available from the keyboard. I will never use
PhotoShop, and I don't know any blind person who will. I still haven't
seen clear concise examples of what is wrong with textually discerned.
For example, why are we just accepting the notion that freehand drawing
must be accessible from the keyboard. I am not against the idea if it
has practical merit, but I want to ensure that the standards provide
practical guidance, not just satisfy an intellectual desire to codify
that which isn't necessary.
From: Robinson, Norman B - Washington, DC
Date: Thu, Jan 18 2007 3:25 PM
Subject: Re: Web Gaps - keyboard operation
Sean,
What I'm most interested in suggesting is that there are many graphic
functions that can be accessible and the standards should not discourage
their implementations.
Yes, the scripting is indication that a textual version can impact
graphic functions. I can also see that software can provide buttons that
run such a script (ala VBScript off of toolbar buttons if you like the
example). So just because you _can_ use the mouse to visually circle the
eyes and apply functions such as blur or red-eye removal doesn't mean
you can't do it from the keyboard and make it work with a screen reader.
If I find that CorelDraw vs. PhotoManip2.0 both meet my business need,
but find that CorelDraw provides text fields to allow access that
PhotoManip2.0 does not, then under Section 508 I legally have to
purchase CorelDraw. Section 508 makes things possible. While I don't
suggest that all software *must* provide such a function, I do suggest
that I have a legal and practical mandate to promote the accessible text
alternatives when either software meets my business needs. I don't want
to hear "It isn't practical" I want to hear vendors say "our is
accessible and meets your business needs" and I want to have the vendors
pick up on this an protest where it can let them advance the state of
accessibility.
Again, my point is to not say "it isn't practical and lets make sure in
the discussion of the law that we point this out" as to say "let us
evaluate on the standards and implementations may be created that are
accessible, so why discourage vendors from doing so?".
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean
Hayes
Sent: Thursday, January 18, 2007 4:05 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
Yes Photoshop allows scripting, albeit not with LISP.
So, if you are saying that:
(define (my-make-new-image)
(let* ((image (car (gimp-image-new 256 256 RGB)))
(layer (car (gimp-layer-new image 256 256
RGB-IMAGE "foobar" 100 NORMAL-MODE))))
(gimp-drawable-fill layer BG-IMAGE-FILL)
(gimp-image-add-layer image layer 0)
(gimp-display-new image)
image))
[extracted from GIMP-FU ]
Is an acceptable keyboard replacement for drawing a word on a grey
background then the argument is going in a direction I had not
anticipated, and in that case yes I accept it is possible to provide
keyboard access to all functions of software.
I still assert however, that it is not possible to recreate the nuance
of a human performance using such a system. If this aspect is not a
requirement, and it is not intended that this provision imply that the
features necessarily be usable to facilitate equal performance using the
software (or even usable at all except by programmers) then I'm happy to
continue with the existing text.
[I note that the red-eye removal script does require the user to select
the red pupils first, btw]
Sean Hayes
Standards and Policy Team
Accessible Technology Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Robinson, Norman B - Washington, DC
Sent: 18 January 2007 20:43
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
I don't know in how to tell you to do such a thing in Photoshop. What I
can tell you is that it is possible (perhaps not with Photoshop). If you
want an example of something to work with and debate, what about
Script-fu and The Gimp
(http://www.seul.org/~grumbel/gimp/script-fu/script-fu-tut.html#intro)?
This is a scripting extension that allows you to manipulate graphic
images. It has been used on web sites to automatically perform image
functions. Perhaps a better example would be a working script that
performs red-eye removal technique:
http://www.linuxjournal.com/article/6567
My point being that I don't have to be specific to insist the Section
508 standards allow such a thing (but hopefully I provided useful
examples for your consideration).
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of David
Poehlman
Sent: Thursday, January 18, 2007 2:15 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
If I use the smudge tool in photoshop to blend colors, how do we do this
effectively without the visual component?
On Jan 18, 2007, at 12:08 PM, Robinson, Norman B - Washington, DC wrote:
Gregg,
I have to say I like the existing language used in software and
operating systems as well, so I agree with Don.
For the benefit of the new readers that language is: (a) When
software is designed to run on a system that has a keyboard, products
functions shall be executable from a keyboard where the function itself
or the result of the function can be discerned textually.
I would like to understand your examples. Finger painting isn't
electronic & information technology (E&IT). Flying a helicopter
real-time isn't E&IT. Computer aided design (CAD) is E&IT. I could
design a system that would allow electronic finger painting using a
touch pad. I could design it such as there are text equivalents for all
the functions and provide it accessibly. I can design a system to fly a
helicopter via E&IT. I can make it accessible. I can make CAD functions
accessible. Please help me understand your example and thus your
arguments.
Finally, do you think the existing preamble is a good example? I
note the recommendation for a explanation. Perhaps in the refresh it
would be useful to have clearer direction to consult the preamble during
the interpretation of the technical standards. On that note, I would
like to specifically recommend that the preamble eliminate discussion in
the response justifying inaccessibility; software exists that allows
"selection of a paintbrush, picking a color, and drawing a design". The
difficulty is not what is important, that is a value judgment I don't
want to see continued in the refresh. (See Preamble discussion on
1194.21(a) via
http://www.access-board.gov/sec508/preamble.htm#Subpart%20B for more
information).
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Saturday, January 13, 2007 10:39 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
Hmmmm. It does sound a little arcane. However it is in fact the real
problem. We can create keyboard access except when the input required
is analog in nature (not a discreet item) and has a time dependent
aspect to it (so you can't just type in numbers to specify an analog
number).
Finger painting is one example. Flying a helicopter in real time is
another.
CAD is not.
The problem with the existing text is that the problem isn't whether you
can describe the task or output in text. It is whether the action
actually
requires input that cannot be done from a keyboard. I have had people
think we were talking about voice control or natural language control by
typing into the keyboard. That was really confusing to them. I also
have people saying that with enough words you can describe anything.
And any limit on words raises the question of why that number of words.
So I don't think the current wording does either.
Maybe we go with the new words and a good description to explain?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Barrett, Don
> Sent: Saturday, January 13, 2007 2:48 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Sorry, but I am not sure "time-dependent analogue input"
> really gets at the issue. Actually, I think it avoids the issue by
> using an intimidating arcane phrase which no developer I have ever
> worked with will understand. And when they ask me what it means, I
> will have to use phrases which should have been in the standard in the
> first place. It confuses rather than clarifies.
>
> I missed the call, but what's wrong with the standard as it exists
> now.
>
From: Sean Hayes
Date: Thu, Jan 18 2007 4:00 PM
Subject: Re: Web Gaps - keyboard operation
I'm sorry, I didn't think the intention of this was specific to blind users, but might include those with limited motor skills. I guess this illustrates the necessity of clarifying what this provision is actually about.
Sean Hayes
Standards and Policy Team
Accessible Technology Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Barrett, Don
Sent: 18 January 2007 21:54
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
In all my testing over the years, I have never come across a situation in which a blind persons's career was negatively affected because drawing capacity wasn't available from the keyboard. I will never use PhotoShop, and I don't know any blind person who will. I still haven't seen clear concise examples of what is wrong with textually discerned.
For example, why are we just accepting the notion that freehand drawing must be accessible from the keyboard. I am not against the idea if it has practical merit, but I want to ensure that the standards provide practical guidance, not just satisfy an intellectual desire to codify that which isn't necessary.
From: Barrett, Don
Date: Thu, Jan 18 2007 4:05 PM
Subject: Re: Web Gaps - keyboard operation
I understand that; but there are some many analog mouse alternatives,
that should cover them. I would think the keyboard would be the hardest
for those with limited motor impairments so a mouse alternative would
most likely be the choice of AT thus eliminating them from the equation.
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 Sean
Hayes
Sent: Thursday, January 18, 2007 5:57 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
I'm sorry, I didn't think the intention of this was specific to blind
users, but might include those with limited motor skills. I guess this
illustrates the necessity of clarifying what this provision is actually
about.
Sean Hayes
Standards and Policy Team
Accessible Technology Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Barrett, Don
Sent: 18 January 2007 21:54
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
In all my testing over the years, I have never come across a situation
in which a blind persons's career was negatively affected because
drawing capacity wasn't available from the keyboard. I will never use
PhotoShop, and I don't know any blind person who will. I still haven't
seen clear concise examples of what is wrong with textually discerned.
For example, why are we just accepting the notion that freehand drawing
must be accessible from the keyboard. I am not against the idea if it
has practical merit, but I want to ensure that the standards provide
practical guidance, not just satisfy an intellectual desire to codify
that which isn't necessary.
From: David Poehlman
Date: Thu, Jan 18 2007 5:05 PM
Subject: Re: Web Gaps - keyboard operation
DON,
PHOTOSHOP IS AN EXAMPLE OF A MODEL WE ARE TRYING TO ACHIEVE. I WON'T
DEBATE IT HERE, BUT I DO KNOW OF WORK BLIND PEOPLE DO WHICH COULD BE
IMPACTED BY THEIR ABILITY TO USE THIS TYPE OF TOOL.
On Jan 18, 2007, at 4:53 PM, Barrett, Don wrote:
In all my testing over the years, I have never come across a situation
in which a blind persons's career was negatively affected because
drawing capacity wasn't available from the keyboard. I will never use
PhotoShop, and I don't know any blind person who will. I still haven't
seen clear concise examples of what is wrong with textually discerned.
For example, why are we just accepting the notion that freehand drawing
must be accessible from the keyboard. I am not against the idea if it
has practical merit, but I want to ensure that the standards provide
practical guidance, not just satisfy an intellectual desire to codify
that which isn't necessary.
From: Randy Marsden
Date: Thu, Jan 18 2007 7:25 PM
Subject: Re: Web Gaps - keyboard operation
Here, here.
In these discussion, we tend to think a lot about computer access for blind
users, partly because it often presents the most difficult technical
challenges (plus, there are several people who are blind on the TEITAC
committee itself, who are providing excellent first-hand knowledge). But we
need to be careful to remember the other types of disabilities as well.
-Randy
>
> From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Thu, 18 Jan 2007 22:56:53 +0000
> To: TEITAC Web/Software Subcommittee < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> I'm sorry, I didn't think the intention of this was specific to blind users,
> but might include those with limited motor skills. I guess this illustrates
> the necessity of clarifying what this provision is actually about.
>
> Sean Hayes
> Standards and Policy Team
> Accessible Technology Group
> Microsoft
> Phone:
> mob +44 7977 455002
> office +44 117 9719730
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Barrett, Don
> Sent: 18 January 2007 21:54
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> In all my testing over the years, I have never come across a situation in
> which a blind persons's career was negatively affected because drawing
> capacity wasn't available from the keyboard. I will never use PhotoShop, and
> I don't know any blind person who will. I still haven't seen clear concise
> examples of what is wrong with textually discerned.
> For example, why are we just accepting the notion that freehand drawing must
> be accessible from the keyboard. I am not against the idea if it has
> practical merit, but I want to ensure that the standards provide practical
> guidance, not just satisfy an intellectual desire to codify that which isn't
> necessary.
>
From: Randy Marsden
Date: Thu, Jan 18 2007 7:30 PM
Subject: Re: Web Gaps - keyboard operation
Not a correct assumption. Many people with motor impairments who can¹t use
a keyboard also can¹t use a mouse alternative. For some of them, switch
access is the only way. A lot of assistive technology switch access
solutions rely on keyboard equivalents to send commands to the target
application. The more things that can be done via the keyboard, the more
things that can be done with a switch via these AT switch solutions.
-Randy
>
> From: "Barrett, Don" < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Thu, 18 Jan 2007 18:00:22 -0500
> To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> I understand that; but there are some many analog mouse alternatives,
> that should cover them. I would think the keyboard would be the hardest
> for those with limited motor impairments so a mouse alternative would
> most likely be the choice of AT thus eliminating them from the equation.
>
>
>
> 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 Sean
> Hayes
> Sent: Thursday, January 18, 2007 5:57 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> I'm sorry, I didn't think the intention of this was specific to blind
> users, but might include those with limited motor skills. I guess this
> illustrates the necessity of clarifying what this provision is actually
> about.
>
> Sean Hayes
> Standards and Policy Team
> Accessible Technology Group
> Microsoft
> Phone:
> mob +44 7977 455002
> office +44 117 9719730
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Barrett, Don
> Sent: 18 January 2007 21:54
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> In all my testing over the years, I have never come across a situation
> in which a blind persons's career was negatively affected because
> drawing capacity wasn't available from the keyboard. I will never use
> PhotoShop, and I don't know any blind person who will. I still haven't
> seen clear concise examples of what is wrong with textually discerned.
> For example, why are we just accepting the notion that freehand drawing
> must be accessible from the keyboard. I am not against the idea if it
> has practical merit, but I want to ensure that the standards provide
> practical guidance, not just satisfy an intellectual desire to codify
> that which isn't necessary.
>
From: Barrett, Don
Date: Thu, Jan 18 2007 8:40 PM
Subject: Re: Web Gaps - keyboard operation
Theoretically perhaps; I just don't see it, excuse the pun.
"-----Original Message-----
"From: = EMAIL ADDRESS REMOVED =
"[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
"Of David Poehlman
"Sent: Thursday, January 18, 2007 7:03 PM
"To: TEITAC Web/Software Subcommittee
"Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
"
"DON,
"
"PHOTOSHOP IS AN EXAMPLE OF A MODEL WE ARE TRYING TO ACHIEVE. I WON'T
"DEBATE IT HERE, BUT I DO KNOW OF WORK BLIND PEOPLE DO WHICH COULD BE
"IMPACTED BY THEIR ABILITY TO USE THIS TYPE OF TOOL.
"
"On Jan 18, 2007, at 4:53 PM, Barrett, Don wrote:
"
"In all my testing over the years, I have never come across a situation
"in which a blind persons's career was negatively affected because
"drawing capacity wasn't available from the keyboard. I will never use
"PhotoShop, and I don't know any blind person who will. I still haven't
"seen clear concise examples of what is wrong with textually discerned.
"For example, why are we just accepting the notion that freehand drawing
"must be accessible from the keyboard. I am not against the idea if it
"has practical merit, but I want to ensure that the standards provide
"practical guidance, not just satisfy an intellectual desire to codify
"that which isn't necessary.
"
From: Barrett, Don
Date: Thu, Jan 18 2007 8:45 PM
Subject: Re: Web Gaps - keyboard operation
Sounds like it would be a much better idea to develop a mouse
alternative that was switched-based than to get industry to make drawing
keyboard accessible.
"-----Original Message-----
"From: = EMAIL ADDRESS REMOVED =
"[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
"Of Randy Marsden
"Sent: Thursday, January 18, 2007 9:25 PM
"To: TEITAC Web/Software Subcommittee
"Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
"
"Not a correct assumption. Many people with motor impairments
"who can't use a keyboard also can't use a mouse alternative.
"For some of them, switch access is the only way. A lot of
"assistive technology switch access solutions rely on keyboard
"equivalents to send commands to the target application. The
"more things that can be done via the keyboard, the more things
"that can be done with a switch via these AT switch solutions.
"
"-Randy
"
"
"
" From: "Barrett, Don" < = EMAIL ADDRESS REMOVED = >
" Reply-To: TEITAC Web/Software Subcommittee
"< = EMAIL ADDRESS REMOVED = >
" Date: Thu, 18 Jan 2007 18:00:22 -0500
" To: "TEITAC Web/Software Subcommittee"
"< = EMAIL ADDRESS REMOVED = >
" Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
"
"
"
"
"
"
" I understand that; but there are some many analog mouse
"alternatives,
" that should cover them. I would think the keyboard
"would be the hardest
" for those with limited motor impairments so a mouse
"alternative would
" most likely be the choice of AT thus eliminating them
"from the equation.
"
"
"
" 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 Sean
" Hayes
" Sent: Thursday, January 18, 2007 5:57 PM
" To: TEITAC Web/Software Subcommittee
" Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
"
" I'm sorry, I didn't think the intention of this was
"specific to blind
" users, but might include those with limited motor
"skills. I guess this
" illustrates the necessity of clarifying what this
"provision is actually
" about.
"
" Sean Hayes
" Standards and Policy Team
" Accessible Technology Group
" Microsoft
" Phone:
" mob +44 7977 455002
" office +44 117 9719730
"
" -----Original Message-----
" From: = EMAIL ADDRESS REMOVED =
" [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
" Barrett, Don
" Sent: 18 January 2007 21:54
" To: TEITAC Web/Software Subcommittee
" Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
"
" In all my testing over the years, I have never come
"across a situation
" in which a blind persons's career was negatively
"affected because
" drawing capacity wasn't available from the keyboard. I
"will never use
" PhotoShop, and I don't know any blind person who will.
"I still haven't
" seen clear concise examples of what is wrong with
"textually discerned.
" For example, why are we just accepting the notion that
"freehand drawing
" must be accessible from the keyboard. I am not against
"the idea if it
" has practical merit, but I want to ensure that the
"standards provide
" practical guidance, not just satisfy an intellectual
"desire to codify
" that which isn't necessary.
"
From: Randy Marsden (Home)
Date: Thu, Jan 18 2007 11:30 PM
Subject: Re: Web Gaps - keyboard operation
I agree, if we¹re speaking only of drawing. I was speaking more generally.
The more things you can make controllable with a keyboard, the better (from
AT¹s standpoint).
But I tend to agree that there are some things where keyboard control will
be impractical. Drawing seems like the most obvious example. I¹m sitting
here trying to think of other good ones, but am having a hard time.
-Randy
>
> From: "Barrett, Don" < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Thu, 18 Jan 2007 22:42:44 -0500
> To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Sounds like it would be a much better idea to develop a mouse
> alternative that was switched-based than to get industry to make drawing
> keyboard accessible.
>
> "-----Original Message-----
> "From: = EMAIL ADDRESS REMOVED =
> "[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> "Of Randy Marsden
> "Sent: Thursday, January 18, 2007 9:25 PM
> "To: TEITAC Web/Software Subcommittee
> "Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
> "
> "Not a correct assumption. Many people with motor impairments
> "who can't use a keyboard also can't use a mouse alternative.
> "For some of them, switch access is the only way. A lot of
> "assistive technology switch access solutions rely on keyboard
> "equivalents to send commands to the target application. The
> "more things that can be done via the keyboard, the more things
> "that can be done with a switch via these AT switch solutions.
> "
> "-Randy
> "
> "
> "
> " From: "Barrett, Don" < = EMAIL ADDRESS REMOVED = >
> " Reply-To: TEITAC Web/Software Subcommittee
> "< = EMAIL ADDRESS REMOVED = >
> " Date: Thu, 18 Jan 2007 18:00:22 -0500
> " To: "TEITAC Web/Software Subcommittee"
> "< = EMAIL ADDRESS REMOVED = >
> " Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
> "
> "
> "
> "
> "
> "
> " I understand that; but there are some many analog mouse
> "alternatives,
> " that should cover them. I would think the keyboard
> "would be the hardest
> " for those with limited motor impairments so a mouse
> "alternative would
> " most likely be the choice of AT thus eliminating them
> "from the equation.
> "
> "
> "
> " 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 Sean
> " Hayes
> " Sent: Thursday, January 18, 2007 5:57 PM
> " To: TEITAC Web/Software Subcommittee
> " Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
> "
> " I'm sorry, I didn't think the intention of this was
> "specific to blind
> " users, but might include those with limited motor
> "skills. I guess this
> " illustrates the necessity of clarifying what this
> "provision is actually
> " about.
> "
> " Sean Hayes
> " Standards and Policy Team
> " Accessible Technology Group
> " Microsoft
> " Phone:
> " mob +44 7977 455002
> " office +44 117 9719730
> "
> " -----Original Message-----
> " From: = EMAIL ADDRESS REMOVED =
> " [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> " Barrett, Don
> " Sent: 18 January 2007 21:54
> " To: TEITAC Web/Software Subcommittee
> " Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
> "
> " In all my testing over the years, I have never come
> "across a situation
> " in which a blind persons's career was negatively
> "affected because
> " drawing capacity wasn't available from the keyboard. I
> "will never use
> " PhotoShop, and I don't know any blind person who will.
> "I still haven't
> " seen clear concise examples of what is wrong with
> "textually discerned.
> " For example, why are we just accepting the notion that
> "freehand drawing
> " must be accessible from the keyboard. I am not against
> "the idea if it
> " has practical merit, but I want to ensure that the
> "standards provide
> " practical guidance, not just satisfy an intellectual
> "desire to codify
> " that which isn't necessary.
> "
From: Gregg Vanderheiden
Date: Fri, Jan 19 2007 12:10 AM
Subject: Re: Web Gaps - keyboard operation
Some people physical disabilities can use a mouse equivalent very easily.
Others cannot use a mouse or other pointer at all.
Some use speech control (which is basically keyboard control)
So keyboard operation is important for them too.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:teitac-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Barrett, Don
> Sent: Thursday, January 18, 2007 5:00 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> I understand that; but there are some many analog mouse alternatives,
> that should cover them. I would think the keyboard would be the hardest
> for those with limited motor impairments so a mouse alternative would
> most likely be the choice of AT thus eliminating them from the equation.
>
>
>
> 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 Sean
> Hayes
> Sent: Thursday, January 18, 2007 5:57 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> I'm sorry, I didn't think the intention of this was specific to blind
> users, but might include those with limited motor skills. I guess this
> illustrates the necessity of clarifying what this provision is actually
> about.
>
> Sean Hayes
> Standards and Policy Team
> Accessible Technology Group
> Microsoft
> Phone:
> mob +44 7977 455002
> office +44 117 9719730
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Barrett, Don
> Sent: 18 January 2007 21:54
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> In all my testing over the years, I have never come across a situation
> in which a blind persons's career was negatively affected because
> drawing capacity wasn't available from the keyboard. I will never use
> PhotoShop, and I don't know any blind person who will. I still haven't
> seen clear concise examples of what is wrong with textually discerned.
> For example, why are we just accepting the notion that freehand drawing
> must be accessible from the keyboard. I am not against the idea if it
> has practical merit, but I want to ensure that the standards provide
> practical guidance, not just satisfy an intellectual desire to codify
> that which isn't necessary.
>
From: Gregg Vanderheiden
Date: Fri, Jan 19 2007 12:15 AM
Subject: Re: Web Gaps - keyboard operation
I think we should start by figuring out what we think should be in and out
of our requirement. Then work on how to define it.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Sean Hayes
> Sent: Thursday, January 18, 2007 1:41 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Defining that Photoshop, Corel Paint and similar tools are
> not E&IT and therefore exempt is certainly an interesting
> approach, but probably one that is too easily open to abuse?
>
> I am certainly interested to hear how one could type a set of
> instructions to create a painting with a watercolour brush.
>
> Another interesting example ocurred to me after the call
> yesterday. In music one can play most western music scores
From: David Poehlman
Date: Fri, Jan 19 2007 4:40 AM
Subject: Re: Web Gaps - keyboard operation
Hi Randy,
For drawing, I used to uuse a perfectly keyboardable app that came
bundled with word perfect for dos. It's not drawingg which is
difficult, it's making colors andd changing the style of brush and
stroke but then we are getting into painting so I guess it's painting
that is difficult to capture with the keyboard.
On Jan 19, 2007, at 1:24 AM, Randy Marsden (Home) wrote:
I agree, if we’re speaking only of drawing. I was speaking more
generally.
The more things you can make controllable with a keyboard, the better
(from AT’s standpoint).
But I tend to agree that there are some things where keyboard control
will be impractical. Drawing seems like the most obvious example.
I’m sitting here trying to think of other good ones, but am having a
hard time.
-Randy
>
> From: "Barrett, Don" < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC Web/Software Subcommittee <teitac-
> = EMAIL ADDRESS REMOVED = >
> Date: Thu, 18 Jan 2007 22:42:44 -0500
> To: "TEITAC Web/Software Subcommittee" <teitac-
> = EMAIL ADDRESS REMOVED = >
> Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
>
> Sounds like it would be a much better idea to develop a mouse
> alternative that was switched-based than to get industry to make
> drawing
> keyboard accessible.
>
> "-----Original Message-----
> "From: = EMAIL ADDRESS REMOVED =
> "[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> "Of Randy Marsden
> "Sent: Thursday, January 18, 2007 9:25 PM
> "To: TEITAC Web/Software Subcommittee
> "Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
> "
> "Not a correct assumption. Many people with motor impairments
> "who can't use a keyboard also can't use a mouse alternative.
> "For some of them, switch access is the only way. A lot of
> "assistive technology switch access solutions rely on keyboard
> "equivalents to send commands to the target application. The
> "more things that can be done via the keyboard, the more things
> "that can be done with a switch via these AT switch solutions.
> "
> "-Randy
> "
> "
> "
> " From: "Barrett, Don" < = EMAIL ADDRESS REMOVED = >
> " Reply-To: TEITAC Web/Software Subcommittee
> "< = EMAIL ADDRESS REMOVED = >
> " Date: Thu, 18 Jan 2007 18:00:22 -0500
> " To: "TEITAC Web/Software Subcommittee"
> "< = EMAIL ADDRESS REMOVED = >
> " Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
> "
> "
> "
> "
> "
> "
> " I understand that; but there are some many analog mouse
> "alternatives,
> " that should cover them. I would think the keyboard
> "would be the hardest
> " for those with limited motor impairments so a mouse
> "alternative would
> " most likely be the choice of AT thus eliminating them
> "from the equation.
> "
> "
> "
> " 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 Sean
> " Hayes
> " Sent: Thursday, January 18, 2007 5:57 PM
> " To: TEITAC Web/Software Subcommittee
> " Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
> "
> " I'm sorry, I didn't think the intention of this was
> "specific to blind
> " users, but might include those with limited motor
> "skills. I guess this
> " illustrates the necessity of clarifying what this
> "provision is actually
> " about.
> "
> " Sean Hayes
> " Standards and Policy Team
> " Accessible Technology Group
> " Microsoft
> " Phone:
> " mob +44 7977 455002
> " office +44 117 9719730
> "
> " -----Original Message-----
> " From: = EMAIL ADDRESS REMOVED =
> " [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> " Barrett, Don
> " Sent: 18 January 2007 21:54
> " To: TEITAC Web/Software Subcommittee
> " Subject: Re: [teitac-websoftware] Web Gaps - keyboard operation
> "
> " In all my testing over the years, I have never come
> "across a situation
> " in which a blind persons's career was negatively
> "affected because
> " drawing capacity wasn't available from the keyboard. I
> "will never use
> " PhotoShop, and I don't know any blind person who will.
> "I still haven't
> " seen clear concise examples of what is wrong with
> "textually discerned.
> " For example, why are we just accepting the notion that
> "freehand drawing
> " must be accessible from the keyboard. I am not against
> "the idea if it
> " has practical merit, but I want to ensure that the
> "standards provide
> " practical guidance, not just satisfy an intellectual
> "desire to codify
> " that which isn't necessary.
> "
From: Jim Tobias
Date: Fri, Jan 19 2007 6:10 AM
Subject: Re: Web Gaps - keyboard operation
Gregg wrote:
"I think we should start by figuring out what we think should be in and out
of our requirement. Then work on how to define it."
Yes, quite right. I think this may be the genius of having relatively short
Standards text linked tightly to the guidance materials. Instead of
spending
so much time looking for the perfect phrase to replace "discerned textually"
(if such a replacement is even necessary), we can focus on our intent and
provide guidance by example.
This approach has the added benefit of allowing the Access Board to refresh
the guidance material more nimbly and frequently, while keeping the basic
principles as embedded in the Standards unchanged.
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias
From: Gregg Vanderheiden
Date: Sun, Jan 21 2007 11:10 PM
Subject: Re: Web Gaps - keyboard operation
Examples is a great idea.
Examples aren't normative so the guideline has to completely define the
provision though. Example can then be used to make it clearer but not to
add detail or definition.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: Jim Tobias [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Friday, January 19, 2007 7:06 AM
> To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Web/Software Subcommittee'
> Subject: RE: [teitac-websoftware] Web Gaps - keyboard operation
>
> Gregg wrote:
>
> "I think we should start by figuring out what we think should
> be in and out
> of our requirement. Then work on how to define it."
>
> Yes, quite right. I think this may be the genius of having
> relatively short Standards text linked tightly to the
> guidance materials. Instead of spending so much time looking
> for the perfect phrase to replace "discerned textually"
> (if such a replacement is even necessary), we can focus on
> our intent and provide guidance by example.
>
> This approach has the added benefit of allowing the Access
> Board to refresh the guidance material more nimbly and
> frequently, while keeping the basic principles as embedded in
> the Standards unchanged.
>
>
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
>
WebAIM is an initiative of:
