Thread Subject: Re: Final? draft of 1194.41a, b,and c (was discussion of who pays for alternate format)

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: David Poehlman
Date: Mon, Mar 19 2007 3:30 PM

Good points.

See my observations in line marked with dp:
On Mar 19, 2007, at 5:36 PM, Whitney Quesenbery wrote:

At 04:52 PM 3/19/2007, David Poehlman wrote:
> In other words, do away with alternate formats altogether
> and talk about compliant formats if you will.

So, if I posted a "file" in several formats and at least one of the
formats
met each of the general functional performance requirements, I'd be in
compliance?
dp: I'd say that all formats used must meet the standards set for
documentation/content. Of course, print on paper would be at least
partially exempt but it should be easily scannable.

As I think about this, I do this all the time, even outside of
disabilities
considerations. For example, if the information if the info is from an
application used by some (but not all) members of a project, I might
send
it out in the native format, but also send an exported format such as
text
or PDF or HTML. (Example: Microsoft Project, which will create a
number of
formats to read a project plan.)
dp: this is an excellent example and one which points out my intent
quite well. Part of the specificationf forr standards would allow
for a project plan too be distributed in formats which at some
functional level met a variety of acccess needs. For instance, the
"normal" way to put this out might be a chart which would be much
more effective for some than streight text and this goes with cognition.

The next question is what is a "sufficient" format. Is it enough to have
formats that (taken as a group) conform to requirements? What else
must be
taken into consideration:
dp: I don't see how a group of formats could be taken to meet the
requirements but I supposse that the rrequirements could be written
and or enterpretted in that way. I'd actually like to see
requirements such that we get cross modality in open standards in any
compliant format but failing that, we could have a provision or set
of provisions which allow forr mmultiiple formats to meet the
requirements as a whole. The problem I see fwith this is that some
mixed modalities might require several formats twhich might defeat
the purposees of dealing with thee issue of mmultiple modalities.
For instance, iff one of the requirements was that the content would
be available in a form which was usable by someonw not using a screen
or their eyes in any other fashion, a typical response would be
audioo. Another might be that the needs of those not listening would
be able to utillize the content so print or visual content would be
appropriate. What though if I don't listen or watch? So we needd an
approach that takes thesee potentially oppositess into account.


-- The capabilities of the users' IT be taken into consideration? The
example above is one (from general use) in which the availability of the
"reader program" is a consideration.
dp: this is why I advocate for open standards here. We cannot
provide with certainty that our format specifications will fit all
situations, but we can at least mittigate this by providing ways to
make it easier to do so.

-- User preferences? I can see how this might be determined through
user
research in a specific case (easier or perhaps more targeted for
employees
than for the public), but how would it be specified as a general
requirement.

-- Availability (% adoption? cost? ease of acquisition/installation?)
of
the AT or "reader program"?

What if I choose not to install a wildly popular and free plugin (e.g.
Acrobat, Flash)? Is that "my choice" but not "your responsibility"?
dp: if the format is open and there is something freely available
that will not trump the user environment, it becomes the
responsibility of the user.

Whitney Quesenbery
Whitney Interactive Design
= EMAIL ADDRESS REMOVED =
phone: 908-638-5467
mobile: 908-328-5959
www.WQusability.com
www.usabilityprofessionals.org

"Warning: Objects in the calendar are closer than they appear."

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