Thread Subject: Re: General Issues:Speechinterfacesandequivalent facilitation

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: Fratkin, Mike
Date: Wed, Jan 10 2007 6:55 AM
Subject: Re: General Issues:Speechinterfacesandequivalent facilitation

AT SSA we have a significant number of refreshable Braille users that
find Braille essential in navigating mainframe screens. Speech and
Braille go hand-in-hand and to exclude the capability when speech
engines are implemented would tend to diminish functionality
significantly for Braille users.

Mike Fratkin
SSA

[Allen wrote:]


Is refreshable braille support something we feel is a requirement?
I can waffle on this--but if I were deaf/blind I'd not waffle one bit.

Allen Hoffman
DHS Office on Accessible Systems & Technology

From: Gregg Vanderheiden
Date: Wed, Jan 10 2007 9:05 AM
Subject: Re: General Issues:Speechinterfaces and equivalent facilitation

Thanks Aubrey,



What i meant was things like workstations. As compared to say an info
kiosk in the lobby.



If it takes you 4 times as long to find a room number it is inconvenient but
doesn't affect your ability to do your job. If it takes you 4 times as
long to enter text on your keyboard though and you are mostly doing that for
a living - then you can get a days work done every 4 or so.





Screen reader compatibility may be needed for workstations even if apps were
all self voicing unless they did so in so harmonious a way that they
performed to the same level as a screen reader.



Just trying to draw a line where AT may be needed even if some type of
access is built in. This would be true for screen readers and perhaps
even more so for people with some physical disabilities where you can't
build in custom interfaces and built in would be limited.




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






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Wednesday, January 10, 2007 7:39 AM
To: TEITAC General Interface Accessibility Subcommittee
Subject: Re: [teitac-general] [teitac-websoftware] General Issues:
Speechinterfaces and equivalent facilitation


RE:

What if we just said

2) that products that require productivity (e.g. workstations) need to be
accessible to assistive technologies to allow matching of user abilities
necessary to achieve high levels of productivity.

Gregg, could you explain more about what could be considered "products that
require productivity"?

It seems that it could be almost any E&IT product, depending on how it is
being used.

I'm also concerned that if this group of products were only required to be
accessible through AT, manufacturers would no longer be motivated to design
accessibility into the product itself and we may even lose some of the
progress we have gained in this area.

Aubrey

Aubrey Woolley
Government Policy and Compliance Analyst
Government Marketing Division
Canon USA, Inc.
TEL: (703) 807-3158
= EMAIL ADDRESS REMOVED =





"Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
Sent by: = EMAIL ADDRESS REMOVED =

01/10/2007 01:19 AM


Please respond to
TEITAC General Interface Accessibility Subcommittee
< = EMAIL ADDRESS REMOVED = >


To

"'TEITAC Web/Software Subcommittee'" < = EMAIL ADDRESS REMOVED = >,
"'TEITAC General Interface Accessibility Subcommittee'"
< = EMAIL ADDRESS REMOVED = >


cc




Subject

Re: [teitac-general] [teitac-websoftware] General Issues: Speech
interfaces and equivalent facilitation











I posted something on this earlier that might be helpful to you.

Here, I found it. We need to tweak the words to fit but the basic idea is
here.


What if we just said

1) that products need to be accessible either via available assistive
technology or directly accessible.

2) that products that require productivity (e.g. workstations) need to be
accessible to assistive technologies to allow matching of user abilities
necessary to achieve high levels of productivity.


Since this would apply to the functional performance criteria I am adding
the General list.

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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andi Snow-Weaver
> Sent: Tuesday, January 09, 2007 2:12 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [teitac-websoftware] General Issues: Speech
> interfaces and equivalent facilitation
>
>
> Speech interfaces are being incorporated into some
> applications seemingly replacing the need for screen readers.
> This typically is not equivalent to the functionality of
> screen readers and normally does not interface with
> refreshable Braille displays. It does, however, meet the
> functional performance criteria (31(a)) to provide at least
> one mode of operation and information retrieval that does not
> require user vision (assuming other necessary features such
> as keyboard operation, etc.).
>
> Thoughts on this topic?
>
> Andi
>
>

From: Debbie Cook
Date: Wed, Jan 10 2007 4:50 PM
Subject: Re: General Issues:Speechinterfacesandequivalent facilitation

"Is refreshable braille support something we feel is a requirement?
I can waffle on this--but if I were deaf/blind I'd not waffle one bit."

The issue is that in a PC type application both speech and Braille support
come from the screen reader. If Braille isn't supported well in that
context, it's frankly the problem of the screen reader. If we're talking
about something that is self-contained and therefore provides its own AT,
it's not possible for it to support Braille other than to provide the
interface and even that's tricky since there are so many varieties each with
their own protocol. I think Braille has to come through interface with a PC
or directly with a Braille device supplied by the user. Unlike enlargement
and speech output which can easily be native to the application.

From: David Poehlman
Date: Sat, Jan 20 2007 4:55 AM
Subject: Re: General Issues:Speechinterfacesandequivalent facilitation

I'd be interested in exploring this. What would it take since apps
already provide display paths and could provide keyboard access to ad
a braille driver much like using a printer driver. maybe this needs
to be done at the os level.

