Thread Subject: Authoring Tools -- Wiki section added

Return to this mailing list's archives

From: Judy Brewer
Date: Wed, Jul 25 2007 10:30 AM
Subject: Authoring Tools -- Wiki section added

I have added a section collecting our discussions to date on provisions for
authoring tools to the Web/Software Wiki:
http://teitac.org/wiki/Web_and_Software:General_issues#Authoring_Tools
This includes the latest version of the proposal, from June 27; the
proposal threads in the mail archive; and links to our recent discussion
minutes.

At our meeting today, let's review the June 27 proposal, starting with the
definition, then the four provisions. For those provisions not yet ready to
move forward, it would be helpful to identify specifically what the pending
issues are, so that those can be addressed and resolved over the next two
weeks.

Proposed definition:

"Authoring Tool: any software, or collection of software
components, that authors use to create or modify content for publication."

Proposed provisions:

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 electronic content
accessibility standards.

2. Authoring tools must preserve accessibility information necessary
for meeting the electronic content 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 interoperability 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 electronic content accessibility standards.

Any specific remaining concerns for discussion -- in which case also
suggestions for how to resolve those concerns?

Thank you,

- Judy


--
Judy Brewer +1.617.258.9741 http://www.w3.org/WAI
Director, Web Accessibility Initiative (WAI), World Wide Web Consortium (W3C)
MIT/CSAIL Building 32-G526
32 Vassar Street
Cambridge, MA, 02139, USA

From: William Loughborough
Date: Wed, Jul 25 2007 11:05 AM
Subject: Re: Authoring Tools -- Wiki section added

Somewhere in the provisions we should (must?) specifically include the
notion that authoring tools are themselves accessible to PWD. A slight
expansion of Provision 1 would be a logical place for this: "...allow
the author [particularly one with disabilities]..." for example?

Judy Brewer wrote:
> At our meeting today, let's review the June 27 proposal, starting with the
> definition, then the four provisions.
> Proposed definition:
>
> "Authoring Tool: any software, or collection of software
> components, that authors use to create or modify content for publication."
>
> Proposed provisions:
>
> 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 electronic content
> accessibility standards.
>
> 2. Authoring tools must preserve accessibility information necessary
> for meeting the electronic content 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 interoperability 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 electronic content accessibility standards.
>
> Any specific remaining concerns for discussion -- in which case also
> suggestions for how to resolve those concerns?
>
> Thank you,
>
> - Judy
>
>
>

From: Robinson, Norman B - Washington, DC
Date: Wed, Jul 25 2007 12:40 PM
Subject: Re: Authoring Tools -- Wiki section added

Regarding "[teitac-websoftware] Authoring Tools -- Wiki section added",
it was asked for any specific remaining concerns for discussion -- in
which case also suggestions for how to resolve those concerns?

Playing devil's advocate on the Authoring Tool proposed provisions:

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 electronic content
accessibility standards.

a. What is the definition for "accessible content formats"?
b. Content is not currently covered in the existing provisions.
How might content be referenced in the next revision? As a file format?
If file formats are not covered, how will this work?

2. Authoring tools must preserve accessibility information necessary
for meeting the electronic content provisions, unless the user
explicitly
indicates otherwise.

a. What is the complete definition of "accessibility
information"?
b. If the user indicates they do not want accessibility
information does that then imply we could still have compliant content?

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 interoperability with evaluation tools that provide that
function.

a. What are authoring tools without a user interface? Bash shell
scripts?
b. Isn't this redundant with the first (#1) statement?

4. Authoring tools which provide pre-authored content, or templates
to facilitate production of content, must provide at least one version
that
meets applicable electronic content accessibility standards.

a. What happens when the content doesn't have an accessible
version? Think of Flash 1.0.
b. Again, per statement #1 question (b), content is not
currently covered in the existing provisions. Is content the same as a
file format? If file formats are not in the revision, how will this
work?

