Thread Subject: Proposal (updated 20 June) on authoring tools

Return to this mailing list's archives

From: Judy Brewer
Date: Wed, Jun 20 2007 11:05 AM
Subject: Proposal (updated 20 June) on authoring tools

Dear All,

I have further updated the proposal on authoring tools based on our
discussion at last week's Web/Software meeting and some subsequent
discussion on the mailing list. I've highlighted some of the open questions
remaining for discussion; it would be valuable to get some input into those
questions today, though some of these provisions will need additional
discussion on the list.

The "WAS" text below now refers to last week's proposal; the "UPDATED"
represents best efforts to capture comments since then; and "BECAUSE"
summarizes some of the input. "PROPOSED" means that we appear to have
reached consensus as there are no objections or discussions pending.
"DISCUSS" identifies known remaining questions for discussion.

#1. [WAS] Authoring tools must have the ability to produce content which
passes the electronic content provisions for each content format that
individual tools are capable of producing.
[UPDATED] (no updated wording yet, but possibly go back to...) Authoring
tools must have the ability to produce content which passes the electronic
content provisions.
[BECAUSE] (need info on electronic content provisions, and more on-list
discussion on this one.)
[DISCUSS] On list.

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

#3. [WAS] Authoring tools must provide a mode so that any content that can
be generated by the tool without requiring author input will pass the
electronic content provisions
[UPDATED] (same, unless one of the following is an improvement)
[BECAUSE] At our last teleconference it was requested that a rewording of
this be attempted without the restriction of "mode" or "provide a mode." I
believe that the most direct rewording of this without the "provide a mode"
restriction would be:
- "Any content that can be generated by an authoring tool without requiring
author input must be able to pass the electronic content provisions."
If "generated by" cannot be interpreted to include "converted by," then
perhaps that rewording would work; but if not, the requirement would not be
feasible since converted content would not always include the necessary
accessibility information. Possible alternative re-wordings then would be:
- "With the exception of conversion tools, any content that can be
generated by an authoring tool without requiring author input must be able
to pass the electronic content provisions."
OR:
- "Authoring tools must, with the exception of conversion tools, ensure
that any content that can be generated by the tool without requiring author
input will pass the electronic content provisions."
[DISCUSS] Are any of the possible re-wordings in the "Because" section
above an improvement over the "Was" version above, which includes the
phrase "must provide a mode"?

#4. [WAS] For authoring tools with a user interface, authoring tools must
provide a default mode which prompts authors to create accessible content.
[UPDATED] For authoring tools with a user interface, authoring tools must
prompt authors to create accessible content, unless the default mode is to
produce accessible content.
[BECAUSE] It was noted that prompting does not make sense where the default
mode already results in production of accessible content.
[DISCUSS] Does this wording work?

#5. [WAS] For authoring tools with a user interface, authoring tools must
provide a mode which assists authors in checking for accessibility problems.
[UPDATED] For authoring tools with a user interface, authoring tools must
either provide a mode which assists authors in checking for accessibility
problems, or interoperate with evaluation tools that provide that function.
[BECAUSE] Kept separate so far from #4 because emphasis in #4 now on
required prompting or default, and because there is still on-going
discussion as to on-board evaluation function vs interoperability with
evaluation tools.
[DISCUSS] Does this wording work?

#6. [WAS] Authoring tools, when providing templates or other pre-authored
content, should provide templates that facilitate production of accessible
content, and pre-authored content that is accessible.
[UPDATED] Authoring tools with a user interface must provide templates that
facilitate production of accessible content, and pre-authored content (such
as buttons and form components) that is accessible.
[BECAUSE] It was suggested that this be a "must" rather than a "should";
but it was also noted that this requirement would not make sense for some
kinds of authoring tools, such as those which convert existing content.
Also, clarifications were requested on the meaning of "pre-authored content".
[DISCUSS] (1) Are the examples of "pre-authored content" sufficient, and do
they belong in the provision, or as explanatory notes following the
provision? (2) Several people have expressed concerns about the testability
of this provision, including a question about whether the provision should
specify how many templates, or how much facilitation, should be provided.
Is this provision sufficiently testable?

#7. [WAS] Authoring tools should give prominence to the most accessible
authoring action for achieving an authoring outcome.
[UPDATED] (same)
[BECAUSE] A clarification was requested for "prominence," and was provided
from ATAG 2.0. It was suggested that this be changed from "should" to
"must"; but conversely it was suggested by several people that this be
dropped, and that "most accessible authoring action" is not testable.
[DISCUSS] Is the intent of this provision to ensure that accessible
authoring actions are not buried in the tool interface, and if so, isn't
this at least partially addressed by #4, meaning that this could be dropped?

#8. [DEFINITION] Several people asked and others discussed the definition
of authoring tools. The following definition was drawn from ATAG 2.0:
"...any software, or collection of software components, that authors use to
create or modify Web content for publication." It was also suggested that
this definition be broadened beyond Web-related authoring tools.
[DISCUSS] Does this definition work for authoring tools within TEITAC? Does
the definition still work if "Web" is dropped?

Regards,

- 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: Hoffman, Allen
Date: Wed, Jun 20 2007 11:15 AM
Subject: Re: Proposal (updated 20 June) on authoring tools

I am sorry, I emailed this to myself yesterday not to the group.

Hi folks.
any further thinking on the authoring tools requirements yet?

Here are my changes. I think while these are not as clean and simple as
I might like they are closer.

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.

Rationale:
When content formats allow accessibility information, such as alternate
text for images, to be authored and included in the content, the tool
used to create new content must provide the author a way to create that
information.

Impact:
Medium. Many authoring tools do have functionality to allow access to
and authors use of such attributes, but such functions are often not
well known, or documented.

2. Authoring tools MUST preserve accessibility information within
content accept by explicit user action, or when that change will
increase the compliance of the content.

Rationale:
Often when content is imported in to another tool, or exported to
another tool in the authoring process, accessibility information and
attributes are overwritten, or deleted during the exchange. This causes
authors to recreate the accessibility work for each phase of the
process, and makes any changes to the content very difficult.

Impact:
Low. Authoring tools do know how to import and export content to other
tools, they simply need to include detailed attention to how to address
accessibility attributes for various formats.

3. Authoring tools MUST provide authors the capacity to assess and
remediate content for compliance with the applicable electronic content
accessibility standards. Such functionality MUST include, but is not
limited to, interactively prompting authors for accessibility
information during the authoring process, and when possible, giving
prominence to the most accessible authoring action for achieving a
compliant authoring outcome.

discussion/sufficient techniques:
Discussion/sufficient techniques
Examples of functions which MUST be provided include, but are not
limited to:
Providing a mechanism to author alternate text for non-text elements;
Providing a mechanism to author synchronized captioning for synchronized
audio and video content; Providing a mechanism to associate table
headers and cells; Providing a mechanism to bypass blocks of content;
providing a mechanism to generate a report of all noncompliance
instances from a content item; providing a mechanism to interactively
remediate content accessibility information and offering guidance on
best solutions; providing a mechanism to specify logical reading order;

Rationale:
Authoring tools currently include such features as spell check, grammar
check, red-eye reduction, and many other advanced assessment and
remediation options that authors need to produce professional content.
Accessibility has not been included in such authoring job aids to date
for almost all tools and MUST be provided if accessible electronic
content is ever to be the standard and not the exception. A vast
variety of inaccessible existing content requires update, and during
such update accessibility can, and must be introduced at some point. to
enable everyday authors to complete these tasks, programmatic assistance
is needed.

Impact:
Medium. This may be a major addition to some tools, while not so major
to others. Third party products are now available that integrate to
some extent with authoring tools to provide such functionalities. the
benefit far outweighs the cost for this requirement, since giving the
power of computing to authors for accessibility will greatly increase
their ability to meet these electronic content accessibility standards.



4. Authoring tools which provide preauthored content or templates to
facilitate rapid production of electronic content MUST provide at least
one version that meets applicable electronic content accessibility
standards.

Discussion:
Preauthored content such as memo, report, multimedia movie, picture
album, and fillable form are needed to set the accessibility standard
for such content. Often authors are using pre-existing inaccessible
templates to make their work more consistent and take advantage of
functions the authoring tools have that they are not familiar with.
This strength must be extended to the accessibility arena, and can make
a dramatic impact on production of accessible content.

Impact:
Low. Remediating preauthored content for tools is not a large job, but
the subsequent impact on the accessibility of a wide variety of content
would be disproportionately large in return.








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

