Thread Subject: Re: "Content" in our subcommittee

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, Nov 06 2006 4:08 PM

Jim Thatcher wrote:
"This content thread has troubled me from the beginning and the recent
message (with subject "RE: [teitac-websoftware] teitac-websoftware
Digest, Vol 2,
Issue 4" (thanks a lot) brought my concerns to a head."

it is a difficult issue I agree.

Jim Thatcher wrote:
"You cannot put accessibility requirements on that client area. As you
work on an image in Photoshop there is nothing about that content that
is accessible.
As I create a table in Lotus 123 (yes I do!) there is nothing accessible
about the tables I am creating. What must be accessible is the software.
When
I move around cells, focus is available to screen readers and they can
announce the contents of the cells, and the textual characteristics of
the contents.
All the surrounding menus and dialogs must be accessible. But about the
actual tables, the actual content - we are silent. We have no way to
judge or measure
that. If I work in a text editor, say WordPad or SlickEdit (which I use)
and I make some text bold - what should AT know? They need to know the
text and
its properties, like being bold.

The only content we know how to address for accessibility is Web
content."

I believe that other encoding/markup mechanisms include accessibility
attributes.

Your points are well taken, and bring me to the concept that the
encoding formats used must include specific accessibility attributes to
support specific accessibility functionalities. so how about something
such as:

Encoding formats used shall include or incorporate/support attributes
to: (insert list) such as, associate images with alternate text,
identify reading order, associate table headers and cells, provide
focus, identity, operation and state for input elements, (etc.). this
might even be something in the 1194.41 section.

Then, we might also insert in that area, or in software & web, something
like an ATAG requirement.

Content is really just content; it is the encoding mechanisms and
encoding tools that often are the factors to drive accessibility. Web
is often more accessible than other formats because, the format has
accessibility attributes available, requirements for those attributes to
be used, and some tools to help people encode the information with those
attributes.

I do agree these may be two tracks here--specific web/software
requirements, and content/format and tool requirements. Web
requirements are really format requirements, since no user-agent
requirements or authoring tool requirements are in place yet.
eventually it comes down to end-to-end coverage, gaps have and will
cause inaccessibility I believe.

allen Hoffman
Department of Homeland Security
Office on Accessible Systems & Technology

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