Finally, questions about the goals regarding authoring tools:
how is software called "authoring tools" any different from any other
software under the Section 508 provisions? Why can't we simply apply the
Section 508 technical software standards to "authoring tools"? How are
we to get away from the logic trap that we are mandating specific
features in software of type "authoring tools?". Do we do that for any
other particular type of software? Does this only apply to *web based
content*? How can the be misused? (e.g., If I use Notepad or Bash Shell
as an authoring tool, does this really apply?

My suggestion for resolving these concerns:
1. Remove the section on authoring tools. Rationale is they are
no different than any other software!
2. Define "accessible content formats" or "file formats"
required for accessibility in the refresh.
3. Address *validation* and *well-formed* in the new "file
formats" section of the refresh.

Regards,


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

From: William Loughborough
Date: Wed, Jul 25 2007 1:20 PM
Subject: Re: Authoring Tools -- Wiki section added

Robinson, Norman B - Washington, DC wrote:
> My suggestion for resolving these concerns:
> 1. Remove the section on authoring tools. Rationale is they are
> no different than any other software!
>
The rationale falls a bit short because of historical reasons.
"Authoring Tools" as commonly understood are different from other
software in that they have a "meta" character to them: they "create"
other software than themselves and in the case of the Web they have
provided a long-term barrier to producing accessible Web content, so
deserve special attention.

Although it is possible to write Web content using a simple text editor,
virtually nobody does that: we all use special tools to prepare such
materials. Those special tools merit close attention because they've
been repeatedly/demonstrably shown to contribute inordinately to
problems of inaccessibility. Just as the Ku Klux Klan isn't simply an
organization for social togetherness, so Authoring Tools aren't merely
ordinary software, they are culprits in repeated offenses against
accessibility.

Love.

From: Peter Wallack
Date: Wed, Jul 25 2007 1:45 PM
Subject: Re: Authoring Tools -- Wiki section added

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
My thoughts on three of these, the first of which was already covered
on the phonecall:<br>
<pre wrap=""><b>"Authoring Tool: any software, or collection of software
components, that authors use to create or modify content for publication."</b></pre>
I'd like to see 'authors' dropped from that, and wouldn't mind seeing
some slight rewording of 'content for publication' as others also
raised. My fear is that this could be interpreted as only applying to a
tool that creates 'simple' or non-interactive content. How about:<br>
<pre wrap="">"Authoring Tool: any software, or collection of software components, used to create or modify content."</pre>
I am fine with 'authors' appearing in the actual provisions, though I
suppose they could be tweaked as well (one already uses 'users').<br>
<br>
<pre wrap=""><b>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 interoperability with evaluation tools that provide that function.</b>

'interoperability with evaluation tools' concerns me. If we have to provide some kind of 'tight' interoperability with third party tools, it raises the exact same problem we have with AT-IT interoperability: where are the standards that define this? And this might trigger licensing issues, raising the cost for everyone.

<b>4. Authoring tools which provide pre-authored content, or templates to
facilitate production of content, must provide at least one version that
meets applicable electronic content accessibility standards.

</b>A comment was made that 'at least one' was not sufficient, but as a software vendor I am in a far better position to make something accessible if I can focus on a single solution. And if multiple solutions are provided, I can't figure out how their differences could be meaningfully explained to an audience which is generally described as not being 'accessibility experts'.
</pre>
<br>
<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
Oracle Corporation</pre>
<br>
<br>
Judy Brewer wrote:
<blockquote cite="mid:5.1.0.14.2.20070725112607.0433c9a8@localhost"
type="cite">
<pre wrap="">I have added a section collecting our discussions to date on provisions for
authoring tools to the Web/Software Wiki:
<a class="moz-txt-link-freetext" href="http://teitac.org/wiki/Web_and_Software:General_issues#Authoring_Tools">http://teitac.org/wiki/Web_and_Software:General_issues#Authoring_Tools</a>
This includes the latest version of the proposal, from June 27; the
proposal threads in the mail archive; and links to our recent discussion
minutes.

At our meeting today, let's review the June 27 proposal, starting with the
definition, then the four provisions. For those provisions not yet ready to
move forward, it would be helpful to identify specifically what the pending
issues are, so that those can be addressed and resolved over the next two
weeks.

Proposed definition:

"Authoring Tool: any software, or collection of software
components, that authors use to create or modify content for publication."

Proposed provisions:

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 electronic content
accessibility standards.

2. Authoring tools must preserve accessibility information necessary
for meeting the electronic content 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 interoperability 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 electronic content accessibility standards.

Any specific remaining concerns for discussion -- in which case also
suggestions for how to resolve those concerns?

Thank you,

- Judy


</pre>
</blockquote>
</body>
</html>

From: Hoffman, Allen
Date: Wed, Jul 25 2007 2:15 PM
Subject: Re: Authoring Tools -- Wiki section added

The challenge I have heard is that authoring tools may not meet this
requirement when work is in interim phases of authoring, but must allow
it at "final publication" phase. others mentioned that accessibility
should be available in all phases. I'd be happy to drop the publication
word myself.



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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: Wednesday, July 25, 2007 4:02 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added

Hi guys,

I took the action item to start a discussion on defining "publication"
for use in the definition of "authoring tool". But I wonder if we can
simply drop "publication", just as we have dropped "author", in the
suggestion by the other Peter, below.

How about we just go with, as Peter suggests, "Authoring Tool: any
software, or collection of software components, used to create or modify
content."

While we still need a definition of content, we don't need a definition
of publication anymore.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> My thoughts on three of these, the first of which was already covered
> on the phonecall:
> *"Authoring Tool: any software, or collection of software
> components, that authors use to create or modify content for
publication."*
> I'd like to see 'authors' dropped from that, and wouldn't mind seeing
> some slight rewording of 'content for publication' as others also
> raised. My fear is that this could be interpreted as only applying to
> a tool that creates 'simple' or non-interactive content. How about:
> "Authoring Tool: any software, or collection of software components,
used to create or modify content."
> I am fine with 'authors' appearing in the actual provisions, though I
> suppose they could be tweaked as well (one already uses 'users').
>
> *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 interoperability with evaluation tools that provide that function.*
>
> 'interoperability with evaluation tools' concerns me. If we have to
provide some kind of 'tight' interoperability with third party tools, it
raises the exact same problem we have with AT-IT interoperability: where
are the standards that define this? And this might trigger licensing
issues, raising the cost for everyone.
>
> *4. Authoring tools which provide pre-authored content, or templates
to
> facilitate production of content, must provide at least one version
that
> meets applicable electronic content accessibility standards.
>
> *A comment was made that 'at least one' was not sufficient, but as a
software vendor I am in a far better position to make something
accessible if I can focus on a single solution. And if multiple
solutions are provided, I can't figure out how their differences could
be meaningfully explained to an audience which is generally described as
not being 'accessibility experts'.
>
>
> Peter Wallack
> Accessibility Program Director
> Oracle Corporation
>
>
> Judy Brewer wrote:
>> I have added a section collecting our discussions to date on
provisions for
>> authoring tools to the Web/Software Wiki:
>>
http://teitac.org/wiki/Web_and_Software:General_issues#Authoring_Tools
>> This includes the latest version of the proposal, from June 27; the
>> proposal threads in the mail archive; and links to our recent
discussion
>> minutes.
>>
>> At our meeting today, let's review the June 27 proposal, starting
with the
>> definition, then the four provisions. For those provisions not yet
ready to
>> move forward, it would be helpful to identify specifically what the
pending
>> issues are, so that those can be addressed and resolved over the next
two
>> weeks.
>>
>> Proposed definition:
>>
>> "Authoring Tool: any software, or collection of software
>> components, that authors use to create or modify content for
publication."
>>
>> Proposed provisions:
>>
>> 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 electronic content
>> accessibility standards.
>>
>> 2. Authoring tools must preserve accessibility information
necessary
>> for meeting the electronic content 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 interoperability 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 electronic content accessibility standards.
>>
>> Any specific remaining concerns for discussion -- in which case also
>> suggestions for how to resolve those concerns?
>>
>> Thank you,
>>
>> - Judy
>>
>>
>>
>
------------------------------------------------------------------------
>
>

From: Peter Korn
Date: Wed, Jul 25 2007 2:20 PM
Subject: Re: Authoring Tools -- Wiki section added

Hi guys,

I took the action item to start a discussion on defining "publication"
for use in the definition of "authoring tool". But I wonder if we can
simply drop "publication", just as we have dropped "author", in the
suggestion by the other Peter, below.

How about we just go with, as Peter suggests, "Authoring Tool: any
software, or collection of software components, used to create or modify
content."

While we still need a definition of content, we don't need a definition
of publication anymore.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> My thoughts on three of these, the first of which was already covered
> on the phonecall:
> *"Authoring Tool: any software, or collection of software
> components, that authors use to create or modify content for publication."*
> I'd like to see 'authors' dropped from that, and wouldn't mind seeing
> some slight rewording of 'content for publication' as others also
> raised. My fear is that this could be interpreted as only applying to
> a tool that creates 'simple' or non-interactive content. How about:
> "Authoring Tool: any software, or collection of software components, used to create or modify content."
> I am fine with 'authors' appearing in the actual provisions, though I
> suppose they could be tweaked as well (one already uses 'users').
>
> *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 interoperability with evaluation tools that provide that function.*
>
> 'interoperability with evaluation tools' concerns me. If we have to provide some kind of 'tight' interoperability with third party tools, it raises the exact same problem we have with AT-IT interoperability: where are the standards that define this? And this might trigger licensing issues, raising the cost for everyone.
>
> *4. Authoring tools which provide pre-authored content, or templates to
> facilitate production of content, must provide at least one version that
> meets applicable electronic content accessibility standards.
>
> *A comment was made that 'at least one' was not sufficient, but as a software vendor I am in a far better position to make something accessible if I can focus on a single solution. And if multiple solutions are provided, I can't figure out how their differences could be meaningfully explained to an audience which is generally described as not being 'accessibility experts'.
>
>
> Peter Wallack
> Accessibility Program Director
> Oracle Corporation
>
>
> Judy Brewer wrote:
>> I have added a section collecting our discussions to date on provisions for
>> authoring tools to the Web/Software Wiki:
>> http://teitac.org/wiki/Web_and_Software:General_issues#Authoring_Tools
>> This includes the latest version of the proposal, from June 27; the
>> proposal threads in the mail archive; and links to our recent discussion
>> minutes.
>>
>> At our meeting today, let's review the June 27 proposal, starting with the
>> definition, then the four provisions. For those provisions not yet ready to
>> move forward, it would be helpful to identify specifically what the pending
>> issues are, so that those can be addressed and resolved over the next two
>> weeks.
>>
>> Proposed definition:
>>
>> "Authoring Tool: any software, or collection of software
>> components, that authors use to create or modify content for publication."
>>
>> Proposed provisions:
>>
>> 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 electronic content
>> accessibility standards.
>>
>> 2. Authoring tools must preserve accessibility information necessary
>> for meeting the electronic content 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 interoperability 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 electronic content accessibility standards.
>>
>> Any specific remaining concerns for discussion -- in which case also
>> suggestions for how to resolve those concerns?
>>
>> Thank you,
>>
>> - Judy
>>
>>
>>
> ------------------------------------------------------------------------
>
>

From: Hoffman, Allen
Date: Wed, Jul 25 2007 2:45 PM
Subject: Re: Authoring Tools -- Wiki section added

Peter wrote:
'interoperability with evaluation tools' concerns me. If we have to
provide some kind of 'tight' interoperability with third party tools, it
raises the
exact same problem we have with AT-IT interoperability: where are the
standards that define this? And this might trigger licensing issues,
raising the
cost for everyone.

This arose from current vendors of assessment/remediation tools concern
that by defining authoring tools as "a" tool, they would be precluded
from this market. My interpretation here is that, for example, an
authoring tool provided could claim compliance with this rule if they
know of another tool that can be packaged with theirs, or purchased
independently, that performs this functionality as part of their
authoring process. I don't think, for example, external tools that do
web assessment and remediation stand-alone without some actual
integration in to the authoring process would qualify here. This may
require more specific constrains and/or additional supplemental language
to aid the Access-Board and FAR folks to finalize it.




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

From: Hoffman, Allen
Date: Wed, Jul 25 2007 3:25 PM
Subject: Re: Authoring Tools -- Wiki section added

Norman Robinson wrote:
a. What is the definition for "accessible content formats"?


An accessible content format is one that meets the requirements
identified in the new "content formats" section of the proposed
standards. So, for example, if OOXML was proposed, it would need to
meet the requirements identified in that section for the functions it
supports in that format.

Norman wrote:
b. Content is not currently covered in the existing provisions.
How might content be referenced in the next revision? As a file format?


Peter Korn wrote:
Thus we have content accessibility guidelines, including specific HTML
content accessibility guidelines. These apply to HTML content whether
they are viewed via an HTTP GET request from a website, or a File->Open
command within a web browser from a local/networked disk, or within a
Help browser, or from a word processor.

Likewise, we have application accessibility guidelines, perhaps
including specifically guidelines for applications that are a blend of
HTML/SVG/whatever and running code (be that code Flash or Java or
ActiveX or whatever).


There are significant challenges with this view of things, most
especially including harmonization challenges and the existing &
historical view/language around "Web accessibility". But increasingly,
making distinctions about where a thing comes from is making less and
less sense.

Allen continues:
1. Define accessibility requirements for formats. Without the ability
to store appropriate information and the specific accessibility
attributes, a format can not be made accessible by the author,
user-agent, and in many circumstances, by the assistive technology.
1a. Require that the most accessible content format is used.
2. Establish that "all content" must be made compliant via the
accessibility features the format supports.
3. provide specific requirements for "web" content since we know
specific mechanisms
that must be employed to meet accessibility needs for this area.
3a. provide specific requirements for "multimedia" since these area
already known.
4. provide software requirements since we know specific requirements
for this area.
4a. provide authoring tool requirements to improve authors ability to
use the accessibility attributes in the format when available.
4b. provide "platform" requirements to ensure that accessibility
attributes from content are able to be represented in a programatic
fashion.
4c. provide user-agent requirements to ensure that the accessibility
attributes of content are rendered with all appropriate options, and to
alleviate some authoring burden when some accessibility options can be
made at the user-agent phase of the delivery chain. Hypothetical
example of this is the W3C 2 level AA requirement to address blinking
after 3 seconds. If this is implemented as a content requirement all
authors and testers will need to start authoring and testing for this
requirement, but if implemented as a user-agent requirement, a smaller
group of people will have to address this problem with a solution.

Norman wrote:
a. What is the complete definition of "accessibility
information"?

Allen responds:
"accessibility information" includes the set of attributes or encoding
that makes the content meet the requirements for that format. For
example, if a format allows for insertion of images in to a document,
and has the alternate text function, that would be accessibility
information. if it also allows tables to be marked up for header/cell
association, then that would also be in that set of attributes. So, at
the end of the day the author would be bound by the functionality of the
format--which is true under any condition already.

Norman wrote:
b. If the user indicates they do not want accessibility
information does that then imply we could still have compliant content?

Allen responds:
not specifically. but, this arose from the situation where someone is
working on a draft and just wants to get the work in to some shape to
then finalize. In this situation they may not feel it appropriate to
put alt-text on images, mark up tables, set headers, etc--but can do so
at final publication time. There may be better more precise language
for this situation we can craft--any proposal?

Norman writes:
a. What are authoring tools without a user interface? Bash shell
scripts?
b. Isn't this redundant with the first (#1) statement?

Allen responds:
first, authoring tools without user-interfaces might be transparent
items in the work flow. Shell scripts are good! Second, maybe, but
more precise to such non-interface tools.






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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Robinson, Norman B - Washington, DC
Sent: Wednesday, July 25, 2007 2:38 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added

Regarding "[teitac-websoftware] Authoring Tools -- Wiki section added",
it was asked for any specific remaining concerns for discussion -- in
which case also suggestions for how to resolve those concerns?

Playing devil's advocate on the Authoring Tool proposed provisions:

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 electronic content
accessibility standards.

a. What is the definition for "accessible content formats"?
b. Content is not currently covered in the existing provisions.
How might content be referenced in the next revision? As a file format?
If file formats are not covered, how will this work?

2. Authoring tools must preserve accessibility information necessary
for meeting the electronic content provisions, unless the user
explicitly indicates otherwise.

a. What is the complete definition of "accessibility
information"?
b. If the user indicates they do not want accessibility
information does that then imply we could still have compliant content?

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 interoperability with evaluation tools that provide that
function.

a. What are authoring tools without a user interface? Bash shell
scripts?
b. Isn't this redundant with the first (#1) statement?

4. Authoring tools which provide pre-authored content, or templates
to facilitate production of content, must provide at least one version
that meets applicable electronic content accessibility standards.

a. What happens when the content doesn't have an accessible
version? Think of Flash 1.0.
b. Again, per statement #1 question (b), content is not
currently covered in the existing provisions. Is content the same as a
file format? If file formats are not in the revision, how will this
work?

Finally, questions about the goals regarding authoring tools:
how is software called "authoring tools" any different from any other
software under the Section 508 provisions? Why can't we simply apply the
Section 508 technical software standards to "authoring tools"? How are
we to get away from the logic trap that we are mandating specific
features in software of type "authoring tools?". Do we do that for any
other particular type of software? Does this only apply to *web based
content*? How can the be misused? (e.g., If I use Notepad or Bash Shell
as an authoring tool, does this really apply?

My suggestion for resolving these concerns:
1. Remove the section on authoring tools. Rationale is they are
no different than any other software!
2. Define "accessible content formats" or "file formats"
required for accessibility in the refresh.
3. Address *validation* and *well-formed* in the new "file
formats" section of the refresh.

Regards,


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

From: Hoffman, Allen
Date: Wed, Jul 25 2007 3:30 PM
Subject: Re: Authoring Tools -- Wiki section added

William wrote:
Somewhere in the provisions we should (must?) specifically include the
notion that authoring tools are themselves accessible to PWD. A slight
expansion of Provision 1 would be a logical place for this: "...allow
the author [particularly one with disabilities]..." for example?

Allen responds:
My take is that this is addressed, if not "directly" in the general web
and software requirements already, but maybe it could be made more clear
via language in #1 of the authoring tools requirements.



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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of William
Loughborough
Sent: Wednesday, July 25, 2007 1:00 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added

Somewhere in the provisions we should (must?) specifically include the
notion that authoring tools are themselves accessible to PWD. A slight
expansion of Provision 1 would be a logical place for this: "...allow
the author [particularly one with disabilities]..." for example?

Judy Brewer wrote:
> At our meeting today, let's review the June 27 proposal, starting with

> the definition, then the four provisions.
> Proposed definition:
>
> "Authoring Tool: any software, or collection of software
> components, that authors use to create or modify content for
publication."
>
> Proposed provisions:
>
> 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 electronic content
> accessibility standards.
>
> 2. Authoring tools must preserve accessibility information
> necessary for meeting the electronic content 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 interoperability 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 electronic content accessibility
standards.
>
> Any specific remaining concerns for discussion -- in which case also
> suggestions for how to resolve those concerns?
>
> Thank you,
>
> - Judy
>
>
>

From: Sailesh Panchang
Date: Wed, Jul 25 2007 3:35 PM
Subject: Re: Authoring Tools -- Wiki section added

I think the proposed wording for authoring tools can be improved. Here is #3
and 4:



3. Authoring tools with a user interface must prompt authors to create
accessible content and should incorporate a mechanism that enables content
creators to detect accessibility problems in the authored content either
directly or by interfacing with other accessibility evaluation tools.



4. Authoring tools which provide pre-authored content or templates to
facilitate production of content must provide at least one version of
pre-authored content or templates that meet applicable electronic content
accessibility standards.



> 'interoperability with evaluation tools' concerns me. If we have to
provide some kind of 'tight' interoperability with third party tools, it
raises the

> exact same problem we have with AT-IT interoperability: where are the
standards that define this? And this might trigger licensing issues, raising
the

> cost for everyone.

Comment:

Authoring tool makers are free to build evaluation capability within their
tools. Alternatively they can work with external evaluation tool makers to
ensure both tools work in tandem. Sure there are licensing issues involved.
So what? Here is a parallel: Today Microsoft is free to build its own
screen readers and screen magnifiers or work with other AT makers to
ensure that Windows based software work with AT. So today the end user has
to buy Windows based software and whatever AT is suitable.



Market economics will dictate strategies for development of new tools or
associations between vendors.



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 Hoffman,
Allen
Sent: Wednesday, July 25, 2007 4:39 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added



Peter wrote:

'interoperability with evaluation tools' concerns me. If we have to provide
some kind of 'tight' interoperability with third party tools, it raises the
exact same problem we have with AT-IT interoperability: where are the
standards that define this? And this might trigger licensing issues, raising
the
cost for everyone.

This arose from current vendors of assessment/remediation tools concern that
by defining authoring tools as "a" tool, they would be precluded from this
market. My interpretation here is that, for example, an authoring tool
provided could claim compliance with this rule if they know of another tool
that can be packaged with theirs, or purchased independently, that performs
this functionality as part of their authoring process. I don't think, for
example, external tools that do web assessment and remediation stand-alone
without some actual integration in to the authoring process would qualify
here. This may require more specific constrains and/or additional
supplemental language to aid the Access-Board and FAR folks to finalize it.






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





_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Wallack
Sent: Wednesday, July 25, 2007 3:41 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added

My thoughts on three of these, the first of which was already covered on the
phonecall:



"Authoring Tool: any software, or collection of software
components, that authors use to create or modify content for publication."

I'd like to see 'authors' dropped from that, and wouldn't mind seeing some
slight rewording of 'content for publication' as others also raised. My fear
is that this could be interpreted as only applying to a tool that creates
'simple' or non-interactive content. How about:



"Authoring Tool: any software, or collection of software components, used to
create or modify content."

I am fine with 'authors' appearing in the actual provisions, though I
suppose they could be tweaked as well (one already uses 'users').




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 interoperability with evaluation tools that provide that function.

'interoperability with evaluation tools' concerns me. If we have to provide
some kind of 'tight' interoperability with third party tools, it raises the
exact same problem we have with AT-IT interoperability: where are the
standards that define this? And this might trigger licensing issues, raising
the cost for everyone.

4. Authoring tools which provide pre-authored content, or templates to
facilitate production of content, must provide at least one version that
meets applicable electronic content accessibility standards.

A comment was made that 'at least one' was not sufficient, but as a software
vendor I am in a far better position to make something accessible if I can
focus on a single solution. And if multiple solutions are provided, I can't
figure out how their differences could be meaningfully explained to an
audience which is generally described as not being 'accessibility experts'.





Peter Wallack
Accessibility Program Director
Oracle Corporation



Judy Brewer wrote:

I have added a section collecting our discussions to date on provisions for
authoring tools to the Web/Software Wiki:

http://teitac.org/wiki/Web_and_Software:General_issues#Authoring_Tools
This includes the latest version of the proposal, from June 27; the
proposal threads in the mail archive; and links to our recent discussion
minutes.

At our meeting today, let's review the June 27 proposal, starting with the
definition, then the four provisions. For those provisions not yet ready to
move forward, it would be helpful to identify specifically what the pending
issues are, so that those can be addressed and resolved over the next two
weeks.

Proposed definition:

"Authoring Tool: any software, or collection of software
components, that authors use to create or modify content for publication."

Proposed provisions:

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 electronic content
accessibility standards.

2. Authoring tools must preserve accessibility information necessary
for meeting the electronic content 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 interoperability 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 electronic content accessibility standards.

Any specific remaining concerns for discussion -- in which case also
suggestions for how to resolve those concerns?

Thank you,

- Judy

From: David Poehlman
Date: Wed, Jul 25 2007 4:45 PM
Subject: Re: Authoring Tools -- Wiki section added

I agree with Norman.

----- Original Message -----
From: "Robinson, Norman B - Washington, DC" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, July 25, 2007 2:37 PM
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added


Regarding "[teitac-websoftware] Authoring Tools -- Wiki section added",
it was asked for any specific remaining concerns for discussion -- in
which case also suggestions for how to resolve those concerns?

Playing devil's advocate on the Authoring Tool proposed provisions:

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 electronic content
accessibility standards.

a. What is the definition for "accessible content formats"?
b. Content is not currently covered in the existing provisions.
How might content be referenced in the next revision? As a file format?
If file formats are not covered, how will this work?

2. Authoring tools must preserve accessibility information necessary
for meeting the electronic content provisions, unless the user
explicitly
indicates otherwise.

a. What is the complete definition of "accessibility
information"?
b. If the user indicates they do not want accessibility
information does that then imply we could still have compliant content?

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 interoperability with evaluation tools that provide that
function.

a. What are authoring tools without a user interface? Bash shell
scripts?
b. Isn't this redundant with the first (#1) statement?

4. Authoring tools which provide pre-authored content, or templates
to facilitate production of content, must provide at least one version
that
meets applicable electronic content accessibility standards.

a. What happens when the content doesn't have an accessible
version? Think of Flash 1.0.
b. Again, per statement #1 question (b), content is not
currently covered in the existing provisions. Is content the same as a
file format? If file formats are not in the revision, how will this
work?

Finally, questions about the goals regarding authoring tools:
how is software called "authoring tools" any different from any other
software under the Section 508 provisions? Why can't we simply apply the
Section 508 technical software standards to "authoring tools"? How are
we to get away from the logic trap that we are mandating specific
features in software of type "authoring tools?". Do we do that for any
other particular type of software? Does this only apply to *web based
content*? How can the be misused? (e.g., If I use Notepad or Bash Shell
as an authoring tool, does this really apply?

My suggestion for resolving these concerns:
1. Remove the section on authoring tools. Rationale is they are
no different than any other software!
2. Define "accessible content formats" or "file formats"
required for accessibility in the refresh.
3. Address *validation* and *well-formed* in the new "file
formats" section of the refresh.

Regards,


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

From: Gregg Vanderheiden
Date: Wed, Jul 25 2007 7:30 PM
Subject: Re: Authoring Tools -- Wiki section added

I don't think meeting the content format provisions alone makes something
accessible.

It might 'meet accessibility standards' but to be accessible it has to
actually be useable. You must then ask - accessible to who?

Also - one of they key links is the existence of AT that can work with the
technology format.

Assume I create a new document format called the Gregorian Document Format
(GDF). I create the format such that it meets all of the document format
provisions. However, I failed to work with AT vendors (why should I - it
will be labeled accessible if I meet the standard) and as a result there are
no AT that will work with GDF. Should it be called accessible anyway?
Should we be posting information on social security benefits in this
technology? It is 'accessible' after all. The only problem is that no AT
users can access it.

Hence I think we should be careful here.

1) we should never call things accessible just because they meet the our
standard. Think of cognitive to prove this.

2) we should not think of things as 'meeting our guidelines' via 'at
support" but rather through "AT". That is, there has to actually be AT that
supports it and users have to have access to it -- or they will not be able
to 'access' the E&IT.

This of course also applies to the doc formats. They should be worded such
that 'programmatically determinable' means that is can be determined using
real AT and not just has the potential to be accessible via software.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Wednesday, July 25, 2007 4:18 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
> section added
>
> Norman Robinson wrote:
> a. What is the definition for "accessible content formats"?
>
>
> An accessible content format is one that meets the
> requirements identified in the new "content formats" section
> of the proposed standards. So, for example, if OOXML was
> proposed, it would need to meet the requirements identified
> in that section for the functions it supports in that format.
>
> Norman wrote:
> b. Content is not currently covered in the existing provisions.
> How might content be referenced in the next revision? As a
> file format?
>
>
> Peter Korn wrote:
> Thus we have content accessibility guidelines, including
> specific HTML content accessibility guidelines. These apply
> to HTML content whether they are viewed via an HTTP GET
> request from a website, or a File->Open command within a web
> browser from a local/networked disk, or within a Help
> browser, or from a word processor.
>
> Likewise, we have application accessibility guidelines,
> perhaps including specifically guidelines for applications
> that are a blend of HTML/SVG/whatever and running code (be
> that code Flash or Java or ActiveX or whatever).
>
>
> There are significant challenges with this view of things,
> most especially including harmonization challenges and the
> existing & historical view/language around "Web
> accessibility". But increasingly, making distinctions about
> where a thing comes from is making less and less sense.
>
> Allen continues:
> 1. Define accessibility requirements for formats. Without
> the ability to store appropriate information and the specific
> accessibility attributes, a format can not be made accessible
> by the author, user-agent, and in many circumstances, by the
> assistive technology.
> 1a. Require that the most accessible content format is used.
> 2. Establish that "all content" must be made compliant via
> the accessibility features the format supports.
> 3. provide specific requirements for "web" content since we
> know specific mechanisms that must be employed to meet
> accessibility needs for this area.
> 3a. provide specific requirements for "multimedia" since
> these area already known.
> 4. provide software requirements since we know specific
> requirements for this area.
> 4a. provide authoring tool requirements to improve authors
> ability to use the accessibility attributes in the format
> when available.
> 4b. provide "platform" requirements to ensure that
> accessibility attributes from content are able to be
> represented in a programatic fashion.
> 4c. provide user-agent requirements to ensure that the
> accessibility attributes of content are rendered with all
> appropriate options, and to alleviate some authoring burden
> when some accessibility options can be made at the user-agent
> phase of the delivery chain. Hypothetical example of this is
> the W3C 2 level AA requirement to address blinking after 3
> seconds. If this is implemented as a content requirement all
> authors and testers will need to start authoring and testing
> for this requirement, but if implemented as a user-agent
> requirement, a smaller group of people will have to address
> this problem with a solution.
>
> Norman wrote:
> a. What is the complete definition of "accessibility
> information"?
>
> Allen responds:
> "accessibility information" includes the set of attributes or
> encoding that makes the content meet the requirements for
> that format. For example, if a format allows for insertion
> of images in to a document, and has the alternate text
> function, that would be accessibility information. if it
> also allows tables to be marked up for header/cell
> association, then that would also be in that set of
> attributes. So, at the end of the day the author would be
> bound by the functionality of the format--which is true under
> any condition already.
>
> Norman wrote:
> b. If the user indicates they do not want accessibility
> information does that then imply we could still have
> compliant content?
>
> Allen responds:
> not specifically. but, this arose from the situation where
> someone is working on a draft and just wants to get the work
> in to some shape to then finalize. In this situation they
> may not feel it appropriate to put alt-text on images, mark
> up tables, set headers, etc--but can do so at final
> publication time. There may be better more precise language
> for this situation we can craft--any proposal?
>
> Norman writes:
> a. What are authoring tools without a user interface?
> Bash shell scripts?
> b. Isn't this redundant with the first (#1) statement?
>
> Allen responds:
> first, authoring tools without user-interfaces might be
> transparent items in the work flow. Shell scripts are good!
> Second, maybe, but more precise to such non-interface tools.
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson, Norman B - Washington, DC
> Sent: Wednesday, July 25, 2007 2:38 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
> section added
>
> Regarding "[teitac-websoftware] Authoring Tools -- Wiki
> section added", it was asked for any specific remaining
> concerns for discussion -- in which case also suggestions for
> how to resolve those concerns?
>
> Playing devil's advocate on the Authoring Tool proposed provisions:
>
> 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 electronic
> content accessibility standards.
>
> a. What is the definition for "accessible content formats"?
> b. Content is not currently covered in the existing provisions.
> How might content be referenced in the next revision? As a
> file format?
> If file formats are not covered, how will this work?
>
> 2. Authoring tools must preserve accessibility
> information necessary for meeting the electronic content
> provisions, unless the user explicitly indicates otherwise.
>
> a. What is the complete definition of "accessibility
> information"?
> b. If the user indicates they do not want accessibility
> information does that then imply we could still have
> compliant content?
>
> 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 interoperability
> with evaluation tools that provide that function.
>
> a. What are authoring tools without a user interface?
> Bash shell scripts?
> b. Isn't this redundant with the first (#1) statement?
>
> 4. Authoring tools which provide pre-authored content, or
> templates to facilitate production of content, must provide
> at least one version that meets applicable electronic content
> accessibility standards.
>
> a. What happens when the content doesn't have an
> accessible version? Think of Flash 1.0.
> b. Again, per statement #1 question (b), content is not
> currently covered in the existing provisions. Is content the
> same as a file format? If file formats are not in the
> revision, how will this work?
>
> Finally, questions about the goals regarding authoring tools:
> how is software called "authoring tools" any different from
> any other software under the Section 508 provisions? Why
> can't we simply apply the Section 508 technical software
> standards to "authoring tools"? How are we to get away from
> the logic trap that we are mandating specific features in
> software of type "authoring tools?". Do we do that for any
> other particular type of software? Does this only apply to
> *web based content*? How can the be misused? (e.g., If I use
> Notepad or Bash Shell as an authoring tool, does this really apply?
>
> My suggestion for resolving these concerns:
> 1. Remove the section on authoring tools. Rationale is
> they are no different than any other software!
> 2. Define "accessible content formats" or "file formats"
> required for accessibility in the refresh.
> 3. Address *validation* and *well-formed* in the new
> "file formats" section of the refresh.
>
> Regards,
>
>
> Norman B. Robinson
> Section 508 Coordinator
> IT Governance, US Postal Service
> phone: 202.268.8246
>

From: Peter Korn
Date: Wed, Jul 25 2007 7:55 PM
Subject: Re: Authoring Tools -- Wiki section added

Hi Gregg,

These are very good points (and I assume you will be seeking ISO
certification for GDF shortly... [insert accessible smiley-face here]).

One question though. You wrote: "That is, there has to actually be AT
that supports it and users have to have access to it -- or they will not
be able to 'access' the E&IT." What do you mean by "users have to have
access to [AT]" in the context of the general public which might be
interested in reading documents posted to government websites in
Gregorian Document Format?

We've discussed this before, but I don't think we have ever come to a
conclusion on it. Government employees can perhaps rely on their
employer to purchase the latest editions of AT which include GDF
support, but the same cannot necessarily be said of an unemployed
citizen wanting to interact with their government electronically.

Do you have any suggestions as to how we deal with that situation?
Should 508 be concerned with this point? Also, should we include the
dimension of platform here (e.g. if GDF runs on Mac & Windows and UNIX,
but AT only exists on Mac that supports GDF, what then)?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> I don't think meeting the content format provisions alone makes something
> accessible.
>
> It might 'meet accessibility standards' but to be accessible it has to
> actually be useable. You must then ask - accessible to who?
>
> Also - one of they key links is the existence of AT that can work with the
> technology format.
>
> Assume I create a new document format called the Gregorian Document Format
> (GDF). I create the format such that it meets all of the document format
> provisions. However, I failed to work with AT vendors (why should I - it
> will be labeled accessible if I meet the standard) and as a result there are
> no AT that will work with GDF. Should it be called accessible anyway?
> Should we be posting information on social security benefits in this
> technology? It is 'accessible' after all. The only problem is that no AT
> users can access it.
>
> Hence I think we should be careful here.
>
> 1) we should never call things accessible just because they meet the our
> standard. Think of cognitive to prove this.
>
> 2) we should not think of things as 'meeting our guidelines' via 'at
> support" but rather through "AT". That is, there has to actually be AT that
> supports it and users have to have access to it -- or they will not be able
> to 'access' the E&IT.
>
> This of course also applies to the doc formats. They should be worded such
> that 'programmatically determinable' means that is can be determined using
> real AT and not just has the potential to be accessible via software.
>
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Hoffman, Allen
>> Sent: Wednesday, July 25, 2007 4:18 PM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
>> section added
>>
>> Norman Robinson wrote:
>> a. What is the definition for "accessible content formats"?
>>
>>
>> An accessible content format is one that meets the
>> requirements identified in the new "content formats" section
>> of the proposed standards. So, for example, if OOXML was
>> proposed, it would need to meet the requirements identified
>> in that section for the functions it supports in that format.
>>
>> Norman wrote:
>> b. Content is not currently covered in the existing provisions.
>> How might content be referenced in the next revision? As a
>> file format?
>>
>>
>> Peter Korn wrote:
>> Thus we have content accessibility guidelines, including
>> specific HTML content accessibility guidelines. These apply
>> to HTML content whether they are viewed via an HTTP GET
>> request from a website, or a File->Open command within a web
>> browser from a local/networked disk, or within a Help
>> browser, or from a word processor.
>>
>> Likewise, we have application accessibility guidelines,
>> perhaps including specifically guidelines for applications
>> that are a blend of HTML/SVG/whatever and running code (be
>> that code Flash or Java or ActiveX or whatever).
>>
>>
>> There are significant challenges with this view of things,
>> most especially including harmonization challenges and the
>> existing & historical view/language around "Web
>> accessibility". But increasingly, making distinctions about
>> where a thing comes from is making less and less sense.
>>
>> Allen continues:
>> 1. Define accessibility requirements for formats. Without
>> the ability to store appropriate information and the specific
>> accessibility attributes, a format can not be made accessible
>> by the author, user-agent, and in many circumstances, by the
>> assistive technology.
>> 1a. Require that the most accessible content format is used.
>> 2. Establish that "all content" must be made compliant via
>> the accessibility features the format supports.
>> 3. provide specific requirements for "web" content since we
>> know specific mechanisms that must be employed to meet
>> accessibility needs for this area.
>> 3a. provide specific requirements for "multimedia" since
>> these area already known.
>> 4. provide software requirements since we know specific
>> requirements for this area.
>> 4a. provide authoring tool requirements to improve authors
>> ability to use the accessibility attributes in the format
>> when available.
>> 4b. provide "platform" requirements to ensure that
>> accessibility attributes from content are able to be
>> represented in a programatic fashion.
>> 4c. provide user-agent requirements to ensure that the
>> accessibility attributes of content are rendered with all
>> appropriate options, and to alleviate some authoring burden
>> when some accessibility options can be made at the user-agent
>> phase of the delivery chain. Hypothetical example of this is
>> the W3C 2 level AA requirement to address blinking after 3
>> seconds. If this is implemented as a content requirement all
>> authors and testers will need to start authoring and testing
>> for this requirement, but if implemented as a user-agent
>> requirement, a smaller group of people will have to address
>> this problem with a solution.
>>
>> Norman wrote:
>> a. What is the complete definition of "accessibility
>> information"?
>>
>> Allen responds:
>> "accessibility information" includes the set of attributes or
>> encoding that makes the content meet the requirements for
>> that format. For example, if a format allows for insertion
>> of images in to a document, and has the alternate text
>> function, that would be accessibility information. if it
>> also allows tables to be marked up for header/cell
>> association, then that would also be in that set of
>> attributes. So, at the end of the day the author would be
>> bound by the functionality of the format--which is true under
>> any condition already.
>>
>> Norman wrote:
>> b. If the user indicates they do not want accessibility
>> information does that then imply we could still have
>> compliant content?
>>
>> Allen responds:
>> not specifically. but, this arose from the situation where
>> someone is working on a draft and just wants to get the work
>> in to some shape to then finalize. In this situation they
>> may not feel it appropriate to put alt-text on images, mark
>> up tables, set headers, etc--but can do so at final
>> publication time. There may be better more precise language
>> for this situation we can craft--any proposal?
>>
>> Norman writes:
>> a. What are authoring tools without a user interface?
>> Bash shell scripts?
>> b. Isn't this redundant with the first (#1) statement?
>>
>> Allen responds:
>> first, authoring tools without user-interfaces might be
>> transparent items in the work flow. Shell scripts are good!
>> Second, maybe, but more precise to such non-interface tools.
>>
>>
>>
>>
>>
>>
>> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Robinson, Norman B - Washington, DC
>> Sent: Wednesday, July 25, 2007 2:38 PM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
>> section added
>>
>> Regarding "[teitac-websoftware] Authoring Tools -- Wiki
>> section added", it was asked for any specific remaining
>> concerns for discussion -- in which case also suggestions for
>> how to resolve those concerns?
>>
>> Playing devil's advocate on the Authoring Tool proposed provisions:
>>
>> 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 electronic
>> content accessibility standards.
>>
>> a. What is the definition for "accessible content formats"?
>> b. Content is not currently covered in the existing provisions.
>> How might content be referenced in the next revision? As a
>> file format?
>> If file formats are not covered, how will this work?
>>
>> 2. Authoring tools must preserve accessibility
>> information necessary for meeting the electronic content
>> provisions, unless the user explicitly indicates otherwise.
>>
>> a. What is the complete definition of "accessibility
>> information"?
>> b. If the user indicates they do not want accessibility
>> information does that then imply we could still have
>> compliant content?
>>
>> 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 interoperability
>> with evaluation tools that provide that function.
>>
>> a. What are authoring tools without a user interface?
>> Bash shell scripts?
>> b. Isn't this redundant with the first (#1) statement?
>>
>> 4. Authoring tools which provide pre-authored content, or
>> templates to facilitate production of content, must provide
>> at least one version that meets applicable electronic content
>> accessibility standards.
>>
>> a. What happens when the content doesn't have an
>> accessible version? Think of Flash 1.0.
>> b. Again, per statement #1 question (b), content is not
>> currently covered in the existing provisions. Is content the
>> same as a file format? If file formats are not in the
>> revision, how will this work?
>>
>> Finally, questions about the goals regarding authoring tools:
>> how is software called "authoring tools" any different from
>> any other software under the Section 508 provisions? Why
>> can't we simply apply the Section 508 technical software
>> standards to "authoring tools"? How are we to get away from
>> the logic trap that we are mandating specific features in
>> software of type "authoring tools?". Do we do that for any
>> other particular type of software? Does this only apply to
>> *web based content*? How can the be misused? (e.g., If I use
>> Notepad or Bash Shell as an authoring tool, does this really apply?
>>
>> My suggestion for resolving these concerns:
>> 1. Remove the section on authoring tools. Rationale is
>> they are no different than any other software!
>> 2. Define "accessible content formats" or "file formats"
>> required for accessibility in the refresh.
>> 3. Address *validation* and *well-formed* in the new
>> "file formats" section of the refresh.
>>
>> Regards,
>>
>>
>> Norman B. Robinson
>> Section 508 Coordinator
>> IT Governance, US Postal Service
>> phone: 202.268.8246
>>

From: Gregg Vanderheiden
Date: Thu, Jul 26 2007 2:45 AM
Subject: Re: Authoring Tools -- Wiki section added

If a user fills out a form, or clicks on an expand link - -do they modify
content?



Should we change "modify' to "edit" ?



Not a strong concern - just a thought for clarity unless no one else sees a
problem.





I would drop "for publication"

Not sure it adds anything in particular.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Wallack
Sent: Wednesday, July 25, 2007 2:41 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added

My thoughts on three of these, the first of which was already covered on the
phonecall:



"Authoring Tool: any software, or collection of software
components, that authors use to create or modify content for publication."

I'd like to see 'authors' dropped from that, and wouldn't mind seeing some
slight rewording of 'content for publication' as others also raised. My fear
is that this could be interpreted as only applying to a tool that creates
'simple' or non-interactive content. How about:



"Authoring Tool: any software, or collection of software components, used to
create or modify content."

I am fine with 'authors' appearing in the actual provisions, though I
suppose they could be tweaked as well (one already uses 'users').




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 interoperability with evaluation tools that provide that function.

'interoperability with evaluation tools' concerns me. If we have to provide
some kind of 'tight' interoperability with third party tools, it raises the
exact same problem we have with AT-IT interoperability: where are the
standards that define this? And this might trigger licensing issues, raising
the cost for everyone.

4. Authoring tools which provide pre-authored content, or templates to
facilitate production of content, must provide at least one version that
meets applicable electronic content accessibility standards.

A comment was made that 'at least one' was not sufficient, but as a software
vendor I am in a far better position to make something accessible if I can
focus on a single solution. And if multiple solutions are provided, I can't
figure out how their differences could be meaningfully explained to an
audience which is generally described as not being 'accessibility experts'.





Peter Wallack
Accessibility Program Director
Oracle Corporation



Judy Brewer wrote:

I have added a section collecting our discussions to date on provisions for
authoring tools to the Web/Software Wiki:

http://teitac.org/wiki/Web_and_Software:General_issues#Authoring_Tools
This includes the latest version of the proposal, from June 27; the
proposal threads in the mail archive; and links to our recent discussion
minutes.

At our meeting today, let's review the June 27 proposal, starting with the
definition, then the four provisions. For those provisions not yet ready to
move forward, it would be helpful to identify specifically what the pending
issues are, so that those can be addressed and resolved over the next two
weeks.

Proposed definition:

"Authoring Tool: any software, or collection of software
components, that authors use to create or modify content for publication."

Proposed provisions:

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 electronic content
accessibility standards.

2. Authoring tools must preserve accessibility information necessary
for meeting the electronic content 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 interoperability 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 electronic content accessibility standards.

Any specific remaining concerns for discussion -- in which case also
suggestions for how to resolve those concerns?

Thank you,

- Judy

From: Sean Hayes
Date: Thu, Jul 26 2007 2:55 AM
Subject: Re: Authoring Tools -- Wiki section added

Publication does seem like too strong a word, but I think we do need to distinguish between interim unfinished work, and stuff that is archived as "institutional memory" or which gets passed on to others in a 'finished' form. It is simply not feasible to require that a piece of work be maintained in an accessible state from start to finish of a project. It would be kind of like insisting a house be habitable right from architects drawing to finished building.

Sean Hayes
Standards and Policy Team
Corporate Accessibility Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: 25 July 2007 21:02
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added

Hi guys,

I took the action item to start a discussion on defining "publication"
for use in the definition of "authoring tool". But I wonder if we can
simply drop "publication", just as we have dropped "author", in the
suggestion by the other Peter, below.

How about we just go with, as Peter suggests, "Authoring Tool: any
software, or collection of software components, used to create or modify
content."

While we still need a definition of content, we don't need a definition
of publication anymore.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> My thoughts on three of these, the first of which was already covered
> on the phonecall:
> *"Authoring Tool: any software, or collection of software
> components, that authors use to create or modify content for publication."*
> I'd like to see 'authors' dropped from that, and wouldn't mind seeing
> some slight rewording of 'content for publication' as others also
> raised. My fear is that this could be interpreted as only applying to
> a tool that creates 'simple' or non-interactive content. How about:
> "Authoring Tool: any software, or collection of software components, used to create or modify content."
> I am fine with 'authors' appearing in the actual provisions, though I
> suppose they could be tweaked as well (one already uses 'users').
>
> *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 interoperability with evaluation tools that provide that function.*
>
> 'interoperability with evaluation tools' concerns me. If we have to provide some kind of 'tight' interoperability with third party tools, it raises the exact same problem we have with AT-IT interoperability: where are the standards that define this? And this might trigger licensing issues, raising the cost for everyone.
>
> *4. Authoring tools which provide pre-authored content, or templates to
> facilitate production of content, must provide at least one version that
> meets applicable electronic content accessibility standards.
>
> *A comment was made that 'at least one' was not sufficient, but as a software vendor I am in a far better position to make something accessible if I can focus on a single solution. And if multiple solutions are provided, I can't figure out how their differences could be meaningfully explained to an audience which is generally described as not being 'accessibility experts'.
>
>
> Peter Wallack
> Accessibility Program Director
> Oracle Corporation
>
>
> Judy Brewer wrote:
>> I have added a section collecting our discussions to date on provisions for
>> authoring tools to the Web/Software Wiki:
>> http://teitac.org/wiki/Web_and_Software:General_issues#Authoring_Tools
>> This includes the latest version of the proposal, from June 27; the
>> proposal threads in the mail archive; and links to our recent discussion
>> minutes.
>>
>> At our meeting today, let's review the June 27 proposal, starting with the
>> definition, then the four provisions. For those provisions not yet ready to
>> move forward, it would be helpful to identify specifically what the pending
>> issues are, so that those can be addressed and resolved over the next two
>> weeks.
>>
>> Proposed definition:
>>
>> "Authoring Tool: any software, or collection of software
>> components, that authors use to create or modify content for publication."
>>
>> Proposed provisions:
>>
>> 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 electronic content
>> accessibility standards.
>>
>> 2. Authoring tools must preserve accessibility information necessary
>> for meeting the electronic content 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 interoperability 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 electronic content accessibility standards.
>>
>> Any specific remaining concerns for discussion -- in which case also
>> suggestions for how to resolve those concerns?
>>
>> Thank you,
>>
>> - Judy
>>
>>
>>
> ------------------------------------------------------------------------
>
>

From: Gregg Vanderheiden
Date: Thu, Jul 26 2007 3:00 AM
Subject: Re: Authoring Tools -- Wiki section added

Ah good point.

But this is a description of the tools. Not the product. Right?

hmmmmm


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Sean Hayes
> Sent: Thursday, July 26, 2007 3:53 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
> section added
>
> Publication does seem like too strong a word, but I think we
> do need to distinguish between interim unfinished work, and
> stuff that is archived as "institutional memory" or which
> gets passed on to others in a 'finished' form. It is simply
> not feasible to require that a piece of work be maintained in
> an accessible state from start to finish of a project. It
> would be kind of like insisting a house be habitable right
> from architects drawing to finished building.
>
> Sean Hayes
> Standards and Policy Team
> Corporate Accessibility Group
> Microsoft
> Phone:
> mob +44 7977 455002
> office +44 117 9719730
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: 25 July 2007 21:02
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
> section added
>
> Hi guys,
>
> I took the action item to start a discussion on defining "publication"
> for use in the definition of "authoring tool". But I wonder
> if we can simply drop "publication", just as we have dropped
> "author", in the suggestion by the other Peter, below.
>
> How about we just go with, as Peter suggests, "Authoring
> Tool: any software, or collection of software components,
> used to create or modify content."
>
> While we still need a definition of content, we don't need a
> definition of publication anymore.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > My thoughts on three of these, the first of which was
> already covered
> > on the phonecall:
> > *"Authoring Tool: any software, or collection of software
> components,
> > that authors use to create or modify content for publication."* I'd
> > like to see 'authors' dropped from that, and wouldn't mind
> seeing some
> > slight rewording of 'content for publication' as others
> also raised.
> > My fear is that this could be interpreted as only applying
> to a tool
> > that creates 'simple' or non-interactive content. How about:
> > "Authoring Tool: any software, or collection of software
> components, used to create or modify content."
> > I am fine with 'authors' appearing in the actual
> provisions, though I
> > suppose they could be tweaked as well (one already uses 'users').
> >
> > *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 interoperability with evaluation tools that
> provide that
> > function.*
> >
> > 'interoperability with evaluation tools' concerns me. If we
> have to provide some kind of 'tight' interoperability with
> third party tools, it raises the exact same problem we have
> with AT-IT interoperability: where are the standards that
> define this? And this might trigger licensing issues, raising
> the cost for everyone.
> >
> > *4. Authoring tools which provide pre-authored content, or
> templates
> > to facilitate production of content, must provide at least
> one version
> > that meets applicable electronic content accessibility standards.
> >
> > *A comment was made that 'at least one' was not sufficient,
> but as a software vendor I am in a far better position to
> make something accessible if I can focus on a single
> solution. And if multiple solutions are provided, I can't
> figure out how their differences could be meaningfully
> explained to an audience which is generally described as not
> being 'accessibility experts'.
> >
> >
> > Peter Wallack
> > Accessibility Program Director
> > Oracle Corporation
> >
> >
> > Judy Brewer wrote:
> >> I have added a section collecting our discussions to date on
> >> provisions for authoring tools to the Web/Software Wiki:
> >>
> >>
> http://teitac.org/wiki/Web_and_Software:General_issues#Authoring_Tool
> >> s This includes the latest version of the proposal, from
> June 27; the
> >> proposal threads in the mail archive; and links to our recent
> >> discussion minutes.
> >>
> >> At our meeting today, let's review the June 27 proposal, starting
> >> with the definition, then the four provisions. For those
> provisions
> >> not yet ready to move forward, it would be helpful to identify
> >> specifically what the pending issues are, so that those can be
> >> addressed and resolved over the next two weeks.
> >>
> >> Proposed definition:
> >>
> >> "Authoring Tool: any software, or collection of software
> >> components, that authors use to create or modify content
> for publication."
> >>
> >> Proposed provisions:
> >>
> >> 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
> electronic content
> >> accessibility standards.
> >>
> >> 2. Authoring tools must preserve accessibility information
> >> necessary for meeting the electronic content 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 interoperability 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 electronic content
> accessibility standards.
> >>
> >> Any specific remaining concerns for discussion -- in which
> case also
> >> suggestions for how to resolve those concerns?
> >>
> >> Thank you,
> >>
> >> - Judy
> >>
> >>
> >>
> >
> ----------------------------------------------------------------------
> > --
> >
> >

From: Sean Hayes
Date: Thu, Jul 26 2007 3:20 AM
Subject: Re: Authoring Tools -- Wiki section added

If you create the GDF format, either you would also produce the GDFAuthor and GDFPlayer software that goes with it (these may be the same piece of software), or GDF is based on an existing format, like Unicode or XML, so that you rely on existing tools. But either way, for GDF to be useful they must exist.

Both GDFPlayer and GDFAuthor must interoperate with AT, and since these are software and all the rules apply, this should be true.

The content format rules apply to GDF to ensure that artefacts encoded as GDF carry sufficient information to enable GDFPlayer/GDFAuthor to operate to the level required by 508 and also, where GDF is an open format, to allow exporting from GDFAuthor to anOtherGDFAuthor.

Content Format rules do not make anything accessible, but they are a necessary condition to enable player (and sometimes authoring) software to comply with 508.

Sean Hayes
Standards and Policy Team
Corporate Accessibility Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg Vanderheiden
Sent: 26 July 2007 02:29
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added

I don't think meeting the content format provisions alone makes something
accessible.

It might 'meet accessibility standards' but to be accessible it has to
actually be useable. You must then ask - accessible to who?

Also - one of they key links is the existence of AT that can work with the
technology format.

Assume I create a new document format called the Gregorian Document Format
(GDF). I create the format such that it meets all of the document format
provisions. However, I failed to work with AT vendors (why should I - it
will be labeled accessible if I meet the standard) and as a result there are
no AT that will work with GDF. Should it be called accessible anyway?
Should we be posting information on social security benefits in this
technology? It is 'accessible' after all. The only problem is that no AT
users can access it.

Hence I think we should be careful here.

1) we should never call things accessible just because they meet the our
standard. Think of cognitive to prove this.