-----Original Message-----
From: Judy Brewer [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, June 14, 2007 4:40 PM
To: Sean Hayes; Hoffman, Allen; Andrew Kirkpatrick
Subject: RE: authoring; and electronic content

I'm already scheduled for meetings tomorrow morning and all day Monday.

I think that with some more email rounds we can zero in on wording that
will work. I'm willing to keep synthesizing input from different
perspectives every few days, turning out updated language, and I'm
finding it valuable getting the diverse feedback. The discussion
yesterday was useful even though we didn't nail each provision to the
wall yet. I'll get out a summary of that and new suggested language by
Saturday, with the goal of another update by Tuesday, and hopefully
finalizing most of it by the teleconf on Wednesday.

How's that sound?

- Judy

At 04:38 PM 6/14/2007 +0100, Sean Hayes wrote:

>I m not available tomorrow, as I m away this weekend. I can do Monday.
>
>
>
>Sean Hayes
>Standards and Policy Team
>Corporate Accessibility Group
>Microsoft
>Phone:
> mob +44 7977 455002
> office +44 117 9719730
>
>
>
>From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
>Sent: 14 June 2007 16:07
>To: Andrew Kirkpatrick; Hoffman, Allen; Judy Brewer
>Cc: Sean Hayes
>Subject: RE: authoring; and electronic content
>
>
>
>I have a 9:00-12:30 meeting tomorrow.
>
>I can do it at 8:00ish?
>
>
>
>
>
>Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>
>
>
>
>----------
>From: Andrew Kirkpatrick [mailto: = EMAIL ADDRESS REMOVED = ]
>Sent: Thursday, June 14, 2007 11:02 AM
>To: Hoffman, Allen; Judy Brewer
>Cc: Sean Hayes
>Subject: RE: authoring; and electronic content
>
>I can tomorrow morning. The earlier the better...
>
>AWK
>
>----------
>From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
>Sent: Thursday, June 14, 2007 9:51 AM
>To: Judy Brewer
>Cc: Andrew Kirkpatrick; Sean Hayes
>Subject: authoring; and electronic content
>
>All:
>
>I'm not intentionally attempting to exclude anyone, but wonder if you
>three and i could have a phone discussion this week to talk through
>authoring tool provisions a bit more to get some closure at least for
>us, and then talk about how we think we can address how the provisions
>address "electronic content" as a set specifically. I'm all for
>inclusion, but sometimes the wider conference calls can take more time
>than i may have at my disposal.
>
>note:
>I'd be happy to talk about skip-nav too but can let it continue in the
>list if needed.
>
>
>
>Allen Hoffman
>DHS : CRCL & OCIO;
>DHS Office On Accessible Systems and Technology
>v: 202-447-0303; c: 202-213-1835; tty: 202-401-0725
>email: = EMAIL ADDRESS REMOVED = or = EMAIL ADDRESS REMOVED =
>
>This communication, along with any attachments, is covered by federal
>and state law governing electronic communications and may contain
>sensitive and legally privileged information. If the reader of this
>message is not the intended recipient, you are hereby notified that any

>dissemination, distribution, use or copying of this message is strictly

>prohibited. If you have received this in error, please reply
>immediately to the sender and delete this message.
>
> Thank you.
>
>

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



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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy
Brewer
Sent: Wednesday, June 20, 2007 1:03 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] Proposal (updated 20 June) on authoring
tools

Dear All,

I have further updated the proposal on authoring tools based on our
discussion at last week's Web/Software meeting and some subsequent
discussion on the mailing list. I've highlighted some of the open
questions remaining for discussion; it would be valuable to get some
input into those questions today, though some of these provisions will
need additional discussion on the list.

The "WAS" text below now refers to last week's proposal; the "UPDATED"
represents best efforts to capture comments since then; and "BECAUSE"
summarizes some of the input. "PROPOSED" means that we appear to have
reached consensus as there are no objections or discussions pending.
"DISCUSS" identifies known remaining questions for discussion.

#1. [WAS] Authoring tools must have the ability to produce content which
passes the electronic content provisions for each content format that
individual tools are capable of producing.
[UPDATED] (no updated wording yet, but possibly go back to...) Authoring
tools must have the ability to produce content which passes the
electronic content provisions.
[BECAUSE] (need info on electronic content provisions, and more on-list
discussion on this one.) [DISCUSS] On list.

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

#3. [WAS] Authoring tools must provide a mode so that any content that
can be generated by the tool without requiring author input will pass
the electronic content provisions [UPDATED] (same, unless one of the
following is an improvement) [BECAUSE] At our last teleconference it was
requested that a rewording of this be attempted without the restriction
of "mode" or "provide a mode." I believe that the most direct rewording
of this without the "provide a mode"
restriction would be:
- "Any content that can be generated by an authoring tool without
requiring author input must be able to pass the electronic content
provisions."
If "generated by" cannot be interpreted to include "converted by," then
perhaps that rewording would work; but if not, the requirement would not
be feasible since converted content would not always include the
necessary accessibility information. Possible alternative re-wordings
then would be:
- "With the exception of conversion tools, any content that can be
generated by an authoring tool without requiring author input must be
able to pass the electronic content provisions."
OR:
- "Authoring tools must, with the exception of conversion tools, ensure
that any content that can be generated by the tool without requiring
author input will pass the electronic content provisions."
[DISCUSS] Are any of the possible re-wordings in the "Because" section
above an improvement over the "Was" version above, which includes the
phrase "must provide a mode"?

#4. [WAS] For authoring tools with a user interface, authoring tools
must provide a default mode which prompts authors to create accessible
content.
[UPDATED] For authoring tools with a user interface, authoring tools
must prompt authors to create accessible content, unless the default
mode is to produce accessible content.
[BECAUSE] It was noted that prompting does not make sense where the
default mode already results in production of accessible content.
[DISCUSS] Does this wording work?

#5. [WAS] For authoring tools with a user interface, authoring tools
must provide a mode which assists authors in checking for accessibility
problems.
[UPDATED] For authoring tools with a user interface, authoring tools
must either provide a mode which assists authors in checking for
accessibility problems, or interoperate with evaluation tools that
provide that function.
[BECAUSE] Kept separate so far from #4 because emphasis in #4 now on
required prompting or default, and because there is still on-going
discussion as to on-board evaluation function vs interoperability with
evaluation tools.
[DISCUSS] Does this wording work?

#6. [WAS] Authoring tools, when providing templates or other
pre-authored content, should provide templates that facilitate
production of accessible content, and pre-authored content that is
accessible.
[UPDATED] Authoring tools with a user interface must provide templates
that facilitate production of accessible content, and pre-authored
content (such as buttons and form components) that is accessible.
[BECAUSE] It was suggested that this be a "must" rather than a "should";
but it was also noted that this requirement would not make sense for
some kinds of authoring tools, such as those which convert existing
content.
Also, clarifications were requested on the meaning of "pre-authored
content".
[DISCUSS] (1) Are the examples of "pre-authored content" sufficient, and
do they belong in the provision, or as explanatory notes following the
provision? (2) Several people have expressed concerns about the
testability of this provision, including a question about whether the
provision should specify how many templates, or how much facilitation,
should be provided.
Is this provision sufficiently testable?

#7. [WAS] Authoring tools should give prominence to the most accessible
authoring action for achieving an authoring outcome.
[UPDATED] (same)
[BECAUSE] A clarification was requested for "prominence," and was
provided from ATAG 2.0. It was suggested that this be changed from
"should" to "must"; but conversely it was suggested by several people
that this be dropped, and that "most accessible authoring action" is not
testable.
[DISCUSS] Is the intent of this provision to ensure that accessible
authoring actions are not buried in the tool interface, and if so, isn't
this at least partially addressed by #4, meaning that this could be
dropped?

#8. [DEFINITION] Several people asked and others discussed the
definition of authoring tools. The following definition was drawn from
ATAG 2.0:
"...any software, or collection of software components, that authors use
to create or modify Web content for publication." It was also suggested
that this definition be broadened beyond Web-related authoring tools.
[DISCUSS] Does this definition work for authoring tools within TEITAC?
Does the definition still work if "Web" is dropped?

Regards,

- 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: Judy Brewer
Date: Wed, Jun 20 2007 12:50 PM
Subject: Re: Proposal (updated 20 June) on authoring tools

Alan, sorry that your suggestions were not available when I was preparing
the updated proposals today. I have noted a few questions and comments below.

