Thread Subject: Re: Authoring tools with no user interface

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: Andrew Kirkpatrick
Date: Wed, Aug 08 2007 10:40 PM

If the data being used by the script is simple text information, say a
flat file database with tab-delimited data, then I'd question how that
file was created. Sure, if someone types the data into the shell, then
that is a pretty minimal authoring tool, and is probably not a
"product", so that may fall through the cracks, and in this case that is
probably OK.

Let's take a different scenario - I've got a tool that looks for new
additions of Gregorian Presentation Documents (GPD) to a directory on a
server, and automatically transforms the new files to the Gregorian
Online Format (GOF). The GOF file looks for and uses equivalents for
images, but there is no UI for the transformation steps of this process,
so there is no prompting when image equivalents are missing.

The authoring tool in this case is tool "A" (makes the GPD file) and
tool "B" (my transformation tool that makes the GOF file), combined.
Does it have a UI? In this case, yes. Is there a real combination of
tools where the GPD file (or its precursors) is created without a UI? I
don't think so, not in situations where there is reporting to do.

As a result, I think that it is reasonable to keep the "authoring tools
with no UI" part in #3 because it makes sense for individual products,
but what doesn't make sense is the mushy definition of authoring tool.

When we are writing a VPAT for our product, we need to indicate how we
comply with the standards that we're setting. I'll reiterate my concern
that if it is necessary to report on how our "authoring tool" performs
against these standards, we may be saddled with reporting
responsibilities for multiple products in order to cover our own
product. If five vendors generate GPD files, I may need to research and
author VPATs for some of these products if the developer doesn't do it
themselves, and for products that are part of the authoring tool that do
write VPATs I need to either trust that everything is fine and that they
have done their work well (our legal department will love that), or do
redundant testing.

My Proposal - this one change to the definition will make this
reasonable for reporting. It is unreasonable to place requirements for
reporting on products other than those made by a vendor.
Authoring tool: any software used to publish content

The other standards will work as written with this change - if not,
there are difficulties with #1 and #3.

1. For each accessible content format supported, authoring tools
must allow the author to produce content, including content derived from
programmatic sources, that meets applicable Section 508 provisions.
2. Authoring tools must preserve accessibility information
necessary to meet applicable Section 508 provisions, unless the user
explicitly indicates otherwise.
3. For authoring tools with a user interface, authoring tools must
provide a mode which prompts authors to create accessible content; and
either a mode which assists authors in checking for accessibility
problems, or compatibility with evaluation tools that provide that
function.
4. Authoring tools which provide pre-authored content, or templates
to facilitate production of content, must provide at least one version
that meets applicable Section 508 provisions.

So, in response to the question today, "What is your suggested
language?", there you have it...

AWK

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