Thread Subject: Re:

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: Hoffman, Allen
Date: Mon, Jan 22 2007 6:30 AM

I can't concur more with Peter's summary of the components for document
accessibility, as it mirrors my viewpoint exactly. If we can beat down
what at a minimum will compose capacities for any document encoding
format we can really get this to work across our categories.

Allen Hoffman
DHS Office on Accessible Systems & Technology

Norman Robinson wrote:
> As far as tools go, I would think we would still need a well-defined
> API or standard format for content types (e.g., SGML, XHTML, XML, ODF,

> RTF, PDF, etc.) along with the proper versioning before we could begin

> recommending tools.

Peter Korn wrote:
"Looking at document content, I think the first issue is whether all of
the information needed for accessibility can be encoded in the format
(e.g. HTML defining the existence of ALT tags for images -> if there
isn't such a definition, then you can't encode it even if you want to).

Second to that is the question of whether document authors are encoding
the information that they should. This will likely give rise to some
judgment calls -> if a particular document element can have both a name
and a description, it may not always be necessary for obvious/simple
elements to have a description in addition to the name. The third (and
perhaps final) issue is ensuring that the applications that
read/write/display this content are accessible, support AT on the
platform(s) they run on, etc."

"I think this has less to do with any specific standard format, as it
does that each any every document format in question must address the
first issue (and document authors address the second, and document
related software address the third)."

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