At 01:07 PM 6/20/2007 -0400, Hoffman, Allen wrote:
>I am sorry, I emailed this to myself yesterday not to the group.
>
>Hi folks.
>any further thinking on the authoring tools requirements yet?
>
>Here are my changes. I think while these are not as clean and simple as
>I might like they are closer.
>
>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.
>
>Rationale:
>When content formats allow accessibility information, such as alternate
>text for images, to be authored and included in the content, the tool
>used to create new content must provide the author a way to create that
>information.

Can you please clarify your rationale for proposing the addition of
"content derived from programmatic sources"?

>Impact:
>Medium. Many authoring tools do have functionality to allow access to
>and authors use of such attributes, but such functions are often not
>well known, or documented.

This provision does not seem to address the prominence of accessible
authoring approaches, only the ability to produce accessible content. Your
impact statement however discusses prominence; so I don't believe that this
impact matches the outcome of this provision.

>2. Authoring tools MUST preserve accessibility information within content
>accept by explicit user action, or when that change will increase the
>compliance of the content.

"accept" should be "except"

What is the rationale for dropping "necessary for meeting the electronic
content provisions"?

Also I'm wondering about the necessity of "when that change will increase
the compliance of the content".

>Rationale:
>Often when content is imported in to another tool, or exported to
>another tool in the authoring process, accessibility information and
>attributes are overwritten, or deleted during the exchange. This causes
>authors to recreate the accessibility work for each phase of the
>process, and makes any changes to the content very difficult.
>
>Impact:
>Low. Authoring tools do know how to import and export content to other
>tools, they simply need to include detailed attention to how to address
>accessibility attributes for various formats.
>
>3. Authoring tools MUST provide authors the capacity to assess and
>remediate content for compliance with the applicable electronic content
>accessibility standards. Such functionality MUST include, but is not
>limited to, interactively prompting authors for accessibility
>information during the authoring process, and when possible, giving
>prominence to the most accessible authoring action for achieving a
>compliant authoring outcome.

There seem to be several open questions in this -- whether all authoring
tools must have evaluation functions on board as opposed to through
interoperability, and what the definition of "most accessible authoring
action" is.

>discussion/sufficient techniques:
>Discussion/sufficient techniques
>Examples of functions which MUST be provided include, but are not
>limited to:
>Providing a mechanism to author alternate text for non-text elements;
>Providing a mechanism to author synchronized captioning for synchronized
>audio and video content; Providing a mechanism to associate table
>headers and cells; Providing a mechanism to bypass blocks of content;
>providing a mechanism to generate a report of all noncompliance
>instances from a content item; providing a mechanism to interactively
>remediate content accessibility information and offering guidance on
>best solutions; providing a mechanism to specify logical reading order;
>
>Rationale:
>Authoring tools currently include such features as spell check, grammar
>check, red-eye reduction, and many other advanced assessment and
>remediation options that authors need to produce professional content.
>Accessibility has not been included in such authoring job aids to date
>for almost all tools and MUST be provided if accessible electronic
>content is ever to be the standard and not the exception. A vast
>variety of inaccessible existing content requires update, and during
>such update accessibility can, and must be introduced at some point. to
>enable everyday authors to complete these tasks, programmatic assistance
>is needed.
>
>Impact:
>Medium. This may be a major addition to some tools, while not so major
>to others. Third party products are now available that integrate to
>some extent with authoring tools to provide such functionalities. the
>benefit far outweighs the cost for this requirement, since giving the
>power of computing to authors for accessibility will greatly increase
>their ability to meet these electronic content accessibility standards.
>
>
>
>4. Authoring tools which provide preauthored content or templates to
>facilitate rapid production of electronic content MUST provide at least
>one version that meets applicable electronic content accessibility
>standards.

The added definition of "templates" here potentially restricts the meaning,
and I'm unclear why it's necessary.

The quantification of "at least one version" may be helpful in addressing
testability concerns which have come up in previous discussion of the
provision on templates.

This proposed rewording however leaves out accessible pre-authored content
(widgets etc) which has been noted in previous discussion to also be an
important facilitator for production of accessible content.

