Thread Subject: Re: teitac-websoftware Digest, Vol 2, Issue 4

Return to this mailing list's archives

From: Langum, Michael J
Date: Wed, Nov 01 2006 12:30 PM
Subject: Re: teitac-websoftware Digest, Vol 2, Issue 4

I've been lurking in the woods following this thread.

You've all made a lot of good comments and suggestions. Here is my
brief contribution.

1. I think it might be useful to borrow the concept of "Authoring Tool."
This would mean any application (Word Processor, Spreadsheet, Flow-chart
app., etc.) used to create any content consumed by a human being. Of
course, the Authoring Tools themselves would need to be accessible as
well as their output.

2. This group (or some other standards group), needs to start putting
together guidelines for such tools, just as W3C has done. This will be
a long process, but it would be a good idea to start now, so that the
Application producers can begin to add needed functionality to their
tools.

3. MOST IMPORTANT! There will never be a substitute for training of
content creators on the "how-to" of creating accessible content. There
is not a purely technical "fix." Until clever Authoring Tools exist
that will do an "access check/repair," the only option will be old
fashioned training. Maybe each organization should provide at least
basic training on how to produce accessible content (e.g. correct use of
headers, tables, images, etc.)

From: Jim Tobias
Date: Wed, Nov 01 2006 12:40 PM
Subject: Re: teitac-websoftware Digest, Vol 2, Issue 4

absolutely right on all 3!

***********
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1.732.441.0831 v/tty
skype jimtobias
www.inclusive.com