2) we should not think of things as 'meeting our guidelines' via 'at
support" but rather through "AT". That is, there has to actually be AT that
supports it and users have to have access to it -- or they will not be able
to 'access' the E&IT.

This of course also applies to the doc formats. They should be worded such
that 'programmatically determinable' means that is can be determined using
real AT and not just has the potential to be accessible via software.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Wednesday, July 25, 2007 4:18 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
> section added
>
> Norman Robinson wrote:
> a. What is the definition for "accessible content formats"?
>
>
> An accessible content format is one that meets the
> requirements identified in the new "content formats" section
> of the proposed standards. So, for example, if OOXML was
> proposed, it would need to meet the requirements identified
> in that section for the functions it supports in that format.
>
> Norman wrote:
> b. Content is not currently covered in the existing provisions.
> How might content be referenced in the next revision? As a
> file format?
>
>
> Peter Korn wrote:
> Thus we have content accessibility guidelines, including
> specific HTML content accessibility guidelines. These apply
> to HTML content whether they are viewed via an HTTP GET
> request from a website, or a File->Open command within a web
> browser from a local/networked disk, or within a Help
> browser, or from a word processor.
>
> Likewise, we have application accessibility guidelines,
> perhaps including specifically guidelines for applications
> that are a blend of HTML/SVG/whatever and running code (be
> that code Flash or Java or ActiveX or whatever).
>
>
> There are significant challenges with this view of things,
> most especially including harmonization challenges and the
> existing & historical view/language around "Web
> accessibility". But increasingly, making distinctions about
> where a thing comes from is making less and less sense.
>
> Allen continues:
> 1. Define accessibility requirements for formats. Without
> the ability to store appropriate information and the specific
> accessibility attributes, a format can not be made accessible
> by the author, user-agent, and in many circumstances, by the
> assistive technology.
> 1a. Require that the most accessible content format is used.
> 2. Establish that "all content" must be made compliant via
> the accessibility features the format supports.
> 3. provide specific requirements for "web" content since we
> know specific mechanisms that must be employed to meet
> accessibility needs for this area.
> 3a. provide specific requirements for "multimedia" since
> these area already known.
> 4. provide software requirements since we know specific
> requirements for this area.
> 4a. provide authoring tool requirements to improve authors
> ability to use the accessibility attributes in the format
> when available.
> 4b. provide "platform" requirements to ensure that
> accessibility attributes from content are able to be
> represented in a programatic fashion.
> 4c. provide user-agent requirements to ensure that the
> accessibility attributes of content are rendered with all
> appropriate options, and to alleviate some authoring burden
> when some accessibility options can be made at the user-agent
> phase of the delivery chain. Hypothetical example of this is
> the W3C 2 level AA requirement to address blinking after 3
> seconds. If this is implemented as a content requirement all
> authors and testers will need to start authoring and testing
> for this requirement, but if implemented as a user-agent
> requirement, a smaller group of people will have to address
> this problem with a solution.
>
> Norman wrote:
> a. What is the complete definition of "accessibility
> information"?
>
> Allen responds:
> "accessibility information" includes the set of attributes or
> encoding that makes the content meet the requirements for
> that format. For example, if a format allows for insertion
> of images in to a document, and has the alternate text
> function, that would be accessibility information. if it
> also allows tables to be marked up for header/cell
> association, then that would also be in that set of
> attributes. So, at the end of the day the author would be
> bound by the functionality of the format--which is true under
> any condition already.
>
> Norman wrote:
> b. If the user indicates they do not want accessibility
> information does that then imply we could still have
> compliant content?
>
> Allen responds:
> not specifically. but, this arose from the situation where
> someone is working on a draft and just wants to get the work
> in to some shape to then finalize. In this situation they
> may not feel it appropriate to put alt-text on images, mark
> up tables, set headers, etc--but can do so at final
> publication time. There may be better more precise language
> for this situation we can craft--any proposal?
>
> Norman writes:
> a. What are authoring tools without a user interface?
> Bash shell scripts?
> b. Isn't this redundant with the first (#1) statement?
>
> Allen responds:
> first, authoring tools without user-interfaces might be
> transparent items in the work flow. Shell scripts are good!
> Second, maybe, but more precise to such non-interface tools.
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson, Norman B - Washington, DC
> Sent: Wednesday, July 25, 2007 2:38 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
> section added
>
> Regarding "[teitac-websoftware] Authoring Tools -- Wiki
> section added", it was asked for any specific remaining
> concerns for discussion -- in which case also suggestions for
> how to resolve those concerns?
>
> Playing devil's advocate on the Authoring Tool proposed provisions:
>
> 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 electronic
> content accessibility standards.
>
> a. What is the definition for "accessible content formats"?
> b. Content is not currently covered in the existing provisions.
> How might content be referenced in the next revision? As a
> file format?
> If file formats are not covered, how will this work?
>
> 2. Authoring tools must preserve accessibility
> information necessary for meeting the electronic content
> provisions, unless the user explicitly indicates otherwise.
>
> a. What is the complete definition of "accessibility
> information"?
> b. If the user indicates they do not want accessibility
> information does that then imply we could still have
> compliant content?
>
> 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 interoperability
> with evaluation tools that provide that function.
>
> a. What are authoring tools without a user interface?
> Bash shell scripts?
> b. Isn't this redundant with the first (#1) statement?
>
> 4. Authoring tools which provide pre-authored content, or
> templates to facilitate production of content, must provide
> at least one version that meets applicable electronic content
> accessibility standards.
>
> a. What happens when the content doesn't have an
> accessible version? Think of Flash 1.0.
> b. Again, per statement #1 question (b), content is not
> currently covered in the existing provisions. Is content the
> same as a file format? If file formats are not in the
> revision, how will this work?
>
> Finally, questions about the goals regarding authoring tools:
> how is software called "authoring tools" any different from
> any other software under the Section 508 provisions? Why
> can't we simply apply the Section 508 technical software
> standards to "authoring tools"? How are we to get away from
> the logic trap that we are mandating specific features in
> software of type "authoring tools?". Do we do that for any
> other particular type of software? Does this only apply to
> *web based content*? How can the be misused? (e.g., If I use
> Notepad or Bash Shell as an authoring tool, does this really apply?
>
> My suggestion for resolving these concerns:
> 1. Remove the section on authoring tools. Rationale is
> they are no different than any other software!
> 2. Define "accessible content formats" or "file formats"
> required for accessibility in the refresh.
> 3. Address *validation* and *well-formed* in the new
> "file formats" section of the refresh.
>
> Regards,
>
>
> Norman B. Robinson
> Section 508 Coordinator
> IT Governance, US Postal Service
> phone: 202.268.8246
>

From: Sean Hayes
Date: Thu, Jul 26 2007 3:30 AM
Subject: Re: Authoring Tools -- Wiki section added

Filling out a form and clicking on links are examples of operating a user interface. Content may or may not get modified as a result of any action in a user interface, but one would not normally consider the user interface itself as being the content being modified.

Content in my opinion is something that gets persisted to a storage medium, or transmitted over a communication medium, and is considered modified if after it has been read in by running software and written back out again the after image is semantically different to the before image.

What constitutes a semantic difference (as opposed to just an encoding difference) is dependent on the type of the content format.

Sean Hayes
Standards and Policy Team
Corporate Accessibility Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730

From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg Vanderheiden
Sent: 26 July 2007 09:40
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added

If a user fills out a form, or clicks on an expand link - -do they modify content?

Should we change "modify' to "edit" ?

Not a strong concern - just a thought for clarity unless no one else sees a problem.


I would drop "for publication"
Not sure it adds anything in particular.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

From: David Poehlman
Date: Thu, Jul 26 2007 4:30 AM
Subject: Re: Authoring Tools -- Wiki section added

This shold be fixed in the content provisions. The outcome of the content
provisions should be accessibility, not standards which allow content to
fall short of that. The end result of the content provisions must be
accessible content.

----- Original Message -----
From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, July 25, 2007 9:28 PM
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added


I don't think meeting the content format provisions alone makes something
accessible.

It might 'meet accessibility standards' but to be accessible it has to
actually be useable. You must then ask - accessible to who?

Also - one of they key links is the existence of AT that can work with the
technology format.

Assume I create a new document format called the Gregorian Document Format
(GDF). I create the format such that it meets all of the document format
provisions. However, I failed to work with AT vendors (why should I - it
will be labeled accessible if I meet the standard) and as a result there are
no AT that will work with GDF. Should it be called accessible anyway?
Should we be posting information on social security benefits in this
technology? It is 'accessible' after all. The only problem is that no AT
users can access it.

Hence I think we should be careful here.

1) we should never call things accessible just because they meet the our
standard. Think of cognitive to prove this.

