Thread Subject: Authoring tools with no user interface

Return to this mailing list's archives

From: Andrew Kirkpatrick
Date: Wed, Aug 08 2007 12:45 PM
Subject: 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 =

From: Sean Hayes
Date: Wed, Aug 08 2007 12:55 PM
Subject: Re: 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 =

From: Andrew Kirkpatrick
Date: Wed, Aug 08 2007 1:00 PM
Subject: Re: 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: Sean Hayes
Date: Wed, Aug 08 2007 1:10 PM
Subject: Re: 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: Sailesh Panchang
Date: Wed, Aug 08 2007 2:10 PM
Subject: Re: Authoring tools with no user interface

Andrew / Sean,

I had brought up this same issue on June 7 when I wrote:

"Is "For authoring tools with a user interface, ", required? For user driven

authoring tools, a user interface is certainly needed and if it is an

automated authoring tool, it should provide a programmable switch or

parameter by which one can turn on / off this mode. So I think it

should simply read:

4. Authoring tools must provide a mode which prompts authors to create

accessible content."



In other words some trigger or interface with a human is needed somewhere
in the process to generate content.

Refer:

http://teitac.org/mailarchives/mail_thread.php?thread=1172&id=4989#post8

Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =

_____

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 =

From: Andrew Kirkpatrick
Date: Wed, Aug 08 2007 10:40 PM
Subject: Re: Authoring tools with no user interface

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

From: David Poehlman
Date: Thu, Aug 09 2007 6:40 AM
Subject: Re: Authoring tools with no user interface

I have been seeing and need clarification of:
"2. Authoring tools must preserve accessibility information
necessary to meet applicable Section 508 provisions, **unless the user
explicitly indicates otherwise.**"
especially the notation surrounded by **.

Thanks!
----- Original Message -----
From: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, August 09, 2007 12:34 AM
Subject: Re: [teitac-websoftware] Authoring tools with no user interface


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

From: Robinson, Norman B - Washington, DC
Date: Thu, Aug 09 2007 8:40 AM
Subject: Re: Authoring tools with no user interface

We should remove the qualifiers "for each accessible content format
supported" as all content covers all scenarios, "with a user interface"
as then you have to qualify what a user interface is or is not, and
delete the reference to _file_ templates entirely. Templates are not
software. A templated HTML form is not software or web-based information
- yet(1 see below). We should certainly expect vendors to provide file
templates that already include accessibility information where possible
but we should be focusing on their _tool's_ ability to create and keep
that information, not on the _file_ itself. Please consider that I can
use many different editors on the same file template - and do today. And
where my coworkers prefer Dreamweaver or some other tool, I prefer BASH
shell script editing or VIM text editor (let the flame wars begin) that
has macros for many of the same functions and in our current definition
would fit the definition of an authoring tool.


Regards,


Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246


(1) We should address file formats as file formats and not some
umbrella for web-based information. We haven't even gained agreement
amongst ourselves and addressed valid or well-formed HTML! That
logically will fall into software (flash anyone? SVG? PDF?) at some
point. We should focus on what specific techniques or coding is required
for accessibility in the file format in consideration of where we are
failing to provide accessibility and need it mandated (e.g., being
specific on alt text for images is an obvious need; how do we clarify
that for SVG or any other format?)

From: Sean Hayes
Date: Thu, Aug 09 2007 8:55 AM
Subject: Re: Authoring tools with no user interface

The clause **unless the user explicitly indicates otherwise.**" is there to allow authors to edit the information; if it were not there you would not be able to change the alt text for an image for example.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730

From: David Poehlman
Date: Thu, Aug 09 2007 9:25 AM
Subject: Re: Authoring tools with no user interface

Then, this needs to be made clearer. I want to be able to override the
choices if they are inappropriate, but not to turn off accessability.

----- Original Message -----
From: "Sean Hayes" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, August 09, 2007 10:49 AM
Subject: Re: [teitac-websoftware] Authoring tools with no user interface


The clause **unless the user explicitly indicates otherwise.**" is there to
allow authors to edit the information; if it were not there you would not be
able to change the alt text for an image for example.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730

From: Judy Brewer
Date: Tue, Aug 14 2007 12:00 AM
Subject: Re: 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 =
>
>
>

From: Judy Brewer
Date: Tue, Aug 14 2007 12:10 AM
Subject: Re: Authoring tools with no user interface

Norm,

