Thread Subject: Re: "closedsoftware"

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 10:55 PM

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:
Center for Persons with Disabilities (CPD) Utah State University