On Jan 10, 2007, at 6:45 PM, Debbie Cook wrote:

"Is refreshable braille support something we feel is a requirement?
I can waffle on this--but if I were deaf/blind I'd not waffle one bit."

The issue is that in a PC type application both speech and Braille
support
come from the screen reader. If Braille isn't supported well in that
context, it's frankly the problem of the screen reader. If we're talking
about something that is self-contained and therefore provides its own
AT,
it's not possible for it to support Braille other than to provide the
interface and even that's tricky since there are so many varieties
each with
their own protocol. I think Braille has to come through interface
with a PC
or directly with a Braille device supplied by the user. Unlike
enlargement
and speech output which can easily be native to the application.

From: Gregg Vanderheiden
Date: Sat, Jan 20 2007 11:20 PM
Subject: Re: General Issues:Speechinterfaces and equivalent facilitation

Hi David,

Software working with the Mac screen reader would be accessible. My
point was that the line is getting blurred these days.

And my previous point about productivity products (personal workstations)
may need optimal interfaces rather than just any access.


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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> David Poehlman
> Sent: Saturday, January 20, 2007 4:36 AM
> To: TEITAC General Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] [teitac-websoftware] General
> Issues:Speechinterfaces and equivalent facilitation
>
> Greg,
>
> If my app does not need to be used with a screen reader
> because it has one in it, why would it need to be compatible
> with a screen reader? Does this fail the Mac because it's
> not compatible with JAWS?
>
> On Jan 11, 2007, at 2:19 AM, Gregg Vanderheiden wrote:
>
> I also have trouble with the fact that the line is not bright
> as we would like.
>
>
>
> But the problem with not requiring this is that one could
> have a self voicing application that is not screen reader
> compatible and it would
> be called accessible. I think that that might be a big problem.
> In the past we did this by requiring AT compatibility for
> software. But as we move forward with software being
> generalized,
> this old approach starts to fail. We need to think about
> how we are
> going to deal with this situation. Doing it the way we did
> - isn't
> working as we move forward.
>
>
>
> We need to look at this carefully to be sure that we don't
> avoid one problem and create a greater one.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>
> From: = EMAIL ADDRESS REMOVED =
> [mailto:teitac-general- = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Jim Tobias
> Sent: Wednesday, January 10, 2007 9:28 AM
> To: 'TEITAC General Interface Accessibility Subcommittee'
> Subject: Re: [teitac-general] [teitac-websoftware] General Issues:
> Speechinterfaces and equivalent facilitation
>
> I agree with Audrey's concerns about defining situations
> where "productivity" is required, given that the same products
>
> may be used in different contexts, not to mention the
> difficulty of defining the threshold level of productivity.
>
> ******
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1 732.441.0831 voice/tty
> skype jimtobias
> +1 908.907.2387 mobile
>
>
>
>

From: David Poehlman
Date: Sun, Jan 21 2007 10:25 AM
Subject: Re: General Issues:Speechinterfaces and equivalent facilitation

Isn't "just access" really not access if it doesn't allow one to do
the job?

On Jan 21, 2007, at 1:17 AM, Gregg Vanderheiden wrote:

Hi David,

Software working with the Mac screen reader would be
accessible. My
point was that the line is getting blurred these days.

And my previous point about productivity products (personal
workstations)
may need optimal interfaces rather than just any access.


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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> David Poehlman
> Sent: Saturday, January 20, 2007 4:36 AM
> To: TEITAC General Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] [teitac-websoftware] General
> Issues:Speechinterfaces and equivalent facilitation
>
> Greg,
>
> If my app does not need to be used with a screen reader
> because it has one in it, why would it need to be compatible
> with a screen reader? Does this fail the Mac because it's
> not compatible with JAWS?
>
> On Jan 11, 2007, at 2:19 AM, Gregg Vanderheiden wrote:
>
> I also have trouble with the fact that the line is not bright
> as we would like.
>
>
>
> But the problem with not requiring this is that one could
> have a self voicing application that is not screen reader
> compatible and it would
> be called accessible. I think that that might be a big problem.
> In the past we did this by requiring AT compatibility for
> software. But as we move forward with software being
> generalized,
> this old approach starts to fail. We need to think about
> how we are
> going to deal with this situation. Doing it the way we did
> - isn't
> working as we move forward.
>
>
>
> We need to look at this carefully to be sure that we don't
> avoid one problem and create a greater one.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>
> From: = EMAIL ADDRESS REMOVED =
> [mailto:teitac-general- = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Jim Tobias
> Sent: Wednesday, January 10, 2007 9:28 AM
> To: 'TEITAC General Interface Accessibility Subcommittee'
> Subject: Re: [teitac-general] [teitac-websoftware] General Issues:
> Speechinterfaces and equivalent facilitation
>
> I agree with Audrey's concerns about defining situations
> where "productivity" is required, given that the same products
>
> may be used in different contexts, not to mention the
> difficulty of defining the threshold level of productivity.
>
> ******
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1 732.441.0831 voice/tty
> skype jimtobias
> +1 908.907.2387 mobile
>
>
>
>

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