Expanding the web's potential for people with disabilities

Getting Started

Introduction to web accessibility

WebAIM Training

May 21-22
Training Details

From the Blog

Community

You are here: Home > TEITAC Archives > Mailing List Archives

Thread Subject: "closed software"

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

Next message

From: Jim Tobias
Date: Tue, Dec 19 2006 6:05 AM
Subject: "closed software"

In the discussion of closed products, we seem to be converging on the
opinion that "closed" is a characteristic, not a category. In this context,
software has been mentioned as potentially closed. Can someone please give
me an example, or a further explanation, of what closed software might be?

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

Previous message | Next message

From: Debbie Cook
Date: Tue, Dec 19 2006 11:15 AM
Subject: Re: "closed software"

The most obvious example is probably software protected by DRM.

I think there are also products where the "closed" aspect is hard to
determine in terms of origin. A non-federal procurement example: last week I
flew on Alaska Air. They distributed, for a fee, something called a Didgie
Player. I don't know who makes it. Entertainment including movies and music.
No captioning. No accessible menu. No way to attach AT, but I don't think
there is any AT to augment the physical controls or to make it accessible
non-visually. It has hardware and software issues I suspect. You could make
the hardware more accessible by providing readily identifiable controls and
you could add some kind of ports to allow various AT on board, but the
software is at the heart of the problem along with the lack of existingAT.
So, for me, this product is closed and it doesn't matter whether or not it's
hardware or software. The solution for someone with dexterity limitations
would be addition of hardware connectors for AT. The solution for a blind or
deaf person would be software based.

I don't think it will be meaningful for this type of developer to have to
run all over the standards to figure out what to do. So, I still think
there's a category of closed products where both the hardware and software
have issues.
----- Original Message -----
From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
To: "'TEITAC self contained/closed products subcommittee'"
< = EMAIL ADDRESS REMOVED = >; "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, December 19, 2006 4:55 AM
Subject: [teitac-websoftware] "closed software"

In the discussion of closed products, we seem to be converging on the
opinion that "closed" is a characteristic, not a category. In this context,
software has been mentioned as potentially closed. Can someone please give
me an example, or a further explanation, of what closed software might be?

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

Previous message | Next message

From: Lybarger, Barbara (MOD)
Date: Tue, Dec 19 2006 11:40 AM
Subject: Re: "closed software"

See the Access Board Guidelines for this section
http://www.access-board.gov/sec508/guide/1194.25.htm
<http://www.access-board.gov/sec508/guide/1194.25.htm>

They give several examples of closed products:

"Self contained closed products generally have embedded
software and are commonly designed in such a fashion that a user cannot
easily attach or install assistive technology. For example, one could
attach a screen reader to a computer which meets the section 508
standards but one would not be expected to attach a screen reader to a
copier machine. A copier machine is an example of a self-contained,
closed product. Other examples include, calculators, fax machines,
information transaction machines, and information kiosks. Unlike other
provisions which allow a product to meet the standards by being
compatible with assistive technology, this provision requires self
contained, closed products to contain built-in accessibility. Although
not built-in, a headset is considered an allowable add-on, since it is
not considered assistive technology in this case. Headsets might be used
for privacy, not accessibility reasons."

Barbara Lybarger

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Tobias
Sent: Tuesday, December 19, 2006 7:56 AM
To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
Web/Software Subcommittee'
Subject: [teitac-websoftware] "closed software"

In the discussion of closed products, we seem to be converging on the
opinion that "closed" is a characteristic, not a category. In this
context, software has been mentioned as potentially closed. Can someone
please give me an example, or a further explanation, of what closed
software might be?

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

Previous message | Next message

From: Peter Korn
Date: Tue, Dec 19 2006 4:15 PM
Subject: Re: "closed software"

Hi Jim, Gregg,

To expand on Gregg's answer #1 to your question about closed software:

> Some possible examples of closed software.
>
> Maybe some things like: (numbered only to facilitate discussion)
>
> 1 - Software that for security reasons does not allow anything to access
> what it has on screen and which reads keyboard registers directly to avoid
> tampering or 'remote' typing.
>

Sun's Trusted Solaris 9 - and especially the "multi-level/multi-label
security mode" is a real life example of this. In order to ensure the
highest levels of security for sales to customers like the National
Security Agency, Trusted Solaris goes to great lengths to ensure that
applications are siloed apart from one another. Applications cannot get
access to the keyboard or mouse directly - they only have very limited
access when that particular application is focused.

By the way, we are working on explicitly supporting accessibility in
forthcoming versions of Trusted Solaris - through accessibility APIs
that can only be used by AT software that has been explicitly installed
and given the privileges to have that API level of access to other
applications. For such security sensitive environments, we see
absolutely no other approach that meet both security & accessibility
requirements.

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

Previous message | Next message

From: Randy Marsden
Date: Tue, Dec 19 2006 4:50 PM
Subject: Re: "closed software"

My iPod description given in emails yesterday is one such example.

-Randy
>
> From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Tue, 19 Dec 2006 07:55:58 -0500
> To: "'TEITAC self contained/closed products subcommittee'"
> < = EMAIL ADDRESS REMOVED = >, "'TEITAC Web/Software Subcommittee'"
> < = EMAIL ADDRESS REMOVED = >
> Subject: [teitac-websoftware] "closed software"
>

> In the discussion of closed products, we seem to be converging on the
> opinion that "closed" is a characteristic, not a category. In this context,
> software has been mentioned as potentially closed. Can someone please give
> me an example, or a further explanation, of what closed software might be?
>
> ***********
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1.732.441.0831 v/tty
> skype jimtobias
> www.inclusive.com
>
>

Previous message | Next message

From: Randy Marsden
Date: Tue, Dec 19 2006 4:55 PM
Subject: Re: "closed software"

Previous message | Next message

From: Jim Tobias
Date: Fri, Dec 22 2006 6:00 AM
Subject: Re: "closed software"

Randy wrote, regarding iPods that it's an example of "closed software", even
given David Poehlman's identification of "Rock Box" as alternative
interface. I don't see how this is so.

1. iPods are designed to accept software upgrades from Apple, so they are
not "closed" in that aspect, at least. Apple could somehow lock out all
software changes that did not come thorough Apple themselves, but they
appear not to have done that. Even in that case, the "closedness" would be
by policy, not by technological feasibility.

2. "Rock Box" is an example of a third-party software solution to some
accessibility issues that can be loaded onto an iPod. Assuming that the
original iPod interface can be restored somehow, doesn't that make the iPod
almost like a PC, able to run with or without a screen reader, not like a
product

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

_____