>Discussion:
>Preauthored content such as memo, report, multimedia movie, picture
>album, and fillable form are needed to set the accessibility standard
>for such content. Often authors are using pre-existing inaccessible
>templates to make their work more consistent and take advantage of
>functions the authoring tools have that they are not familiar with.
>This strength must be extended to the accessibility arena, and can make
>a dramatic impact on production of accessible content.
>
>Impact:
>Low. Remediating preauthored content for tools is not a large job, but
>the subsequent impact on the accessibility of a wide variety of content
>would be disproportionately large in return.
>
>
>Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>-----Original Message-----
>From: Judy Brewer [mailto: = EMAIL ADDRESS REMOVED = ]
>Sent: Thursday, June 14, 2007 4:40 PM
>To: Sean Hayes; Hoffman, Allen; Andrew Kirkpatrick
>Subject: RE: authoring; and electronic content
>
>I'm already scheduled for meetings tomorrow morning and all day Monday.
>
>I think that with some more email rounds we can zero in on wording that
>will work. I'm willing to keep synthesizing input from different
>perspectives every few days, turning out updated language, and I'm
>finding it valuable getting the diverse feedback. The discussion
>yesterday was useful even though we didn't nail each provision to the
>wall yet. I'll get out a summary of that and new suggested language by
>Saturday, with the goal of another update by Tuesday, and hopefully
>finalizing most of it by the teleconf on Wednesday.
>
>How's that sound?
>
>- Judy
>
>At 04:38 PM 6/14/2007 +0100, Sean Hayes wrote:
>
> >I m not available tomorrow, as I m away this weekend. I can do Monday.
> >
> >
> >
> >Sean Hayes
> >Standards and Policy Team
> >Corporate Accessibility Group
> >Microsoft
> >Phone:
> > mob +44 7977 455002
> > office +44 117 9719730
> >
> >
> >
> >From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> >Sent: 14 June 2007 16:07
> >To: Andrew Kirkpatrick; Hoffman, Allen; Judy Brewer
> >Cc: Sean Hayes
> >Subject: RE: authoring; and electronic content
> >
> >
> >
> >I have a 9:00-12:30 meeting tomorrow.
> >
> >I can do it at 8:00ish?
> >
> >
> >
> >
> >
> >Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> >
> >
> >
> >
> >----------
> >From: Andrew Kirkpatrick [mailto: = EMAIL ADDRESS REMOVED = ]
> >Sent: Thursday, June 14, 2007 11:02 AM
> >To: Hoffman, Allen; Judy Brewer
> >Cc: Sean Hayes
> >Subject: RE: authoring; and electronic content
> >
> >I can tomorrow morning. The earlier the better...
> >
> >AWK
> >
> >----------
> >From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> >Sent: Thursday, June 14, 2007 9:51 AM
> >To: Judy Brewer
> >Cc: Andrew Kirkpatrick; Sean Hayes
> >Subject: authoring; and electronic content
> >
> >All:
> >
> >I'm not intentionally attempting to exclude anyone, but wonder if you
> >three and i could have a phone discussion this week to talk through
> >authoring tool provisions a bit more to get some closure at least for
> >us, and then talk about how we think we can address how the provisions
> >address "electronic content" as a set specifically. I'm all for
> >inclusion, but sometimes the wider conference calls can take more time
> >than i may have at my disposal.
> >
> >note:
> >I'd be happy to talk about skip-nav too but can let it continue in the
> >list if needed.
> >
> >
> >
> >Allen Hoffman
> >DHS : CRCL & OCIO;
> >DHS Office On Accessible Systems and Technology
> >v: 202-447-0303; c: 202-213-1835; tty: 202-401-0725
> >email: = EMAIL ADDRESS REMOVED = or = EMAIL ADDRESS REMOVED =
> >
> >This communication, along with any attachments, is covered by federal
> >and state law governing electronic communications and may contain
> >sensitive and legally privileged information. If the reader of this
> >message is not the intended recipient, you are hereby notified that any
>
> >dissemination, distribution, use or copying of this message is strictly
>
> >prohibited. If you have received this in error, please reply
> >immediately to the sender and delete this message.
> >
> > Thank you.
> >
> >
>
>--
>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
>
>
>
>Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>-----Original Message-----
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy
>Brewer
>Sent: Wednesday, June 20, 2007 1:03 PM
>To: = EMAIL ADDRESS REMOVED =
>Subject: [teitac-websoftware] Proposal (updated 20 June) on authoring
>tools
>
>Dear All,
>
>I have further updated the proposal on authoring tools based on our
>discussion at last week's Web/Software meeting and some subsequent
>discussion on the mailing list. I've highlighted some of the open
>questions remaining for discussion; it would be valuable to get some
>input into those questions today, though some of these provisions will
>need additional discussion on the list.
>
>The "WAS" text below now refers to last week's proposal; the "UPDATED"
>represents best efforts to capture comments since then; and "BECAUSE"
>summarizes some of the input. "PROPOSED" means that we appear to have
>reached consensus as there are no objections or discussions pending.
>"DISCUSS" identifies known remaining questions for discussion.
>
>#1. [WAS] Authoring tools must have the ability to produce content which
>passes the electronic content provisions for each content format that
>individual tools are capable of producing.
>[UPDATED] (no updated wording yet, but possibly go back to...) Authoring
>tools must have the ability to produce content which passes the
>electronic content provisions.
>[BECAUSE] (need info on electronic content provisions, and more on-list
>discussion on this one.) [DISCUSS] On list.
>
>#2. [PROPOSED] Authoring tools must preserve accessibility information
>necessary for meeting the electronic content provisions unless the user
>explicitly indicates otherwise.
>
>#3. [WAS] Authoring tools must provide a mode so that any content that
>can be generated by the tool without requiring author input will pass
>the electronic content provisions [UPDATED] (same, unless one of the
>following is an improvement) [BECAUSE] At our last teleconference it was
>requested that a rewording of this be attempted without the restriction
>of "mode" or "provide a mode." I believe that the most direct rewording
>of this without the "provide a mode"
>restriction would be:
>- "Any content that can be generated by an authoring tool without
>requiring author input must be able to pass the electronic content
>provisions."
>If "generated by" cannot be interpreted to include "converted by," then
>perhaps that rewording would work; but if not, the requirement would not
>be feasible since converted content would not always include the
>necessary accessibility information. Possible alternative re-wordings
>then would be:
>- "With the exception of conversion tools, any content that can be
>generated by an authoring tool without requiring author input must be
>able to pass the electronic content provisions."
>OR:
>- "Authoring tools must, with the exception of conversion tools, ensure
>that any content that can be generated by the tool without requiring
>author input will pass the electronic content provisions."
>[DISCUSS] Are any of the possible re-wordings in the "Because" section
>above an improvement over the "Was" version above, which includes the
>phrase "must provide a mode"?
>
>#4. [WAS] For authoring tools with a user interface, authoring tools
>must provide a default mode which prompts authors to create accessible
>content.
>[UPDATED] For authoring tools with a user interface, authoring tools
>must prompt authors to create accessible content, unless the default
>mode is to produce accessible content.
>[BECAUSE] It was noted that prompting does not make sense where the
>default mode already results in production of accessible content.
>[DISCUSS] Does this wording work?
>
>#5. [WAS] For authoring tools with a user interface, authoring tools
>must provide a mode which assists authors in checking for accessibility
>problems.
>[UPDATED] For authoring tools with a user interface, authoring tools
>must either provide a mode which assists authors in checking for
>accessibility problems, or interoperate with evaluation tools that
>provide that function.
>[BECAUSE] Kept separate so far from #4 because emphasis in #4 now on
>required prompting or default, and because there is still on-going
>discussion as to on-board evaluation function vs interoperability with
>evaluation tools.
>[DISCUSS] Does this wording work?
>
>#6. [WAS] Authoring tools, when providing templates or other
>pre-authored content, should provide templates that facilitate
>production of accessible content, and pre-authored content that is
>accessible.
>[UPDATED] Authoring tools with a user interface must provide templates
>that facilitate production of accessible content, and pre-authored
>content (such as buttons and form components) that is accessible.
>[BECAUSE] It was suggested that this be a "must" rather than a "should";
>but it was also noted that this requirement would not make sense for
>some kinds of authoring tools, such as those which convert existing
>content.
>Also, clarifications were requested on the meaning of "pre-authored
>content".
>[DISCUSS] (1) Are the examples of "pre-authored content" sufficient, and
>do they belong in the provision, or as explanatory notes following the
>provision? (2) Several people have expressed concerns about the
>testability of this provision, including a question about whether the
>provision should specify how many templates, or how much facilitation,
>should be provided.
>Is this provision sufficiently testable?
>
>#7. [WAS] Authoring tools should give prominence to the most accessible
>authoring action for achieving an authoring outcome.
>[UPDATED] (same)
>[BECAUSE] A clarification was requested for "prominence," and was
>provided from ATAG 2.0. It was suggested that this be changed from
>"should" to "must"; but conversely it was suggested by several people
>that this be dropped, and that "most accessible authoring action" is not
>testable.
>[DISCUSS] Is the intent of this provision to ensure that accessible
>authoring actions are not buried in the tool interface, and if so, isn't
>this at least partially addressed by #4, meaning that this could be
>dropped?
>
>#8. [DEFINITION] Several people asked and others discussed the
>definition of authoring tools. The following definition was drawn from
>ATAG 2.0:
>"...any software, or collection of software components, that authors use
>to create or modify Web content for publication." It was also suggested
>that this definition be broadened beyond Web-related authoring tools.
>[DISCUSS] Does this definition work for authoring tools within TEITAC?
>Does the definition still work if "Web" is dropped?
>
>Regards,
>
>- 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: Hoffman, Allen
Date: Wed, Jun 20 2007 12:55 PM
Subject: Re: Proposal (updated 20 June) on authoring tools

I will reply inline. Look for AWH:


Alan, sorry that your suggestions were not available when I was
preparing the updated proposals today. I have noted a few questions and
comments below.

At 01:07 PM 6/20/2007 -0400, Hoffman, Allen wrote:
>I am sorry, I emailed this to myself yesterday not to the group.
>
>Hi folks.
>any further thinking on the authoring tools requirements yet?
>
>Here are my changes. I think while these are not as clean and simple
>as I might like they are closer.
>
>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.
>
>Rationale:
>When content formats allow accessibility information, such as alternate

>text for images, to be authored and included in the content, the tool
>used to create new content must provide the author a way to create that

>information.

Can you please clarify your rationale for proposing the addition of
"content derived from programmatic sources"?

AWH:
This addresses generated content from previous #3.
>Impact:
>Medium. Many authoring tools do have functionality to allow access to
>and authors use of such attributes, but such functions are often not
>well known, or documented.

This provision does not seem to address the prominence of accessible
authoring approaches, only the ability to produce accessible content.
Your impact statement however discusses prominence; so I don't believe
that this impact matches the outcome of this provision.

AWHL:
My bad, we'll fix.

>2. Authoring tools MUST preserve accessibility information within
>content accept by explicit user action, or when that change will
>increase the compliance of the content.

"accept" should be "except"
AWH: Concur.


What is the rationale for dropping "necessary for meeting the electronic
content provisions"?

AWH: None.

Also I'm wondering about the necessity of "when that change will
increase the compliance of the content".

AWH: To allow for the condition where a tool changes content
automatically but has a way to improve it transparently, or even
interactively.

>Rationale:
>Often when content is imported in to another tool, or exported to
>another tool in the authoring process, accessibility information and
>attributes are overwritten, or deleted during the exchange. This
>causes authors to recreate the accessibility work for each phase of the

>process, and makes any changes to the content very difficult.
>
>Impact:
>Low. Authoring tools do know how to import and export content to other

>tools, they simply need to include detailed attention to how to address

>accessibility attributes for various formats.
>
>3. Authoring tools MUST provide authors the capacity to assess and
>remediate content for compliance with the applicable electronic content

>accessibility standards. Such functionality MUST include, but is not
>limited to, interactively prompting authors for accessibility
>information during the authoring process, and when possible, giving
>prominence to the most accessible authoring action for achieving a
>compliant authoring outcome.

There seem to be several open questions in this -- whether all authoring
tools must have evaluation functions on board as opposed to through
interoperability, and what the definition of "most accessible authoring
action" is.

AWH: Authoring tools are defined that include either stand alone tools
or combinations of tools. We can define "most accessible authoring
action" I think as, "the coding technique that creates content that
meets more electronic content accessibility standards than another.


>discussion/sufficient techniques:
>Discussion/sufficient techniques
>Examples of functions which MUST be provided include, but are not
>limited to:
>Providing a mechanism to author alternate text for non-text elements;
>Providing a mechanism to author synchronized captioning for
>synchronized audio and video content; Providing a mechanism to
>associate table headers and cells; Providing a mechanism to bypass
>blocks of content; providing a mechanism to generate a report of all
>noncompliance instances from a content item; providing a mechanism to
>interactively remediate content accessibility information and offering
>guidance on best solutions; providing a mechanism to specify logical
>reading order;
>
>Rationale:
>Authoring tools currently include such features as spell check, grammar

