Thread Subject: Re: "closed software"
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.
Yes, if the hardware prevents installation of assistive technology
then the vendor has to build access in. When they do that they should
follow the software accessibility standards. Even if the software is in
a copier the user interface may be different (e.g., a 50 by 20 digital
display) but the software standards can be used as guidance and to
verify against for accessibility.
To elaborate, 1194.21 Software applications and operating systems
(a): When software is designed to run on a system that has a keyboard,
product functions shall be executable from a keyboard where the function
itself or the result of performing a function can be discerned
My printer has the following buttons (to which I'm alluding to
having a keyboard) as "Sleep" "Start" "Stop" "arrow keys" and a numeric
pad zero through 9, labeled with alpha characters the same as on the
phone pad (e.g., #2 has A, B, C; #3 had D, E, F; etc.). The printer is
running software internally. The buttons are the keyboard. The functions
available on the display are navigable using the keys. The display is
textual. I expect status on the display to follow the rest of the
software standards as well.
- well-defined on-screen indication of current focus (c); does this
via highlighting the menu item.
- info. conveyed by image is available in text (d); the paper jam
symbol is spelled out in text.
- the paper jam symbol is used in the same fashion (e)
- text information isn't provided to be accessed by assistive
technology (f) doesn't apply.
- there is only one application, the printer control software
running, but it consistently uses my contrast settings per (g)
- there is no animation (h)
- color coding is for convenience; all information is textual (i).
- a range of contrast is available using the arrow keys to
manipulate the setting (j)
- flashing is slow and within tolerances (k)
- there are no forms, no assistive technology add-ons, unless you
consider all these functions are also available via a web server
embedded in the printer itself (and the web standards apply).
Note there are some issues with moving hardware specific items
around such as (f) brings into question do we really want to say the
Operating System belongs in software or hardware? But besides minor
exceptions does that example help?
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, January 20, 2007 11:25 PM
To: Robinson, Norman B - Washington, DC; 'TEITAC self
contained/closed products subcommittee'; 'TEITAC Web/Software
Subject: RE: [teitac-closed] [teitac-websoftware] "closed
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 C Vanderheiden Ph.D.
Jonathan Avila wrote:
"What I'm trying to articulate is that the current hardware standards are
insufficient for this type of kiosk that uses a standard OS such as XP. For
example, the current standard 1194.25(h) only requires that a range of
color/contrast settings be available if the color settings can be changed.
Since the program is running on XP the colors can be changed in the OS and
thus I think the kiosk application should honor those settings."
This is interesting. I think you're saying that if a "closed" product has
an underlying OS that has
accessibility features, those features should be exposed in the product's
interface. I'm not
opposed to incorporating that idea, but it might require us to list or
otherwise identify what
those features are, something that the current 508 rule slides by by
referring to "features ... that
are identified as accessibility features, where those features are developed
and documented according
to industry standards". (As an aside, we recently evaluated a consumer
electronics product whose
documentation includes a GPL licensing statement for Linux. It's unclear
what part of Linux actually
is embedded in the product, but perhaps Linux accessibility features might
A related step would be to require those "accessibility features" in all
covered by 508. As it stands, a vendor *could* market an OS with no
accessibility features, seriously
complicating 508 application software compliance.