At 10:34 AM 8/9/2007 -0400, Robinson, Norman B - Washington, DC wrote:
>
>We should remove the qualifiers "for each accessible content format
>supported" as all content covers all scenarios,

I believe that this was added to account for situations where for instance
the output might be something other than electronic content, for instance,
a printed format. Sean, didn't this come from you, and if so can you remind us?

>"with a user interface" as then you have to qualify what a user interface
>is or is not,

This one is under discussion.

>and delete the reference to _file_ templates entirely. Templates are not
>software. A templated HTML form is not software or web-based information -
>yet(1 see below). We should certainly expect vendors to provide file
>templates that already include accessibility information where possible
>but we should be focusing on their _tool's_ ability to create and keep
>that information, not on the _file_ itself.

Not sure where you're seeing the emphasis on the file itself. The proposed
provision does not include "file" and its emphasis is facilitating the
production of accessible content through provision of accessible templates
and certain types of pre-authored content:
"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."

>Please consider that I can use many different editors on the same file
>template - and do today. And where my coworkers prefer Dreamweaver or some
>other tool, I prefer BASH shell script editing or VIM text editor (let the
>flame wars begin) that has macros for many of the same functions and in
>our current definition would fit the definition of an authoring tool.

Can you suggest language that would be more encompassing of these types of
macros and that would be feasible and appropriate to add to, or amend, the
existing language?

Thanks,

- Judy

>
>
>Regards,
>
>
>
>Norman B. Robinson
>Section 508 Coordinator
>IT Governance, US Postal Service
>phone: 202.268.8246
>(1) We should address file formats as file formats and not some umbrella
>for web-based information. We haven't even gained agreement amongst
>ourselves and addressed valid or well-formed HTML! That logically will
>fall into software (flash anyone? SVG? PDF?) at some point. We should
>focus on what specific techniques or coding is required for accessibility
>in the file format in consideration of where we are failing to provide
>accessibility and need it mandated (e.g., being specific on alt text for
>images is an obvious need; how do we clarify that for SVG or any other
>format?)
>
>

From: Sean Hayes
Date: Tue, Aug 14 2007 3:45 AM
Subject: Re: Authoring tools with no user interface

<quote Norm>
We should remove the qualifiers "for each accessible content format
supported" as all content covers all scenarios,
</quote Norm>

<quote Judy>
I believe that this was added to account for situations where for instance
the output might be something other than electronic content, for instance,
a printed format. Sean, didn't this come from you, and if so can you remind us?
</quote Judy>

Yes the problem here is that authoring systems often provide the ability to export into formats which are not able to pass all the content requirements.
Some examples: Creating a FAX document for transmission. Creating an image of the content to include in an advertisement. Creating a thumbnail for use as a web preview. Saving as simple text to migrate content between incompatible systems.

If we prevent authoring tools from supporting these scenarios, this will cause a lot of problems in the market. On the other hand we do want to make sure that where the tool is saving to a format that can pass the provisions, the necessary information is added appropriately.

I'm not sure what the right language is here, but that is my concern.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

From: William Loughborough
Date: Tue, Aug 14 2007 7:25 AM
Subject: Re: Authoring tools with no user interface