2) we should not think of things as 'meeting our guidelines' via 'at
support" but rather through "AT". That is, there has to actually be AT that
supports it and users have to have access to it -- or they will not be able
to 'access' the E&IT.

This of course also applies to the doc formats. They should be worded such
that 'programmatically determinable' means that is can be determined using
real AT and not just has the potential to be accessible via software.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Wednesday, July 25, 2007 4:18 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
> section added
>
> Norman Robinson wrote:
> a. What is the definition for "accessible content formats"?
>
>
> An accessible content format is one that meets the
> requirements identified in the new "content formats" section
> of the proposed standards. So, for example, if OOXML was
> proposed, it would need to meet the requirements identified
> in that section for the functions it supports in that format.
>
> Norman wrote:
> b. Content is not currently covered in the existing provisions.
> How might content be referenced in the next revision? As a
> file format?
>
>
> Peter Korn wrote:
> Thus we have content accessibility guidelines, including
> specific HTML content accessibility guidelines. These apply
> to HTML content whether they are viewed via an HTTP GET
> request from a website, or a File->Open command within a web
> browser from a local/networked disk, or within a Help
> browser, or from a word processor.
>
> Likewise, we have application accessibility guidelines,
> perhaps including specifically guidelines for applications
> that are a blend of HTML/SVG/whatever and running code (be
> that code Flash or Java or ActiveX or whatever).
>
>
> There are significant challenges with this view of things,
> most especially including harmonization challenges and the
> existing & historical view/language around "Web
> accessibility". But increasingly, making distinctions about
> where a thing comes from is making less and less sense.
>
> Allen continues:
> 1. Define accessibility requirements for formats. Without
> the ability to store appropriate information and the specific
> accessibility attributes, a format can not be made accessible
> by the author, user-agent, and in many circumstances, by the
> assistive technology.
> 1a. Require that the most accessible content format is used.
> 2. Establish that "all content" must be made compliant via
> the accessibility features the format supports.
> 3. provide specific requirements for "web" content since we
> know specific mechanisms that must be employed to meet
> accessibility needs for this area.
> 3a. provide specific requirements for "multimedia" since
> these area already known.
> 4. provide software requirements since we know specific
> requirements for this area.
> 4a. provide authoring tool requirements to improve authors
> ability to use the accessibility attributes in the format
> when available.
> 4b. provide "platform" requirements to ensure that
> accessibility attributes from content are able to be
> represented in a programatic fashion.
> 4c. provide user-agent requirements to ensure that the
> accessibility attributes of content are rendered with all
> appropriate options, and to alleviate some authoring burden
> when some accessibility options can be made at the user-agent
> phase of the delivery chain. Hypothetical example of this is
> the W3C 2 level AA requirement to address blinking after 3
> seconds. If this is implemented as a content requirement all
> authors and testers will need to start authoring and testing
> for this requirement, but if implemented as a user-agent
> requirement, a smaller group of people will have to address
> this problem with a solution.
>
> Norman wrote:
> a. What is the complete definition of "accessibility
> information"?
>
> Allen responds:
> "accessibility information" includes the set of attributes or
> encoding that makes the content meet the requirements for
> that format. For example, if a format allows for insertion
> of images in to a document, and has the alternate text
> function, that would be accessibility information. if it
> also allows tables to be marked up for header/cell
> association, then that would also be in that set of
> attributes. So, at the end of the day the author would be
> bound by the functionality of the format--which is true under
> any condition already.
>
> Norman wrote:
> b. If the user indicates they do not want accessibility
> information does that then imply we could still have
> compliant content?
>
> Allen responds:
> not specifically. but, this arose from the situation where
> someone is working on a draft and just wants to get the work
> in to some shape to then finalize. In this situation they
> may not feel it appropriate to put alt-text on images, mark
> up tables, set headers, etc--but can do so at final
> publication time. There may be better more precise language
> for this situation we can craft--any proposal?
>
> Norman writes:
> a. What are authoring tools without a user interface?
> Bash shell scripts?
> b. Isn't this redundant with the first (#1) statement?
>
> Allen responds:
> first, authoring tools without user-interfaces might be
> transparent items in the work flow. Shell scripts are good!
> Second, maybe, but more precise to such non-interface tools.
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson, Norman B - Washington, DC
> Sent: Wednesday, July 25, 2007 2:38 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
> section added
>
> Regarding "[teitac-websoftware] Authoring Tools -- Wiki
> section added", it was asked for any specific remaining
> concerns for discussion -- in which case also suggestions for
> how to resolve those concerns?
>
> Playing devil's advocate on the Authoring Tool proposed provisions:
>
> 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 electronic
> content accessibility standards.
>
> a. What is the definition for "accessible content formats"?
> b. Content is not currently covered in the existing provisions.
> How might content be referenced in the next revision? As a
> file format?
> If file formats are not covered, how will this work?
>
> 2. Authoring tools must preserve accessibility
> information necessary for meeting the electronic content
> provisions, unless the user explicitly indicates otherwise.
>
> a. What is the complete definition of "accessibility
> information"?
> b. If the user indicates they do not want accessibility
> information does that then imply we could still have
> compliant content?
>
> 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 interoperability
> with evaluation tools that provide that function.
>
> a. What are authoring tools without a user interface?
> Bash shell scripts?
> b. Isn't this redundant with the first (#1) statement?
>
> 4. Authoring tools which provide pre-authored content, or
> templates to facilitate production of content, must provide
> at least one version that meets applicable electronic content
> accessibility standards.
>
> a. What happens when the content doesn't have an
> accessible version? Think of Flash 1.0.
> b. Again, per statement #1 question (b), content is not
> currently covered in the existing provisions. Is content the
> same as a file format? If file formats are not in the
> revision, how will this work?
>
> Finally, questions about the goals regarding authoring tools:
> how is software called "authoring tools" any different from
> any other software under the Section 508 provisions? Why
> can't we simply apply the Section 508 technical software
> standards to "authoring tools"? How are we to get away from
> the logic trap that we are mandating specific features in
> software of type "authoring tools?". Do we do that for any
> other particular type of software? Does this only apply to
> *web based content*? How can the be misused? (e.g., If I use
> Notepad or Bash Shell as an authoring tool, does this really apply?
>
> My suggestion for resolving these concerns:
> 1. Remove the section on authoring tools. Rationale is
> they are no different than any other software!
> 2. Define "accessible content formats" or "file formats"
> required for accessibility in the refresh.
> 3. Address *validation* and *well-formed* in the new
> "file formats" section of the refresh.
>
> Regards,
>
>
> Norman B. Robinson
> Section 508 Coordinator
> IT Governance, US Postal Service
> phone: 202.268.8246
>

From: Hoffman, Allen
Date: Thu, Jul 26 2007 8:05 AM
Subject: Re: Authoring Tools -- Wiki section added

outcome of content format provisions can not by itself make content
accessible, as it is a combination of format capacity, authoring usage,
and user-agent, and in some circumstances, assistive technology, that
makes for accessibility. Meeting the set of these is how accessibility
is achieved. Just saying "content must be accessible" won't get us
there, as we have to then say the user-agent must be accessible to, and
if we don't address the content format's underlying capacities to store
the information in an accessible way, then none of this can be
successful.




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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of David
Poehlman
Sent: Thursday, July 26, 2007 6:28 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added

This shold be fixed in the content provisions. The outcome of the
content provisions should be accessibility, not standards which allow
content to fall short of that. The end result of the content provisions
must be accessible content.

----- Original Message -----
From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, July 25, 2007 9:28 PM
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added


I don't think meeting the content format provisions alone makes
something
accessible.

It might 'meet accessibility standards' but to be accessible it has to
actually be useable. You must then ask - accessible to who?

Also - one of they key links is the existence of AT that can work with
the
technology format.

Assume I create a new document format called the Gregorian Document
Format
(GDF). I create the format such that it meets all of the document
format
provisions. However, I failed to work with AT vendors (why should I
- it
will be labeled accessible if I meet the standard) and as a result there
are
no AT that will work with GDF. Should it be called accessible anyway?
Should we be posting information on social security benefits in this
technology? It is 'accessible' after all. The only problem is that no
AT
users can access it.

Hence I think we should be careful here.

1) we should never call things accessible just because they meet the our
standard. Think of cognitive to prove this.