>check, red-eye reduction, and many other advanced assessment and
>remediation options that authors need to produce professional content.
>Accessibility has not been included in such authoring job aids to date
>for almost all tools and MUST be provided if accessible electronic
>content is ever to be the standard and not the exception. A vast
>variety of inaccessible existing content requires update, and during
>such update accessibility can, and must be introduced at some point.
>to enable everyday authors to complete these tasks, programmatic
>assistance is needed.
>
>Impact:
>Medium. This may be a major addition to some tools, while not so major

>to others. Third party products are now available that integrate to
>some extent with authoring tools to provide such functionalities. the
>benefit far outweighs the cost for this requirement, since giving the
>power of computing to authors for accessibility will greatly increase
>their ability to meet these electronic content accessibility standards.
>
>
>
>4. Authoring tools which provide preauthored content or templates to
>facilitate rapid production of electronic content MUST provide at least

>one version that meets applicable electronic content accessibility
>standards.

The added definition of "templates" here potentially restricts the
meaning, and I'm unclear why it's necessary.

The quantification of "at least one version" may be helpful in
addressing testability concerns which have come up in previous
discussion of the provision on templates.

AWH: I don't think adding "templates" here restricts it, but includes
that concept here.

This proposed rewording however leaves out accessible pre-authored
content (widgets etc) which has been noted in previous discussion to
also be an important facilitator for production of accessible content.

>Discussion:
>Preauthored content such as memo, report, multimedia movie, picture
>album, and fillable form are needed to set the accessibility standard
>for such content. Often authors are using pre-existing inaccessible
>templates to make their work more consistent and take advantage of
>functions the authoring tools have that they are not familiar with.
>This strength must be extended to the accessibility arena, and can make

>a dramatic impact on production of accessible content.
>
>Impact:
>Low. Remediating preauthored content for tools is not a large job, but

>the subsequent impact on the accessibility of a wide variety of content

>would be disproportionately large in return.
>
>
AWH:
We can certainly develop a list of pre-authored items to include in the
supporting documentation beyond templates.

>Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>-----Original Message-----
>From: Judy Brewer [mailto: = EMAIL ADDRESS REMOVED = ]
>Sent: Thursday, June 14, 2007 4:40 PM
>To: Sean Hayes; Hoffman, Allen; Andrew Kirkpatrick
>Subject: RE: authoring; and electronic content
>
>I'm already scheduled for meetings tomorrow morning and all day Monday.
>
>I think that with some more email rounds we can zero in on wording that

>will work. I'm willing to keep synthesizing input from different
>perspectives every few days, turning out updated language, and I'm
>finding it valuable getting the diverse feedback. The discussion
>yesterday was useful even though we didn't nail each provision to the
>wall yet. I'll get out a summary of that and new suggested language by
>Saturday, with the goal of another update by Tuesday, and hopefully
>finalizing most of it by the teleconf on Wednesday.
>
>How's that sound?
>
>- Judy
>
>At 04:38 PM 6/14/2007 +0100, Sean Hayes wrote:
>
> >I m not available tomorrow, as I m away this weekend. I can do
Monday.
> >
> >
> >
> >Sean Hayes
> >Standards and Policy Team
> >Corporate Accessibility Group
> >Microsoft
> >Phone:
> > mob +44 7977 455002
> > office +44 117 9719730
> >
> >
> >
> >From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> >Sent: 14 June 2007 16:07
> >To: Andrew Kirkpatrick; Hoffman, Allen; Judy Brewer
> >Cc: Sean Hayes
> >Subject: RE: authoring; and electronic content
> >
> >
> >
> >I have a 9:00-12:30 meeting tomorrow.
> >
> >I can do it at 8:00ish?
> >
> >
> >
> >
> >
> >Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> >
> >
> >
> >
> >----------
> >From: Andrew Kirkpatrick [mailto: = EMAIL ADDRESS REMOVED = ]
> >Sent: Thursday, June 14, 2007 11:02 AM
> >To: Hoffman, Allen; Judy Brewer
> >Cc: Sean Hayes
> >Subject: RE: authoring; and electronic content
> >
> >I can tomorrow morning. The earlier the better...
> >
> >AWK
> >
> >----------
> >From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> >Sent: Thursday, June 14, 2007 9:51 AM
> >To: Judy Brewer
> >Cc: Andrew Kirkpatrick; Sean Hayes
> >Subject: authoring; and electronic content
> >
> >All:
> >
> >I'm not intentionally attempting to exclude anyone, but wonder if you

> >three and i could have a phone discussion this week to talk through
> >authoring tool provisions a bit more to get some closure at least for

> >us, and then talk about how we think we can address how the
> >provisions address "electronic content" as a set specifically. I'm
> >all for inclusion, but sometimes the wider conference calls can take
> >more time than i may have at my disposal.
> >
> >note:
> >I'd be happy to talk about skip-nav too but can let it continue in
> >the list if needed.
> >
> >
> >
> >Allen Hoffman
> >DHS : CRCL & OCIO;
> >DHS Office On Accessible Systems and Technology
> >v: 202-447-0303; c: 202-213-1835; tty: 202-401-0725
> >email: = EMAIL ADDRESS REMOVED = or = EMAIL ADDRESS REMOVED =
> >
> >This communication, along with any attachments, is covered by federal

> >and state law governing electronic communications and may contain
> >sensitive and legally privileged information. If the reader of this
> >message is not the intended recipient, you are hereby notified that
> >any
>
> >dissemination, distribution, use or copying of this message is
> >strictly
>
> >prohibited. If you have received this in error, please reply
> >immediately to the sender and delete this message.
> >
> > Thank you.
> >
> >
>
>--
>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
>
>
>
>Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>-----Original Message-----
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy
>Brewer
>Sent: Wednesday, June 20, 2007 1:03 PM
>To: = EMAIL ADDRESS REMOVED =
>Subject: [teitac-websoftware] Proposal (updated 20 June) on authoring
>tools
>
>Dear All,
>
>I have further updated the proposal on authoring tools based on our
>discussion at last week's Web/Software meeting and some subsequent
>discussion on the mailing list. I've highlighted some of the open
>questions remaining for discussion; it would be valuable to get some
>input into those questions today, though some of these provisions will
>need additional discussion on the list.
>
>The "WAS" text below now refers to last week's proposal; the "UPDATED"
>represents best efforts to capture comments since then; and "BECAUSE"
>summarizes some of the input. "PROPOSED" means that we appear to have
>reached consensus as there are no objections or discussions pending.
>"DISCUSS" identifies known remaining questions for discussion.
>
>#1. [WAS] Authoring tools must have the ability to produce content
>which passes the electronic content provisions for each content format
>that individual tools are capable of producing.
>[UPDATED] (no updated wording yet, but possibly go back to...)
>Authoring tools must have the ability to produce content which passes
>the electronic content provisions.
>[BECAUSE] (need info on electronic content provisions, and more on-list

>discussion on this one.) [DISCUSS] On list.
>
>#2. [PROPOSED] Authoring tools must preserve accessibility information
>necessary for meeting the electronic content provisions unless the user

>explicitly indicates otherwise.
>
>#3. [WAS] Authoring tools must provide a mode so that any content that
>can be generated by the tool without requiring author input will pass
>the electronic content provisions [UPDATED] (same, unless one of the
>following is an improvement) [BECAUSE] At our last teleconference it
>was requested that a rewording of this be attempted without the
>restriction of "mode" or "provide a mode." I believe that the most
>direct rewording of this without the "provide a mode"
>restriction would be:
>- "Any content that can be generated by an authoring tool without
>requiring author input must be able to pass the electronic content
>provisions."
>If "generated by" cannot be interpreted to include "converted by," then

>perhaps that rewording would work; but if not, the requirement would
>not be feasible since converted content would not always include the
>necessary accessibility information. Possible alternative re-wordings
>then would be:
>- "With the exception of conversion tools, any content that can be
>generated by an authoring tool without requiring author input must be
>able to pass the electronic content provisions."
>OR:
>- "Authoring tools must, with the exception of conversion tools, ensure

>that any content that can be generated by the tool without requiring
>author input will pass the electronic content provisions."
>[DISCUSS] Are any of the possible re-wordings in the "Because" section
>above an improvement over the "Was" version above, which includes the
>phrase "must provide a mode"?
>
>#4. [WAS] For authoring tools with a user interface, authoring tools
>must provide a default mode which prompts authors to create accessible
>content.
>[UPDATED] For authoring tools with a user interface, authoring tools
>must prompt authors to create accessible content, unless the default
>mode is to produce accessible content.
>[BECAUSE] It was noted that prompting does not make sense where the
>default mode already results in production of accessible content.
>[DISCUSS] Does this wording work?
>
>#5. [WAS] For authoring tools with a user interface, authoring tools
>must provide a mode which assists authors in checking for accessibility