Judy Brewer wrote:
> "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."
how about striking out "provide at least one verstion that" (and change
"meets" to "meet"?

Love.

From: William Loughborough
Date: Tue, Aug 14 2007 7:35 AM
Subject: Re: Authoring tools with no user interface

Judy Brewer wrote:
> 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"
>
If we don't cover the software used to create/modify we are missing the
point of "authoring".

Software "used to publish content" could eliminate from coverage
anything except that which actually pushes the content into use by
devices or the Web - FTP for example.

The intent is to more or less compel/simplify(trivialize?) creation of
accessible content seamlessly so that authors aren't burdened with a
bunch of guidelines, but have that part taken care of by the tool.

Love.

From: Hoffman, Allen
Date: Tue, Aug 14 2007 8:40 AM
Subject: Re: Authoring tools with no user interface

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 =
>
>
>

From: Judy Brewer
Date: Tue, Aug 14 2007 9:45 AM
Subject: Re: Authoring tools with no user interface

Sean,

Thanks for the further elaboration on this.

I think the language which we developed to address that, "...for each
accessible content format supported" works fine, and that we should keep it.

- Judy

At 10:40 AM 8/14/2007 +0100, Sean Hayes wrote:
><quote Norm>
>We should remove the qualifiers "for each accessible content format
>supported" as all content covers all scenarios,
></quote Norm>
>
><quote Judy>
>I believe that this was added to account for situations where for instance
>the output might be something other than electronic content, for instance,
>a printed format. Sean, didn't this come from you, and if so can you
>remind us?
></quote Judy>
>
>Yes the problem here is that authoring systems often provide the ability
>to export into formats which are not able to pass all the content requirements.
>Some examples: Creating a FAX document for transmission. Creating an image
>of the content to include in an advertisement. Creating a thumbnail for
>use as a web preview. Saving as simple text to migrate content between
>incompatible systems.
>
>If we prevent authoring tools from supporting these scenarios, this will
>cause a lot of problems in the market. On the other hand we do want to
>make sure that where the tool is saving to a format that can pass the
>provisions, the necessary information is added appropriately.
>
>I'm not sure what the right language is here, but that is my concern.
>
>Sean Hayes
>Incubation Lab
>Accessibility Business Unit
>Microsoft
>
>
>
>

From: Andrew Kirkpatrick
Date: Tue, Aug 14 2007 10:40 AM
Subject: Re: Authoring tools with no user interface

> 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.

And as far as interoperability with testing tools, I agree that
something is needed since all authoring tools can't integrate testing
directly. However, this language causes other issues, which are the
reasons why I'm opposed to this phrase.

AWK

From: Hoffman, Allen
Date: Tue, Aug 14 2007 11:00 AM
Subject: Re: Authoring tools with no user interface

Can you suggest a solution to ensure the interoperability for 3rd party
tools is clear?



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

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

> 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.

And as far as interoperability with testing tools, I agree that
something is needed since all authoring tools can't integrate testing
directly. However, this language causes other issues, which are the
reasons why I'm opposed to this phrase.

AWK

From: Hoffman, Allen
Date: Tue, Aug 14 2007 11:20 AM
Subject: Re: Authoring tools with no user interface

This was included from my memory to identify that for a product which
allows production, or saving of multiple formats, and a set of those
meet accessibility requirements, functionality to produce fully
accessible content in each of those formats is provided, not just for
one format.

So, for example, at the "save as" option, if one selects a format that
does have the functionality to be accessible, all the accessibility
features must be usable by the author and savable in that format. On
the other hand, if the author wants to save in an inaccessible format,
what can we do anyway, no tool can overcome that. To be more precise we
should probably require that for each format supported, or format that
content can be saved in, that all that format's accessibility
functionality/attributes are available to the author and are preserved
when saved.



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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Tuesday, August 14, 2007 12:29 PM
To: TEITAC Web/Software Subcommittee; Robinson, Norman B - Washington,
DC
Subject: Re: [teitac-websoftware] Authoring tools with no user interface

Who is going to define if the format is accessibility supported? For
example, if OpenOffice, Acrobat, and Quark output PDF, could one decide
that PDF is not accessibility supported? How supported is "supported"?

AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy
> Brewer
> Sent: Tuesday, August 14, 2007 11:41 AM
> To: TEITAC Web/Software Subcommittee; Robinson, Norman B - Washington,

> DC
> Subject: Re: [teitac-websoftware] Authoring tools with no user
> interface
>
> Sean,
>
> Thanks for the further elaboration on this.
>
> I think the language which we developed to address that, "...for each
> accessible content format supported" works fine, and that we should
> keep it.
>
> - Judy
>
> At 10:40 AM 8/14/2007 +0100, Sean Hayes wrote:
> ><quote Norm>
> >We should remove the qualifiers "for each accessible content format
> >supported" as all content covers all scenarios, </quote Norm>
> >
> ><quote Judy>
> >I believe that this was added to account for situations where for
> >instance the output might be something other than electronic
> content,
> >for instance, a printed format. Sean, didn't this come from
> you, and if
> >so can you remind us?
> ></quote Judy>
> >
> >Yes the problem here is that authoring systems often provide the
> >ability to export into formats which are not able to pass
> all the content requirements.
> >Some examples: Creating a FAX document for transmission. Creating an
> >image of the content to include in an advertisement. Creating a
> >thumbnail for use as a web preview. Saving as simple text to migrate
> >content between incompatible systems.
> >
> >If we prevent authoring tools from supporting these scenarios, this
> >will cause a lot of problems in the market. On the other hand we do
> >want to make sure that where the tool is saving to a format that can
> >pass the provisions, the necessary information is added
> appropriately.
> >
> >I'm not sure what the right language is here, but that is my concern.
> >
> >Sean Hayes
> >Incubation Lab
> >Accessibility Business Unit
> >Microsoft
> >
> >
> >
> >

From: Andrew Kirkpatrick
Date: Tue, Aug 14 2007 12:30 PM
Subject: Re: Authoring tools with no user interface

The second suggestion may be a good one to consider.
AWK

> So, for example, at the "save as" option, if one selects a
> format that does have the functionality to be accessible, all
> the accessibility features must be usable by the author and
> savable in that format. On the other hand, if the author
> wants to save in an inaccessible format, what can we do
> anyway, no tool can overcome that. To be more precise we
> should probably require that for each format supported, or
> format that content can be saved in, that all that format's
> accessibility functionality/attributes are available to the
> author and are preserved when saved.

From: Andrew Kirkpatrick
Date: Tue, Aug 14 2007 1:15 PM
Subject: Re: Authoring tools with no user interface

Who is going to define if the format is accessibility supported? For
example, if OpenOffice, Acrobat, and Quark output PDF, could one decide
that PDF is not accessibility supported? How supported is "supported"?

AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Judy Brewer
> Sent: Tuesday, August 14, 2007 11:41 AM
> To: TEITAC Web/Software Subcommittee; Robinson, Norman B -
> Washington, DC
> Subject: Re: [teitac-websoftware] Authoring tools with no
> user interface
>
> Sean,
>
> Thanks for the further elaboration on this.
>
> I think the language which we developed to address that,
> "...for each accessible content format supported" works fine,
> and that we should keep it.
>
> - Judy
>
> At 10:40 AM 8/14/2007 +0100, Sean Hayes wrote:
> ><quote Norm>
> >We should remove the qualifiers "for each accessible content format
> >supported" as all content covers all scenarios, </quote Norm>
> >
> ><quote Judy>
> >I believe that this was added to account for situations where for
> >instance the output might be something other than electronic
> content,
> >for instance, a printed format. Sean, didn't this come from
> you, and if
> >so can you remind us?
> ></quote Judy>
> >
> >Yes the problem here is that authoring systems often provide the
> >ability to export into formats which are not able to pass
> all the content requirements.
> >Some examples: Creating a FAX document for transmission. Creating an
> >image of the content to include in an advertisement. Creating a
> >thumbnail for use as a web preview. Saving as simple text to migrate
> >content between incompatible systems.
> >
> >If we prevent authoring tools from supporting these scenarios, this
> >will cause a lot of problems in the market. On the other hand we do
> >want to make sure that where the tool is saving to a format that can
> >pass the provisions, the necessary information is added
> appropriately.
> >
> >I'm not sure what the right language is here, but that is my concern.
> >
> >Sean Hayes
> >Incubation Lab
> >Accessibility Business Unit
> >Microsoft
> >
> >
> >
> >

From: Judy Brewer
Date: Tue, Aug 14 2007 2:25 PM
Subject: Re: Authoring tools with no user interface

Sean,

Thanks for the further elaboration on this.

I think the language which we developed to address that, "...for each
accessible content format supported" works fine, and that we should keep it.

- Judy

At 10:40 AM 8/14/2007 +0100, Sean Hayes wrote:
><quote Norm>
>We should remove the qualifiers "for each accessible content format
>supported" as all content covers all scenarios,
></quote Norm>
>
><quote Judy>
>I believe that this was added to account for situations where for instance
>the output might be something other than electronic content, for instance,
>a printed format. Sean, didn't this come from you, and if so can you
>remind us?
></quote Judy>
>
>Yes the problem here is that authoring systems often provide the ability
>to export into formats which are not able to pass all the content requirements.
>Some examples: Creating a FAX document for transmission. Creating an image
>of the content to include in an advertisement. Creating a thumbnail for
>use as a web preview. Saving as simple text to migrate content between
>incompatible systems.
>
>If we prevent authoring tools from supporting these scenarios, this will
>cause a lot of problems in the market. On the other hand we do want to
>make sure that where the tool is saving to a format that can pass the
>provisions, the necessary information is added appropriately.
>
>I'm not sure what the right language is here, but that is my concern.
>
>Sean Hayes
>Incubation Lab
>Accessibility Business Unit
>Microsoft
>
>
>
>