Thread Subject: Re: Proposal on authoring tools
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: Peter Wallack
Date: Fri, Jun 08 2007 10:40 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Walser, Kate: "Re: Proposal on authoring tools"
- Previous message in thread: Sean Hayes: "Re: Proposal on authoring tools"
- Messages sorted by: Author | Thread | Date
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
I too question why are we are singling out 'authoring tools with a UI'.
Why not require that a product that operates unattended or as an API
return "failure" when the data sent to it is insufficient or ambiguous
in terms of its ability to return an accessible result. I suppose it
could optionally offer an interactive mode to help remedy the
situation, but I wouldn't suggest requiring that.<br>
<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
David Poehlman wrote:
<blockquote cite="mid:001301c7a9db$3ac13120$0901a8c0@HANDS" type="cite">
<pre wrap="">I wonder why we don't just require them to produce accessible content and
prompt where there are ambiguities as to how to address them.
----- Original Message -----
From: "Sailesh Panchang" <a class="moz-txt-link-rfc2396E" href="mailto: = EMAIL ADDRESS REMOVED = ">< = EMAIL ADDRESS REMOVED = ></a>
To: <a class="moz-txt-link-rfc2396E" href="mailto: = EMAIL ADDRESS REMOVED = ">< = EMAIL ADDRESS REMOVED = ></a>; "'TEITAC Web/Software Subcommittee'"
<a class="moz-txt-link-rfc2396E" href="mailto: = EMAIL ADDRESS REMOVED = ">< = EMAIL ADDRESS REMOVED = ></a>
Sent: Friday, June 08, 2007 9:10 AM
Subject: Re: [teitac-websoftware] Proposal on authoring tools
Refer: 4. For authoring tools with a user interface, authoring tools must
provide a mode which prompts authors to create accessible content.
<pre wrap="">I believe the "with a user interface" clause is required. Otherwise you
are essentially saying that the government cannot purchase any unattended,
automated tools that operate on content. Because then every such tool
"must provide a mode which prompts".
Peter, that is my point. I am raising the bar and saying that an automated
tool too should have some programmable switch or mechanism by which one can
turn on / off generation of accessible content. Maybe "prompts" is not the
right word because it does suggest that it will have a UI. The statement
needs to be re-worded in case the concept is acceptable.
Senior Accessibility Engineer
Deque Systems Inc. (<a class="moz-txt-link-abbreviated" href="http://www.deque.com">www.deque.com</a>)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: <a class="moz-txt-link-abbreviated" href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a>