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: Tom Brett
Date: Fri, Feb 23 2007 7:55 AM

Well, in fact, current 508 does not address any type of disability.



".would not have worked in the particular situation because they don't
support the level of customization needed in that situation."



Can you elaborate on this? I'd be interested in knowing the type of
customization that would be needed.





_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jonathan
Avila
Sent: Friday, February 23, 2007 9:47 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"



The current 508 standards don't address the needs of deaf-blind or people
with multiple disabilities. As far as JAWS, I was talking about it in a
particular example. In the example, JAWS was simply used as the screen
reader but do to the simplicity of the kiosk no knowledge of a screen reader
was required. Other screen readers like Window Eyes would not have worked
in the particular situation because they don't support the level of
customization needed in that situation.



Jonathan



_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
Sent: Friday, February 23, 2007 8:03 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

I believe that most of the subcommittee uses Jaws generically that means a
screen reader. It is, however in my opinion, not good practice to specify a
specific product when writing standards. Assistive technology is a personal
preference. Many individuals do not like jaws because of the number of key
combinations that are required to be retained. Developers of
software/hardware products need to be directed to develop those product to
standards and not to a specific assistive technology product.



Talking closed products would permit the blind to utilize them but there is
still those who are Deaf-Blind.







_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Smith,
Jamie
Sent: Friday, February 23, 2007 7:28 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"



I think you are talking about speech and are using a product name. JAWS is
one type of speech. Folks that use say Window Eyes would not necessarily
have the skills to use JAWS. One must learn the program. I feel that if a
specific speech product were "built in" that there would end up being the
same issues that Microsoft had regarding the monopoly issue.

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, February 23, 2007 12:48 AM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

Hmmm. Not sure I understand your point.



If a kiosk has jaws built in - then it has built in access - which is what
closed products must have.



You wouldn't want a windows XP based kiosk to be called accessible (or
conformant) if it DIDN'T have jaws installed or any other built in access
would you? If we don't have a concept of 'closed' with rules about built
in access then you could find that you have a fare machine, an ATM, a kiosk,
an information directory all of which run on XP and all of which would work
with a screen reader if you installed one - but none have one installed and
you can't open the devices to install one. But they would be called
accessible without having to install any access.



Again, if you DID install a screen reader etc for access then they would
meet the closed system requirements that accessibility was built into the
product.



Make sense now? Or am I missing your point?




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






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jonathan
Avila
Sent: Thursday, February 22, 2007 1:23 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "closed software"

<quote> 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. </quote>



I have to disagree with the definition of closed. A closed product could be
kiosk with JAWS installed on Windows XP. The user isn't able to install
different AT but the system is using a standard platform and APIs and AT.



I think we should ge rid of the word "closed" altogether.



Jonathan




_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Saturday, January 20, 2007 11:25 PM
To: 'Robinson, Norman B - Washington, DC'; 'TEITAC self contained/closed
products subcommittee'; 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] [teitac-closed] "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.


_____

size=2 width="100%" align=center tabIndex=-1>

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







Please take a few minutes to provide feedback on the quality of service you
received. The Department of Education values your feedback as a customer.
Commissioner John L. Winn is committed to continuously assessing and
improving the level and quality of services provided to you by Department
staff. Simply click on this link to the "DOE Customer Survey". Thank you in
advance for completing the survey.

DOE
<http://data.fldoe.org/cs/default.cfm?staff= = EMAIL ADDRESS REMOVED = |07:27:
56%20Fri%2023%20Feb%202007> Customer Survey

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