Thread Subject: Re: Agenda for today's AV subcom meeting

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: Dave Singer
Date: Fri, Sep 21 2007 10:15 AM

At 9:03 -0400 21/09/07, Larry Goldberg wrote:
>Having an access solution that requires external/specialized AT makes sense
>in some PC-based products, the notion that a deaf or blind person would need
>to bring AT to bear on using the menus on their TV is a major, untenable
>burden. The complete opposite of any universal design principle.
>
>I understand that dictating product design can be anathema to innovation and
>the ability of companies to meet marketplace demands, but because the
>marketplace hasn't been able to incentivize the usability of such things as
>menus that can be accessed by deaf or blind people, the products have
>drifted toward implementations that approach sheer unusability. A hands-off
>approach has led to such situations as a cable set-top box that must be
>powered off to access a secret, hidden firmware menu which gives access to
>caption controls. Once adjusted, the cable box menu must be turned off, the
>box powered back on, and the resulting captions then viewed for
>acceptability. If the captions don't look right, the user has to start the
>process all over again.
>
>Meets the letter of the law? Yes.
>Usable? Hardly.
>Indicates a need to address a "design" issue? Probably.
>
>... Larry ...

The basic problem is that there is no way to mandate good design. I
can do a poorly designed remote, poorly designed top-level menu, and
a generally poorly designed product. Indeed, if we mandate a
specific design, but not the effect we want, we might be worse off.
As you say, the product can claim compliance ('see, this little
unlabeled recessed button on the side, it enables captions if you
press it for 10 seconds or more!') without being usable at all.

Accessibility requires that the delivery chain (authoring,
transmission, presentation) have a means to deliver, which means that
manufacturers actually build in the function; that content makers
actually make useful accessible content; and that users who need it
can find it and enable it. Getting the right level and style of
mandate so that all this happens is not easy, I fear.

I'll give an example of a back-fire from another realm. The
installer used on Mac OS X requires that if you choose "custom
install", the user is shown the various pieces that might get
installed, with a check-box for the optional pieces. Selecting an
optional piece shows an explanatory string for what you get if you
install that option.

I cannot tell you the number of times I have seen something like
"Frobotz 2" as an optional install, and wondered if I needed it or
not, clicked on it to find out what it was, and been given the
explanatory string "This installs the Frobotz 2 option". Which is
useless to me. If the design had not mandated a string here, then
the author wouldn't have supplied this useless one, and the installer
could say "this installs a background process that launches at boot
and has root privileges" or "this adds the frobotz extension to
Microsoft Office", and so on. The installer can work out what pieces
it is putting where. So the mandate ('provide an explanatory string
always') was actually counter-productive.

And less there is any doubt, people needing accessibility are not the
only ones who get frustrated by poorly designed products.
--
David Singer
Apple/QuickTime

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