>problems.
>[UPDATED] For authoring tools with a user interface, authoring tools
>must either provide a mode which assists authors in checking for
>accessibility problems, or interoperate with evaluation tools that
>provide that function.
>[BECAUSE] Kept separate so far from #4 because emphasis in #4 now on
>required prompting or default, and because there is still on-going
>discussion as to on-board evaluation function vs interoperability with
>evaluation tools.
>[DISCUSS] Does this wording work?
>
>#6. [WAS] Authoring tools, when providing templates or other
>pre-authored content, should provide templates that facilitate
>production of accessible content, and pre-authored content that is
>accessible.
>[UPDATED] Authoring tools with a user interface must provide templates
>that facilitate production of accessible content, and pre-authored
>content (such as buttons and form components) that is accessible.
>[BECAUSE] It was suggested that this be a "must" rather than a
>"should"; but it was also noted that this requirement would not make
>sense for some kinds of authoring tools, such as those which convert
>existing content.
>Also, clarifications were requested on the meaning of "pre-authored
>content".
>[DISCUSS] (1) Are the examples of "pre-authored content" sufficient,
>and do they belong in the provision, or as explanatory notes following
>the provision? (2) Several people have expressed concerns about the
>testability of this provision, including a question about whether the
>provision should specify how many templates, or how much facilitation,
>should be provided.
>Is this provision sufficiently testable?
>
>#7. [WAS] Authoring tools should give prominence to the most accessible

>authoring action for achieving an authoring outcome.
>[UPDATED] (same)
>[BECAUSE] A clarification was requested for "prominence," and was
>provided from ATAG 2.0. It was suggested that this be changed from
>"should" to "must"; but conversely it was suggested by several people
>that this be dropped, and that "most accessible authoring action" is
>not testable.
>[DISCUSS] Is the intent of this provision to ensure that accessible
>authoring actions are not buried in the tool interface, and if so,
>isn't this at least partially addressed by #4, meaning that this could
>be dropped?
>
>#8. [DEFINITION] Several people asked and others discussed the
>definition of authoring tools. The following definition was drawn from
>ATAG 2.0:
>"...any software, or collection of software components, that authors
>use to create or modify Web content for publication." It was also
>suggested that this definition be broadened beyond Web-related
authoring tools.
>[DISCUSS] Does this definition work for authoring tools within TEITAC?
>Does the definition still work if "Web" is dropped?
>
>Regards,
>
>- 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: Judy Brewer
Date: Thu, Jun 21 2007 11:45 AM
Subject: Re: Proposal (updated 20 June) on authoring tools

Replies inline, with JB:

At 02:50 PM 6/20/2007 -0400, Hoffman, Allen wrote:
>I will reply inline. Look for AWH:
><...>
> >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.
> >
> >Rationale:
> >When content formats allow accessibility information, such as alternate
> >text for images, to be authored and included in the content, the tool
> >used to create new content must provide the author a way to create that
>
> >information.
>
>Can you please clarify your rationale for proposing the addition of
>"content derived from programmatic sources"?
>
>AWH:
>This addresses generated content from previous #3.

JB: The phrasing in the previous #3 was "any content that can be generated
by the tool without requiring author input." Looking up definitions of
programmatically determined from WCAG 2.0
http://www.w3.org/TR/WCAG20/#programmaticallydetermineddef
it appears that the meaning of programmatically determined might be
narrower than "any content that can be generated by the tool without
requiring author input."

JB: If we are seeking a way to combine #1 and #3 then I would tend to bring
in the original wording from #3, unless anyone else wants to weigh in and
verify that these are exactly the same, or that programmatically determined
would be sufficient here.

<...>
> >2. Authoring tools MUST preserve accessibility information within
> content accept by explicit user action, or when that change will increase
> the compliance of the content.
<...>
>What is the rationale for dropping "necessary for meeting the electronic
>content provisions"?
>
>AWH: None.

JB: Perhaps the phrase is unnecessary, since ideally all accessibility
information would be preserved, and in any case there is an easy out which
is "except by explicit user action."

>Also I'm wondering about the necessity of "when that change will increase
>the compliance of the content".
>
>AWH: To allow for the condition where a tool changes content
>automatically but has a way to improve it transparently, or even interactively.

JB: Understood.

<...>
> >3. Authoring tools MUST provide authors the capacity to assess and
> >remediate content for compliance with the applicable electronic content
> >accessibility standards. Such functionality MUST include, but is not
> >limited to, interactively prompting authors for accessibility
> >information during the authoring process, and when possible, giving
> >prominence to the most accessible authoring action for achieving a
> >compliant authoring outcome.
>
>There seem to be several open questions in this -- whether all authoring
>tools must have evaluation functions on board as opposed to through
>interoperability, and what the definition of "most accessible authoring
>action" is.
>
>AWH: Authoring tools are defined that include either stand alone tools
>or combinations of tools. We can define "most accessible authoring
>action" I think as, "the coding technique that creates content that
>meets more electronic content accessibility standards than another.

JB: For those who have commented that a definition of "most accessible
authoring action" was needed, does this work for you?

<...>

> >4. Authoring tools which provide preauthored content or templates to
> >facilitate rapid production of electronic content MUST provide at least
>
> >one version that meets applicable electronic content accessibility
> >standards.
>
>The added definition of "templates" here potentially restricts the
>meaning, and I'm unclear why it's necessary.
>
>The quantification of "at least one version" may be helpful in
>addressing testability concerns which have come up in previous
>discussion of the provision on templates.
>
>AWH: I don't think adding "templates" here restricts it, but includes
>that concept here.

JB: My concern was not about adding "templates" since that was already
included in the previous language. My concern was the added clause
following "templates": "...to facilitate rapid production of electronic
content." In adding this explanation of templates, you also may be
restricting its meaning. Templates are required in some organizations to
standardize the organization of the content that is created and published
within that organization. In some cases, those templates might slow down,
not speed up, content creation, if otherwise people would be throwing
non-standard Web pages on the site. So I don't think that the explanation
"...to facilitate rapid production of electronic content" belongs in the
provision.

>This proposed rewording however leaves out accessible pre-authored
>content (widgets etc) which has been noted in previous discussion to
>also be an important facilitator for production of accessible content.
>
> >Discussion:
> >Preauthored content such as memo, report, multimedia movie, picture
> >album, and fillable form are needed to set the accessibility standard
> >for such content. Often authors are using pre-existing inaccessible
> >templates to make their work more consistent and take advantage of
> >functions the authoring tools have that they are not familiar with.
> >This strength must be extended to the accessibility arena, and can make
>
> >a dramatic impact on production of accessible content.
> >
> >Impact:
> >Low. Remediating preauthored content for tools is not a large job, but
> >the subsequent impact on the accessibility of a wide variety of content
> >would be disproportionately large in return.
> >
>AWH:
>We can certainly develop a list of pre-authored items to include in the
>supporting documentation beyond templates.

JB: Yes I think it would help to have examples of pre-authored items.
Perhaps the examples do not belong in the provisions -- however, the
expectation would have to be clear enough to be testable.

- 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: Andrew Kirkpatrick
Date: Fri, Jun 22 2007 9:20 AM
Subject: Re: Proposal (updated 20 June) on authoring tools

Replies inline, with "AWK"

> > >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.
> > >
> > >Rationale:
> > >When content formats allow accessibility information, such as
> > >alternate text for images, to be authored and included in the
> > >content, the tool used to create new content must provide
> the author
> > >a way to create that
> >
> > >information.
> >
> >Can you please clarify your rationale for proposing the addition of
> >"content derived from programmatic sources"?
> >
> >AWH:
> >This addresses generated content from previous #3.
>
> JB: The phrasing in the previous #3 was "any content that can
> be generated by the tool without requiring author input."
> Looking up definitions of programmatically determined from
> WCAG 2.0 http://www.w3.org/TR/WCAG20/#programmaticallydetermineddef
> it appears that the meaning of programmatically determined
> might be narrower than "any content that can be generated by
> the tool without requiring author input."
>
> JB: If we are seeking a way to combine #1 and #3 then I would
> tend to bring in the original wording from #3, unless anyone
> else wants to weigh in and verify that these are exactly the
> same, or that programmatically determined would be sufficient here.

