Thread Subject: Re: "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.

From: Gregg Vanderheiden
Date: Sat, Jan 20 2007 9:35 PM

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

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