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: Robinson, Norman B - Washington, DC
Date: Wed, Dec 27 2006 1:35 PM

Peter,

I just wanted to state the security requirement is a business
requirement that in most likelihood can be clearly documented and would
be covered by fundamental alteration if no other technical solution
currently exists. Or consider stronger ties to 1194.21(b) and they
shouldn't interfere with assistive technology.

There is no such thing as "closed software". For me, the security
issues, including related issues such as digital rights management (DRM)
are NOT closed product (software) issues. They are often at odds with
accessibility (and basic user expectations for that matter). It is
usually a usability issue (we are all restricted equally regardless of
our abilities) or freedom of use issue if you prefer. Yes I could use
the word closed in conversation, restrictive works better, but not in
the context of Section 508.

I suggest the definition of "self-contained, closed products" be changed
to simply "Closed product hardware". There are many self-contained
products that can be upgraded, updated, and contain a full operating
system and hardware capable of providing full function accessibility. I
think the final definition should be "Products commonly designed in such
a fashion that a user cannot easily attach or install assistive
technology. These products include, but are not limited to, information
kiosks, printers, and other similar non-standard hardware products where
accessibility must be designed into the product by the manufacturer."

What happens when the user can install assistive technology but the
product is not accessible? Well, it isn't closed if the user can install
assistive technology! All the other provisions of Section 508 technical
standards apply.

You'll note two concepts. One, hardware. Two, accessibility must be
designed in.

I also advocate 1194.26 Desktop and portable computers and the 1194.23
Telecommunications products (a) & (h) &(k) section be merged with
1194.25 "Closed product hardware" and simply be called "Hardware
Technical Standards". Sorry for thinking outside the box <grins>.(note
comment below signature)

Regards,


Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246

P.S. I advocate the above approach generically to software and web too.
Functional performance criteria (1194.31) maps to "Hardware" and then to
specific section "Closed product hardware". Functional performance
criteria also maps to Software (1194.21) and then specifically web
browser software (1194.22). It isn't perfect, some of the "technical
standards" are actually functional criteria, but together we can work it
all out.


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Tuesday, December 19, 2006 3:22 PM
To: TEITAC Web/Software Subcommittee
Cc: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
General Interface Accessibility Subcommittee'
Subject: Re: [teitac-closed] [teitac-websoftware] "closed software"


Hi Jim, Gregg,

To expand on Gregg's answer #1 to your question about closed software:

> Some possible examples of closed software.
>
> Maybe some things like: (numbered only to facilitate discussion)
>
> 1 - Software that for security reasons does not allow anything to
access
> what it has on screen and which reads keyboard registers directly to
avoid
> tampering or 'remote' typing.
>

Sun's Trusted Solaris 9 - and especially the "multi-level/multi-label
security mode" is a real life example of this. In order to ensure the
highest levels of security for sales to customers like the National
Security Agency, Trusted Solaris goes to great lengths to ensure that
applications are siloed apart from one another. Applications cannot get

access to the keyboard or mouse directly - they only have very limited
access when that particular application is focused.


By the way, we are working on explicitly supporting accessibility in
forthcoming versions of Trusted Solaris - through accessibility APIs
that can only be used by AT software that has been explicitly installed
and given the privileges to have that API level of access to other
applications. For such security sensitive environments, we see
absolutely no other approach that meet both security & accessibility
requirements.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

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