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: Hoffman, Allen
Date: Tue, Aug 14 2007 8:40 AM

The "collection of software components" language is intended to allow
for 3rd party interoperability and was strongly supported from vendors
of such products. As far as the "create or modify" language i agree
with you Judy, it is more precise.




Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy
Brewer
Sent: Tuesday, August 14, 2007 1:32 AM
To: TEITAC Web/Software Subcommittee; Andrew Kirkpatrick
Subject: Re: [teitac-websoftware] Authoring tools with no user interface

Thanks for the sample language Andrew. I didn't see any specific reply
from people after this, so let me ask people:

My understanding is that you're proposing changing the definition of
authoring tool from "...any software, or collection of software
components, used to create or modify content for publication."
to:
"...any software used to publish content"

Two questions -- feedback from anyone on these?

- Any concerns about dropping "...or collection of software components"?
I recall that we went through a series of discussions that led to
*adding"
the phrase "collection of software components," and as I recall there
were some types of tools -- or rather collections of tools -- for which
some people strongly felt the "collection of software components" was
needed.

- Are there any benefits to dropping "create or modify..." before
"publish"? To me, "create or modify content for publication" seems more
precise, and more likely to avoid unintended consequences, thus worthy
of keeping.

Judy

At 09:34 PM 8/8/2007 -0700, Andrew Kirkpatrick wrote:
>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.
> * 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.
> * Authoring tools must preserve accessibility information necessary

>to meet applicable Section 508 provisions, unless the user explicitly

>indicates otherwise.
> * 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.
> * 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
>----------
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean
>Hayes
>Sent: Wednesday, August 08, 2007 3:07 PM
>To: TEITAC Web/Software Subcommittee
>Subject: Re: [teitac-websoftware] Authoring tools with no user
>interface Well I guess that speaks to my concern that the definition
>includes all software. Typically one would not think of information
>typed into the shell as part of the definition of an authoring tool
suite.
>
>
>Sean Hayes
>Incubation Lab
>Accessibility Business Unit
>Microsoft
>Phone:
> mob +44 7977 455002
> office +44 117 9719730
>
>
>
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew

>Kirkpatrick
>Sent: 08 August 2007 19:58
>To: TEITAC Web/Software Subcommittee
>Subject: Re: [teitac-websoftware] Authoring tools with no user
>interface
>
>
>
>How was the information that the sed, awk, perl script obtained? That
>information's creation pathway would include other software that is
>part of the overall "authoring tool"
>
>AWK
>
>
>----------
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean
>Hayes
>Sent: Wednesday, August 08, 2007 2:52 PM
>To: TEITAC Web/Software Subcommittee
>Subject: Re: [teitac-websoftware] Authoring tools with no user
>interface
>
>The language was intended to exclude a number of tools such as sed,
>awk, perl which modify content but often run silently as part of batch

>operations
>
>
>
>Sean Hayes
>Incubation Lab
>Accessibility Business Unit
>Microsoft
>Phone:
> mob +44 7977 455002
> office +44 117 9719730
>
>
>
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew

>Kirkpatrick
>Sent: 08 August 2007 19:41
>To: TEITAC Web/Software Subcommittee
>Subject: [teitac-websoftware] Authoring tools with no user interface
>
>
>Can anyone name an authoring tool with no user interface? To be
>specific, if an authoring tool is "any software, or collection of
>software components, that authors use to create or modify content for
publication"
>there seems to be a need for a user interface in one or more of the
>tools that are part of every "authoring tool". Any thoughts?
>
>AWK
>
>
>
>Andrew Kirkpatrick
>
>Corporate Accessibility Engineering Manager
>
>Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
>
>
>

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