2) we should not think of things as 'meeting our guidelines' via 'at
support" but rather through "AT". That is, there has to actually be AT
that
supports it and users have to have access to it -- or they will not be
able
to 'access' the E&IT.

This of course also applies to the doc formats. They should be worded
such
that 'programmatically determinable' means that is can be determined
using
real AT and not just has the potential to be accessible via software.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Wednesday, July 25, 2007 4:18 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
> section added
>
> Norman Robinson wrote:
> a. What is the definition for "accessible content formats"?
>
>
> An accessible content format is one that meets the
> requirements identified in the new "content formats" section
> of the proposed standards. So, for example, if OOXML was
> proposed, it would need to meet the requirements identified
> in that section for the functions it supports in that format.
>
> Norman wrote:
> b. Content is not currently covered in the existing provisions.
> How might content be referenced in the next revision? As a
> file format?
>
>
> Peter Korn wrote:
> Thus we have content accessibility guidelines, including
> specific HTML content accessibility guidelines. These apply
> to HTML content whether they are viewed via an HTTP GET
> request from a website, or a File->Open command within a web
> browser from a local/networked disk, or within a Help
> browser, or from a word processor.
>
> Likewise, we have application accessibility guidelines,
> perhaps including specifically guidelines for applications
> that are a blend of HTML/SVG/whatever and running code (be
> that code Flash or Java or ActiveX or whatever).
>
>
> There are significant challenges with this view of things,
> most especially including harmonization challenges and the
> existing & historical view/language around "Web
> accessibility". But increasingly, making distinctions about
> where a thing comes from is making less and less sense.
>
> Allen continues:
> 1. Define accessibility requirements for formats. Without
> the ability to store appropriate information and the specific
> accessibility attributes, a format can not be made accessible
> by the author, user-agent, and in many circumstances, by the
> assistive technology.
> 1a. Require that the most accessible content format is used.
> 2. Establish that "all content" must be made compliant via
> the accessibility features the format supports.
> 3. provide specific requirements for "web" content since we
> know specific mechanisms that must be employed to meet
> accessibility needs for this area.
> 3a. provide specific requirements for "multimedia" since
> these area already known.
> 4. provide software requirements since we know specific
> requirements for this area.
> 4a. provide authoring tool requirements to improve authors
> ability to use the accessibility attributes in the format
> when available.
> 4b. provide "platform" requirements to ensure that
> accessibility attributes from content are able to be
> represented in a programatic fashion.
> 4c. provide user-agent requirements to ensure that the
> accessibility attributes of content are rendered with all
> appropriate options, and to alleviate some authoring burden
> when some accessibility options can be made at the user-agent
> phase of the delivery chain. Hypothetical example of this is
> the W3C 2 level AA requirement to address blinking after 3
> seconds. If this is implemented as a content requirement all
> authors and testers will need to start authoring and testing
> for this requirement, but if implemented as a user-agent
> requirement, a smaller group of people will have to address
> this problem with a solution.
>
> Norman wrote:
> a. What is the complete definition of "accessibility
> information"?
>
> Allen responds:
> "accessibility information" includes the set of attributes or
> encoding that makes the content meet the requirements for
> that format. For example, if a format allows for insertion
> of images in to a document, and has the alternate text
> function, that would be accessibility information. if it
> also allows tables to be marked up for header/cell
> association, then that would also be in that set of
> attributes. So, at the end of the day the author would be
> bound by the functionality of the format--which is true under
> any condition already.
>
> Norman wrote:
> b. If the user indicates they do not want accessibility
> information does that then imply we could still have
> compliant content?
>
> Allen responds:
> not specifically. but, this arose from the situation where
> someone is working on a draft and just wants to get the work
> in to some shape to then finalize. In this situation they
> may not feel it appropriate to put alt-text on images, mark
> up tables, set headers, etc--but can do so at final
> publication time. There may be better more precise language
> for this situation we can craft--any proposal?
>
> Norman writes:
> a. What are authoring tools without a user interface?
> Bash shell scripts?
> b. Isn't this redundant with the first (#1) statement?
>
> Allen responds:
> first, authoring tools without user-interfaces might be
> transparent items in the work flow. Shell scripts are good!
> Second, maybe, but more precise to such non-interface tools.
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson, Norman B - Washington, DC
> Sent: Wednesday, July 25, 2007 2:38 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
> section added
>
> Regarding "[teitac-websoftware] Authoring Tools -- Wiki
> section added", it was asked for any specific remaining
> concerns for discussion -- in which case also suggestions for
> how to resolve those concerns?
>
> Playing devil's advocate on the Authoring Tool proposed provisions:
>
> 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 electronic
> content accessibility standards.
>
> a. What is the definition for "accessible content formats"?
> b. Content is not currently covered in the existing provisions.
> How might content be referenced in the next revision? As a
> file format?
> If file formats are not covered, how will this work?
>
> 2. Authoring tools must preserve accessibility
> information necessary for meeting the electronic content
> provisions, unless the user explicitly indicates otherwise.
>
> a. What is the complete definition of "accessibility
> information"?
> b. If the user indicates they do not want accessibility
> information does that then imply we could still have
> compliant content?
>
> 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 interoperability
> with evaluation tools that provide that function.
>
> a. What are authoring tools without a user interface?
> Bash shell scripts?
> b. Isn't this redundant with the first (#1) statement?
>
> 4. Authoring tools which provide pre-authored content, or
> templates to facilitate production of content, must provide
> at least one version that meets applicable electronic content
> accessibility standards.
>
> a. What happens when the content doesn't have an
> accessible version? Think of Flash 1.0.
> b. Again, per statement #1 question (b), content is not
> currently covered in the existing provisions. Is content the
> same as a file format? If file formats are not in the
> revision, how will this work?
>
> Finally, questions about the goals regarding authoring tools:
> how is software called "authoring tools" any different from
> any other software under the Section 508 provisions? Why
> can't we simply apply the Section 508 technical software
> standards to "authoring tools"? How are we to get away from
> the logic trap that we are mandating specific features in
> software of type "authoring tools?". Do we do that for any
> other particular type of software? Does this only apply to
> *web based content*? How can the be misused? (e.g., If I use
> Notepad or Bash Shell as an authoring tool, does this really apply?
>
> My suggestion for resolving these concerns:
> 1. Remove the section on authoring tools. Rationale is
> they are no different than any other software!
> 2. Define "accessible content formats" or "file formats"
> required for accessibility in the refresh.
> 3. Address *validation* and *well-formed* in the new
> "file formats" section of the refresh.
>
> Regards,
>
>
> Norman B. Robinson
> Section 508 Coordinator
> IT Governance, US Postal Service
> phone: 202.268.8246
>

From: William Loughborough
Date: Thu, Jul 26 2007 8:10 AM
Subject: Re: Authoring Tools -- Wiki section added

Gregg Vanderheiden wrote:
>
> If a user fills out a form, or clicks on an expand link - -do they
> modify content?
>
Yes, and the medium through which they do this is an "Authoring Tool"!
>
> Should we change �modify� to �edit� ?
>
Or perhaps "interactively edit"?

Love.

From: Barrett, Don
Date: Thu, Jul 26 2007 1:05 PM
Subject: Re: Authoring Tools -- Wiki section added

Indeed; we have always found in our testing that something might meet
the standard and yet not be accessible for lack of AT support for
example. However, this gives us leverage to go to the AT folks and say,
"fix your AT to work with this compliant or conformant code, and it
usually does get fixed. We have seen agencies which deploy screen
readers which don't support Java applications, deploy Java applications
which of course are not accessible, although by definition, they meet
the standards. Then it becomes a 504 issue. What really matters is
ensuring that the standards promote the capacity to be accessible, which
is the best we can expect.

Don


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, July 25, 2007 9:29 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added

I don't think meeting the content format provisions alone makes
something accessible.

It might 'meet accessibility standards' but to be accessible it has to
actually be useable. You must then ask - accessible to who?

Also - one of they key links is the existence of AT that can work with
the technology format.

Assume I create a new document format called the Gregorian Document
Format
(GDF). I create the format such that it meets all of the document
format
provisions. However, I failed to work with AT vendors (why should I
- it
will be labeled accessible if I meet the standard) and as a result there
are
no AT that will work with GDF. Should it be called accessible anyway?
Should we be posting information on social security benefits in this
technology? It is 'accessible' after all. The only problem is that no
AT
users can access it.

Hence I think we should be careful here.

1) we should never call things accessible just because they meet the our
standard. Think of cognitive to prove this.

