Thread Subject: Repost of Jim's Straw Man Proposal

Return to this mailing list's archives

From: Debbie Cook
Date: Tue, Dec 05 2006 2:20 PM
Subject: Repost of Jim's Straw Man Proposal

For our discussion on the call:



1. appliance-type ICT, like calculators

2. peripherals like printers that don't typically have their own user

interface

3. public transaction terminals where the content or transaction is not

sensitive, such as a specially-configured PC used for access to a library's

electronic catalog

4. public transaction terminals where the content or transaction is

sensitive, such as voting machine



Am I missing any product sub-categories here?



Let me propose a straw man.



For #1, grant an exception because suitable alternative appliances are

available. That is, don't require an agency to purchase only talking

calculators because it's burdensome and because talking calculators are

available.



For #2, require that all functions be able to be performed from a

workstation (a particular user's workstation or one connected to the

peripheral). This means that my screen-reader-equipped computer can operate

the printer/copier remotely, because all functions (including status readout

like empty paper trays) are exposed. This would be a significant step

forward, and appears to be fully feasible.



For #3, require the terminal to (a) support all accessibility features

native to the operating system the terminal uses and (b) provide either

permanently installed assistive technology functionality, or the use of a

temporary installation of assistive technology. This means in (a) that the

terminal basically running an operating system must permit users to access

the OS features. In (b) it means the device must have been configured with

AT (e.g. built-in screen reader) or permit temporary AT (e.g. screen reader

on a flash drive, NCITS V2 network download of an alternate interface, EZ

Access).



For #4, to what extent can we use the voting machine standards the way we're

using WCAG and ISO for web and software? A lot of work has gone into them,

and if certain sections can be adopted or adapted, why not do so?

From: Randy Marsden
Date: Tue, Dec 05 2006 2:25 PM
Subject: Repost of Jim's Straw Man Proposal & ClosedDefinition Proposal

There is value in defining all three categories of ³Closed Products²:
1. ³Technically closed² (ie. Not open to AT)
2. ³Closed by Policy², and
3. ³Open to AT, but no AT exists².

If a product is in the latter category, then a solution could be technically
produced. If AT doesn¹t exist today, yet the mainstream manufacturer did
everything they needed to do in order to open up their product to AT, then
at least half the battle is won. After that, market forces should lead AT
manufacturers to provide the solution. (I know that¹s a ³perfect world²
scenario, but AT manufacturers are in the business of providing AT
solutions, and if enough demand exists for a solution, they will make it).

The real question then becomes ³what if the market forces (or other factors)
are not enough to entice AT vendors to create a solution?². In this case,
does the burden of accessibility rest on the original mainstream
manufacturer? In other words, are they required to create the AT themselves
(or build in accessibility)? An example of that very thing happening is the
Voice Over screen reader made by Apple for Mac OSX.

However, if a mainstream product is technically closed to AT (and doesn¹t
have built-in accessibility of its own), then there is no hope of making it
accessible ­ market forces or not. It would be helpful to know which
product fits into which category.

-Randy Marsden, ATIA
>
> From: "Debbie Cook" < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC self contained/closed products subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Tue, 5 Dec 2006 13:16:43 -0800
> To: "TEITAC self contained/closed products subcommittee"
> < = EMAIL ADDRESS REMOVED = >
> Subject: [teitac-closed] Repost of Jim's Straw Man Proposal
>

> For our discussion on the call:
>
>
>
> 1. appliance-type ICT, like calculators
>
> 2. peripherals like printers that don't typically have their own user
>
> interface
>
> 3. public transaction terminals where the content or transaction is not
>
> sensitive, such as a specially-configured PC used for access to a library's
>
> electronic catalog
>
> 4. public transaction terminals where the content or transaction is
>
> sensitive, such as voting machine
>
>
>
> Am I missing any product sub-categories here?
>
>
>
> Let me propose a straw man.
>
>
>
> For #1, grant an exception because suitable alternative appliances are
>
> available. That is, don't require an agency to purchase only talking
>
> calculators because it's burdensome and because talking calculators are
>
> available.
>
>
>
> For #2, require that all functions be able to be performed from a
>
> workstation (a particular user's workstation or one connected to the
>
> peripheral). This means that my screen-reader-equipped computer can operate
>
> the printer/copier remotely, because all functions (including status readout
>
> like empty paper trays) are exposed. This would be a significant step
>
> forward, and appears to be fully feasible.
>
>
>
> For #3, require the terminal to (a) support all accessibility features
>
> native to the operating system the terminal uses and (b) provide either
>
> permanently installed assistive technology functionality, or the use of a
>
> temporary installation of assistive technology. This means in (a) that the
>
> terminal basically running an operating system must permit users to access
>
> the OS features. In (b) it means the device must have been configured with
>
> AT (e.g. built-in screen reader) or permit temporary AT (e.g. screen reader
>
> on a flash drive, NCITS V2 network download of an alternate interface, EZ
>
> Access).
>
>
>
> For #4, to what extent can we use the voting machine standards the way we're
>
> using WCAG and ISO for web and software? A lot of work has gone into them,
>
> and if certain sections can be adopted or adapted, why not do so?
>
>
>
>

