Thread Subject: Re: "Content" in our subcommittee
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
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: None
- Previous message in thread: Jim Thatcher: "Re: "Content" in our subcommittee"
- Messages sorted by: Author | Thread | Date
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
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.
I move around cells, focus is available to screen readers and they can
announce the contents of the cells, and the textual characteristics of
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
its properties, like being bold.
The only content we know how to address for accessibility is Web
I believe that other encoding/markup mechanisms include accessibility
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
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
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.
Department of Homeland Security
Office on Accessible Systems & Technology
- Next message in Thread: None
- Previous message in Thread: Jim Thatcher: "Re: "Content" in our subcommittee"