2) we should not think of things as 'meeting our guidelines' via 'at
support" but rather through "AT". That is, there has to actually be AT
that supports it and users have to have access to it -- or they will not
be able to 'access' the E&IT.

This of course also applies to the doc formats. They should be worded
such that 'programmatically determinable' means that is can be
determined using real AT and not just has the potential to be accessible
via software.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Hoffman, Allen
> Sent: Wednesday, July 25, 2007 4:18 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section
> added
>
> Norman Robinson wrote:
> a. What is the definition for "accessible content formats"?
>
>
> An accessible content format is one that meets the requirements
> identified in the new "content formats" section of the proposed
> standards. So, for example, if OOXML was proposed, it would need to
> meet the requirements identified in that section for the functions it
> supports in that format.
>
> Norman wrote:
> b. Content is not currently covered in the existing provisions.
> How might content be referenced in the next revision? As a file
> format?
>
>
> Peter Korn wrote:
> Thus we have content accessibility guidelines, including specific HTML

> content accessibility guidelines. These apply to HTML content whether

> they are viewed via an HTTP GET request from a website, or a
> File->Open command within a web browser from a local/networked disk,
> or within a Help browser, or from a word processor.
>
> Likewise, we have application accessibility guidelines, perhaps
> including specifically guidelines for applications that are a blend of