From: Brett, Thomas F
Date: Tue, Dec 05 2006 2:40 PM
Subject: Re: Repost of Jim's Straw Man Proposal &ClosedDefinition Proposal

please identify yourself prior to speaking on the telecon.

Tom Brett

From: Gregg Vanderheiden
Date: Tue, Dec 05 2006 3:40 PM
Subject: Re: Repost of Jim's Straw Man Proposal &Closed Definition Proposal

Very good suggestion Randy. And very good characterization.



Interestingly, to a person with a disability - all three are not accessible.
Does that mean same provisions apply?




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






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy Marsden
Sent: Tuesday, December 05, 2006 3:22 PM
To: TEITAC self contained/closed products subcommittee
Subject: [teitac-closed] Repost of Jim's Straw Man Proposal & Closed
Definition Proposal

There is value in defining all three categories of "Closed Products":

1. "Technically closed" (ie. Not open to AT)
2. "Closed by Policy", and
3. "Open to AT, but no AT exists".


If a product is in the latter category, then a solution could be technically
produced. If AT doesn't exist today, yet the mainstream manufacturer did
everything they needed to do in order to open up their product to AT, then
at least half the battle is won. After that, market forces should lead AT
manufacturers to provide the solution. (I know that's a "perfect world"
scenario, but AT manufacturers are in the business of providing AT
solutions, and if enough demand exists for a solution, they will make it).

The real question then becomes "what if the market forces (or other factors)
are not enough to entice AT vendors to create a solution?". In this case,
does the burden of accessibility rest on the original mainstream
manufacturer? In other words, are they required to create the AT themselves
(or build in accessibility)? An example of that very thing happening is the
Voice Over screen reader made by Apple for Mac OSX.

However, if a mainstream product is technically closed to AT (and doesn't
have built-in accessibility of its own), then there is no hope of making it
accessible - market forces or not. It would be helpful to know which
product fits into which category.

-Randy Marsden, ATIA


From: "Debbie Cook" < = EMAIL ADDRESS REMOVED = >
Reply-To: TEITAC self contained/closed products subcommittee
< = EMAIL ADDRESS REMOVED = >
Date: Tue, 5 Dec 2006 13:16:43 -0800
To: "TEITAC self contained/closed products subcommittee"
< = EMAIL ADDRESS REMOVED = >
Subject: [teitac-closed] Repost of Jim's Straw Man Proposal



For our discussion on the call:



1. appliance-type ICT, like calculators

2. peripherals like printers that don't typically have their own user

interface

3. public transaction terminals where the content or transaction is not

sensitive, such as a specially-configured PC used for access to a library's

electronic catalog

4. public transaction terminals where the content or transaction is

sensitive, such as voting machine



Am I missing any product sub-categories here?



Let me propose a straw man.



For #1, grant an exception because suitable alternative appliances are

available. That is, don't require an agency to purchase only talking

calculators because it's burdensome and because talking calculators are

available.



For #2, require that all functions be able to be performed from a

workstation (a particular user's workstation or one connected to the

peripheral). This means that my screen-reader-equipped computer can operate

the printer/copier remotely, because all functions (including status readout

like empty paper trays) are exposed. This would be a significant step

forward, and appears to be fully feasible.



For #3, require the terminal to (a) support all accessibility features

native to the operating system the terminal uses and (b) provide either

permanently installed assistive technology functionality, or the use of a

temporary installation of assistive technology. This means in (a) that the

terminal basically running an operating system must permit users to access

the OS features. In (b) it means the device must have been configured with

AT (e.g. built-in screen reader) or permit temporary AT (e.g. screen reader

on a flash drive, NCITS V2 network download of an alternate interface, EZ

Access).



For #4, to what extent can we use the voting machine standards the way we're

using WCAG and ISO for web and software? A lot of work has gone into them,

and if certain sections can be adopted or adapted, why not do so?