> -----Original Message-----
> From: Langum, Michael J [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Wednesday, November 01, 2006 2:26 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [teitac-websoftware] teitac-websoftware Digest,
> Vol 2, Issue 4
>
> I've been lurking in the woods following this thread.
>
> You've all made a lot of good comments and suggestions. Here
> is my brief contribution.
>
> 1. I think it might be useful to borrow the concept of
> "Authoring Tool."
> This would mean any application (Word Processor, Spreadsheet,
> Flow-chart app., etc.) used to create any content consumed by
> a human being. Of course, the Authoring Tools themselves
> would need to be accessible as well as their output.
>
> 2. This group (or some other standards group), needs to start
> putting together guidelines for such tools, just as W3C has
> done. This will be a long process, but it would be a good
> idea to start now, so that the Application producers can
> begin to add needed functionality to their tools.
>
> 3. MOST IMPORTANT! There will never be a substitute for
> training of content creators on the "how-to" of creating
> accessible content. There is not a purely technical "fix."
> Until clever Authoring Tools exist that will do an "access
> check/repair," the only option will be old fashioned
> training. Maybe each organization should provide at least
> basic training on how to produce accessible content (e.g.
> correct use of headers, tables, images, etc.)
>

From: Hoffman, Allen
Date: Wed, Nov 01 2006 1:35 PM
Subject: Re: teitac-websoftware Digest, Vol 2, Issue 4

Michael Langham wrote:
"1. I think it might be useful to borrow the concept of "Authoring
Tool."
This would mean any application (Word Processor, Spreadsheet, Flow-chart
app., etc.) used to create any content consumed by a human being. Of
course, the Authoring Tools themselves would need to be accessible as
well as their output."

Perfectly right, I should have recalled the right language.

Michael continues:
"3. MOST IMPORTANT! There will never be a substitute for training of
content creators on the "how-to" of creating accessible content. There
is not a purely technical "fix." Until clever Authoring Tools exist
that will do an "access check/repair," the only option will be old
fashioned training. Maybe each organization should provide at least
basic training on how to produce accessible content (e.g. correct use of
headers, tables, images, etc.)"

I agree that training can't be replaced, but we desperately need tools
that "just work" for accessibility as they do for other requirements.

I'm suggesting we develop authoring tool functional requirements, and
general "content" requirements to match. If we restrict ourselves to
the nonsubjective requirements only these can be automated, testable,
and doable. I think sometimes we have to consider that the harder we
make doing accessibility, the less of it we will get, which I think is
exactly what is happening regarding accessible content.



Allen Hoffman
Department of Homeland Security
Office on Accessible systems & Technology

From: Stephen Baum
Date: Tue, Nov 14 2006 11:00 AM
Subject: Re: teitac-websoftware Digest, Vol 2, Issue 20

I find I want a little clarification regarding 21(b), so I'll provide
a real example. Many applications for the blind, including at least
one screen reader and one scan and read application that I can think
of, disable the keyboard shortcut for the StickyKeys accessibility
option in Windows. The default shortcut is to press Shift five times
in a row. That is problematic in those applications, because the
prominence and position of the shift keys make them valuable keyboard
real estate - they are often used to, for example, advance or rewind
by a certain amount of text while reading continuously. The keyboard
shortcut would get in the way, because its pretty reasonable to
expect a customer to press the right shift key repeatedly to move
forward by five (or more) units. The shortcut is disabled (if it had
been enabled), when the application starts, and reenabled (again, if
it was originally disabled by the application), when the application exits.

Does that fall within, or outside of, this language?

Stephen


>Proposed: 21(b) Applications shall not disrupt or disable activated features
>of other products (including Operating Systems) that are identified as
>accessibility features, where those features are developed and documented
>according to industry standards.

From: Debbie Cook
Date: Tue, Nov 14 2006 12:55 PM
Subject: Re: teitac-websoftware Digest, Vol 2, Issue 20

"I find I want a little clarification regarding 21(b), so I'll provide
a real example. Many applications for the blind, including at least
one screen reader and one scan and read application that I can think
of, disable the keyboard shortcut for the StickyKeys accessibility
option in Windows."

My comments: This is indeed a bad idea. Currently it seems to be the
pervasive view that AT is exempt from 508 requirements but this is a great
example of why it should not be. There are an increasing number of people
who are blind, for example, who need features such as sticky keys. In fact
they may perform all screen reader functions (which often require pressing
three keys at once) through sticky keys. I am seriously hoping that we will
be including language that suggests the 508 requirements also apply to AT
unless they somehow prohibit the functionality of the AT. As a compromise
Iwould say that the AT should provide one mode of operation that does not
disable a documented accessibility feature.

From: Stephen Baum
Date: Tue, Nov 14 2006 1:20 PM
Subject: Re: teitac-websoftware Digest, Vol 2, Issue 24

Perhaps it is worth noting that the accessibility feature itself is
not disabled. The default mechanism for enabling it via a sequence of
key clicks is. Most people who use sticky keys would have them
enabled all of the time. I have never, in fact, heard any customer of
the products in question complain about the fact that the hot key
sequence is disabled while the product is active - on the contrary,
the "feature" exists because of customer complaints.

Perhaps the broader issue is that all applications, including
operating systems, are designed with a particular customer, and a
particular usage pattern, in mind - sometimes deliberately, sometimes
inadvertently. Those assumptions get in the way - particularly for
products that are designed with a low incidence customer base in mind.

Stephen

At 02:00 PM 11/14/2006, you wrote:
>"I find I want a little clarification regarding 21(b), so I'll provide
>a real example. Many applications for the blind, including at least
>one screen reader and one scan and read application that I can think
>of, disable the keyboard shortcut for the StickyKeys accessibility
>option in Windows."
>
>My comments: This is indeed a bad idea. Currently it seems to be the
>pervasive view that AT is exempt from 508 requirements but this is a great
>example of why it should not be. There are an increasing number of people
>who are blind, for example, who need features such as sticky keys. In fact
>they may perform all screen reader functions (which often require pressing
>three keys at once) through sticky keys. I am seriously hoping that we will
>be including language that suggests the 508 requirements also apply to AT
>unless they somehow prohibit the functionality of the AT. As a compromise
>Iwould say that the AT should provide one mode of operation that does not
>disable a documented accessibility feature.

From: Eric Damery
Date: Tue, Nov 14 2006 1:30 PM
Subject: Re: teitac-websoftware Digest, Vol 2, Issue 20

Regarding:
"I am seriously hoping that we will be including language that suggests
the 508 requirements also apply to AT unless they somehow prohibit the
functionality of the AT."

To follow up on Stephen Baum's feedback on the subject...

The fact that we disable certain "Accessibility Features" built into
Windows is a direct result of trying to help the majority of our users.
>From a JAWS stand point, there are several which we modify the behavior
of at run time of our product by default. A couple of examples are:

1. Disable Personalized Menus
2. Disable Hide Keyboard Navigation Indicators Until I Use The ALT Key

These are check boxes that can be unchecked by a JAWS user of course,
but the fact is that a Keyboard user that can not see the screen is
greatly confused why key combinations that worked yesterday fail to work
today which is the case when personalized menus are active. Fortunately,
Microsoft built in the ability for us to turn it off at run time and
then back on when we exit. In all cases, we go to great length to ensure
the alternative exist for those with multiple disabilities.

Regards,
Eric Damery
Freedom Scientific, Inc.


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie
Cook
Sent: Tuesday, November 14, 2006 2:50 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] teitac-websoftware Digest, Vol 2,
Issue 20