> HTML/SVG/whatever and running code (be that code Flash or Java or
> ActiveX or whatever).
>
>
> There are significant challenges with this view of things, most
> especially including harmonization challenges and the existing &
> historical view/language around "Web accessibility". But
> increasingly, making distinctions about where a thing comes from is
> making less and less sense.
>
> Allen continues:
> 1. Define accessibility requirements for formats. Without the
> ability to store appropriate information and the specific
> accessibility attributes, a format can not be made accessible by the
> author, user-agent, and in many circumstances, by the assistive
> technology.
> 1a. Require that the most accessible content format is used.
> 2. Establish that "all content" must be made compliant via the
> accessibility features the format supports.
> 3. provide specific requirements for "web" content since we know
> specific mechanisms that must be employed to meet accessibility needs
> for this area.
> 3a. provide specific requirements for "multimedia" since these area
> already known.
> 4. provide software requirements since we know specific requirements
> for this area.
> 4a. provide authoring tool requirements to improve authors ability to

> use the accessibility attributes in the format when available.
> 4b. provide "platform" requirements to ensure that accessibility
> attributes from content are able to be represented in a programatic
> fashion.
> 4c. provide user-agent requirements to ensure that the accessibility
> attributes of content are rendered with all appropriate options, and
> to alleviate some authoring burden when some accessibility options can