AWK: I support the idea of this standard, but with "authoring tool"
potentially meaning "multiple tools in a process" I'm not sure that
there is such a thing as automatically-generated content. We have a
product that creates a flash-based version of a Microsoft PowerPoint
slideshow. You can't add an equivalent to an image but if it is in the
PowerPoint slides it is included - my "authoring tool" is PowerPoint and
the Adobe product" and the Powerpoint portion is part of the process
that is non-automatic, but we're evaluating based on the whole "tool".

> <...>
> > >2. Authoring tools MUST preserve accessibility information within
> > content accept by explicit user action, or when that change will
> > increase the compliance of the content.
> <...>
> >What is the rationale for dropping "necessary for meeting the
> >electronic content provisions"?
> >
> >AWH: None.
>
> JB: Perhaps the phrase is unnecessary, since ideally all
> accessibility information would be preserved, and in any case
> there is an easy out which is "except by explicit user action."
>
> >Also I'm wondering about the necessity of "when that change will
> >increase the compliance of the content".
> >
> >AWH: To allow for the condition where a tool changes content
> >automatically but has a way to improve it transparently, or
> even interactively.
>
> JB: Understood.

AWK: Is there a possible world where a tool can meet #1 and not meet #2?
If so, why have #2?

> <...>
> > >3. Authoring tools MUST provide authors the capacity to
> assess and
> > >remediate content for compliance with the applicable electronic
> > >content accessibility standards. Such functionality MUST include,
> > >but is not limited to, interactively prompting authors for
> > >accessibility information during the authoring process, and when
> > >possible, giving prominence to the most accessible
> authoring action
> > >for achieving a compliant authoring outcome.
> >
> >There seem to be several open questions in this -- whether all
> >authoring tools must have evaluation functions on board as
> opposed to
> >through interoperability, and what the definition of "most
> accessible
> >authoring action" is.
> >
> >AWH: Authoring tools are defined that include either stand
> alone tools
> >or combinations of tools. We can define "most accessible authoring
> >action" I think as, "the coding technique that creates content that
> >meets more electronic content accessibility standards than another.
>
> JB: For those who have commented that a definition of "most
> accessible authoring action" was needed, does this work for you?

AWK: I think that this is easy to agree to for certain items (e.g.
adding image equivalents) but there are other situations where many
different workflows can be used, depending on the author's preferences
or their working situation that would make defining the most accessible
authoring action somewhere between impossible and merely contentious. I
can hear our developer-customers saying "don't force me into _your_
path, tell me what I need to do (e.g. meet the 1194.21 or .22 standards)
and I'll figure out the best way to accomplish that for the way I work".


> <...>
>
> > >4. Authoring tools which provide preauthored content or
> templates to
> > >facilitate rapid production of electronic content MUST provide at
> > >least
> >
> > >one version that meets applicable electronic content accessibility
> > >standards.
> >
> >The added definition of "templates" here potentially restricts the
> >meaning, and I'm unclear why it's necessary.
> >
> >The quantification of "at least one version" may be helpful in
> >addressing testability concerns which have come up in previous
> >discussion of the provision on templates.
> >
> >AWH: I don't think adding "templates" here restricts it,
> but includes
> >that concept here.
>
> JB: My concern was not about adding "templates" since that
> was already included in the previous language. My concern was
> the added clause following "templates": "...to facilitate
> rapid production of electronic content." In adding this
> explanation of templates, you also may be restricting its
> meaning. Templates are required in some organizations to
> standardize the organization of the content that is created
> and published within that organization. In some cases, those
> templates might slow down, not speed up, content creation, if
> otherwise people would be throwing non-standard Web pages on
> the site. So I don't think that the explanation "...to
> facilitate rapid production of electronic content" belongs in
> the provision.

AWK: As has been stated before, many aspects of designing an accessible
web page require author input and can't be made part of a template. I'm
concerned about how this gets scoped against the web content standards
as a result.

AWK

From: Judy Brewer
Date: Tue, Jun 26 2007 11:20 PM
Subject: Re: Proposal (updated 20 June) on authoring tools

Replies inline, with JB:

At 08:15 AM 6/22/2007 -0700, Andrew Kirkpatrick wrote:
>Replies inline, with "AWK"
>
> > > >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.
> > > >
> > > >Rationale:
> > > >When content formats allow accessibility information, such as
> > > >alternate text for images, to be authored and included in the
> > > >content, the tool used to create new content must provide the author
> > > >a way to create that information.
> > >
> > >Can you please clarify your rationale for proposing the addition of
> > >"content derived from programmatic sources"?
> > >
> > >AWH:
> > >This addresses generated content from previous #3.
> >
> > JB: The phrasing in the previous #3 was "any content that can
> > be generated by the tool without requiring author input."
> > Looking up definitions of programmatically determined from
> > WCAG 2.0 http://www.w3.org/TR/WCAG20/#programmaticallydetermineddef
> > it appears that the meaning of programmatically determined
> > might be narrower than "any content that can be generated by
> > the tool without requiring author input."
> >
> > JB: If we are seeking a way to combine #1 and #3 then I would
> > tend to bring in the original wording from #3, unless anyone
> > else wants to weigh in and verify that these are exactly the
> > same, or that programmatically determined would be sufficient here.
>
>AWK: I support the idea of this standard, but with "authoring tool"
>potentially meaning "multiple tools in a process" I'm not sure that
>there is such a thing as automatically-generated content. We have a
>product that creates a flash-based version of a Microsoft PowerPoint
>slideshow. You can't add an equivalent to an image

JB: There's no way in this product to add an equivalent to an image that
doesn't have one yet, when it is bringing in converted content? Seems that
this would be useful to have.

>but if it is in the PowerPoint slides it is included - my "authoring tool"
>is PowerPoint and
>the Adobe product" and the Powerpoint portion is part of the process
>that is non-automatic, but we're evaluating based on the whole "tool".
>
> > <...>
> > > >2. Authoring tools MUST preserve accessibility information within
> > > content accept by explicit user action, or when that change will
> > > increase the compliance of the content.
> > <...>
> > >What is the rationale for dropping "necessary for meeting the
> > >electronic content provisions"?
> > >
> > >AWH: None.
> >
> > JB: Perhaps the phrase is unnecessary, since ideally all
> > accessibility information would be preserved, and in any case
> > there is an easy out which is "except by explicit user action."
> >
> > >Also I'm wondering about the necessity of "when that change will
> > >increase the compliance of the content".
> > >
> > >AWH: To allow for the condition where a tool changes content
> > >automatically but has a way to improve it transparently, or
> > even interactively.
> >
> > JB: Understood.
>
>AWK: Is there a possible world where a tool can meet #1 and not meet #2?
>If so, why have #2?

JB: #1 addresses the ability to produce accessible content; #2 addresses
the preservation of accessibility information in existing content.
[Unfortunately] it is possible for an authoring tool to be able to produce
accessible content, yet also strip out existing accessibility information.
Therefore these are two separate problems, and I believe that it is both
appropriate and necessary to have both provisions.

> > <...>
> > > >3. Authoring tools MUST provide authors the capacity to assess and
> > > >remediate content for compliance with the applicable electronic
> > > >content accessibility standards. Such functionality MUST include,
> > > >but is not limited to, interactively prompting authors for
> > > >accessibility information during the authoring process, and when
> > > >possible, giving prominence to the most accessible authoring action
> > > >for achieving a compliant authoring outcome.
> > >
> > >There seem to be several open questions in this -- whether all
> > >authoring tools must have evaluation functions on board as
> > opposed to through interoperability, and what the definition of "most
> > accessible authoring action" is.
> > >
> > >AWH: Authoring tools are defined that include either stand
> > alone tools
> > >or combinations of tools. We can define "most accessible authoring
> > >action" I think as, "the coding technique that creates content that
> > >meets more electronic content accessibility standards than another.
> >
> > JB: For those who have commented that a definition of "most
> > accessible authoring action" was needed, does this work for you?
>
>AWK: I think that this is easy to agree to for certain items (e.g.
>adding image equivalents) but there are other situations where many
>different workflows can be used, depending on the author's preferences
>or their working situation that would make defining the most accessible
>authoring action somewhere between impossible and merely contentious. I
>can hear our developer-customers saying "don't force me into _your_
>path, tell me what I need to do (e.g. meet the 1194.21 or .22 standards)
>and I'll figure out the best way to accomplish that for the way I work".

