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: Jim Tobias
Date: Tue, Jan 16 2007 5:15 PM

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