"I find I want a little clarification regarding 21(b), so I'll provide a
real example. Many applications for the blind, including at least one
screen reader and one scan and read application that I can think of,
disable the keyboard shortcut for the StickyKeys accessibility option in
Windows."

My comments: This is indeed a bad idea. Currently it seems to be the
pervasive view that AT is exempt from 508 requirements but this is a
great example of why it should not be. There are an increasing number of
people who are blind, for example, who need features such as sticky
keys. In fact they may perform all screen reader functions (which often
require pressing three keys at once) through sticky keys. I am seriously
hoping that we will be including language that suggests the 508
requirements also apply to AT unless they somehow prohibit the
functionality of the AT. As a compromise Iwould say that the AT should
provide one mode of operation that does not disable a documented
accessibility feature.

From: Debbie Cook
Date: Tue, Nov 14 2006 1:50 PM
Subject: Re: teitac-websoftware Digest, Vol 2, Issue 20

Those are not examples of disabling functionality though because the user
can very easily restore them if they wished to do so. Not sure why one would
want to of course, but it's very possible. In the case of disabling sticky
keys though, it does impact a pretty significant number of users and in fact
it's an incrdasing number.
----- Original Message -----
From: "Eric Damery" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, November 14, 2006 12:28 PM
Subject: Re: [teitac-websoftware] teitac-websoftware Digest, Vol 2, Issue 20


Regarding:
"I am seriously hoping that we will be including language that suggests
the 508 requirements also apply to AT unless they somehow prohibit the
functionality of the AT."

To follow up on Stephen Baum's feedback on the subject...

The fact that we disable certain "Accessibility Features" built into
Windows is a direct result of trying to help the majority of our users.
>From a JAWS stand point, there are several which we modify the behavior
of at run time of our product by default. A couple of examples are:

1. Disable Personalized Menus
2. Disable Hide Keyboard Navigation Indicators Until I Use The ALT Key

These are check boxes that can be unchecked by a JAWS user of course,
but the fact is that a Keyboard user that can not see the screen is
greatly confused why key combinations that worked yesterday fail to work
today which is the case when personalized menus are active. Fortunately,
Microsoft built in the ability for us to turn it off at run time and
then back on when we exit. In all cases, we go to great length to ensure
the alternative exist for those with multiple disabilities.

Regards,
Eric Damery
Freedom Scientific, Inc.


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie
Cook
Sent: Tuesday, November 14, 2006 2:50 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] teitac-websoftware Digest, Vol 2,
Issue 20

"I find I want a little clarification regarding 21(b), so I'll provide a
real example. Many applications for the blind, including at least one
screen reader and one scan and read application that I can think of,
disable the keyboard shortcut for the StickyKeys accessibility option in
Windows."

My comments: This is indeed a bad idea. Currently it seems to be the
pervasive view that AT is exempt from 508 requirements but this is a
great example of why it should not be. There are an increasing number of
people who are blind, for example, who need features such as sticky
keys. In fact they may perform all screen reader functions (which often
require pressing three keys at once) through sticky keys. I am seriously
hoping that we will be including language that suggests the 508
requirements also apply to AT unless they somehow prohibit the
functionality of the AT. As a compromise Iwould say that the AT should
provide one mode of operation that does not disable a documented
accessibility feature.