JB: There doesn't seem to be any need to identify what "*the most*
accessible authoring action" in a given situation would be, but rather to
give prominence to "accessible authoring actions," or "authoring actions
that support production of accessible content." This would remove the
problem of potentially forcing a specific workflow onto people. Jan
Richards had suggested the following wording, which I think is an
improvement: "An alternative proposal would be 'Authoring tools should give
prominence to accessible authoring actions for achieving an authoring outcome."

> > <...>
> > > >4. Authoring tools which provide preauthored content or templates to
> > > >facilitate rapid production of electronic content MUST provide at least
> > > >one version that meets applicable electronic content accessibility
> > > >standards.
> > >
> > >The added definition of "templates" here potentially restricts the
> > >meaning, and I'm unclear why it's necessary.
> > >
> > >The quantification of "at least one version" may be helpful in
> > >addressing testability concerns which have come up in previous
> > >discussion of the provision on templates.
> > >
> > >AWH: I don't think adding "templates" here restricts it,
> > but includes that concept here.
> >
> > JB: My concern was not about adding "templates" since that
> > was already included in the previous language. My concern was
> > the added clause following "templates": "...to facilitate
> > rapid production of electronic content." In adding this
> > explanation of templates, you also may be restricting its
> > meaning. Templates are required in some organizations to
> > standardize the organization of the content that is created
> > and published within that organization. In some cases, those
> > templates might slow down, not speed up, content creation, if
> > otherwise people would be throwing non-standard Web pages on
> > the site. So I don't think that the explanation "...to
> > facilitate rapid production of electronic content" belongs in
> > the provision.
>
>AWK: As has been stated before, many aspects of designing an accessible
>web page require author input and can't be made part of a template. I'm
>concerned about how this gets scoped against the web content standards
>as a result.

JB: I'm not sure that there's an assumption that templates would encompass
all possible author actions. It seems that some author input needed for
development of an accessible Web page would be possible to do through a
template, and some might need to be done outside a template. The version of
the draft language on this above reads: "Authoring tools which provide
preauthored content or templates to facilitate rapid production of
electronic content MUST provide at least one version that meets applicable
electronic content accessibility standards." If it's not possible to do the
given authoring action within a template, wouldn't that content
accessibility standard be not applicable? Do you have a different
suggestion for how to scope this?

Regards,

- Judy

>
>AWK
>

From: Andrew Kirkpatrick
Date: Wed, Jun 27 2007 7:10 AM
Subject: Re: Proposal (updated 20 June) on authoring tools

> >AWK: I support the idea of this standard, but with "authoring tool"
> >potentially meaning "multiple tools in a process" I'm not sure that
> >there is such a thing as automatically-generated content. We have a
> >product that creates a flash-based version of a Microsoft PowerPoint
> >slideshow. You can't add an equivalent to an image
>
> JB: There's no way in this product to add an equivalent to an
> image that doesn't have one yet, when it is bringing in
> converted content? Seems that this would be useful to have.

In this "authoring tool" there is, it is through the interface in
PowerPoint. We have other products that provide the ability to do
editiing, but this particular product is just a simple push-button to
generate content (and do so accessibly if fed the right information).

> >AWK: Is there a possible world where a tool can meet #1 and
> not meet #2?
> >If so, why have #2?
>
> JB: #1 addresses the ability to produce accessible content;
> #2 addresses the preservation of accessibility information in
> existing content.
> [Unfortunately] it is possible for an authoring tool to be
> able to produce accessible content, yet also strip out
> existing accessibility information.
> Therefore these are two separate problems, and I believe that
> it is both appropriate and necessary to have both provisions.

I think that you're splitting a hair here. The goal is to generate
accessible content, and if the tool does that it should be OK. I think
that #1 is sufficient.

> JB: There doesn't seem to be any need to identify what "*the
> most* accessible authoring action" in a given situation would
> be, but rather to give prominence to "accessible authoring
> actions," or "authoring actions that support production of
> accessible content." This would remove the problem of
> potentially forcing a specific workflow onto people. Jan
> Richards had suggested the following wording, which I think is an
> improvement: "An alternative proposal would be 'Authoring
> tools should give prominence to accessible authoring actions
> for achieving an authoring outcome."

This doesn't address the issue that there are many ways to accomplish
different tasks - how do we choose which to give prominence to? Any
what exactly does "give prominence" mean?

> >AWK: As has been stated before, many aspects of designing an
> accessible
> >web page require author input and can't be made part of a template.
> >I'm concerned about how this gets scoped against the web content
> >standards as a result.
>
> JB: I'm not sure that there's an assumption that templates
> would encompass all possible author actions. It seems that
> some author input needed for development of an accessible Web
> page would be possible to do through a template, and some
> might need to be done outside a template. The version of the
> draft language on this above reads: "Authoring tools which
> provide preauthored content or templates to facilitate rapid
> production of electronic content MUST provide at least one
> version that meets applicable electronic content
> accessibility standards." If it's not possible to do the
> given authoring action within a template, wouldn't that
> content accessibility standard be not applicable? Do you have
> a different suggestion for how to scope this?

I'll have to think on this a bit.

AWK

From: Judy Brewer
Date: Wed, Jun 27 2007 8:10 AM
Subject: Re: Proposal (updated 20 June) on authoring tools

At 06:06 AM 6/27/2007 -0700, Andrew Kirkpatrick wrote:
> > >AWK: I support the idea of this standard, but with "authoring tool"
> > >potentially meaning "multiple tools in a process" I'm not sure that
> > >there is such a thing as automatically-generated content. We have a
> > >product that creates a flash-based version of a Microsoft PowerPoint
> > >slideshow. You can't add an equivalent to an image
> >
> > JB: There's no way in this product to add an equivalent to an
> > image that doesn't have one yet, when it is bringing in
> > converted content? Seems that this would be useful to have.
>
>In this "authoring tool" there is, it is through the interface in
>PowerPoint. We have other products that provide the ability to do
>editiing, but this particular product is just a simple push-button to
>generate content (and do so accessibly if fed the right information).

JB: Does the definition that's been in circulation (I'm re-sending again)
work for you on this? ("...or collection of software components..." Seems
that it includes the concept of multiple tools in a process.

> > >AWK: Is there a possible world where a tool can meet #1 and
> > not meet #2?
> > >If so, why have #2?
> >
> > JB: #1 addresses the ability to produce accessible content;
> > #2 addresses the preservation of accessibility information in
> > existing content.
> > [Unfortunately] it is possible for an authoring tool to be
> > able to produce accessible content, yet also strip out
> > existing accessibility information.
> > Therefore these are two separate problems, and I believe that
> > it is both appropriate and necessary to have both provisions.
>
>I think that you're splitting a hair here. The goal is to generate
>accessible content, and if the tool does that it should be OK. I think
>that #1 is sufficient.

JB: If tool A allows production of new accessibility content, but without
author action strips out other types of accessibility content that may have
been produced by tool B and imported into tool A, then that seems to be
interfering with one of the goals of arriving at accessible content.

> > JB: There doesn't seem to be any need to identify what "*the
> > most* accessible authoring action" in a given situation would
> > be, but rather to give prominence to "accessible authoring
> > actions," or "authoring actions that support production of
> > accessible content." This would remove the problem of
> > potentially forcing a specific workflow onto people. Jan
> > Richards had suggested the following wording, which I think is an
> > improvement: "An alternative proposal would be 'Authoring
> > tools should give prominence to accessible authoring actions
> > for achieving an authoring outcome."
>
>This doesn't address the issue that there are many ways to accomplish
>different tasks - how do we choose which to give prominence to? Any
>what exactly does "give prominence" mean?

JB: I've provided links to a definition, explanation and examples earlier
on the thread. Will re-post.

> > >AWK: As has been stated before, many aspects of designing an
> > accessible
> > >web page require author input and can't be made part of a template.
> > >I'm concerned about how this gets scoped against the web content
> > >standards as a result.
> >
> > JB: I'm not sure that there's an assumption that templates
> > would encompass all possible author actions. It seems that
> > some author input needed for development of an accessible Web
> > page would be possible to do through a template, and some
> > might need to be done outside a template. The version of the
> > draft language on this above reads: "Authoring tools which
> > provide preauthored content or templates to facilitate rapid
> > production of electronic content MUST provide at least one
> > version that meets applicable electronic content
> > accessibility standards." If it's not possible to do the
> > given authoring action within a template, wouldn't that
> > content accessibility standard be not applicable? Do you have
> > a different suggestion for how to scope this?
>
>I'll have to think on this a bit.

Please see wrt slightly updated language.

Regards,

- Judy


>AWK
>