> be made at the user-agent phase of the delivery chain. Hypothetical
> example of this is the W3C 2 level AA requirement to address blinking
> after 3 seconds. If this is implemented as a content requirement all
> authors and testers will need to start authoring and testing for this
> requirement, but if implemented as a user-agent requirement, a smaller

> group of people will have to address this problem with a solution.
>
> Norman wrote:
> a. What is the complete definition of "accessibility
information"?
>
> Allen responds:
> "accessibility information" includes the set of attributes or encoding

> that makes the content meet the requirements for that format. For
> example, if a format allows for insertion of images in to a document,
> and has the alternate text function, that would be accessibility
> information. if it also allows tables to be marked up for header/cell

> association, then that would also be in that set of attributes. So,
> at the end of the day the author would be bound by the functionality
> of the format--which is true under any condition already.
>
> Norman wrote:
> b. If the user indicates they do not want accessibility
information
> does that then imply we could still have compliant content?
>
> Allen responds:
> not specifically. but, this arose from the situation where someone is

> working on a draft and just wants to get the work in to some shape to
> then finalize. In this situation they may not feel it appropriate to
> put alt-text on images, mark up tables, set headers, etc--but can do
> so at final publication time. There may be better more precise
> language for this situation we can craft--any proposal?
>
> Norman writes:
> a. What are authoring tools without a user interface?
> Bash shell scripts?
> b. Isn't this redundant with the first (#1) statement?
>
> Allen responds:
> first, authoring tools without user-interfaces might be transparent
> items in the work flow. Shell scripts are good!
> Second, maybe, but more precise to such non-interface tools.
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Robinson, Norman B - Washington, DC
> Sent: Wednesday, July 25, 2007 2:38 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section
> added
>
> Regarding "[teitac-websoftware] Authoring Tools -- Wiki section
> added", it was asked for any specific remaining concerns for
> discussion -- in which case also suggestions for how to resolve those
> concerns?
>
> Playing devil's advocate on the Authoring Tool proposed provisions:
>
> 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 electronic content
> accessibility standards.
>
> a. What is the definition for "accessible content formats"?
> b. Content is not currently covered in the existing provisions.
> How might content be referenced in the next revision? As a file
> format?
> If file formats are not covered, how will this work?
>
> 2. Authoring tools must preserve accessibility information
> necessary for meeting the electronic content provisions, unless the
> user explicitly indicates otherwise.
>
> a. What is the complete definition of "accessibility
information"?
> b. If the user indicates they do not want accessibility
information
> does that then imply we could still have compliant content?
>
> 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 interoperability with evaluation tools that provide that
> function.
>
> a. What are authoring tools without a user interface?
> Bash shell scripts?
> b. Isn't this redundant with the first (#1) statement?
>
> 4. Authoring tools which provide pre-authored content, or
> templates to facilitate production of content, must provide at least
> one version that meets applicable electronic content accessibility
> standards.
>
> a. What happens when the content doesn't have an accessible
version?
> Think of Flash 1.0.
> b. Again, per statement #1 question (b), content is not
currently
> covered in the existing provisions. Is content the same as a file
> format? If file formats are not in the revision, how will this work?
>
> Finally, questions about the goals regarding authoring tools:
> how is software called "authoring tools" any different from any other
> software under the Section 508 provisions? Why can't we simply apply
> the Section 508 technical software standards to "authoring tools"? How

> are we to get away from the logic trap that we are mandating specific
> features in software of type "authoring tools?". Do we do that for any

> other particular type of software? Does this only apply to *web based
> content*? How can the be misused? (e.g., If I use Notepad or Bash
> Shell as an authoring tool, does this really apply?
>
> My suggestion for resolving these concerns:
> 1. Remove the section on authoring tools. Rationale is they are
no
> different than any other software!
> 2. Define "accessible content formats" or "file formats"
> required for accessibility in the refresh.
> 3. Address *validation* and *well-formed* in the new "file
formats"
> section of the refresh.
>
> Regards,
>
>
> Norman B. Robinson
> Section 508 Coordinator
> IT Governance, US Postal Service
> phone: 202.268.8246
>