From: Victor Tsaran
Date: Tue, Nov 14 2006 2:00 PM
Subject: Re: teitac-websoftware Digest, Vol 2, Issue 20

I would second Eric's comments. However, what could be done is
that perhaps assistive technologies run a kind of wizzard,
similar to what Accessibility Wizzard in Windows XP/Vista do.
I would not want this kind of things to be baked into standards
though.
--- Debbie Cook < = EMAIL ADDRESS REMOVED = > wrote:

> "I find I want a little clarification regarding 21(b), so I'll
> provide
> a real example. Many applications for the blind, including at
> least
> one screen reader and one scan and read application that I can
> think
> of, disable the keyboard shortcut for the StickyKeys
> accessibility
> option in Windows."
>
> My comments: This is indeed a bad idea. Currently it seems to
> be the
> pervasive view that AT is exempt from 508 requirements but
> this is a great
> example of why it should not be. There are an increasing
> number of people
> who are blind, for example, who need features such as sticky
> keys. In fact
> they may perform all screen reader functions (which often
> require pressing
> three keys at once) through sticky keys. I am seriously hoping
> that we will
> be including language that suggests the 508 requirements also
> apply to AT
> unless they somehow prohibit the functionality of the AT. As a
> compromise
> Iwould say that the AT should provide one mode of operation
> that does not
> disable a documented accessibility feature.
>
>

From: Jim Thatcher
Date: Tue, Nov 14 2006 2:50 PM
Subject: Re: teitac-websoftware Digest, Vol 2, Issue 20

Hi Debbie,

Stephen made a point of stressing that sticky keys are not disabled, the
"hot key sequence is disabled" while the application is running.

Jim

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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie Cook
Sent: Tuesday, November 14, 2006 2:49 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] teitac-websoftware Digest, Vol 2, Issue 20

Those are not examples of disabling functionality though because the user
can very easily restore them if they wished to do so. Not sure why one would

want to of course, but it's very possible. In the case of disabling sticky
keys though, it does impact a pretty significant number of users and in fact

it's an incrdasing number.
----- Original Message -----
From: "Eric Damery" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, November 14, 2006 12:28 PM
Subject: Re: [teitac-websoftware] teitac-websoftware Digest, Vol 2, Issue 20


Regarding:
"I am seriously hoping that we will be including language that suggests
the 508 requirements also apply to AT unless they somehow prohibit the
functionality of the AT."

To follow up on Stephen Baum's feedback on the subject...

The fact that we disable certain "Accessibility Features" built into
Windows is a direct result of trying to help the majority of our users.
>From a JAWS stand point, there are several which we modify the behavior
of at run time of our product by default. A couple of examples are:

1. Disable Personalized Menus
2. Disable Hide Keyboard Navigation Indicators Until I Use The ALT Key

These are check boxes that can be unchecked by a JAWS user of course,
but the fact is that a Keyboard user that can not see the screen is
greatly confused why key combinations that worked yesterday fail to work
today which is the case when personalized menus are active. Fortunately,
Microsoft built in the ability for us to turn it off at run time and
then back on when we exit. In all cases, we go to great length to ensure
the alternative exist for those with multiple disabilities.

Regards,
Eric Damery
Freedom Scientific, Inc.


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie
Cook
Sent: Tuesday, November 14, 2006 2:50 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] teitac-websoftware Digest, Vol 2,
Issue 20

"I find I want a little clarification regarding 21(b), so I'll provide a
real example. Many applications for the blind, including at least one
screen reader and one scan and read application that I can think of,
disable the keyboard shortcut for the StickyKeys accessibility option in
Windows."

My comments: This is indeed a bad idea. Currently it seems to be the
pervasive view that AT is exempt from 508 requirements but this is a
great example of why it should not be. There are an increasing number of
people who are blind, for example, who need features such as sticky
keys. In fact they may perform all screen reader functions (which often
require pressing three keys at once) through sticky keys. I am seriously
hoping that we will be including language that suggests the 508
requirements also apply to AT unless they somehow prohibit the
functionality of the AT. As a compromise Iwould say that the AT should
provide one mode of operation that does not disable a documented
accessibility feature.