From: Randy Marsden [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, December 19, 2006 6:46 PM
To: TEITAC Web/Software Subcommittee; TEITAC self contained/closed products
subcommittee
Subject: Re: [teitac-websoftware] "closed software"

My iPod description given in emails yesterday is one such example.

-Randy

From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
Reply-To: TEITAC Web/Software Subcommittee
< = EMAIL ADDRESS REMOVED = >
Date: Tue, 19 Dec 2006 07:55:58 -0500
To: "'TEITAC self contained/closed products subcommittee'"
< = EMAIL ADDRESS REMOVED = >, "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Subject: [teitac-websoftware] "closed software"

In the discussion of closed products, we seem to be converging on the
opinion that "closed" is a characteristic, not a category. In this context,
software has been mentioned as potentially closed. Can someone please give
me an example, or a further explanation, of what closed software might be?

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

Previous message | Next message

From: Jim Tobias
Date: Fri, Dec 22 2006 6:05 AM
Subject: Re: "closed software"

Previous message | Next message

From: Michael R. Burks
Date: Fri, Dec 22 2006 6:45 AM
Subject: Re: "closed software"

How about Cell Phones? Many have operating systems that we cannot upgrade.
Would those pass as closed systems?

Mike Burks

919 870 8788 - Office

919-882-1884 - Fax

703-254-3881 - Cell

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Friday, December 22, 2006 7:59 AM
To: 'TEITAC Web/Software Subcommittee'; 'TEITAC self contained/closed
products subcommittee'
Subject: Re: [teitac-websoftware] "closed software"

Randy wrote, regarding iPods that it's an example of "closed software", even
given David Poehlman's identification of "Rock Box" as alternative
interface. I don't see how this is so.

1. iPods are designed to accept software upgrades from Apple, so they are
not "closed" in that aspect, at least. Apple could somehow lock out all
software changes that did not come thorough Apple themselves, but they
appear not to have done that. Even in that case, the "closedness" would be
by policy, not by technological feasibility.

2. "Rock Box" is an example of a third-party software solution to some
accessibility issues that can be loaded onto an iPod. Assuming that the
original iPod interface can be restored somehow, doesn't that make the iPod
almost like a PC, able to run with or without a screen reader, not like a
product

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

_____

From: Randy Marsden [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, December 19, 2006 6:46 PM
To: TEITAC Web/Software Subcommittee; TEITAC self contained/closed products
subcommittee
Subject: Re: [teitac-websoftware] "closed software"

My iPod description given in emails yesterday is one such example.

-Randy

From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
Reply-To: TEITAC Web/Software Subcommittee
< = EMAIL ADDRESS REMOVED = >
Date: Tue, 19 Dec 2006 07:55:58 -0500
To: "'TEITAC self contained/closed products subcommittee'"
< = EMAIL ADDRESS REMOVED = >, "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Subject: [teitac-websoftware] "closed software"

In the discussion of closed products, we seem to be converging on the
opinion that "closed" is a characteristic, not a category. In this context,
software has been mentioned as potentially closed. Can someone please give
me an example, or a further explanation, of what closed software might be?

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

Previous message | Next message

From: Gregg Vanderheiden
Date: Fri, Dec 22 2006 8:00 AM
Subject: Re: "closed software"

The hardware is not closed but the software is. It is not designed to
accept AT.

The fact that at product can be upgraded by its manufacturer with
proprietary software - or even that it allows 3rd party extensions - is a
different issue from whether it works with AT.

But maybe you are just trying to focus on the fact that the word "closed" is
ambiguous. And often misinterpreted.

Hmmm

I think that may be a key point.

I suggest we stop using the word "closed" since it is universally ambiguous
and very often misinterpreted. Instead we should say what we mean.

"Products that do not work with AT" and then say what should be true "must
provide built in access". And then specify what is "good enough" built in
access. (and also what AT is good enough.

Hmmmmm .. interesting

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

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Friday, December 22, 2006 6:59 AM
To: 'TEITAC Web/Software Subcommittee'; 'TEITAC self contained/closed
products subcommittee'
Subject: Re: [teitac-websoftware] "closed software"

Randy wrote, regarding iPods that it's an example of "closed software", even
given David Poehlman's identification of "Rock Box" as alternative
interface. I don't see how this is so.

1. iPods are designed to accept software upgrades from Apple, so they are
not "closed" in that aspect, at least. Apple could somehow lock out all
software changes that did not come thorough Apple themselves, but they
appear not to have done that. Even in that case, the "closedness" would be
by policy, not by technological feasibility.

2. "Rock Box" is an example of a third-party software solution to some
accessibility issues that can be loaded onto an iPod. Assuming that the
original iPod interface can be restored somehow, doesn't that make the iPod
almost like a PC, able to run with or without a screen reader, not like a
product

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

_____

From: Randy Marsden [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, December 19, 2006 6:46 PM
To: TEITAC Web/Software Subcommittee; TEITAC self contained/closed products
subcommittee
Subject: Re: [teitac-websoftware] "closed software"

My iPod description given in emails yesterday is one such example.

-Randy

From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
Reply-To: TEITAC Web/Software Subcommittee
< = EMAIL ADDRESS REMOVED = >
Date: Tue, 19 Dec 2006 07:55:58 -0500
To: "'TEITAC self contained/closed products subcommittee'"
< = EMAIL ADDRESS REMOVED = >, "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Subject: [teitac-websoftware] "closed software"

In the discussion of closed products, we seem to be converging on the
opinion that "closed" is a characteristic, not a category. In this context,
software has been mentioned as potentially closed. Can someone please give
me an example, or a further explanation, of what closed software might be?

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

Previous message | Next message

From: Gregg Vanderheiden
Date: Fri, Dec 22 2006 8:10 AM
Subject: Re: "closed software"

Previous message | Next message

From: Gregg Vanderheiden
Date: Fri, Dec 22 2006 8:15 AM
Subject: Re: "closed software"

Previous message | Next message

From: Jim Tobias
Date: Fri, Dec 22 2006 9:05 AM
Subject: Re: "closed software"

Gregg wrote:

" The hardware is not closed but the software is. It is not designed to
accept AT.

The fact that at product can be upgraded by its manufacturer with
proprietary software - or even that it allows 3rd party extensions - is a
different issue from whether it works with AT."

As I've posted recently, "closed" means BOTH unable to be controlled from
another, accessible, device like an AT-equipped PC workstation; AND unable
to load and run its own accessibility software.

What does "... works with AT" mean -- only current AT? We should not be
constrained by the current crop of AT. The goal of the regs is to stimulate
native accessibility in products that don't have it right now, and to
stimulate AT where native accessibility is not feasible or reasonable.

Jim Tobias

= EMAIL ADDRESS REMOVED =

Previous message | Next message

From: Jim Tobias
Date: Fri, Dec 22 2006 9:15 AM
Subject: Re: "closed software"

Mike Burks wrote:

" How about Cell Phones? Many have operating systems that we cannot
upgrade. Would those pass as closed systems? "

There may be such cell phones. But there are cell phones with operating
systems that either (1) already contain accessibility features, (2) can be
modified to contain them, or (3) are compatible with third-party software
for access. The regs should encourage feds to purchase *these* phones, not
the inaccessible/closed ones. That would, as intended, drive the market
towards wireless platforms with accessibility features and/or compatible AT
software packages.

(For the benefit of our benevolent Access Board overlords: it's too bad that
there's not a continually updated report that monitors the market to
indicate where such progress has been made. Why, such a report would
probably also be useful in performing the kind of market research that the
508 FAR regs require....)

Jim Tobias

= EMAIL ADDRESS REMOVED =

Previous message | Next message

From: Gregg Vanderheiden
Date: Fri, Dec 22 2006 9:50 AM
Subject: Re: "closed software"

"closed" means BOTH unable to be controlled from another, accessible,
device like an AT-equipped PC workstation; AND unable to load and run its
own accessibility software.

That is close to what I was assuming. I would say that it would have to
have the access software in it - not just that it could. For example, if a
person with a disability goes to a library and encounters the card catalog
system. If they are unable to connect or install their AT then then system
would be closed - even if the manufacturer somewhere had software it could
install that would make it accessible - but it did not sell that to the
library (or the library did not buy or install it).

E.g. 'work with AT'. You asked if that meant current AT. I would assume
so. The purpose of 508 was to make things accessible to people with
disabilities. If the AT doesn't exist yet - or users don't or can't get it
- then the product cannot be used by people with disabilities - and fails
both the performance criteria and the intent of 508.

This is important enough a topic I will be posting a separate email on this
one in a bit. Have to run now.

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

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Friday, December 22, 2006 9:58 AM
To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
Web/Software Subcommittee'
Cc: 'TEITAC General Interface Accessibility Subcommittee'
Subject: Re: [teitac-general] [teitac-closed] [teitac-websoftware] "closed
software"

Gregg wrote:

" The hardware is not closed but the software is. It is not designed to
accept AT.

The fact that at product can be upgraded by its manufacturer with
proprietary software - or even that it allows 3rd party extensions - is a
different issue from whether it works with AT."

As I've posted recently, "closed" means BOTH unable to be controlled from
another, accessible, device like an AT-equipped PC workstation; AND unable
to load and run its own accessibility software.

What does "... works with AT" mean -- only current AT? We should not be
constrained by the current crop of AT. The goal of the regs is to stimulate
native accessibility in products that don't have it right now, and to
stimulate AT where native accessibility is not feasible or reasonable.

Jim Tobias

= EMAIL ADDRESS REMOVED =

Previous message | Next message

From: Randy Marsden (Home)
Date: Fri, Dec 22 2006 9:55 AM
Subject: Re: "closed software"

>>
>>
>> Jim Tobias wrote:
>>
>> What does "... works with AT" mean -- only current AT? We should not be
>> constrained by the current crop of AT. The goal of the regs is to stimulate
>> native accessibility in products that don't have it right now, and to
>> stimulate AT where native accessibility is not feasible or reasonable.
>>
>> I find this language disturbing. My impression was the goal of the regs was
>> to make mainstream technology more accessible to people with disabilities Â
>> not necessarily to explicitly drive built-in accessibility. Many people with
>> disabilities prefer to use their own AT, even when a product has its own
>> built-in accessibility. The two are not mutually exclusive, nor should be.
>> (Although the current wording of 508 tends to separate them by using the word
>> Â³orÂ² in the functional performance criteria Â perhaps something we should
>> look at). I think the best situation is when both exist.
>>
>> Â³constrained by the current crop of ATÂ². AT is evolving even as IT is. I
>> think what has been suggested for wording is something along the lines of
>> Â³works with readily available ATÂ². That doesnÂ¹t constrain the regs to the
>> current crop of AT Â it leaves room for whatever AT is developed in the
>> future that becomes readily available.
>>
>> -Randy Marsden
>> ATIA
>>
>>
>
>
>

Previous message | Next message

From: Gregg Vanderheiden
Date: Fri, Dec 22 2006 10:00 AM
Subject: Re: "closed software"

Previous message | Next message

From: Jim Tobias
Date: Fri, Dec 22 2006 2:40 PM
Subject: Re: "closed software"

I was quoting Gregg's comments about what to include or exclude in any
"closed" determination. I *thought* I was speaking very much in favor of AT
innovation, but maybe I wasn't clear. Here's what I mean. Let's look at 3
cases for an "appliance"-type product:

1. has native accessibility (built-in accessibility features)
2. has no native accessibility, but there is AT
3. has no native accessibility, and no current AT

The goal is to move more products into categories #1 and #2. Not to
eliminate #2, but to expand it. More consumer/procurer choice.

A mainstream company with a #3 product has 3 options:

a. give up on federal sales
b. add native accessibility
c. partner with or otherwise encourage an AT company to develop an AT
solution for the product

_____

From: Randy Marsden (Home) [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, December 22, 2006 11:51 AM
To: TEITAC self contained/closed products subcommittee; 'TEITAC Web/Software
Subcommittee'
Cc: 'TEITAC General Interface Accessibility Subcommittee'
Subject: Re: [teitac-closed] [teitac-websoftware] "closed software"

Jim Tobias wrote:

What does "... works with AT" mean -- only current AT? We should not be
constrained by the current crop of AT. The goal of the regs is to stimulate
native accessibility in products that don't have it right now, and to
stimulate AT where native accessibility is not feasible or reasonable.

I find this language disturbing. My impression was the goal of the regs was
to make mainstream technology more accessible to people with disabilities -
not necessarily to explicitly drive built-in accessibility. Many people
with disabilities prefer to use their own AT, even when a product has its
own built-in accessibility. The two are not mutually exclusive, nor should
be. (Although the current wording of 508 tends to separate them by using
the word "or" in the functional performance criteria - perhaps something we
should look at). I think the best situation is when both exist.

"constrained by the current crop of AT". AT is evolving even as IT is. I
think what has been suggested for wording is something along the lines of
"works with readily available AT". That doesn't constrain the regs to the
current crop of AT - it leaves room for whatever AT is developed in the
future that becomes readily available.

-Randy Marsden
ATIA

_____

Previous message | Next message

From: Randy Marsden (Home)
Date: Fri, Dec 22 2006 11:25 PM
Subject: Re: "closed software"

Thanks for the clarification, Jim. I agree with your thoughts below.

-Randy
>
> From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC General Interface Accessibility Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Fri, 22 Dec 2006 16:32:14 -0500
> To: "'TEITAC self contained/closed products subcommittee'"
> < = EMAIL ADDRESS REMOVED = >, "'TEITAC Web/Software Subcommittee'"
> < = EMAIL ADDRESS REMOVED = >
> Cc: 'TEITAC General Interface Accessibility Subcommittee'
> < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [teitac-general] [teitac-closed] [teitac-websoftware] "closed
> software"
>

> I was quoting Gregg's comments about what to include or exclude in any
> "closed" determination. I *thought* I was speaking very much in favor of AT
> innovation, but maybe I wasn't clear. Here's what I mean. Let's look at 3
> cases for an "appliance"-type product:
>
> 1. has native accessibility (built-in accessibility features)
> 2. has no native accessibility, but there is AT
> 3. has no native accessibility, and no current AT
>
> The goal is to move more products into categories #1 and #2. Not to eliminate
> #2, but to expand it. More consumer/procurer choice.
>
> A mainstream company with a #3 product has 3 options:
>
> a. give up on federal sales
> b. add native accessibility
> c. partner with or otherwise encourage an AT company to develop an AT solution
> for the product
>
>>
>> From: Randy Marsden (Home) [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Friday, December 22, 2006 11:51 AM
>> To: TEITAC self contained/closed products subcommittee; 'TEITAC Web/Software
>> Subcommittee'
>> Cc: 'TEITAC General Interface Accessibility Subcommittee'
>> Subject: Re: [teitac-closed] [teitac-websoftware] "closed software"
>>
>>>>
>>>>
>>>> Jim Tobias wrote:
>>>>
>>>> What does "... works with AT" mean -- only current AT? We should not be
>>>> constrained by the current crop of AT. The goal of the regs is to
>>>> stimulate native accessibility in products that don't have it right now,
>>>> and to stimulate AT where native accessibility is not feasible or
>>>> reasonable.
>>>>
>>>> I find this language disturbing. My impression was the goal of the regs
>>>> was to make mainstream technology more accessible to people with
>>>> disabilities Â not necessarily to explicitly drive built-in accessibility.
>>>> Many people with disabilities prefer to use their own AT, even when a
>>>> product has its own built-in accessibility. The two are not mutually
>>>> exclusive, nor should be. (Although the current wording of 508 tends to
>>>> separate them by using the word Â³orÂ² in the functional performance criteria
>>>> Â perhaps something we should look at). I think the best situation is when
>>>> both exist.
>>>>
>>>> Â³constrained by the current crop of ATÂ². AT is evolving even as IT is. I
>>>> think what has been suggested for wording is something along the lines of
>>>> Â³works with readily available ATÂ². That doesnÂ¹t constrain the regs to the
>>>> current crop of AT Â it leaves room for whatever AT is developed in the
>>>> future that becomes readily available.
>>>>
>>>> -Randy Marsden
>>>> ATIA
>>>>
>>>>
>>>
>>>
>>>

Previous message | Next message

From: Randy Marsden (Home)
Date: Fri, Dec 22 2006 11:30 PM
Subject: Re: "closed software"

Previous message | Next message

From: Robinson, Norman B - Washington, DC
Date: Wed, Dec 27 2006 1:35 PM
Subject: Re: "closed software"

Peter,

I just wanted to state the security requirement is a business
requirement that in most likelihood can be clearly documented and would
be covered by fundamental alteration if no other technical solution
currently exists. Or consider stronger ties to 1194.21(b) and they
shouldn't interfere with assistive technology.

There is no such thing as "closed software". For me, the security
issues, including related issues such as digital rights management (DRM)
are NOT closed product (software) issues. They are often at odds with
accessibility (and basic user expectations for that matter). It is
usually a usability issue (we are all restricted equally regardless of
our abilities) or freedom of use issue if you prefer. Yes I could use
the word closed in conversation, restrictive works better, but not in
the context of Section 508.

I suggest the definition of "self-contained, closed products" be changed
to simply "Closed product hardware". There are many self-contained
products that can be upgraded, updated, and contain a full operating
system and hardware capable of providing full function accessibility. I
think the final definition should be "Products commonly designed in such
a fashion that a user cannot easily attach or install assistive
technology. These products include, but are not limited to, information
kiosks, printers, and other similar non-standard hardware products where
accessibility must be designed into the product by the manufacturer."

What happens when the user can install assistive technology but the
product is not accessible? Well, it isn't closed if the user can install
assistive technology! All the other provisions of Section 508 technical
standards apply.

You'll note two concepts. One, hardware. Two, accessibility must be
designed in.

I also advocate 1194.26 Desktop and portable computers and the 1194.23
Telecommunications products (a) & (h) &(k) section be merged with
1194.25 "Closed product hardware" and simply be called "Hardware
Technical Standards". Sorry for thinking outside the box <grins>.(note
comment below signature)

Regards,

Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246

P.S. I advocate the above approach generically to software and web too.
Functional performance criteria (1194.31) maps to "Hardware" and then to
specific section "Closed product hardware". Functional performance
criteria also maps to Software (1194.21) and then specifically web
browser software (1194.22). It isn't perfect, some of the "technical
standards" are actually functional criteria, but together we can work it
all out.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Tuesday, December 19, 2006 3:22 PM
To: TEITAC Web/Software Subcommittee
Cc: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
General Interface Accessibility Subcommittee'
Subject: Re: [teitac-closed] [teitac-websoftware] "closed software"

Hi Jim, Gregg,

To expand on Gregg's answer #1 to your question about closed software:

> Some possible examples of closed software.
>
> Maybe some things like: (numbered only to facilitate discussion)
>
> 1 - Software that for security reasons does not allow anything to
access
> what it has on screen and which reads keyboard registers directly to
avoid
> tampering or 'remote' typing.
>

Sun's Trusted Solaris 9 - and especially the "multi-level/multi-label
security mode" is a real life example of this. In order to ensure the
highest levels of security for sales to customers like the National
Security Agency, Trusted Solaris goes to great lengths to ensure that
applications are siloed apart from one another. Applications cannot get

access to the keyboard or mouse directly - they only have very limited
access when that particular application is focused.

By the way, we are working on explicitly supporting accessibility in
forthcoming versions of Trusted Solaris - through accessibility APIs
that can only be used by AT software that has been explicitly installed
and given the privileges to have that API level of access to other
applications. For such security sensitive environments, we see
absolutely no other approach that meet both security & accessibility
requirements.

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

Previous message | Next message

From: Gregg Vanderheiden
Date: Wed, Jan 03 2007 8:25 AM
Subject: Re: "closed software"

I thought of that as I wrote it.

Well, since it is built into the OS, the application that work with it would
be directly accessible since they are accessible without needing any AT.
Remember that any software with access built in would need to rely on OS
functions (speech, sound, keyboard etc). this would also rely on the
voiceover functionality.

Since they have an API - it would ALSO be compatible with any AT that was
out there.

Having an API only though - without AT support would not be accessible (i.e.
usable with people who have disabilities) if there was no AT. That is why
Apple built it into their system and have an API. They support AT but are
not subject to AT availability - which was a problem for them - at least for
screen readers.

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> David Poehlman
> Sent: Wednesday, January 03, 2007 4:38 AM
> To: TEITAC Web/Software Subcommittee
> Cc: 'TEITAC self contained/closed products subcommittee';
> 'TEITAC General Interface Accessibility Subcommittee'
> Subject: Re: [teitac-general] [teitac-websoftware]
> [teitac-closed] "closed software"
>
> greg, am I to understand then that your #2 excludes the Mac
> which has its ownn AT?
>
> On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:
>
> Hi Norman,
>
> I agree with your premise that there shouldn't be any closed software.
>
> But if there is software that is closed (not accessible to
> AT) for any reason (business, technical or security) then we
> do want to require that it
> is accessible - no? And I believe that there will be legitimate
> arguments
> for some places where the software will be closed - and/or
> that there will be no AT developed for or that can be used
> with the product.
>
> I'm not talking about desktop computers necessarily.
>
> 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.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson,
> > Norman B - Washington, DC
> > Sent: Wednesday, December 27, 2006 2:54 PM
> > To: TEITAC self contained/closed products subcommittee; TEITAC
> > Web/Software Subcommittee
> > Cc: TEITAC General Interface Accessibility Subcommittee
> > Subject: Re: [teitac-general] [teitac-closed] "closed software"
> >
> > Since I earlier offered a different perspective on "closed
> software",
> > I thought I would respond to each item.
> >
> > 1. Security reasons: Security should be a part of a
> requirement in the
> > same way accessibility should be a part of the requirement for a
> > product. First, security options _CAN_ be accessible (e.g.,
> accessible
> > CAPTCHAs or accessible login screens). Second, where there is a
> > technical determination that no access to application programming
> > interfaces (APIs) that work with assistive technology is allowed,
> > there is a business justification. No matter what assistive
> technology
> > can do, if the system designed to block user interaction to
> only one
> > type of system interface for business reasons, that is an
> exception.
> > However, I'd be amiss if I didn't say see "First".
> >
> > 2. Besides semantics, and debating among friends, software
> can't run
> > without an operating system unless it, itself, IS the operating
> > system.
> >
> > 3. What is the point of making a classification of "CLOSED
> SOFTWARE"?
> > What does it mean to us in context of Section 508? Your
> example is one
> > of being accessible through design. I'd say the example
> doesn't help
> > the argument and problem we are trying to solve (if you'll please
> > forgive me). We are concerned when software doesn't work with
> > assistive technology and isn't designed to be accessible.
> I'd also say
> > I have the expectation that this software is generally only used in
> > conjunction with specialized hardware. Firefox web browser was
> > considered to be too small a market for certain AT vendors.
> What does
> > that mean? I think they have an API. I think this is complex
> > interaction of _accessibility interfaces_ dependent on the
> operating
> > system. Sorry, I'm an Amiga/Windows/OSX/Linux user and it varies
> > considerably. It is too easy to just think in context of
> one platform,
> > especially when embedded operating systems in phones are so
> plentiful
> > and experiencing these same issues. Sorry to ramble, I
> think I need to
> > discuss this some more.
> >
> > 4. Platform software issues are interesting. Is commercial
> > availability exemptions? Tying it to vendor product and 'official'
> > support is dangerous too; I'm sure my MS Windows vendor doesn't
> > support me running Linux on my corporate desktop, but the screen
> > reader and web browser works just fine for most of my
> needs. I think
> > that is close to the earlier iPod firmware upgrade. But who cares?
> > Even if a 3rd party or Apple made the software as an add-on to the
> > product it can be made accessible. The debate so far has focused on
> > the vendor not developing assistive technology. Third
> parties do and
> > you can make things accessible without assistive technology.
> >
> > Sorry to disagree, but the closed software approach doesn't
> work well
> > for Section 508 evaluation. I can't help but feel we're not
> asking the
> > right questions. DRM is bad for end-users, security typically
> > negatively impacts end-user experience, and accessibility
> is all about
> > the user!
> > This discussion is really useful for questioning vendors
> and how they
> > support our business/agency. I don't think finding
> justification for
> > closed software means we should place a label on software
> and treat it
> > any differently from any other software. Closed software should be
> > accessible and follow the same technical standards as any other
> > software.
> >
> > 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: Tuesday, December 19, 2006 12:45 PM
> > To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
> > Web/Software Subcommittee'
> > Cc: 'TEITAC General Interface Accessibility Subcommittee'
> > Subject: Re: [teitac-closed] "closed software"
> >
> >
> > Some possible examples of closed software.
> >
> > Maybe some things like: (numbered only to facilitate discussion)
> >
> > 1 - Software that for security reasons does not allow anything to
> > access what it has on screen and which reads keyboard registers
> > directly to avoid tampering or 'remote' typing.
> >
> > 2 - Software designed to run on a product without and operating
> > system.
> >
> > 3 - Software that has no API for AT - but instead has built in
> > accessibility since there is no AT vendor who will work with and
> > support the unique capability of the software because the market is
> > too small for AT vendors.
> >
> > 4 - Something like Randy pointed to (see just below). The
> hardware is
> > not closed since new software can be loaded. But the
> > platform/software is closed.
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >

Previous message | Next message

From: Randy Marsden (Home)
Date: Wed, Jan 03 2007 9:30 AM
Subject: Re: "closed software"

A screen reader is but one category of assistive technology. Because Apple
happened to make their own for the Mac doesnÂ¹t mean all aspects of assistive
technology are covered. (Access for the mobility impaired, for example, is
not addressed by a screen reader).

Also, AppleÂ¹s screen reader uses accessibility APIÂ¹s built into the
operating system, as any other assistive technology screen reader would. It
just happens that the same company makes both the IT and the screen reader.
So, technically, I think it would fit into GreggÂ¹s category 1: an IT
product that is compatible with external AT.

-Randy
>
> From: David Poehlman < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC General Interface Accessibility Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Wed, 3 Jan 2007 05:37:33 -0500
> To: TEITAC Web/Software Subcommittee < = EMAIL ADDRESS REMOVED = >
> Cc: 'TEITAC self contained/closed products subcommittee'
> < = EMAIL ADDRESS REMOVED = >, 'TEITAC General Interface Accessibility
> Subcommittee' < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [teitac-general] [teitac-websoftware] [teitac-closed] "closed
> software"
>

> greg, am I to understand then that your #2 excludes the Mac which has
> its ownn AT?
>

Previous message | Next message

From: Gregg Vanderheiden
Date: Wed, Jan 03 2007 10:30 PM
Subject: Re: "closed software"

No. AT can be from same company.

If the user has to pay extra for it - then I would call it AT.

If it comes as part of the product - I would call it built in. Especially
if it is shipped as part of the product to everyone.

But I think we need to write our regs so that we don't have to get into such
discussions or hair splitting. Because the way things are going it will be
impossible to separate things into AT or not-AT. Use any definition you
like and I will give you examples that fit both definitions at different
times.

The issue isn't whether it is AT or not. I belive that what we need to
focus on is whether people with disabilities, with whatever they have, can
access and use the products.

Now - how to phrase the standards to do this...

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Peter Korn
> Sent: Wednesday, January 03, 2007 2:07 PM
> To: TEITAC Web/Software Subcommittee
> Cc: 'TEITAC self contained/closed products subcommittee';
> 'TEITAC General Interface Accessibility Subcommittee'
> Subject: Re: [teitac-general] [teitac-websoftware]
> [teitac-closed]"closed software"
>
> Hi Gregg,
>
> I don't understand this. Is it part of the definition of AT
> that it comes from a 3rd party, separate from the OS? Or can
> it be the same party as the OS, but just not with the OS
> (e.g. ScreenReader/2 for OS/2)?
>
> Separately, today in the Web & Software SC call, Andi asked
> about non-AT voice recognition software (is it only AT if it
> is called "AT"?).
>
>
> I suggest that Apple's VoiceOver (bundled with the OS X 10.4
> and later),
> and Gnopernicus & GOK (bundled with Solaris 10), and GOK &
> Orca (bundled
> with Ubuntu GNU/Linux 6.10) *are* all AT. In exactly the
> same way that
> we (now) say that WordPad is an application (even though it
> is bundled
> with Windows).
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
> > I thought of that as I wrote it.
> >
> > Well, since it is built into the OS, the application that
> work with it would
> > be directly accessible since they are accessible without
> needing any AT.
> > Remember that any software with access built in would need
> to rely on OS
> > functions (speech, sound, keyboard etc). this would also
> rely on the
> > voiceover functionality.
> >
> > Since they have an API - it would ALSO be compatible with
> any AT that was
> > out there.
> >
> > Having an API only though - without AT support would not be
> accessible (i.e.
> > usable with people who have disabilities) if there was no
> AT. That is why
> > Apple built it into their system and have an API. They
> support AT but are
> > not subject to AT availability - which was a problem for
> them - at least for
> > screen readers.
> >
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: = EMAIL ADDRESS REMOVED =
> >> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> >> David Poehlman
> >> Sent: Wednesday, January 03, 2007 4:38 AM
> >> To: TEITAC Web/Software Subcommittee
> >> Cc: 'TEITAC self contained/closed products subcommittee';
> >> 'TEITAC General Interface Accessibility Subcommittee'
> >> Subject: Re: [teitac-general] [teitac-websoftware]
> >> [teitac-closed] "closed software"
> >>
> >> greg, am I to understand then that your #2 excludes the Mac
> >> which has its ownn AT?
> >>
> >> On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:
> >>
> >> Hi Norman,
> >>
> >> I agree with your premise that there shouldn't be any
> closed software.
> >>
> >> But if there is software that is closed (not accessible to
> >> AT) for any reason (business, technical or security) then we
> >> do want to require that it
> >> is accessible - no? And I believe that there will be legitimate
> >> arguments
> >> for some places where the software will be closed - and/or
> >> that there will be no AT developed for or that can be used
> >> with the product.
> >>
> >> I'm not talking about desktop computers necessarily.
> >>
> >> 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.
> >>
> >>
> >> Gregg
> >> -- ------------------------------
> >> Gregg C Vanderheiden Ph.D.
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: = EMAIL ADDRESS REMOVED =
> >>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> >>>
> >> Of Robinson,
> >>
> >>> Norman B - Washington, DC
> >>> Sent: Wednesday, December 27, 2006 2:54 PM
> >>> To: TEITAC self contained/closed products subcommittee; TEITAC
> >>> Web/Software Subcommittee
> >>> Cc: TEITAC General Interface Accessibility Subcommittee
> >>> Subject: Re: [teitac-general] [teitac-closed] "closed software"
> >>>
> >>> Since I earlier offered a different perspective on "closed
> >>>
> >> software",
> >>
> >>> I thought I would respond to each item.
> >>>
> >>> 1. Security reasons: Security should be a part of a
> >>>
> >> requirement in the
> >>
> >>> same way accessibility should be a part of the requirement for a
> >>> product. First, security options _CAN_ be accessible (e.g.,
> >>>
> >> accessible
> >>
> >>> CAPTCHAs or accessible login screens). Second, where there is a
> >>> technical determination that no access to application programming
> >>> interfaces (APIs) that work with assistive technology is allowed,
> >>> there is a business justification. No matter what assistive
> >>>
> >> technology
> >>
> >>> can do, if the system designed to block user interaction to
> >>>
> >> only one
> >>
> >>> type of system interface for business reasons, that is an
> >>>
> >> exception.
> >>
> >>> However, I'd be amiss if I didn't say see "First".
> >>>
> >>> 2. Besides semantics, and debating among friends, software
> >>>
> >> can't run
> >>
> >>> without an operating system unless it, itself, IS the operating
> >>> system.
> >>>
> >>> 3. What is the point of making a classification of "CLOSED
> >>>
> >> SOFTWARE"?
> >>
> >>> What does it mean to us in context of Section 508? Your
> >>>
> >> example is one
> >>
> >>> of being accessible through design. I'd say the example
> >>>
> >> doesn't help
> >>
> >>> the argument and problem we are trying to solve (if you'll please
> >>> forgive me). We are concerned when software doesn't work with
> >>> assistive technology and isn't designed to be accessible.
> >>>
> >> I'd also say
> >>
> >>> I have the expectation that this software is generally
> only used in
> >>> conjunction with specialized hardware. Firefox web browser was
> >>> considered to be too small a market for certain AT vendors.
> >>>
> >> What does
> >>
> >>> that mean? I think they have an API. I think this is complex
> >>> interaction of _accessibility interfaces_ dependent on the
> >>>
> >> operating
> >>
> >>> system. Sorry, I'm an Amiga/Windows/OSX/Linux user and it varies
> >>> considerably. It is too easy to just think in context of
> >>>
> >> one platform,
> >>
> >>> especially when embedded operating systems in phones are so
> >>>
> >> plentiful
> >>
> >>> and experiencing these same issues. Sorry to ramble, I
> >>>
> >> think I need to
> >>
> >>> discuss this some more.
> >>>
> >>> 4. Platform software issues are interesting. Is commercial
> >>> availability exemptions? Tying it to vendor product and
> 'official'
> >>> support is dangerous too; I'm sure my MS Windows vendor doesn't
> >>> support me running Linux on my corporate desktop, but the screen
> >>> reader and web browser works just fine for most of my
> >>>
> >> needs. I think
> >>
> >>> that is close to the earlier iPod firmware upgrade. But
> who cares?
> >>> Even if a 3rd party or Apple made the software as an
> add-on to the
> >>> product it can be made accessible. The debate so far has
> focused on
> >>> the vendor not developing assistive technology. Third
> >>>
> >> parties do and
> >>
> >>> you can make things accessible without assistive technology.
> >>>
> >>> Sorry to disagree, but the closed software approach doesn't
> >>>
> >> work well
> >>
> >>> for Section 508 evaluation. I can't help but feel we're not
> >>>
> >> asking the
> >>
> >>> right questions. DRM is bad for end-users, security typically
> >>> negatively impacts end-user experience, and accessibility
> >>>
> >> is all about
> >>
> >>> the user!
> >>> This discussion is really useful for questioning vendors
> >>>
> >> and how they
> >>
> >>> support our business/agency. I don't think finding
> >>>
> >> justification for
> >>
> >>> closed software means we should place a label on software
> >>>
> >> and treat it
> >>
> >>> any differently from any other software. Closed software
> should be
> >>> accessible and follow the same technical standards as any other
> >>> software.
> >>>
> >>> 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: Tuesday, December 19, 2006 12:45 PM
> >>> To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
> >>> Web/Software Subcommittee'
> >>> Cc: 'TEITAC General Interface Accessibility Subcommittee'
> >>> Subject: Re: [teitac-closed] "closed software"
> >>>
> >>>
> >>> Some possible examples of closed software.
> >>>
> >>> Maybe some things like: (numbered only to facilitate discussion)
> >>>
> >>> 1 - Software that for security reasons does not allow anything to
> >>> access what it has on screen and which reads keyboard registers
> >>> directly to avoid tampering or 'remote' typing.
> >>>
> >>> 2 - Software designed to run on a product without and operating
> >>> system.
> >>>
> >>> 3 - Software that has no API for AT - but instead has built in
> >>> accessibility since there is no AT vendor who will work with and
> >>> support the unique capability of the software because the
> market is
> >>> too small for AT vendors.
> >>>
> >>> 4 - Something like Randy pointed to (see just below). The
> >>>
> >> hardware is
> >>
> >>> not closed since new software can be loaded. But the
> >>> platform/software is closed.
> >>>
> >>> Gregg
> >>> -- ------------------------------
> >>> Gregg C Vanderheiden Ph.D.
> >>>

Previous message | Next message

From: Rex Lint
Date: Mon, Jan 08 2007 7:45 PM
Subject: Re: "closed software"

GV = Gregg
RL = Rex

GV:
" Not sure what "AT middleware is"."

RL:

My name for, lets say, a screen reader: It's not an "application" that does
work like a word processor.
It's not a utility, like NARRATOR, analogous to your 30-second door opener.
It's in the middle, between an application, the o/s and the user.

GV:

You asked
> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"

RL:

I didn't really ask this. I proposed that there were levels of
accessibility, just like you proposed different speeds of "door openers." I
said that if you accept the idea of different levels of accessibility, there
was an open question that we've been kicking around before, having to do
with providing hooks for AT but having no AT that took advantage of those
hooks and thereby provided access to the IT for people with disabilities.

Rex
---------

Rex Lint, Consultant
Chair, Section 508 Working Group
Information Technology Association of America
PH: 603-860-7651, FAX: 603-882-6612

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, January 08, 2007 6:25 PM
To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General Interface
Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
Cc: 'TEITAC self contained/closed products subcommittee'
Subject: Re: [teitac-closed][teitac-websoftware][teitac-general]"closed
software"

Not sure what "AT middleware is". You said you thought screen readers were
middleware. (not sure what a screen reader is in the middle of - unless
all interfaces are middleware.) so I'm not sure I'm understanding you. But
let me take a stab and see if I misunderstood.

You asked

> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"

If I understand the proposition you mean "Only" accessible through AT
correct? (if it was also directly accessible then there is not problem).
But if the product is not usable by people with disabilities except through
AT and there is no AT - then I don't see how we could call it accessible.
Certainly, anyone with a disability that was employed in a government job
that would now be using that software would have to find another job or go
create their own AT for the software it would seem.

Did I misunderstand?

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

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Rex Lint
> Sent: Monday, January 08, 2007 11:17 AM
> To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General
> Interface Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
> Cc: 'TEITAC self contained/closed products subcommittee'
> Subject: Re:
> [teitac-websoftware][teitac-general][teitac-closed]"closed software"
>
> Jim, Gregg, et. al.
>
> Many manufacturers include "Out of the Box" (OOTB)
> applications with their operating systems. These are not
> (necessarily) cutting edge, but intended to provide SOME
> level of access to functionality. An example is WORDPAD (I
> don't think they include NOTEPAD any more) by Microsoft, for
> simple, limited editing.
>
> Anyone who wants to do more than rudimentary editing would
> procure and use some other, robust application - a
> word-processor. WORD is one, and there are others. These
> feature-rich applications supplant the function of the OOTB
> application(s).
>
> Manufacturers have taken similar approaches to accessibility
> provisions.
> Take NARRATOR on XP. It's not for extensive use, it's for
> getting access to something on a VERY occasional basis. I
> think it's valuable because it gives the general public the
> vision that it's possible to hear the contents of a page
> instead of see it - good for simple demos about accessibility.
>
> I'm sure the same situation applies to the use of O/S "Out of the Box"
> accessibility utilities: people with specific disabilities
> will want to get really robust "middleware" to address their needs.
>
> So I see there is a range of software we're talking about in
> this thread -
>
> * Utilities intended for limited, infrequent use,
> * Applications that address the needs to accomplish a task
> * Middleware that sits between applications and the OS or
> applications and the user.
>
> I think AT like screen readers fall in the middleware class.
>
> I think a definition of AT that acknowledges this spectrum would be
> appropriate:
>
> Perhaps the utilities (particularly if done through a
> published API) could form the basis of one level, "built-in"
> perhaps, accessibility.
>
> Then compatibility with middleware-class AT (hopefully
> through the sendor-supplied published API) would be enough to
> make the product rise to a level classed as "accessible
> through AT." This approach would tend to make "built-in" AT
> less desirable than "accessible through AT," to people with
> disabilities.
>
> This leaves unaddressed the question of "What if a product is
> 'accessible through AT,' but there is no AT middleware
> available for it?"
>
> As Gregg would say, "Hmmmm...."
>
> Rex
>
>
> Rex Lint,
> Information Technology Association of America
> PH: 603-860-7651
>

Previous message | Next message

From: Peter Korn
Date: Mon, Jan 08 2007 8:10 PM
Subject: Re: "closed software"

Hi Rex,
> GV = Gregg
> RL = Rex
>
> GV:
> " Not sure what "AT middleware is"."
>
> RL:
>
> My name for, lets say, a screen reader: It's not an "application" that does
> work like a word processor.
> It's not a utility, like NARRATOR, analogous to your 30-second door opener.
> It's in the middle, between an application, the o/s and the user.
>
>

This distinction between NARRATOR and a commercial screen reader (one
being a "utility", the other "middleware") seems artificial to me.
While NARRATOR is not a full fledged full-featured application, it
doesn't follow that all built-in AT are likewise not full-fledged,
full-featured. For example, Apple's VoiceOver has far more features
than NARRATOR. The UNIX Orca screen reader likewise has a rich feature
set (and unlike NARRATOR and VoiceOver, work with the major office suite
on their platform). Do they remain "utilities" because they are
built-in? Or because they haven't crossed some threshold of functionality?

Also note, AT that comes with an OS can even be more full-featured than
commercial AT - the GNOME On-screen keyboard does far more than
commercial Windows products, and it ships with several UNIX OSes. And
the Dasher text-entry alternative for eye-gaze and head tracker users is
bundled with some UNIX releases, while it is a 3rd party download
(though a free one) for Windows and Macintosh. So is it a "utility" on
UNIX and "middleware" on Windows & Mac?

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> GV:
>
> You asked
>
>> This leaves unaddressed the question of "What if a product is
>> 'accessible through AT,' but there is no AT middleware
>> available for it?"
>>
>
> RL:
>
> I didn't really ask this. I proposed that there were levels of
> accessibility, just like you proposed different speeds of "door openers." I
> said that if you accept the idea of different levels of accessibility, there
> was an open question that we've been kicking around before, having to do
> with providing hooks for AT but having no AT that took advantage of those
> hooks and thereby provided access to the IT for people with disabilities.
>
>
> Rex
> ---------
>
> Rex Lint, Consultant
> Chair, Section 508 Working Group
> Information Technology Association of America
> PH: 603-860-7651, FAX: 603-882-6612
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
> Vanderheiden
> Sent: Monday, January 08, 2007 6:25 PM
> To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General Interface
> Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
> Cc: 'TEITAC self contained/closed products subcommittee'
> Subject: Re: [teitac-closed][teitac-websoftware][teitac-general]"closed
> software"
>
> Not sure what "AT middleware is". You said you thought screen readers were
> middleware. (not sure what a screen reader is in the middle of - unless
> all interfaces are middleware.) so I'm not sure I'm understanding you. But
> let me take a stab and see if I misunderstood.
>
> You asked
>
>
>> This leaves unaddressed the question of "What if a product is
>> 'accessible through AT,' but there is no AT middleware
>> available for it?"
>>
>
> If I understand the proposition you mean "Only" accessible through AT
> correct? (if it was also directly accessible then there is not problem).
> But if the product is not usable by people with disabilities except through
> AT and there is no AT - then I don't see how we could call it accessible.
> Certainly, anyone with a disability that was employed in a government job
> that would now be using that software would have to find another job or go
> create their own AT for the software it would seem.
>
> Did I misunderstand?
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Rex Lint
>> Sent: Monday, January 08, 2007 11:17 AM
>> To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General
>> Interface Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
>> Cc: 'TEITAC self contained/closed products subcommittee'
>> Subject: Re:
>> [teitac-websoftware][teitac-general][teitac-closed]"closed software"
>>
>> Jim, Gregg, et. al.
>>
>> Many manufacturers include "Out of the Box" (OOTB)
>> applications with their operating systems. These are not
>> (necessarily) cutting edge, but intended to provide SOME
>> level of access to functionality. An example is WORDPAD (I
>> don't think they include NOTEPAD any more) by Microsoft, for
>> simple, limited editing.
>>
>> Anyone who wants to do more than rudimentary editing would
>> procure and use some other, robust application - a
>> word-processor. WORD is one, and there are others. These
>> feature-rich applications supplant the function of the OOTB
>> application(s).
>>
>> Manufacturers have taken similar approaches to accessibility
>> provisions.
>> Take NARRATOR on XP. It's not for extensive use, it's for
>> getting access to something on a VERY occasional basis. I
>> think it's valuable because it gives the general public the
>> vision that it's possible to hear the contents of a page
>> instead of see it - good for simple demos about accessibility.
>>
>> I'm sure the same situation applies to the use of O/S "Out of the Box"
>> accessibility utilities: people with specific disabilities
>> will want to get really robust "middleware" to address their needs.
>>
>> So I see there is a range of software we're talking about in
>> this thread -
>>
>> * Utilities intended for limited, infrequent use,
>> * Applications that address the needs to accomplish a task
>> * Middleware that sits between applications and the OS or
>> applications and the user.
>>
>> I think AT like screen readers fall in the middleware class.
>>
>> I think a definition of AT that acknowledges this spectrum would be
>> appropriate:
>>
>> Perhaps the utilities (particularly if done through a
>> published API) could form the basis of one level, "built-in"
>> perhaps, accessibility.
>>
>> Then compatibility with middleware-class AT (hopefully
>> through the sendor-supplied published API) would be enough to
>> make the product rise to a level classed as "accessible
>> through AT." This approach would tend to make "built-in" AT
>> less desirable than "accessible through AT," to people with
>> disabilities.
>>
>> This leaves unaddressed the question of "What if a product is
>> 'accessible through AT,' but there is no AT middleware
>> available for it?"
>>
>> As Gregg would say, "Hmmmm...."
>>
>> Rex
>>
>>
>> Rex Lint,
>> Information Technology Association of America
>> PH: 603-860-7651
>>
>>
>
>

Previous message | Next message

From: David Poehlman
Date: Tue, Jan 09 2007 4:05 AM
Subject: Re: "closed software"

todays AT are often operating environments because of the
invasiveness of their results. They are middleware in the sense that
they take something passed to them and alter it for rendering or
interaction.

On Jan 8, 2007, at 10:00 PM, Peter Korn wrote:

Hi Rex,
> GV = Gregg
> RL = Rex
>
> GV:
> " Not sure what "AT middleware is"."
>
> RL:
>
> My name for, lets say, a screen reader: It's not an "application"
> that does
> work like a word processor.
> It's not a utility, like NARRATOR, analogous to your 30-second door
> opener.
> It's in the middle, between an application, the o/s and the user.
>
>

This distinction between NARRATOR and a commercial screen reader (one
being a "utility", the other "middleware") seems artificial to me.
While NARRATOR is not a full fledged full-featured application, it
doesn't follow that all built-in AT are likewise not full-fledged,
full-featured. For example, Apple's VoiceOver has far more features
than NARRATOR. The UNIX Orca screen reader likewise has a rich feature
set (and unlike NARRATOR and VoiceOver, work with the major office suite
on their platform). Do they remain "utilities" because they are
built-in? Or because they haven't crossed some threshold of
functionality?

Also note, AT that comes with an OS can even be more full-featured than
commercial AT - the GNOME On-screen keyboard does far more than
commercial Windows products, and it ships with several UNIX OSes. And
the Dasher text-entry alternative for eye-gaze and head tracker users is
bundled with some UNIX releases, while it is a 3rd party download
(though a free one) for Windows and Macintosh. So is it a "utility" on
UNIX and "middleware" on Windows & Mac?

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> GV:
>
> You asked
>
>> This leaves unaddressed the question of "What if a product is
>> 'accessible through AT,' but there is no AT middleware
>> available for it?"
>>
>
> RL:
>
> I didn't really ask this. I proposed that there were levels of
> accessibility, just like you proposed different speeds of "door
> openers." I
> said that if you accept the idea of different levels of
> accessibility, there
> was an open question that we've been kicking around before, having
> to do
> with providing hooks for AT but having no AT that took advantage of
> those
> hooks and thereby provided access to the IT for people with
> disabilities.
>
>
> Rex
> ---------
>
> Rex Lint, Consultant
> Chair, Section 508 Working Group
> Information Technology Association of America
> PH: 603-860-7651, FAX: 603-882-6612
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
> Vanderheiden
> Sent: Monday, January 08, 2007 6:25 PM
> To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General Interface
> Accessibility Subcommittee'; 'TEITAC Subpart A Subcommittee'
> Cc: 'TEITAC self contained/closed products subcommittee'
> Subject: Re: [teitac-closed][teitac-websoftware][teitac-
> general]"closed
> software"
>
> Not sure what "AT middleware is". You said you thought screen
> readers were
> middleware. (not sure what a screen reader is in the middle of -
> unless
> all interfaces are middleware.) so I'm not sure I'm understanding
> you. But
> let me take a stab and see if I misunderstood.
>
> You asked
>
>
>> This leaves unaddressed the question of "What if a product is
>> 'accessible through AT,' but there is no AT middleware
>> available for it?"
>>
>
> If I understand the proposition you mean "Only" accessible through AT
> correct? (if it was also directly accessible then there is not
> problem).
> But if the product is not usable by people with disabilities except
> through
> AT and there is no AT - then I don't see how we could call it
> accessible.
> Certainly, anyone with a disability that was employed in a
> government job
> that would now be using that software would have to find another
> job or go
> create their own AT for the software it would seem.
>
> Did I misunderstand?
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Rex Lint
>> Sent: Monday, January 08, 2007 11:17 AM
>> To: 'TEITAC Web/Software Subcommittee'; 'TEITAC General
>> Interface Accessibility Subcommittee'; 'TEITAC Subpart A
>> Subcommittee'
>> Cc: 'TEITAC self contained/closed products subcommittee'
>> Subject: Re:
>> [teitac-websoftware][teitac-general][teitac-closed]"closed software"
>>
>> Jim, Gregg, et. al.
>>
>> Many manufacturers include "Out of the Box" (OOTB)
>> applications with their operating systems. These are not
>> (necessarily) cutting edge, but intended to provide SOME
>> level of access to functionality. An example is WORDPAD (I
>> don't think they include NOTEPAD any more) by Microsoft, for
>> simple, limited editing.
>>
>> Anyone who wants to do more than rudimentary editing would
>> procure and use some other, robust application - a
>> word-processor. WORD is one, and there are others. These
>> feature-rich applications supplant the function of the OOTB
>> application(s).
>>
>> Manufacturers have taken similar approaches to accessibility
>> provisions.
>> Take NARRATOR on XP. It's not for extensive use, it's for
>> getting access to something on a VERY occasional basis. I
>> think it's valuable because it gives the general public the
>> vision that it's possible to hear the contents of a page
>> instead of see it - good for simple demos about accessibility.
>>
>> I'm sure the same situation applies to the use of O/S "Out of the
>> Box"
>> accessibility utilities: people with specific disabilities
>> will want to get really robust "middleware" to address their needs.
>>
>> So I see there is a range of software we're talking about in
>> this thread -
>>
>> * Utilities intended for limited, infrequent use,
>> * Applications that address the needs to accomplish a task
>> * Middleware that sits between applications and the OS or
>> applications and the user.
>>
>> I think AT like screen readers fall in the middleware class.
>>
>> I think a definition of AT that acknowledges this spectrum would be
>> appropriate:
>>
>> Perhaps the utilities (particularly if done through a
>> published API) could form the basis of one level, "built-in"
>> perhaps, accessibility.
>>
>> Then compatibility with middleware-class AT (hopefully
>> through the sendor-supplied published API) would be enough to
>> make the product rise to a level classed as "accessible
>> through AT." This approach would tend to make "built-in" AT
>> less desirable than "accessible through AT," to people with
>> disabilities.
>>
>> This leaves unaddressed the question of "What if a product is
>> 'accessible through AT,' but there is no AT middleware
>> available for it?"
>>
>> As Gregg would say, "Hmmmm...."
>>
>> Rex
>>
>>
>> Rex Lint,
>> Information Technology Association of America
>> PH: 603-860-7651
>>
>>
>
>

Previous message | Next message

From: David Poehlman
Date: Tue, Jan 09 2007 4:15 AM
Subject: Re: "closed software"

Previous message | Next message

From: Jim Tobias
Date: Tue, Jan 16 2007 5:07 PM
Subject: Re: "closed software"

Previous message | Next message

From: Jim Tobias
Date: Tue, Jan 16 2007 5:09 PM
Subject: Re: "closed software"

Previous message | Next message

From: Randy Marsden (Home)
Date: Tue, Jan 16 2007 5:09 PM
Subject: Re: "closed software"

Jim Â I see this is a repost from the same email sent on Dec 22nd. My
apologies for not responding back then.

WeÂ¹re starting to split hairs here, but technically I think the iPod could
be characterized as follows:

1. The iPod hardware is an example of open hardware, since there is a port
that allows 3rd party software to be loaded on the device (ie. Rock Box).
2. The iPod operating system as shipped from Apple is an example of closed
software, since it does not allow 3rd party application software or
assistive technology software to be loaded in addition to the existing
software that it ships with.

I think youÂ¹re accurate in drawing the analogy between the iPod hardware and
PC hardware. Loading Rock Box on an iPod is analogous to purchasing a PC
with Windows loaded, but then reformatting the hard drive and loading Linux
instead. Same PC Â different operating systems. So, in terms of
definition, I think you would still have to characterize the iPodÂ¹s software
as closed (but its hardware as open).

So what defines a product? Its hardware, its software, or the combination
of both? When the federal government purchases iPods for their employees to
use for training purposes, I assume they are thinking of the latter. If a
Department bids out and receives 500 computer running Windows, they donÂ¹t
expect some people to remove Windows and load Linux instead (or visa versa).
With respect to the iPod, they probably have little instruction manuals
written that say things like:

Â³To listen to module 1 of the training, navigate to the Music menu, select
Playlists, and choose ?Module 1Â¹Â².

I doubt there is an addendum to the manual that says:

Â³If you have a disability, back up all the content of the iPod, load the new
operating system called Rock Box by connecting a USB cable from your iPod to
your computer that is running the Rock Box installation software (which
youÂ¹ll need to obtain on-line), restore the content (and try to keep it in
the same order), and then find Module 1. And by the way, since there is no
text-to-speech engine that comes with Rock Box, you will need to find
?Module 1Â² by listening to each letter pronounced Â³mÂ², Â³oÂ², Â³dÂ², and so on.

This just doesnÂ¹t seem like an equitable solution for people with
disabilities. If the government hands them an iPod for training, it should
be accessible as-is, or with the addition of AT. Right now it isnÂ¹t, so I
would call that Â³closedÂ² (ie. Not accessible on its own, and not possible to
add AT that makes it accessible to people with disabilities).

-Randy

PS: Maybe the repost is because of the recent announcement of the iPhone,
which is also an iPod, and running OS X, which (I think) is open, and
completely changes my iPod argument! ;-) See how fast technology
changes...?

>
> From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
> Reply-To: TEITAC self contained/closed products subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Sat, 13 Jan 2007 10:01:39 -0500
> To: "'TEITAC Web/Software Subcommittee'" < = EMAIL ADDRESS REMOVED = >,
> "'TEITAC self contained/closed products subcommittee'"
> < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [teitac-closed] [teitac-websoftware] "closed software"
>

> Randy wrote, regarding iPods that it's an example of "closed software", even
> given David Poehlman's identification of "Rock Box" as alternative interface.
> I don't see how this is so.
>
> 1. iPods are designed to accept software upgrades from Apple, so they are not
> "closed" in that aspect, at least. Apple could somehow lock out all software
> changes that did not come thorough Apple themselves, but they appear not to
> have done that. Even in that case, the "closedness" would be by policy, not
> by technological feasibility.
>
> 2. "Rock Box" is an example of a third-party software solution to some
> accessibility issues that can be loaded onto an iPod. Assuming that the
> original iPod interface can be restored somehow, doesn't that make the iPod
> almost like a PC, able to run with or without a screen reader, not like a
> product
>
> ***********
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1.732.441.0831 v/tty
> skype jimtobias
> www.inclusive.com
>
>
>>
>> From: Randy Marsden [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Tuesday, December 19, 2006 6:46 PM
>> To: TEITAC Web/Software Subcommittee; TEITAC self contained/closed products
>> subcommittee
>> Subject: Re: [teitac-websoftware] "closed software"
>>
>> My iPod description given in emails yesterday is one such example.
>>
>> -Randy
>>>
>>> From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
>>> Reply-To: TEITAC Web/Software Subcommittee
>>> < = EMAIL ADDRESS REMOVED = >
>>> Date: Tue, 19 Dec 2006 07:55:58 -0500
>>> To: "'TEITAC self contained/closed products subcommittee'"
>>> < = EMAIL ADDRESS REMOVED = >, "'TEITAC Web/Software Subcommittee'"
>>> < = EMAIL ADDRESS REMOVED = >
>>> Subject: [teitac-websoftware] "closed software"
>>>
>>
>>> In the discussion of closed products, we seem to be converging on the
>>> opinion that "closed" is a characteristic, not a category. In this context,
>>> software has been mentioned as potentially closed. Can someone please give
>>> me an example, or a further explanation, of what closed software might be?
>>>
>>> ***********
>>> Jim Tobias
>>> Inclusive Technologies
>>> = EMAIL ADDRESS REMOVED =
>>> +1.732.441.0831 v/tty
>>> skype jimtobias
>>> www.inclusive.com
>>>
>>>

Previous message | Next message

From: Gregg Vanderheiden
Date: Tue, Jan 16 2007 5:11 PM
Subject: Re: "closed software"

I think this is a good example of how we need to think of 'closed' as a
condition - not as a type of software or hardware.

Anyone know more about the iphone? They said it was based on OS X but it
could be just a small version of it (like windows and windows mobile).

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

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy
Marsden (Home)
Sent: Saturday, January 13, 2007 10:32 AM
To: TEITAC self contained/closed products subcommittee; 'TEITAC Web/Software
Subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

Jim - I see this is a repost from the same email sent on Dec 22nd. My
apologies for not responding back then.

We're starting to split hairs here, but technically I think the iPod could
be characterized as follows:

1. The iPod hardware is an example of open hardware, since there is a
port that allows 3rd party software to be loaded on the device (ie. Rock
Box).
2. The iPod operating system as shipped from Apple is an example of
closed software, since it does not allow 3rd party application software or
assistive technology software to be loaded in addition to the existing
software that it ships with.

I think you're accurate in drawing the analogy between the iPod hardware and
PC hardware. Loading Rock Box on an iPod is analogous to purchasing a PC
with Windows loaded, but then reformatting the hard drive and loading Linux
instead. Same PC - different operating systems. So, in terms of
definition, I think you would still have to characterize the iPod's software
as closed (but its hardware as open).

So what defines a product? Its hardware, its software, or the combination
of both? When the federal government purchases iPods for their employees to
use for training purposes, I assume they are thinking of the latter. If a
Department bids out and receives 500 computer running Windows, they don't
expect some people to remove Windows and load Linux instead (or visa versa).
With respect to the iPod, they probably have little instruction manuals
written that say things like:

"To listen to module 1 of the training, navigate to the Music menu, select
Playlists, and choose 'Module 1'".

I doubt there is an addendum to the manual that says:

"If you have a disability, back up all the content of the iPod, load the new
operating system called Rock Box by connecting a USB cable from your iPod to
your computer that is running the Rock Box installation software (which
you'll need to obtain on-line), restore the content (and try to keep it in
the same order), and then find Module 1. And by the way, since there is no
text-to-speech engine that comes with Rock Box, you will need to find
'Module 1" by listening to each letter pronounced "m", "o", "d", and so on.

This just doesn't seem like an equitable solution for people with
disabilities. If the government hands them an iPod for training, it should
be accessible as-is, or with the addition of AT. Right now it isn't, so I
would call that "closed" (ie. Not accessible on its own, and not possible to
add AT that makes it accessible to people with disabilities).

-Randy

PS: Maybe the repost is because of the recent announcement of the iPhone,
which is also an iPod, and running OS X, which (I think) is open, and
completely changes my iPod argument! ;-) See how fast technology
changes...?

From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
Reply-To: TEITAC self contained/closed products subcommittee
< = EMAIL ADDRESS REMOVED = >
Date: Sat, 13 Jan 2007 10:01:39 -0500
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >, "'TEITAC self contained/closed
products subcommittee'" < = EMAIL ADDRESS REMOVED = >
Subject: Re: [teitac-closed] [teitac-websoftware] "closed software"

Randy wrote, regarding iPods that it's an example of "closed software", even
given David Poehlman's identification of "Rock Box" as alternative
interface. I don't see how this is so.

1. iPods are designed to accept software upgrades from Apple, so they are
not "closed" in that aspect, at least. Apple could somehow lock out all
software changes that did not come thorough Apple themselves, but they
appear not to have done that. Even in that case, the "closedness" would be
by policy, not by technological feasibility.

2. "Rock Box" is an example of a third-party software solution to some
accessibility issues that can be loaded onto an iPod. Assuming that the
original iPod interface can be restored somehow, doesn't that make the iPod
almost like a PC, able to run with or without a screen reader, not like a
product

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

_____

From: Randy Marsden [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, December 19, 2006 6:46 PM
To: TEITAC Web/Software Subcommittee; TEITAC self contained/closed products
subcommittee
Subject: Re: [teitac-websoftware] "closed software"

My iPod description given in emails yesterday is one such example.

-Randy

From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
Reply-To: TEITAC Web/Software Subcommittee
< = EMAIL ADDRESS REMOVED = >
Date: Tue, 19 Dec 2006 07:55:58 -0500
To: "'TEITAC self contained/closed products subcommittee'"
< = EMAIL ADDRESS REMOVED = >, "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Subject: [teitac-websoftware] "closed software"

In the discussion of closed products, we seem to be converging on the
opinion that "closed" is a characteristic, not a category. In this context,
software has been mentioned as potentially closed. Can someone please give
me an example, or a further explanation, of what closed software might be?

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

Previous message | Next message

From: Brett, Thomas F
Date: Tue, Jan 16 2007 5:11 PM
Subject: Re: "closed software"

The information that I have received is that there will be a 4 gig & 8 gig version, it will be modeled after the ipod meaning no key board, and it will act as a super cell phone with full internet access.

Tom Brett

Previous message | Next message

From: Jim Tobias
Date: Tue, Jan 16 2007 5:14 PM
Subject: Re: "closed software"

Randy wrote:
The iPod operating system as shipped from Apple is an example of closed
software, since it does not allow 3rd party application software or
assistive technology software to be loaded in addition to the existing
software that it ships with. I think you're accurate in drawing the analogy
between the iPod hardware and PC hardware. Loading Rock Box on an iPod is
analogous to purchasing a PC with Windows loaded, but then reformatting the
hard drive and loading Linux instead. Same PC - different operating
systems. So, in terms of definition, I think you would still have to
characterize the iPod's software as closed (but its hardware as open).

[JT] I'm not sure that what you're saying is technically accurate. Is it
impossible to retain iPod functionality and only change the user interface?
If you can still sync your iPod, search for a song, and have complete play
control, but instead of the original controls use a speech interface or a
scanning control with the same or external hardware, I'd say the iPod is
functioning more like a PC with an OS that has not been overridden, but
supplemented by an AT user interface.

More to the point, can't the feds *require* the latter: a base unit that
allows the loading (and unloading) of a more accessible user interface?
(This, of course, does not mean that someone has created such an interface
-- we still have the tricky issue of a mainstream product that meets the
standards but is only accessible if AT is used, and no such AT is
available.)

And over to an even stickier concept: what is the true purpose of the
procurement? Let's say that the feds are issuing iPods for training
purposes, exactly as suggested by Terry Weaver. It's access to that
training content that matters, right? Let's say the content is mp3. Any
accessible mobile device capable of playing mp3s should qualify. Shouldn't
the requirement be that the *content* is provided in an accessible format,
as long as there is a procurable accessible mobile player that can play that
format? What would happen if part of the procurement was the distribution
channel for the content: only distributed via iTunes?

This takes us into a concept related to the "value chain". It's another one
imported from the world of business analysis: "product ecosystem". That is,
where does a given product fit in the context of other products and wholly
other ways of achieving the same goal? They use the word "ecosystem"
because it matches certain concepts from biology: there are keystone
species, dominant species, competition, cooperation, evolution, niches....

To contrast "value chain" and "product ecosystem", consider the iPod value
chain for federal training. It includes the training content developer,
iTunes, computer hardware and software companies, iPod, retailers, end users
(and their supervisors and IT managers). The product ecosystem would have
to show all possible value chains (now shown as products rather than
companies) from the training content developer to the end users. Think of
all the ways the mp3 content could reach the user aside from the iPod chain:
CD, email attachment, broadcast, website download, website stream.... The
richness of ICT product ecosystems is stunning once you look at the *goals*
rather than the gadgets.

The upside of such a view is that it can be much more "efficient": rather
than requiring every product to include every accessibility feature, you
only need to guarantee a robust subset of chains (not just one) that offer
the full range of accessibility. The downsides are that:

1. you need to have really specific goals in mind
2. you need to guarantee the robustness of the chains
3. you need to monitor the market for rapid evolutionary changes (products
and product types entering and leaving)

Disability advocates may assume that such an approach is the same as the
rejected "product line" approach, which would have let companies create one
accessible product per product type, or that it is about accommodations, not
universal design. There are risks of both of those in a product ecosystem
approach, but they can be addressed.

Note that the tradeoff between the current "all products must be fully
accessible in and of themselves" regulatory approach and a goal-oriented
product ecosystem approach is that technical costs are traded for
information costs. That is, the myth of the current approach is that it's
feasible to put every accessibility feature in every product; the myth of
the product ecosystem approach is that it's feasible to find out the optimal
mix of products so that any given user's accessibility needs are addressed.
Perhaps this speaks to a hybrid approach, in which features that are "very
readily achievable" or "almost burdenless" are required to be universally
implemented, while others are considered within a goal-oriented framework.

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

Previous message | Next message

From: Gregg Vanderheiden
Date: Fri, Jan 19 2007 12:20 AM
Subject: Re: "closed software"

I think the concept of 'closed" is a good one in that it allows yet another
degree of innovation and flexibility. I agree that it should be an
'attribute' rather than a type of product since it is crosscutting. And
of course if you are closed then you need to build access in. As to being
hardware only. that might or might not be true depending on how we define
things.

We have an amazing number of really tough questions to cover.

Perhaps we should start with a bunch of examples or scenarios to map out the
territory.

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

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robinson,
Norman B - Washington, DC
Sent: Thursday, January 18, 2007 11:35 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

Joe,

I don't think having the distinction of "closed hardware" helps us at
all. But I advocate reorganizing the standards themselves in this regard. I
think there might be a place for this discussion in the preamble, but not in
the Section 508 technical standards themselves.

I think the self contained, closed products section really addresses is
hardware requirements. So I suggest the inclusion of all hardware related
functional requirements from all the other sections be consolidated along
with the hardware requirements in 1194.25 and call it "physical design
requirements".

As for the accessibility requirements of the software running on any
hardware, no matter what the form factor, the existing software standards
(or web standards specific to web content) applies.

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 Lazzaro,
Joe (ITD)
Sent: Monday, January 15, 2007 11:37 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

This may be a little radical, but do so called closed hardware devices
really have a place anymore? With the rapidly decreasing prices of
off-the-shelf hardware like PDAs and phones that support real operating
systems, why is industry building closed devices? It seems to me that a lot
of our problems could be solved if devices were open and able to accept
software applications, and assistive technology solutions as well.

At the very least, we could reload such closed devices with the operating
system, desktop, applications, and assistive technology that we choose.

Joe

Joe Lazzaro
Manager: Assistive Technology Group
Information Technology Division
Commonwealth of Massachusetts
One Ashburton Place
Room 1601
Boston, MA 02108
Voice: 617-626-4410
Email: = EMAIL ADDRESS REMOVED =
Web: www.Mass.gov/ITD

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Monday, January 15, 2007 10:53 AM
To: 'TEITAC self contained/closed products subcommittee'
Cc: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

Randy wrote:
The iPod operating system as shipped from Apple is an example of closed
software, since it does not allow 3rd party application software or
assistive technology software to be loaded in addition to the existing
software that it ships with. I think you're accurate in drawing the analogy
between the iPod hardware and PC hardware. Loading Rock Box on an iPod is
analogous to purchasing a PC with Windows loaded, but then reformatting the
hard drive and loading Linux instead. Same PC - different operating
systems. So, in terms of definition, I think you would still have to
characterize the iPod's software as closed (but its hardware as open).

[JT] I'm not sure that what you're saying is technically accurate. Is it
impossible to retain iPod functionality and only change the user interface?
If you can still sync your iPod, search for a song, and have complete play
control, but instead of the original controls use a speech interface or a
scanning control with the same or external hardware, I'd say the iPod is
functioning more like a PC with an OS that has not been overridden, but
supplemented by an AT user interface.

More to the point, can't the feds *require* the latter: a base unit that
allows the loading (and unloading) of a more accessible user interface?
(This, of course, does not mean that someone has created such an interface
-- we still have the tricky issue of a mainstream product that meets the
standards but is only accessible if AT is used, and no such AT is
available.)

And over to an even stickier concept: what is the true purpose of the
procurement? Let's say that the feds are issuing iPods for training
purposes, exactly as suggested by Terry Weaver. It's access to that
training content that matters, right? Let's say the content is mp3. Any
accessible mobile device capable of playing mp3s should qualify. Shouldn't
the requirement be that the *content* is provided in an accessible format,
as long as there is a procurable accessible mobile player that can play that
format? What would happen if part of the procurement was the distribution
channel for the content: only distributed via iTunes?

This takes us into a concept related to the "value chain". It's another one
imported from the world of business analysis: "product ecosystem". That is,
where does a given product fit in the context of other products and wholly
other ways of achieving the same goal? They use the word "ecosystem"
because it matches certain concepts from biology: there are keystone
species, dominant species, competition, cooperation, evolution, niches....

To contrast "value chain" and "product ecosystem", consider the iPod value
chain for federal training. It includes the training content developer,
iTunes, computer hardware and software companies, iPod, retailers, end users
(and their supervisors and IT managers). The product ecosystem would have
to show all possible value chains (now shown as products rather than
companies) from the training content developer to the end users. Think of
all the ways the mp3 content could reach the user aside from the iPod chain:
CD, email attachment, broadcast, website download, website stream.... The
richness of ICT product ecosystems is stunning once you look at the *goals*
rather than the gadgets.

The upside of such a view is that it can be much more "efficient": rather
than requiring every product to include every accessibility feature, you
only need to guarantee a robust subset of chains (not just one) that offer
the full range of accessibility. The downsides are that:

1. you need to have really specific goals in mind

2. you need to guarantee the robustness of the chains

3. you need to monitor the market for rapid evolutionary changes (products
and product types entering and leaving)

Disability advocates may assume that such an approach is the same as the
rejected "product line" approach, which would have let companies create one
accessible product per product type, or that it is about accommodations, not
universal design. There are risks of both of those in a product ecosystem
approach, but they can be addressed.

Note that the tradeoff between the current "all products must be fully
accessible in and of themselves" regulatory approach and a goal-oriented
product ecosystem approach is that technical costs are traded for
information costs. That is, the myth of the current approach is that it's
feasible to put every accessibility feature in every product; the myth of
the product ecosystem approach is that it's feasible to find out the optimal
mix of products so that any given user's accessibility needs are addressed.
Perhaps this speaks to a hybrid approach, in which features that are "very
readily achievable" or "almost burdenless" are required to be universally
implemented, while others are considered within a goal-oriented framework.

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

Previous message | Next message

From: Robinson, Norman B - Washington, DC
Date: Sat, Jan 20 2007 8:20 AM
Subject: Re: "closed software"

Gregg,

How does this allow another degree of innovation and flexibility? I
don't challenge you or your words on face value but I've experienced the
opposite.

In past experience the concept of "closed" has usually meant the
vendor or creator of the E&IT thinks they have special considerations
and they find ways to interpret them to mean the other existing
technical standards don't apply - in effect that only the self
contained, closed products provisions apply. The reference in 1194.25,
(c) back to software requirements doesn't seem to be clear to the
creators, when things go wrong.

Perhaps I'm phrasing this wrong. I do think some of the provisions
in the current section 1194.25 Self contained, closed products are good.
I don't think the label "self contained, closed products" is a useful
construct in how the standards are structured. I don't see how it helped
anyone innovate. I think the provisions should be relabeled "Hardware
Design Requirements" and the software related items should be
incorporated into the software accessibility standards.

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 19, 2007 2:07 AM
To: 'TEITAC Web/Software Subcommittee'
Cc: 'TEITAC self contained/closed products subcommittee'
Subject: Re: [teitac-closed] [teitac-websoftware] "closed
software"

I think the concept of 'closed" is a good one in that it allows
yet another degree of innovation and flexibility. I agree that it
should be an 'attribute' rather than a type of product since it is
crosscutting. And of course if you are closed then you need to build
access in. As to being hardware only... that might or might not be
true depending on how we define things.

We have an amazing number of really tough questions to cover.

Perhaps we should start with a bunch of examples or scenarios to
map out the territory.

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

Previous message | Next message

From: Gregg Vanderheiden
Date: Sat, Jan 20 2007 9:40 PM
Subject: Re: "closed software"

Hi Norman,

Not sure what "THIS" refers to.

If you mean the concept of "closed" as a property rather than type of
product. then all it means is that if a manufacturer makes a product that
is closed - they have to build access in. That leaves lots and lots of
room for innovation.

You said that 'closed' should only be on hardware and software should be
handled by software accessibility standards. If the hardware prevents
installation of AT then the software access standards (If you meant the AT
compatibility standards) have no effect or meaning. By software did you
mean any software in any product? Even the software in a copier? Or did
you just mean software installed on open hardware?

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

_____

From: Robinson, Norman B - Washington, DC
[mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, January 19, 2007 8:43 AM
To: = EMAIL ADDRESS REMOVED = ; TEITAC self contained/closed products subcommittee;
TEITAC Web/Software Subcommittee
Subject: RE: [teitac-closed] [teitac-websoftware] "closed software"

Gregg,

How does this allow another degree of innovation and flexibility? I
don't challenge you or your words on face value but I've experienced the
opposite.

In past experience the concept of "closed" has usually meant the vendor
or creator of the E&IT thinks they have special considerations and they find
ways to interpret them to mean the other existing technical standards don't
apply - in effect that only the self contained, closed products provisions
apply. The reference in 1194.25, (c) back to software requirements doesn't
seem to be clear to the creators, when things go wrong.

Perhaps I'm phrasing this wrong. I do think some of the provisions in
the current section 1194.25 Self contained, closed products are good. I
don't think the label "self contained, closed products" is a useful
construct in how the standards are structured. I don't see how it helped
anyone innovate. I think the provisions should be relabeled "Hardware Design
Requirements" and the software related items should be incorporated into the
software accessibility standards.

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 19, 2007 2:07 AM
To: 'TEITAC Web/Software Subcommittee'
Cc: 'TEITAC self contained/closed products subcommittee'
Subject: Re: [teitac-closed] [teitac-websoftware] "closed software"

I think the concept of 'closed" is a good one in that it allows yet another
degree of innovation and flexibility. I agree that it should be an
'attribute' rather than a type of product since it is crosscutting. And
of course if you are closed then you need to build access in. As to being
hardware only. that might or might not be true depending on how we define
things.

We have an amazing number of really tough questions to cover.

Perhaps we should start with a bunch of examples or scenarios to map out the
territory.

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

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robinson,
Norman B - Washington, DC
Sent: Thursday, January 18, 2007 11:35 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

Joe,

I don't think having the distinction of "closed hardware" helps us at
all. But I advocate reorganizing the standards themselves in this regard. I
think there might be a place for this discussion in the preamble, but not in
the Section 508 technical standards themselves.

I think the self contained, closed products section really addresses is
hardware requirements. So I suggest the inclusion of all hardware related
functional requirements from all the other sections be consolidated along
with the hardware requirements in 1194.25 and call it "physical design
requirements".

As for the accessibility requirements of the software running on any
hardware, no matter what the form factor, the existing software standards
(or web standards specific to web content) applies.

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 Lazzaro,
Joe (ITD)
Sent: Monday, January 15, 2007 11:37 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

This may be a little radical, but do so called closed hardware devices
really have a place anymore? With the rapidly decreasing prices of
off-the-shelf hardware like PDAs and phones that support real operating
systems, why is industry building closed devices? It seems to me that a lot
of our problems could be solved if devices were open and able to accept
software applications, and assistive technology solutions as well.

At the very least, we could reload such closed devices with the operating
system, desktop, applications, and assistive technology that we choose.

Joe

Joe Lazzaro
Manager: Assistive Technology Group
Information Technology Division
Commonwealth of Massachusetts
One Ashburton Place
Room 1601
Boston, MA 02108
Voice: 617-626-4410
Email: = EMAIL ADDRESS REMOVED =
Web: www.Mass.gov/ITD

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Monday, January 15, 2007 10:53 AM
To: 'TEITAC self contained/closed products subcommittee'
Cc: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

Randy wrote:
The iPod operating system as shipped from Apple is an example of closed
software, since it does not allow 3rd party application software or
assistive technology software to be loaded in addition to the existing
software that it ships with. I think you're accurate in drawing the analogy
between the iPod hardware and PC hardware. Loading Rock Box on an iPod is
analogous to purchasing a PC with Windows loaded, but then reformatting the
hard drive and loading Linux instead. Same PC - different operating
systems. So, in terms of definition, I think you would still have to
characterize the iPod's software as closed (but its hardware as open).

[JT] I'm not sure that what you're saying is technically accurate. Is it
impossible to retain iPod functionality and only change the user interface?
If you can still sync your iPod, search for a song, and have complete play
control, but instead of the original controls use a speech interface or a
scanning control with the same or external hardware, I'd say the iPod is
functioning more like a PC with an OS that has not been overridden, but
supplemented by an AT user interface.

More to the point, can't the feds *require* the latter: a base unit that
allows the loading (and unloading) of a more accessible user interface?
(This, of course, does not mean that someone has created such an interface
-- we still have the tricky issue of a mainstream product that meets the
standards but is only accessible if AT is used, and no such AT is
available.)

And over to an even stickier concept: what is the true purpose of the
procurement? Let's say that the feds are issuing iPods for training
purposes, exactly as suggested by Terry Weaver. It's access to that
training content that matters, right? Let's say the content is mp3. Any
accessible mobile device capable of playing mp3s should qualify. Shouldn't
the requirement be that the *content* is provided in an accessible format,
as long as there is a procurable accessible mobile player that can play that
format? What would happen if part of the procurement was the distribution
channel for the content: only distributed via iTunes?

This takes us into a concept related to the "value chain". It's another one
imported from the world of business analysis: "product ecosystem". That is,
where does a given product fit in the context of other products and wholly
other ways of achieving the same goal? They use the word "ecosystem"
because it matches certain concepts from biology: there are keystone
species, dominant species, competition, cooperation, evolution, niches....

To contrast "value chain" and "product ecosystem", consider the iPod value
chain for federal training. It includes the training content developer,
iTunes, computer hardware and software companies, iPod, retailers, end users
(and their supervisors and IT managers). The product ecosystem would have
to show all possible value chains (now shown as products rather than
companies) from the training content developer to the end users. Think of
all the ways the mp3 content could reach the user aside from the iPod chain:
CD, email attachment, broadcast, website download, website stream.... The
richness of ICT product ecosystems is stunning once you look at the *goals*
rather than the gadgets.

The upside of such a view is that it can be much more "efficient": rather
than requiring every product to include every accessibility feature, you
only need to guarantee a robust subset of chains (not just one) that offer
the full range of accessibility. The downsides are that:

1. you need to have really specific goals in mind

2. you need to guarantee the robustness of the chains

3. you need to monitor the market for rapid evolutionary changes (products
and product types entering and leaving)

Disability advocates may assume that such an approach is the same as the
rejected "product line" approach, which would have let companies create one
accessible product per product type, or that it is about accommodations, not
universal design. There are risks of both of those in a product ecosystem
approach, but they can be addressed.

Note that the tradeoff between the current "all products must be fully
accessible in and of themselves" regulatory approach and a goal-oriented
product ecosystem approach is that technical costs are traded for
information costs. That is, the myth of the current approach is that it's
feasible to put every accessibility feature in every product; the myth of
the product ecosystem approach is that it's feasible to find out the optimal
mix of products so that any given user's accessibility needs are addressed.
Perhaps this speaks to a hybrid approach, in which features that are "very
readily achievable" or "almost burdenless" are required to be universally
implemented, while others are considered within a goal-oriented framework.

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

Previous message |

From: Gregg Vanderheiden
Date: Sat, Jan 20 2007 11:00 PM
Subject: Re: "closed software"

This is in response to the question about what constitutes closed software -
and if there are examples beyond DRM and Operational security like voting.
Good questions.

1. I would think that any software that doesn't have a published API
that provides access to all information, and ability to control all function
from software, would be closed.

2. I think the question isn't "closed" or 'not closed'. I think we
should move away from the term closed, and instead use: "works with AT
that the users will have." That is simple, meaningful and understandable.
"closed" is none of those.

3. Other software closed by policy? Any software in a system that
doesn't allow installation of software except by administrator and the
administrator won't allow installation of user's AT. Libraries, college
computer labs etc. If the labs ALREADY have AT installed, then the
software on the systems is closed but accessible. But before we get all
bundled up about whether this is hardware or software accessibility that is
closed by policy - I would refer back to my point #2 above. I think we
should get away from the term "closed".

Also, as long as we are trying to label parts of a system (rather than the
whole system) as being open or closed or whatever - we can argue it both
ways. But components by themselves can be used nor assessed. They can
only be assessed in the context they are used. If software is a product
that will be run on an open PC then that is how it should be assessed. If
it will be run on a locked down kiosk then it would need access built in

My thoughts.

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

_____

From: Jim Tobias [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, January 19, 2007 6:54 AM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Web/Software Subcommittee'
Subject: RE: [teitac-websoftware] [teitac-closed] "closed software"

I think we've already agreed to an important distinction between "closed for
reasons of technical or commercial feasibility" and "closed for policy
reasons". I can think of examples of software that are closed for policy
reasons:

1. Digital rights management (DRM), where some proprietary information
(usually music, video, etc., or the rights to use the software itself) is
safeguarded against unauthorized use. Is it necessary or useful to break
this category down further? For example, the *content* itself can be closed
by using encryption or a proprietary file format. Or the *player* acts as
gatekeeper, either using some file metadata or other technique to permit
access to the content. In either of these cases, I cannot see why the
federal government could not require openness, especially where the content
(in the employee training example Terry Weaver gave us) is already either
created or licensed by the government itself. Any examples?

2. Operational security, like voting systems, where concerns about the
integrity of the results (back end) have trumped flexibility in the
interface (front end) and somehow it was judged infeasible to keep them
separate. I'd like to hear from those who were involved in the Voluntary
Voting System Guidelines (VVSG) work, whether they think we should be guided
by VVSG.

http://www.eac.gov/vvsg_intro.htm

Are there other types of software closed by policy?

I cannot think of any software that is closed by technical or commercial
feasibility. I think we have a false analogy between hardware and software
here. While there are hardware products that lack any connectivity (e.g.
calculators) for reasons of technical/commercial feasibility, software is by
its nature more adaptable to interconnection, and not subject to the iron
laws of manufacturing costs. That is, in the first case it may not be
burdensome to add a few lines of code that place some data into a location
where it can be read by another software process. In the second case, once
that code has been written there may be no additional cost to install it in
every instance where it needs to run.

It seems to me that the serious efforts being made at an Accessibility API
are software openness is technically and commercially feasible. Can anyone
think of counterexamples relevant to the case of federal procurement?

Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias

_____

From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, January 19, 2007 2:07 AM
To: 'TEITAC Web/Software Subcommittee'
Cc: 'TEITAC self contained/closed products subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

I think the concept of 'closed" is a good one in that it allows yet another
degree of innovation and flexibility. I agree that it should be an
'attribute' rather than a type of product since it is crosscutting. And
of course if you are closed then you need to build access in. As to being
hardware only. that might or might not be true depending on how we define
things.

We have an amazing number of really tough questions to cover.

Perhaps we should start with a bunch of examples or scenarios to map out the
territory.

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

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robinson,
Norman B - Washington, DC
Sent: Thursday, January 18, 2007 11:35 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

Joe,

I don't think having the distinction of "closed hardware" helps us at
all. But I advocate reorganizing the standards themselves in this regard. I
think there might be a place for this discussion in the preamble, but not in
the Section 508 technical standards themselves.

I think the self contained, closed products section really addresses is
hardware requirements. So I suggest the inclusion of all hardware related
functional requirements from all the other sections be consolidated along
with the hardware requirements in 1194.25 and call it "physical design
requirements".

As for the accessibility requirements of the software running on any
hardware, no matter what the form factor, the existing software standards
(or web standards specific to web content) applies.

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 Lazzaro,
Joe (ITD)
Sent: Monday, January 15, 2007 11:37 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

This may be a little radical, but do so called closed hardware devices
really have a place anymore? With the rapidly decreasing prices of
off-the-shelf hardware like PDAs and phones that support real operating
systems, why is industry building closed devices? It seems to me that a lot
of our problems could be solved if devices were open and able to accept
software applications, and assistive technology solutions as well.

At the very least, we could reload such closed devices with the operating
system, desktop, applications, and assistive technology that we choose.

Joe

Joe Lazzaro
Manager: Assistive Technology Group
Information Technology Division
Commonwealth of Massachusetts
One Ashburton Place
Room 1601
Boston, MA 02108
Voice: 617-626-4410
Email: = EMAIL ADDRESS REMOVED =
Web: www.Mass.gov/ITD

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Monday, January 15, 2007 10:53 AM
To: 'TEITAC self contained/closed products subcommittee'
Cc: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

Randy wrote:
The iPod operating system as shipped from Apple is an example of closed
software, since it does not allow 3rd party application software or
assistive technology software to be loaded in addition to the existing
software that it ships with. I think you're accurate in drawing the analogy
between the iPod hardware and PC hardware. Loading Rock Box on an iPod is
analogous to purchasing a PC with Windows loaded, but then reformatting the
hard drive and loading Linux instead. Same PC - different operating
systems. So, in terms of definition, I think you would still have to
characterize the iPod's software as closed (but its hardware as open).

[JT] I'm not sure that what you're saying is technically accurate. Is it
impossible to retain iPod functionality and only change the user interface?
If you can still sync your iPod, search for a song, and have complete play
control, but instead of the original controls use a speech interface or a
scanning control with the same or external hardware, I'd say the iPod is
functioning more like a PC with an OS that has not been overridden, but
supplemented by an AT user interface.

More to the point, can't the feds *require* the latter: a base unit that
allows the loading (and unloading) of a more accessible user interface?
(This, of course, does not mean that someone has created such an interface
-- we still have the tricky issue of a mainstream product that meets the
standards but is only accessible if AT is used, and no such AT is
available.)

And over to an even stickier concept: what is the true purpose of the
procurement? Let's say that the feds are issuing iPods for training
purposes, exactly as suggested by Terry Weaver. It's access to that
training content that matters, right? Let's say the content is mp3. Any
accessible mobile device capable of playing mp3s should qualify. Shouldn't
the requirement be that the *content* is provided in an accessible format,
as long as there is a procurable accessible mobile player that can play that
format? What would happen if part of the procurement was the distribution
channel for the content: only distributed via iTunes?

This takes us into a concept related to the "value chain". It's another one
imported from the world of business analysis: "product ecosystem". That is,
where does a given product fit in the context of other products and wholly
other ways of achieving the same goal? They use the word "ecosystem"
because it matches certain concepts from biology: there are keystone
species, dominant species, competition, cooperation, evolution, niches....

To contrast "value chain" and "product ecosystem", consider the iPod value
chain for federal training. It includes the training content developer,
iTunes, computer hardware and software companies, iPod, retailers, end users
(and their supervisors and IT managers). The product ecosystem would have
to show all possible value chains (now shown as products rather than
companies) from the training content developer to the end users. Think of
all the ways the mp3 content could reach the user aside from the iPod chain:
CD, email attachment, broadcast, website download, website stream.... The
richness of ICT product ecosystems is stunning once you look at the *goals*
rather than the gadgets.

The upside of such a view is that it can be much more "efficient": rather
than requiring every product to include every accessibility feature, you
only need to guarantee a robust subset of chains (not just one) that offer
the full range of accessibility. The downsides are that:

1. you need to have really specific goals in mind

2. you need to guarantee the robustness of the chains

3. you need to monitor the market for rapid evolutionary changes (products
and product types entering and leaving)

Disability advocates may assume that such an approach is the same as the
rejected "product line" approach, which would have let companies create one
accessible product per product type, or that it is about accommodations, not
universal design. There are risks of both of those in a product ecosystem
approach, but they can be addressed.

Note that the tradeoff between the current "all products must be fully
accessible in and of themselves" regulatory approach and a goal-oriented
product ecosystem approach is that technical costs are traded for
information costs. That is, the myth of the current approach is that it's
feasible to put every accessibility feature in every product; the myth of
the product ecosystem approach is that it's feasible to find out the optimal
mix of products so that any given user's accessibility needs are addressed.
Perhaps this speaks to a hybrid approach, in which features that are "very
readily achievable" or "almost burdenless" are required to be universally
implemented, while others are considered within a goal-oriented framework.

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

WebAIM is an initiative of: