Thread Subject: more on the "closed" issue

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: Thu, Apr 26 2007 8:25 AM

I apoligize for the long delay in replying. I'm going to try to streamline
some of this
content; I hope Peter thinks I've done it fairly.

I also want to make it clear that we are using the iPod only as an example
of a product, and that
neither the iPod nor Apple is being criticized in any way.

On the issue of loading a different OS and screen reader onto an iPod, Peter
wrote:
> Fundamentally a "Windows PC" that has a screen reader added is still a
Windows PC. The screen reader
> uses the OS services of Windows; it isn't talking directly to the bare
metal."

I think iPod Linux isn't talking to the bare metal either. The problem is,
when one entity
makes both the "OS" and the "app", and holds the technical details close,
defining the boundary
between the OS and the app can be tricky. Do we want to get into those
definitions?

Let's remember that one original impetus for defining a product as "closed"
was that it
was a public device (e.g. ATM) to which no hardware could be attached or
software loaded
for security reasons. That is, even if the ATM was running a conventional
OS, 508 was not going
to require that a user could come along and install AT onto it.

But in this case, we are talking about a personal use device. Should we
want to limit what
a user can do to something that they own, and are perhaps the sole user of?
As the folks at
MAKE magazine say, "If you can't open it, you don't own it". I recognize
that there may be
support and warranty issues, but those can be addressed without eliminating
the heretofore
essential efforts of AT explorers and entrepreneurs to improve the
accessibility of
mainstream products.

Peter wrote:
> And the iPod isn't trying to be a general purpose handheld
> device - the only thing you are expected (and warranted) to
> load onto it is data - songs, notes, etc. Not software of
> any sort, let alone a replacement OS.

What you're saying is true, until the manufacturer decides to do something
else
with the product. The first iPods couldn't do video; now they can.
Companies have made,
and will continue to make, decisions about the "arc" of their products based
on their
own strategies. Those strategies will address accessibility somewhat, but
rarely will
it be a major driver; at least, that's been the experience up till now. We
have been
able to rely on AT only when the product has been more or less open, and
when the company
has shared information about its technologies with developers.

Peter wrote:
> I really don't think "ease of replacement/restoration" makes
> any sense as a measure here.

I agree that Gregg's suggestion is a better measure -- is the basic
functionality
still there. In this case, is the modified iPod still a portable audio
player? We're talking
about third-party efforts to improve the interface. As an example, the
native iPod
mode for recording voice messages is 8K sampling, pretty low quality. Linux
iPod
runs up to 96K. It could be argued that for hard of hearing people, 8K is
unacceptable.
Which is the "better" solution, to require Apple to change the feature, or
to allow users to
install Linux iPod? From the perspective of a federal procurement, either
or both
could be required. It's up to us to provide guidance on that.

As an aside, I have learned that it is easy to toggle between Pixo and
Linux:
http://www.macworld.com/2005/05/secrets/julygeekfactor/; scroll to the
bottom.

Peter wrote:
> Also, you note that Pixo is the OS (today) underlying the
> iPod, and ask
> whether anything changes if someone writes a screen reader for Pixo.
> But unlike the "iPAQ with Windows Mobile", Pixo isn't a defining
> characteristic of the iPod - anymore than a BMW being defined
> by VANOS
> (the BMW engine management system; you don't know or care about the
> engine management software, and if BMW were to change that, the car
> would remain a BMW; if someone were to replace the engine with a Ford
> engine, it would stop being a BMW).

I'm sure there are people who think that users shouldn't know or care
about the underlying technology of the products they own. It's just not
the case, however. A certain small segment of users are interested, and
they have made the preponderance of contributions to accessible ICT, both
AT and mainstream. It could even be argued that these user/developers have
driven much of the current ICT development in totality, not just regarding
accessibility. Do we want to create policy that, by ratifying Company A's
rights to define products as closed, limits Company B's ability to innovate?

I don't understand your examples. Gearheads do fiddle with automobile OS's,
usually to install performance-enhancing software features. Moreover, doing

this does not always void all parts of the warranty, especially when the
feature
in question is found in the manufacturer's OS in another country. And
people
do swap out all kinds of auto components; a lively aftermarket in
carburetors,
for example, could be credited not only with some outrageous street rods,
but
also with driving innovation.

I think the real potential problem here is if BWM decides to begin marketing
gasoline, first suggesting that "for best results, use only BMW fuels", and
then requiring it as a condition of the warranty. We know that such
vertical
integration is great for the company that pulls it off, but terrible for
other
companies, the economy, and consumers.

Peter wrote:
> Finally, you suggest that "a difficult and irreversible
> change would not
> alter the fact that the *hardware* product would have to be
> described as
> "open", compared to a typical calculator, for which such a
> change would
> be technically infeasible." The trouble with that logic is
> the notion
> that one might sell such hardware devoid of an OS, or that the vendor
> might design the product to not be open (you have to go through a
> number of warranty-voiding steps to run Linux on the iPod).

We are dealing here with a large customer, the federal government, and what
the policy of that customer should be. I would argue that the federal
government
could require maximal "openness" such that if the accessibility features of
the product as delivered were deemed insufficiently effective at allowing
comparable access, that the product be able to load and run additional
accessibility utilities or features, with exclusions as necessary to protect
the mainstream company from non-standard AT approaches, and an exclusion for
simple products like a basic (not HP-41c!) calculators.


> Finally, to your two numbered concerns:
>
> "1. That we not abuse the concept of an OS. If one company makes the
> hardware, the OS,
> and the application software, and constrains all changes to
> the latter
> two such that the company itself is the only party legally
> permitted to
> alter them, is that an OS?"
>
> I believe in this example, the product is a closed product -
> closed by
> design (vs. by policy). That it has a formal OS inside, application
> software, etc., doesn't change the fact that it is closed.
> It makes no
> sense to me to apply accessibility regulations to an OS that may be
> embedded within it - so I agree with you here on not abusing
> the term "OS".

"Closed by design" is not necessarily distinct from "closed by policy",
or "closed by strategy".

But I think the problem here is more than just a definition. "Closed"
products
are proliferating, and not only because of technological change. Companies
are, as always, trying to maximize their portion of the value of a product.
One way they do this is by excluding other value adders except as partners.
This is a
hotly debated trend. We see it in the debate over net neutrality; we also
see it in the dispute over what software can be loaded on a mobile phone.
In
both cases an "incumbent" company wants to have gatekeeper rights.

Imagine a nightmare scenario: all ICT products are single function products,
and they are all "closed". There are no general purpose computers. There
are no third party developers, except under contractual arrangement with the
dominating manufacturers.

What are the implications for accessibility? Manufacturers will install
certain
accessibility features, or arrange relationships with selected AT vendors so
that those aftermarket products can be installed. I don't think it's
possible
to argue that such a scenario would provide as much accessibility as the
current
environment does.

Peter wrote:
> Without question, we need to keep in mind a distinction between being
> closed from the manufacturer and closed by policy. But by policy, I
> mean by policy of those deploying the product (e.g. in a
> library, where
> by policy making any modification is a violation of library policy).

I agree that agencies should not automatically be allowed to limit
accessibility on behalf of other motivating factors like network
security. In the same spirit, I think the 508 regulations should
make it clear that vendors should not limit accessibility either.

Peter wrote:
> "technical infeasibility" is a new term to accessibility regulatory
> discussion, and I don't think we should try to use it. Virtually
> anything can be done with technology given enough money and
> time. But
> that doesn't make it "readily achievable" - a term that does
> have a long
> history in accessibility regulation, and moreover the term
> that I think
> it is appropriate for us to use here.

"Readily achievable" is the 255 standard; "undue burden" is 508. "Undue
burden" is more stringent; it doesn't matter that 508 applies to the agency
while 255 applies to industry because both are supposed to provide guidance
about the
degree of effort and expense to be used in achieving accessibility. They
both take into account limits in "money and time".

> By demonstration, adding a screen reader to Windows (or Macintosh or
> Solaris) is readily achievable. Likewise adding a screen reader to a
> number of Windows Mobile devices. That is not the case with
> a myriad of
> consumer electronics devices today.

This is somewhat circular reasoning. The more open and publicly available
the necessary developer information is, the less expensive is the effort in
developing an accessibility solution. That is, a universal or
easy-to-port-to
OS or platform means more, better, faster, cheaper accessibility from third
parties.

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