Thread Subject: 7-C Prompts (in authoring tools)

Return to this mailing list's archives

From: Judy Brewer
Date: Tue, Feb 26 2008 12:45 PM
Subject: 7-C Prompts (in authoring tools)

Coming back to the issue of prompting, the last status of our
conversation is posted at
<http://teitac.org/wiki/EWG:Draft_Jan_7#7-C_-_Prompts_.28Discussed_Dec_4.2C_11.2C_Jan_9.29>

The version in the current draft states:
"Authoring tools with a user interface must provide a mode which
prompts authors to create accessible content.
Note: It is neither expected nor possible that prompts be available
for every type of accessible content."

The proposed version from Sean, Jan 9, states:
"Authoring tools with a user interface must procured and operated
such that they provide, either alone or with additional tools, a mode
which prompts authors to create accessible content."

The version from Judy, Jan 9, states:
"Authoring tools with a user interface, to the extent they provide a
prompting framework, must provide a mode which prompts authors to
create accessible content."

The version from Peter, Jan 9, states:
"An authoring tool, or suite of authoring tools used to author
content, where that suite provides a user interface, must provide a
mode which prompts authors to create accessible content."

With regard to Sean's proposal, as discussed on Jan 9, this appears
to provide no more requirement for prompting than if the provision
did not exist, since it is not clear that the capacity to prompt must
be available in another tool procured as part of the same package.

Peter's proposal makes it clearer that the capability to prompt for
accessible content must be among the features in a given suite of
tools. But I have a number of remaining concerns about this, and I
welcome suggestions for how to address this.

How can we ensure that the prompting would be available in relevant
portions of the bundled package? Here are three examples to consider:

1. A concern that Sean had raised was that a developer might acquire
a tool which didn't have prompting capability on board; but what if
that tool were the only tool in the suite which provided an authoring
interface for certain technologies, for instance MathML or SMIL? In
that case, the absence of prompting capability in that particular
tool in the package would mean that prompting for accessible content
would not be comprehensively available for all technologies that
could be authored by that package.

2. What if primary authoring tool in that bundle has a spectaculary
good interface -- in fact, that's the main attraction in this package
-- but the prompting for accessibility is only available in a scrappy
little add-on that is missing the well-developed functionality of the
primary authoring tool? In this case, the fact that prompting is
available somewhere among the tools in the suite doesn't achieve the
intended result.

3. What if the one tool in the suite that provided a prompting
function were not one that produced valid code?

With regard to my own proposal above, in retrospect I am concerned
about the phrase: "to the extent that they provide a prompting
framework" since it seems that an incentive is needed to provide
prompting during authoring, and phrasing it this way seems that it
might actually create a disincentive.

Additional comments welcome on this; as currently worded, I would be
inclined to support only the wording in the current draft, which is:
"Authoring tools with a user interface must provide a mode which
prompts authors to create accessible content."

Is this related to the additional comment from Jan 9 that apparently
needed more attention:
"Attempt to address "framework" tools, while staying out of
procurement of the dangerous "bundling" territory."
If so, can someone give an example of how to use a "framework"
approach here, and what was the danger to avoid with a "bundling" approach?

Thank you,

- Judy

From: Andrew Kirkpatrick
Date: Tue, Feb 26 2008 1:00 PM
Subject: Re: 7-C Prompts (in authoring tools)

Judy,
Some comments:

> The proposed version from Sean, Jan 9, states:
> "Authoring tools with a user interface must procured and
operated
> such that they provide, either alone or with additional tools, a mode
> which prompts authors to create accessible content."

I'm not sure that we're gaining anything by mandating that tools are
operated with prompting active - it is not likely enforceable, and to
the extent that it is enforceable it is entirely redundant to the
web/software standards.

This is my preference, apart from the above concern.

> The version from Judy, Jan 9, states:
> "Authoring tools with a user interface, to the extent they
> provide a
> prompting framework, must provide a mode which prompts authors to
> create accessible content."

Judy, what do you mean by a prompting framework? If the app prompts for
other things it should prompt for accessibility?

> The version from Peter, Jan 9, states:
> "An authoring tool, or suite of authoring tools used to author
> content, where that suite provides a user interface, must provide a
> mode which prompts authors to create accessible content."

This also raises a concern that is avoided in Sean's, which is that
sometimes 3rd party tools provide this function. I see this on the wiki
but not in your email.

AWK

From: Judy Brewer
Date: Tue, Feb 26 2008 1:20 PM
Subject: Re: 7-C Prompts (in authoring tools)

Hi Andrew,

Comments below.

At 11:55 AM 2/26/2008 -0800, Andrew Kirkpatrick wrote:
>Judy,
>Some comments:
>
> > The proposed version from Sean, Jan 9, states:
> > "Authoring tools with a user interface must procured and operated
> > such that they provide, either alone or with additional tools, a mode
> > which prompts authors to create accessible content."
>
>I'm not sure that we're gaining anything by mandating that tools are
>operated with prompting active - it is not likely enforceable, and to
>the extent that it is enforceable it is entirely redundant to the
>web/software standards.

I'm not sure how you arrive at "mandating that tools are operated
with prompting active." It states "a mode which prompts". I had not
looked closely at Sean's wording because of my greater concerns about
the unclarity of what is available in a given package vs what
available among the universe of authoring tools. But does your
concern stem from Sean's phrasing of "procured and operated..."? My
understanding is that "a mode which..." would overdetermine that by
making the prompting just one among a variety of modes or
configurations. But perhaps it is just too confusing having both
there, in which case I would tend to remove the "and operated with"
since I think that the agency and/or user choice of selecting whether
the prompting mode is active or not is important to maintain.

>This is my preference, apart from the above concern.
>
> > The version from Judy, Jan 9, states:
> > "Authoring tools with a user interface, to the extent they provide a
> > prompting framework, must provide a mode which prompts authors to
> > create accessible content."
>
>Judy, what do you mean by a prompting framework? If the app prompts for
>other things it should prompt for accessibility?

Yes, that is what I meant, that if they provided any prompting
framework then they should also include prompting for accessibility
content, but that if they provided no prompting framework then they
would not need to. However, I had described some further concerns in
my original message on this today as I looked at additional scenarios
for what that might mean. I list those concerns again here (and then
after that I respond to your question about Peter's proposal):

From my earlier message:

>>With regard to my own proposal above, in retrospect I am concerned
>>about the phrase: "to the extent that they provide a prompting
>>framework" since it seems that an incentive is needed to provide
>>prompting during authoring, and phrasing it this way seems that it
>>might actually create a disincentive.
>>
>>Additional comments welcome on this; as currently worded, I would be
>>inclined to support only the wording in the current draft, which is:
>> "Authoring tools with a user interface must provide a mode which
>>prompts authors to create accessible content."
>>
>>Is this related to the additional comment from Jan 9 that apparently
>>needed more attention:
>> "Attempt to address "framework" tools, while staying out of
>>procurement of the dangerous "bundling" territory."
>>If so, can someone give an example of how to use a "framework"
>>approach here, and what was the danger to avoid with a "bundling" approach?


And then replying on your comment about Peter's proposal:

> > The version from Peter, Jan 9, states:
> > "An authoring tool, or suite of authoring tools used to author
> > content, where that suite provides a user interface, must provide a
> > mode which prompts authors to create accessible content."
>
>This also raises a concern that is avoided in Sean's, which is that
>sometimes 3rd party tools provide this function. I see this on the wiki
>but not in your email.

Hmmm, was my email truncated? It looks to me as though it all came
through on the mailing list... I did list Peter's proposal in my
email -- or is this not what you mean by the "this" that is on the
wiki but not in my email?

In any case, that is an interesting comment. Can't a suite of tools
include third party tools as well? I'm not sure that I understand
your concern about Peter's proposal. Could you please say more?

- Judy


>AWK
>

From: Andrew Kirkpatrick
Date: Tue, Feb 26 2008 1:45 PM
Subject: Re: 7-C Prompts (in authoring tools)

Comments within

> I'm not sure how you arrive at "mandating that tools are operated
> with prompting active." It states "a mode which prompts". I had not
> looked closely at Sean's wording because of my greater concerns about
> the unclarity of what is available in a given package vs what
> available among the universe of authoring tools. But does your
> concern stem from Sean's phrasing of "procured and operated..."? My
> understanding is that "a mode which..." would overdetermine that by
> making the prompting just one among a variety of modes or
> configurations. But perhaps it is just too confusing having both
> there, in which case I would tend to remove the "and operated with"
> since I think that the agency and/or user choice of selecting whether
> the prompting mode is active or not is important to maintain.

"must procured and operated" is the phrase. I'm not sure that procured
is needed since this is a procurement standard, and my concern about
"and operated" was what I was referring to in my last message.

> Yes, that is what I meant, that if they provided any prompting
> framework then they should also include prompting for accessibility
> content, but that if they provided no prompting framework then they
> would not need to. However, I had described some further concerns in
> my original message on this today as I looked at additional scenarios
> for what that might mean. I list those concerns again here (and then
> after that I respond to your question about Peter's proposal):

So you're arguing against your proposal. Got it.

> And then replying on your comment about Peter's proposal:
>
> > > The version from Peter, Jan 9, states:
> > > "An authoring tool, or suite of authoring tools used to
> author
> > > content, where that suite provides a user interface, must provide
a
> > > mode which prompts authors to create accessible content."
> >
> >This also raises a concern that is avoided in Sean's, which is that
> >sometimes 3rd party tools provide this function. I see this on the
> wiki
> >but not in your email.
>
> Hmmm, was my email truncated? It looks to me as though it all came
> through on the mailing list... I did list Peter's proposal in my
> email -- or is this not what you mean by the "this" that is on the
> wiki but not in my email?

I'm referring to:
Comments to resolve

Request to add "or be compatible with additional tools that provide this
function."
Request to add "used in conjunction with"
Request to make this a function that an administrator could turn on so
that the tools be used.
Or, "Authoring tools alone, or with a third-party tool"...

> In any case, that is an interesting comment. Can't a suite of tools
> include third party tools as well? I'm not sure that I understand
> your concern about Peter's proposal. Could you please say more?

Weeellll... I'm not sure. When I think of "third party" I think about a
tool that is not part of the primary product directly. If it was it
stops being a third party tool (becomes a 2nd party tool?).

AWK

From: Judy Brewer
Date: Tue, Feb 26 2008 2:20 PM
Subject: Re: 7-C Prompts (in authoring tools)

Hi Andrew,

Thanks for your replies. More comments below.

At 12:43 PM 2/26/2008 -0800, Andrew Kirkpatrick wrote:
>Comments within
>
> > I'm not sure how you arrive at "mandating that tools are operated
> > with prompting active." It states "a mode which prompts". I had not
> > looked closely at Sean's wording because of my greater concerns about
> > the unclarity of what is available in a given package vs what
> > available among the universe of authoring tools. But does your
> > concern stem from Sean's phrasing of "procured and operated..."? My
> > understanding is that "a mode which..." would overdetermine that by
> > making the prompting just one among a variety of modes or
> > configurations. But perhaps it is just too confusing having both
> > there, in which case I would tend to remove the "and operated with"
> > since I think that the agency and/or user choice of selecting whether
> > the prompting mode is active or not is important to maintain.
>
>"must procured and operated" is the phrase. I'm not sure that procured
>is needed since this is a procurement standard, and my concern about
>"and operated" was what I was referring to in my last message.

It might save us a turn or two if you could say a little more here;
for instance, am I correct in assuming that, with regard to Sean's
proposal, which was:

>> > The proposed version from Sean, Jan 9, states:
>> > "Authoring tools with a user interface must procured and operated
>> > such that they provide, either alone or with additional tools, a mode
>> > which prompts authors to create accessible content."

you would support (?):

"Authoring tools with a user interface must provide, either alone or
with additional tools, a mode which prompts authors to create
accessible content."

> > Yes, that is what I meant, that if they provided any prompting
> > framework then they should also include prompting for accessibility
> > content, but that if they provided no prompting framework then they
> > would not need to. However, I had described some further concerns in
> > my original message on this today as I looked at additional scenarios
> > for what that might mean. I list those concerns again here (and then
> > after that I respond to your question about Peter's proposal):
>
>So you're arguing against your proposal. Got it.

Yes; after examining a number of different scenarios, I think that
all of the current and proposed versions have subtle problems, though
I am still thinking that this is fixable.

> > And then replying on your comment about Peter's proposal:
> >
> > > > The version from Peter, Jan 9, states:
> > > > "An authoring tool, or suite of authoring tools used to
> > author
> > > > content, where that suite provides a user interface, must provide
>a
> > > > mode which prompts authors to create accessible content."
> > >
> > >This also raises a concern that is avoided in Sean's, which is that
> > >sometimes 3rd party tools provide this function. I see this on the
> > wiki
> > >but not in your email.
> >
> > Hmmm, was my email truncated? It looks to me as though it all came
> > through on the mailing list... I did list Peter's proposal in my
> > email -- or is this not what you mean by the "this" that is on the
> > wiki but not in my email?
>
>I'm referring to:
>Comments to resolve
>
>Request to add "or be compatible with additional tools that provide this
>function."
>Request to add "used in conjunction with"
>Request to make this a function that an administrator could turn on so
>that the tools be used.
>Or, "Authoring tools alone, or with a third-party tool"...

Ah. Some of those were from earlier discussions, and I believe were
addressed in meetings, but had not yet been removed from the list of
issues. Others I believe are encompassed in versions offered above,
and discussed on this thread, as well as in teleconfs. I had tried to
pull out the one that I did not think was already addressed, or
incorporated conceptually into some proposal that we were discussing
here. If you have remaining concerns, can you raise them specifically?

> > In any case, that is an interesting comment. Can't a suite of tools
> > include third party tools as well? I'm not sure that I understand
> > your concern about Peter's proposal. Could you please say more?
>
>Weeellll... I'm not sure. When I think of "third party" I think about a
>tool that is not part of the primary product directly. If it was it
>stops being a third party tool (becomes a 2nd party tool?).

Hmmm. Interesting issue. I was assuming that sometimes suites might
include, for instance, plug-ins or key utilities, for which one
vendor makes an arrangement with another, without actually acquiring
them. I guess that would be second party, indeed.

- Judy


>AWK
>

From: Andrew Kirkpatrick
Date: Tue, Feb 26 2008 2:35 PM
Subject: Re: 7-C Prompts (in authoring tools)

> It might save us a turn or two if you could say a little more here;
> for instance, am I correct in assuming that, with regard to Sean's
> proposal, which was:

Sure, but I might be less terse if I wasn't also trying to pay attention
to the TEITAC call or the next conference call I'm on...

> you would support (?):
>
> "Authoring tools with a user interface must provide, either alone or
> with additional tools, a mode which prompts authors to create
> accessible content."

Authoring tools with a user interface must provide, either directly or
through a third-party tool, a mode which prompts authors to create
accessible content.

AWK

From: Sean Hayes
Date: Tue, Feb 26 2008 3:35 PM
Subject: Re: 7-C Prompts (in authoring tools)

Not sure I followed the entire thread here, but I could live with

"Authoring tools with a user interface must provide, either directly or
through a third-party tool, a mode which prompts authors to create
accessible content."

And leave it up to subpart D, 2C to ensure the agency sets it up correctly.

However one subtlety which I was trying to explain, is that the environment or framework, while meeting the definition of an authoring tool, may not be able to provide prompting for a plug in tool which is the authoring environment for a specific format, and that the plug in would have to provide any prompting for that format itself.

This could be addressed by clarifying that an authoring tool may be a component of a larger suite or framework into the definition of authoring tool:

<proposal>
Any software intended to create or modify content for publication. This definition covers authoring tools which are able to create or modify content in a format such that the format supports compliance with the user interface and content provisions.

Note: Such software may be a component, either built in or added later as a plug in, of a larger software environment; in which case it is the component that is for the purposes of this definition the authoring tool and not the containing environment, even if the containing environment may also be considered an authoring tool in its own right.
</proposal>

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew Kirkpatrick
Sent: 26 February 2008 21:35
To: TEITAC Committee
Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)

> It might save us a turn or two if you could say a little more here;
> for instance, am I correct in assuming that, with regard to Sean's
> proposal, which was:

Sure, but I might be less terse if I wasn't also trying to pay attention
to the TEITAC call or the next conference call I'm on...

> you would support (?):
>
> "Authoring tools with a user interface must provide, either alone or
> with additional tools, a mode which prompts authors to create
> accessible content."

Authoring tools with a user interface must provide, either directly or
through a third-party tool, a mode which prompts authors to create
accessible content.

AWK

From: Judy Brewer
Date: Tue, Feb 26 2008 3:55 PM
Subject: Re: 7-C Prompts (in authoring tools)

Andrew, my replies below; and Sean, a question for you below as well,
when you get a chance to catch up with this thread.

At 01:34 PM 2/26/2008 -0800, Andrew Kirkpatrick wrote:
> > It might save us a turn or two if you could say a little more here;
> > for instance, am I correct in assuming that, with regard to Sean's
> > proposal, which was:
>
>Sure, but I might be less terse if I wasn't also trying to pay attention
>to the TEITAC call or the next conference call I'm on...

(I know the feeling... I force myself to proofread anything I write
during a meeting twice before I send it, but I'll surely slip up one
of these times...)

> > you would support (?):
> >
> > "Authoring tools with a user interface must provide, either alone or
> > with additional tools, a mode which prompts authors to create
> > accessible content."
>
>Authoring tools with a user interface must provide, either directly or
>through a third-party tool, a mode which prompts authors to create
>accessible content.

OK, that helps on the first part... I have a suspicion that Sean may
have added the "procured and operated" as an effort to address a
concern that I had raised in one of the teleconferences, but I'm OK
without that, particularly if it might create the impression that the
prompting must always be active, since I don't support that position.

Sean, are you OK with dropping "procured and operated", or are there
other reasons that you wanted it there?

But Andrew, the "either directly or through a third-party tool" is
still something that I have major concerns about, for reasons that
I've explained earlier in this thread. As written it seems to provide
no more of an assurance of availability of prompting for
accessibility content in key parts of the authoring system than if
one were to have no requirement for prompting. If an agency were to
procure an authoring tool from Developer X without accessibility
prompting features, naturally they could also go off and acquire a
tool from Developer Y that did have prompting. But that does not
ensure that the agency will indeed procure that additional tool from
Developer Y; nor that, if they do procure it, that prompting would be
available for the covered technologies of Developer X's tool, nor
with the more feature-rich interface of Developer X's tool, nor with
the valid code that Developer X's tool creates; nor that the tool
would preserve accessibility content the way the presumably otherwise
conforming tool from Developer X does... So, the phrase "either
directly or through a third-party tool" has a lot of holes, as do the
phrases "either alone or with additional tools", "compatible with",
"used in conjunction with" etc.

Pasting back in the earlier parts of my thread that I believe relate
to this and remain unaddressed, please note the three examples below
which I believe illustrate the problem:

>How can we ensure that the prompting would be available in relevant
>portions of the bundled package? Here are three examples to consider:
>
>1. A concern that Sean had raised was that a developer might acquire
>a tool which didn't have prompting capability on board; but what if
>that tool were the only tool in the suite which provided an
>authoring interface for certain technologies, for instance MathML or
>SMIL? In that case, the absence of prompting capability in that
>particular tool in the package would mean that prompting for
>accessible content would not be comprehensively available for all
>technologies that could be authored by that package.
>
>2. What if primary authoring tool in that bundle has a spectaculary
>good interface -- in fact, that's the main attraction in this
>package -- but the prompting for accessibility is only available in
>a scrappy little add-on that is missing the well-developed
>functionality of the primary authoring tool? In this case, the fact
>that prompting is available somewhere among the tools in the suite
>doesn't achieve the intended result.
>
>3. What if the one tool in the suite that provided a prompting
>function were not one that produced valid code?

There may be ways to address these concerns through further
qualifying statements regarding availability of prompting for
accessibility content within a bundled suite of authoring tools.

Or it may be more practical to return to the original provision, and
try tweaking that, for instance, starting with the version of the
provision in the current draft:
""Authoring tools with a user interface must provide a mode
which prompts authors to create accessible content.
Note: It is neither expected nor possible that prompts be
available for every type of accessible content."
And then my attempt at tweaking it (sorry, a bit ugly, but
to illustrate the issues): "Authoring tools with a user interface
must provide a mode which prompts authors to create accessible
content, unless they are bundled with a tool that provides prompting
for accessible content for the same range of technologies supported
by the primary tool, and with a comparable user interface, and
conforming with other Web/Software requirements of 508..."
But in that case, wouldn't it be simpler to build the
prompting into the primary authoring tool in the suite?

Can you help me understand what would be difficult about meeting the
current version of the provision, along with its already accompanying
note saying that this is not intended for every type of accessible
content (since there are some types of accessible content which would
clearly be impractical to prompt for)?

Thanks,

- Judy

>AWK
>
>

From: Judy Brewer
Date: Tue, Feb 26 2008 4:10 PM
Subject: Re: 7-C Prompts (in authoring tools)

Hi Sean,

Our responses in the thread overlapped. Your response below
anticipates some of my comments in the other message, but could you
please be sure to read it as well, mainly for consideration of the
three examples of concerns when prompting has only limited
availability with key parts of an authoring suite or bundle? Near the
top, it says: "Sean, a question for you below as well, when you get a
chance to catch up with this thread." That said, I think that I see
the direction that you're going with "environment or framework"
below, and think that this may be a productive direction to pursue. More below.

At 10:34 PM 2/26/2008 +0000, Sean Hayes wrote:
>Not sure I followed the entire thread here, but I could live with
>
>"Authoring tools with a user interface must provide, either directly or
>through a third-party tool, a mode which prompts authors to create
>accessible content."
>
>And leave it up to subpart D, 2C to ensure the agency sets it up correctly.
>
>However one subtlety which I was trying to explain, is that the
>environment or framework, while meeting the definition of an
>authoring tool, may not be able to provide prompting for a plug in
>tool which is the authoring environment for a specific format, and
>that the plug in would have to provide any prompting for that format itself.

Sean, this is a a concern even with the qualification that this
provision only applies to an authoring tool with a user interface?
This is an interesting example; can you provide more information
about how that would work? For the examples that I can think of that
meet the situation that you describe, the requirement would be null
because there would not be a user interface (though perhaps that's a
flaw that might be better addressed by other language).

>This could be addressed by clarifying that an authoring tool may be
>a component of a larger suite or framework into the definition of
>authoring tool:
>
><proposal>
>Any software intended to create or modify content for publication.
>This definition covers authoring tools which are able to create or
>modify content in a format such that the format supports compliance
>with the user interface and content provisions.
>
>Note: Such software may be a component, either built in or added
>later as a plug in, of a larger software environment; in which case
>it is the component that is for the purposes of this definition the
>authoring tool and not the containing environment, even if the
>containing environment may also be considered an authoring tool in
>its own right.
></proposal>

Interesting. Thanks for this idea. Poking at it a bit, I'm not sure
that you want the time-restriction of "later"... you could just drop
that word, and leave the rest there. Also, everything after "that is
for this purposes of this definition" gets extremely difficult to
parse. Any possibility of taking another pass at it in the morning?

- Judy


>Sean Hayes
>Incubation Lab
>Accessibility Business Unit
>Microsoft
>
>Office: +44 118 909 5867,
>Mobile: +44 7875 091385
>
>
>-----Original Message-----
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>Andrew Kirkpatrick
>Sent: 26 February 2008 21:35
>To: TEITAC Committee
>Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
>
> > It might save us a turn or two if you could say a little more here;
> > for instance, am I correct in assuming that, with regard to Sean's
> > proposal, which was:
>
>Sure, but I might be less terse if I wasn't also trying to pay attention
>to the TEITAC call or the next conference call I'm on...
>
> > you would support (?):
> >
> > "Authoring tools with a user interface must provide, either alone or
> > with additional tools, a mode which prompts authors to create
> > accessible content."
>
>Authoring tools with a user interface must provide, either directly or
>through a third-party tool, a mode which prompts authors to create
>accessible content.
>
>AWK
>
>

From: Sean Hayes
Date: Wed, Feb 27 2008 10:55 AM
Subject: Re: 7-C Prompts (in authoring tools)

<Judy>
...the "either directly or through a third-party tool" is still something that I have major concerns about, for reasons that I've explained earlier in this thread. As written it seems to provide no more of an assurance of availability of prompting for accessibility content in key parts of the authoring system than if one were to have no requirement for prompting. If an agency were to procure an authoring tool from Developer X without accessibility prompting features, naturally they could also go off and acquire a tool from Developer Y that did have prompting.
</Judy>

I can see your concern, but I think it is related to the issue with assistive technology. If Tool X is not compliant on its own, then if an agency were to procure tool X without tool Y, then they would not be meeting the requirement of 508 - in particular Subpart D 2-C, in just the same way that if they installed a telephone without installing a visual ringer then they might not meet 508.

That's why I previously proposed the 'procured and operated' language; although we have a distinct section for that now, which I believe is the proper place.

In fact there are scenarios where it is not reasonable to expect a tool to provide prompting, and where relying on additional tools might in fact be preferable, for example where the original team creating the tool may not have the level of expertise of a dedicated expert. Let's take a concrete example of that: the Microsoft media creator which is a low end video editor bundled with Windows.

To pass the letter of this provision, the team can provide a splash screen which says "ensure content meets applicable provisions of 508"; which is not particularly helpful, and I'm sure we would both agree we would like product teams to do better.

I might possibly be able to persuade them to say, "do not create content which flashes in such and such a way", which while better and more specific in terms of prompting, leaves the user clueless as to whether it applies to the project at hand, and what they might do about it if it did. Which is considerably less valuable than running content through a dedicated flash detection tool for video content which can say, "frames XXX to YYY in this production flash in a way which may cause seizures: see <url>, you need to do something about it: see <url>".

Now I'm not going to be able to get the team to build that in to such a low end product, because they do not have the resources or expertise to create/license such a thing, (and they have the other options above); but if they were allowed to rely on third party tools to do that analysis, then it might be a scenario they could support.


Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy Brewer
Sent: 26 February 2008 23:09
To: TEITAC Committee
Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)

Hi Sean,

Our responses in the thread overlapped. Your response below
anticipates some of my comments in the other message, but could you
please be sure to read it as well, mainly for consideration of the
three examples of concerns when prompting has only limited
availability with key parts of an authoring suite or bundle? Near the
top, it says: "Sean, a question for you below as well, when you get a
chance to catch up with this thread." That said, I think that I see
the direction that you're going with "environment or framework"
below, and think that this may be a productive direction to pursue. More below.

At 10:34 PM 2/26/2008 +0000, Sean Hayes wrote:
>Not sure I followed the entire thread here, but I could live with
>
>"Authoring tools with a user interface must provide, either directly or
>through a third-party tool, a mode which prompts authors to create
>accessible content."
>
>And leave it up to subpart D, 2C to ensure the agency sets it up correctly.
>
>However one subtlety which I was trying to explain, is that the
>environment or framework, while meeting the definition of an
>authoring tool, may not be able to provide prompting for a plug in
>tool which is the authoring environment for a specific format, and
>that the plug in would have to provide any prompting for that format itself.

Sean, this is a a concern even with the qualification that this
provision only applies to an authoring tool with a user interface?
This is an interesting example; can you provide more information
about how that would work? For the examples that I can think of that
meet the situation that you describe, the requirement would be null
because there would not be a user interface (though perhaps that's a
flaw that might be better addressed by other language).

>This could be addressed by clarifying that an authoring tool may be
>a component of a larger suite or framework into the definition of
>authoring tool:
>
><proposal>
>Any software intended to create or modify content for publication.
>This definition covers authoring tools which are able to create or
>modify content in a format such that the format supports compliance
>with the user interface and content provisions.
>
>Note: Such software may be a component, either built in or added
>later as a plug in, of a larger software environment; in which case
>it is the component that is for the purposes of this definition the
>authoring tool and not the containing environment, even if the
>containing environment may also be considered an authoring tool in
>its own right.
></proposal>

Interesting. Thanks for this idea. Poking at it a bit, I'm not sure
that you want the time-restriction of "later"... you could just drop
that word, and leave the rest there. Also, everything after "that is
for this purposes of this definition" gets extremely difficult to
parse. Any possibility of taking another pass at it in the morning?

- Judy


>Sean Hayes
>Incubation Lab
>Accessibility Business Unit
>Microsoft
>
>Office: +44 118 909 5867,
>Mobile: +44 7875 091385
>
>
>-----Original Message-----
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>Andrew Kirkpatrick
>Sent: 26 February 2008 21:35
>To: TEITAC Committee
>Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
>
> > It might save us a turn or two if you could say a little more here;
> > for instance, am I correct in assuming that, with regard to Sean's
> > proposal, which was:
>
>Sure, but I might be less terse if I wasn't also trying to pay attention
>to the TEITAC call or the next conference call I'm on...
>
> > you would support (?):
> >
> > "Authoring tools with a user interface must provide, either alone or
> > with additional tools, a mode which prompts authors to create
> > accessible content."
>
>Authoring tools with a user interface must provide, either directly or
>through a third-party tool, a mode which prompts authors to create
>accessible content.
>
>AWK
>
>

From: Judy Brewer
Date: Wed, Feb 27 2008 11:30 PM
Subject: Re: 7-C Prompts (in authoring tools)

Hi Sean,

Your example below was useful as it led me to realize that you are
thinking about a far broader scope of prompting than what I believe
was ever in ATAG (Authoring Tool Accessibility Guidelines) with
regard to prompting. Perhaps this is a risk of our having strayed so
far from the text of ATAG.

Here is what ATAG (2.0, current Working Draft) says about prompting:

>3.1 <http://www.w3.org/TR/WAI-AUTOOLS/atag10.html#def-prompt>Prompt
>the author to provide
><http://www.w3.org/TR/WAI-AUTOOLS/atag10.html#def-alt-eq>equivalent
>alternative information (e.g.,
><http://www.w3.org/TR/WAI-AUTOOLS/atag10.html#def-video-captions>captions,
><http://www.w3.org/TR/WAI-AUTOOLS/atag10.html#def-Auditory>auditory
>descriptions, and
><http://www.w3.org/TR/WAI-AUTOOLS/atag10.html#def-transcript>collated
> text transcripts for video). [Relative Priority]

Would that be a problem?

- Judy

At 05:53 PM 2/27/2008 +0000, Sean Hayes wrote:
><Judy>
>...the "either directly or through a third-party tool" is still
>something that I have major concerns about, for reasons that I've
>explained earlier in this thread. As written it seems to provide no
>more of an assurance of availability of prompting for accessibility
>content in key parts of the authoring system than if one were to
>have no requirement for prompting. If an agency were to procure an
>authoring tool from Developer X without accessibility prompting
>features, naturally they could also go off and acquire a tool from
>Developer Y that did have prompting.
></Judy>
>
>I can see your concern, but I think it is related to the issue with
>assistive technology. If Tool X is not compliant on its own, then if
>an agency were to procure tool X without tool Y, then they would not
>be meeting the requirement of 508 - in particular Subpart D 2-C, in
>just the same way that if they installed a telephone without
>installing a visual ringer then they might not meet 508.
>
>That's why I previously proposed the 'procured and operated'
>language; although we have a distinct section for that now, which I
>believe is the proper place.
>
>In fact there are scenarios where it is not reasonable to expect a
>tool to provide prompting, and where relying on additional tools
>might in fact be preferable, for example where the original team
>creating the tool may not have the level of expertise of a dedicated
>expert. Let's take a concrete example of that: the Microsoft media
>creator which is a low end video editor bundled with Windows.
>
>To pass the letter of this provision, the team can provide a splash
>screen which says "ensure content meets applicable provisions of
>508"; which is not particularly helpful, and I'm sure we would both
>agree we would like product teams to do better.
>
>I might possibly be able to persuade them to say, "do not create
>content which flashes in such and such a way", which while better
>and more specific in terms of prompting, leaves the user clueless as
>to whether it applies to the project at hand, and what they might do
>about it if it did. Which is considerably less valuable than running
>content through a dedicated flash detection tool for video content
>which can say, "frames XXX to YYY in this production flash in a way
>which may cause seizures: see <url>, you need to do something about
>it: see <url>".
>
>Now I'm not going to be able to get the team to build that in to
>such a low end product, because they do not have the resources or
>expertise to create/license such a thing, (and they have the other
>options above); but if they were allowed to rely on third party
>tools to do that analysis, then it might be a scenario they could support.
>
>
>Sean Hayes
>Incubation Lab
>Accessibility Business Unit
>Microsoft
>
>Office: +44 118 909 5867,
>Mobile: +44 7875 091385
>
>
>-----Original Message-----
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy Brewer
>Sent: 26 February 2008 23:09
>To: TEITAC Committee
>Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
>
>Hi Sean,
>
>Our responses in the thread overlapped. Your response below
>anticipates some of my comments in the other message, but could you
>please be sure to read it as well, mainly for consideration of the
>three examples of concerns when prompting has only limited
>availability with key parts of an authoring suite or bundle? Near the
>top, it says: "Sean, a question for you below as well, when you get a
>chance to catch up with this thread." That said, I think that I see
>the direction that you're going with "environment or framework"
>below, and think that this may be a productive direction to pursue.
>More below.
>
>At 10:34 PM 2/26/2008 +0000, Sean Hayes wrote:
> >Not sure I followed the entire thread here, but I could live with
> >
> >"Authoring tools with a user interface must provide, either directly or
> >through a third-party tool, a mode which prompts authors to create
> >accessible content."
> >
> >And leave it up to subpart D, 2C to ensure the agency sets it up correctly.
> >
> >However one subtlety which I was trying to explain, is that the
> >environment or framework, while meeting the definition of an
> >authoring tool, may not be able to provide prompting for a plug in
> >tool which is the authoring environment for a specific format, and
> >that the plug in would have to provide any prompting for that format itself.
>
>Sean, this is a a concern even with the qualification that this
>provision only applies to an authoring tool with a user interface?
>This is an interesting example; can you provide more information
>about how that would work? For the examples that I can think of that
>meet the situation that you describe, the requirement would be null
>because there would not be a user interface (though perhaps that's a
>flaw that might be better addressed by other language).
>
> >This could be addressed by clarifying that an authoring tool may be
> >a component of a larger suite or framework into the definition of
> >authoring tool:
> >
> ><proposal>
> >Any software intended to create or modify content for publication.
> >This definition covers authoring tools which are able to create or
> >modify content in a format such that the format supports compliance
> >with the user interface and content provisions.
> >
> >Note: Such software may be a component, either built in or added
> >later as a plug in, of a larger software environment; in which case
> >it is the component that is for the purposes of this definition the
> >authoring tool and not the containing environment, even if the
> >containing environment may also be considered an authoring tool in
> >its own right.
> ></proposal>
>
>Interesting. Thanks for this idea. Poking at it a bit, I'm not sure
>that you want the time-restriction of "later"... you could just drop
>that word, and leave the rest there. Also, everything after "that is
>for this purposes of this definition" gets extremely difficult to
>parse. Any possibility of taking another pass at it in the morning?
>
>- Judy
>
>
> >Sean Hayes
> >Incubation Lab
> >Accessibility Business Unit
> >Microsoft
> >
> >Office: +44 118 909 5867,
> >Mobile: +44 7875 091385
> >
> >
> >-----Original Message-----
> >From: = EMAIL ADDRESS REMOVED =
> >[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> >Andrew Kirkpatrick
> >Sent: 26 February 2008 21:35
> >To: TEITAC Committee
> >Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> >
> > > It might save us a turn or two if you could say a little more here;
> > > for instance, am I correct in assuming that, with regard to Sean's
> > > proposal, which was:
> >
> >Sure, but I might be less terse if I wasn't also trying to pay attention
> >to the TEITAC call or the next conference call I'm on...
> >
> > > you would support (?):
> > >
> > > "Authoring tools with a user interface must provide, either alone or
> > > with additional tools, a mode which prompts authors to create
> > > accessible content."
> >
> >Authoring tools with a user interface must provide, either directly or
> >through a third-party tool, a mode which prompts authors to create
> >accessible content.
> >
> >AWK
> >
> >

From: Judy Brewer
Date: Thu, Feb 28 2008 7:20 AM
Subject: Re: 7-C Prompts (in authoring tools)

Sean,

Sorry, my versioning was off with the suggestion below. I need to
re-check this and re-propose; please disregard that last posting.

- Judy

At 01:26 AM 2/28/2008 -0500, Judy Brewer wrote:
>Hi Sean,
>
>Your example below was useful as it led me to realize that you are
>thinking about a far broader scope of prompting than what I believe
>was ever in ATAG (Authoring Tool Accessibility Guidelines) with
>regard to prompting. Perhaps this is a risk of our having strayed so
>far from the text of ATAG.
>
>Here is what ATAG (2.0, current Working Draft) says about prompting:
>
> >3.1 <http://www.w3.org/TR/WAI-AUTOOLS/atag10.html#def-prompt>Prompt
> >the author to provide
> ><http://www.w3.org/TR/WAI-AUTOOLS/atag10.html#def-alt-eq>equivalent
> >alternative information (e.g.,
> ><http://www.w3.org/TR/WAI-AUTOOLS/atag10.html#def-video-captions>captions,
> ><http://www.w3.org/TR/WAI-AUTOOLS/atag10.html#def-Auditory>auditory
> >descriptions, and
> ><http://www.w3.org/TR/WAI-AUTOOLS/atag10.html#def-transcript>collated
> > text transcripts for video). [Relative Priority]
>
>Would that be a problem?
>
>- Judy
>
>At 05:53 PM 2/27/2008 +0000, Sean Hayes wrote:
> ><Judy>
> >...the "either directly or through a third-party tool" is still
> >something that I have major concerns about, for reasons that I've
> >explained earlier in this thread. As written it seems to provide no
> >more of an assurance of availability of prompting for accessibility
> >content in key parts of the authoring system than if one were to
> >have no requirement for prompting. If an agency were to procure an
> >authoring tool from Developer X without accessibility prompting
> >features, naturally they could also go off and acquire a tool from
> >Developer Y that did have prompting.
> ></Judy>
> >
> >I can see your concern, but I think it is related to the issue with
> >assistive technology. If Tool X is not compliant on its own, then if
> >an agency were to procure tool X without tool Y, then they would not
> >be meeting the requirement of 508 - in particular Subpart D 2-C, in
> >just the same way that if they installed a telephone without
> >installing a visual ringer then they might not meet 508.
> >
> >That's why I previously proposed the 'procured and operated'
> >language; although we have a distinct section for that now, which I
> >believe is the proper place.
> >
> >In fact there are scenarios where it is not reasonable to expect a
> >tool to provide prompting, and where relying on additional tools
> >might in fact be preferable, for example where the original team
> >creating the tool may not have the level of expertise of a dedicated
> >expert. Let's take a concrete example of that: the Microsoft media
> >creator which is a low end video editor bundled with Windows.
> >
> >To pass the letter of this provision, the team can provide a splash
> >screen which says "ensure content meets applicable provisions of
> >508"; which is not particularly helpful, and I'm sure we would both
> >agree we would like product teams to do better.
> >
> >I might possibly be able to persuade them to say, "do not create
> >content which flashes in such and such a way", which while better
> >and more specific in terms of prompting, leaves the user clueless as
> >to whether it applies to the project at hand, and what they might do
> >about it if it did. Which is considerably less valuable than running
> >content through a dedicated flash detection tool for video content
> >which can say, "frames XXX to YYY in this production flash in a way
> >which may cause seizures: see <url>, you need to do something about
> >it: see <url>".
> >
> >Now I'm not going to be able to get the team to build that in to
> >such a low end product, because they do not have the resources or
> >expertise to create/license such a thing, (and they have the other
> >options above); but if they were allowed to rely on third party
> >tools to do that analysis, then it might be a scenario they could support.
> >
> >
> >Sean Hayes
> >Incubation Lab
> >Accessibility Business Unit
> >Microsoft
> >
> >Office: +44 118 909 5867,
> >Mobile: +44 7875 091385
> >
> >
> >-----Original Message-----
> >From: = EMAIL ADDRESS REMOVED =
> >[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy Brewer
> >Sent: 26 February 2008 23:09
> >To: TEITAC Committee
> >Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> >
> >Hi Sean,
> >
> >Our responses in the thread overlapped. Your response below
> >anticipates some of my comments in the other message, but could you
> >please be sure to read it as well, mainly for consideration of the
> >three examples of concerns when prompting has only limited
> >availability with key parts of an authoring suite or bundle? Near the
> >top, it says: "Sean, a question for you below as well, when you get a
> >chance to catch up with this thread." That said, I think that I see
> >the direction that you're going with "environment or framework"
> >below, and think that this may be a productive direction to pursue.
> >More below.
> >
> >At 10:34 PM 2/26/2008 +0000, Sean Hayes wrote:
> > >Not sure I followed the entire thread here, but I could live with
> > >
> > >"Authoring tools with a user interface must provide, either directly or
> > >through a third-party tool, a mode which prompts authors to create
> > >accessible content."
> > >
> > >And leave it up to subpart D, 2C to ensure the agency sets it up
> correctly.
> > >
> > >However one subtlety which I was trying to explain, is that the
> > >environment or framework, while meeting the definition of an
> > >authoring tool, may not be able to provide prompting for a plug in
> > >tool which is the authoring environment for a specific format, and
> > >that the plug in would have to provide any prompting for that
> format itself.
> >
> >Sean, this is a a concern even with the qualification that this
> >provision only applies to an authoring tool with a user interface?
> >This is an interesting example; can you provide more information
> >about how that would work? For the examples that I can think of that
> >meet the situation that you describe, the requirement would be null
> >because there would not be a user interface (though perhaps that's a
> >flaw that might be better addressed by other language).
> >
> > >This could be addressed by clarifying that an authoring tool may be
> > >a component of a larger suite or framework into the definition of
> > >authoring tool:
> > >
> > ><proposal>
> > >Any software intended to create or modify content for publication.
> > >This definition covers authoring tools which are able to create or
> > >modify content in a format such that the format supports compliance
> > >with the user interface and content provisions.
> > >
> > >Note: Such software may be a component, either built in or added
> > >later as a plug in, of a larger software environment; in which case
> > >it is the component that is for the purposes of this definition the
> > >authoring tool and not the containing environment, even if the
> > >containing environment may also be considered an authoring tool in
> > >its own right.
> > ></proposal>
> >
> >Interesting. Thanks for this idea. Poking at it a bit, I'm not sure
> >that you want the time-restriction of "later"... you could just drop
> >that word, and leave the rest there. Also, everything after "that is
> >for this purposes of this definition" gets extremely difficult to
> >parse. Any possibility of taking another pass at it in the morning?
> >
> >- Judy
> >
> >
> > >Sean Hayes
> > >Incubation Lab
> > >Accessibility Business Unit
> > >Microsoft
> > >
> > >Office: +44 118 909 5867,
> > >Mobile: +44 7875 091385
> > >
> > >
> > >-----Original Message-----
> > >From: = EMAIL ADDRESS REMOVED =
> > >[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > >Andrew Kirkpatrick
> > >Sent: 26 February 2008 21:35
> > >To: TEITAC Committee
> > >Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > >
> > > > It might save us a turn or two if you could say a little more here;
> > > > for instance, am I correct in assuming that, with regard to Sean's
> > > > proposal, which was:
> > >
> > >Sure, but I might be less terse if I wasn't also trying to pay attention
> > >to the TEITAC call or the next conference call I'm on...
> > >
> > > > you would support (?):
> > > >
> > > > "Authoring tools with a user interface must provide, either alone or
> > > > with additional tools, a mode which prompts authors to create
> > > > accessible content."
> > >
> > >Authoring tools with a user interface must provide, either directly or
> > >through a third-party tool, a mode which prompts authors to create
> > >accessible content.
> > >
> > >AWK
> > >
> > >

From: Judy Brewer
Date: Sun, Mar 16 2008 11:35 PM
Subject: Re: 7-C Prompts (in authoring tools)

Sean and I would like to propose the following language for 7-C, for
discussion on the TEITAC list before Tuesday's (March 18) meeting,
and for discussion at Tuesday's meeting as needed.

"An authoring tool, or suite of tools used to author content, whether
such suite is composed of tools from a single vendor or multiple
vendors, must provide a mode which prompts authors to create
accessible content for accessibility problems that the tool or suite
has the capability to analyze or correct, for formats authored by
that tool or suite which support compliance as explained in the
definition of authoring tool."

The Wiki includes the following background on this provision:
http://teitac.org/wiki/EWG:Draft_Jan_7#7-C_-_Prompts_.28Discussed_Dec_4.2C_11.2C_Jan_9.29
and the following thread contains discussion about the various alternatives:
http://teitac.org/mailarchives/mail_thread.php?thread=1905&id=8048#8048

Regards,

- Judy

<...>
> >At 05:53 PM 2/27/2008 +0000, Sean Hayes wrote:
> > ><Judy>
> > >...the "either directly or through a third-party tool" is still
> > >something that I have major concerns about, for reasons that I've
> > >explained earlier in this thread. As written it seems to provide no
> > >more of an assurance of availability of prompting for accessibility
> > >content in key parts of the authoring system than if one were to
> > >have no requirement for prompting. If an agency were to procure an
> > >authoring tool from Developer X without accessibility prompting
> > >features, naturally they could also go off and acquire a tool from
> > >Developer Y that did have prompting.
> > ></Judy>
> > >
> > >I can see your concern, but I think it is related to the issue with
> > >assistive technology. If Tool X is not compliant on its own, then if
> > >an agency were to procure tool X without tool Y, then they would not
> > >be meeting the requirement of 508 - in particular Subpart D 2-C, in
> > >just the same way that if they installed a telephone without
> > >installing a visual ringer then they might not meet 508.
> > >
> > >That's why I previously proposed the 'procured and operated'
> > >language; although we have a distinct section for that now, which I
> > >believe is the proper place.
> > >
> > >In fact there are scenarios where it is not reasonable to expect a
> > >tool to provide prompting, and where relying on additional tools
> > >might in fact be preferable, for example where the original team
> > >creating the tool may not have the level of expertise of a dedicated
> > >expert. Let's take a concrete example of that: the Microsoft media
> > >creator which is a low end video editor bundled with Windows.
> > >
> > >To pass the letter of this provision, the team can provide a splash
> > >screen which says "ensure content meets applicable provisions of
> > >508"; which is not particularly helpful, and I'm sure we would both
> > >agree we would like product teams to do better.
> > >
> > >I might possibly be able to persuade them to say, "do not create
> > >content which flashes in such and such a way", which while better
> > >and more specific in terms of prompting, leaves the user clueless as
> > >to whether it applies to the project at hand, and what they might do
> > >about it if it did. Which is considerably less valuable than running
> > >content through a dedicated flash detection tool for video content
> > >which can say, "frames XXX to YYY in this production flash in a way
> > >which may cause seizures: see <url>, you need to do something about
> > >it: see <url>".
> > >
> > >Now I'm not going to be able to get the team to build that in to
> > >such a low end product, because they do not have the resources or
> > >expertise to create/license such a thing, (and they have the other
> > >options above); but if they were allowed to rely on third party
> > >tools to do that analysis, then it might be a scenario they could support.
> > >
> > >
> > >Sean Hayes
> > >Incubation Lab
> > >Accessibility Business Unit
> > >Microsoft
> > >
> > >Office: +44 118 909 5867,
> > >Mobile: +44 7875 091385
> > >
> > >
> > >-----Original Message-----
> > >From: = EMAIL ADDRESS REMOVED =
> > >[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy Brewer
> > >Sent: 26 February 2008 23:09
> > >To: TEITAC Committee
> > >Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > >
> > >Hi Sean,
> > >
> > >Our responses in the thread overlapped. Your response below
> > >anticipates some of my comments in the other message, but could you
> > >please be sure to read it as well, mainly for consideration of the
> > >three examples of concerns when prompting has only limited
> > >availability with key parts of an authoring suite or bundle? Near the
> > >top, it says: "Sean, a question for you below as well, when you get a
> > >chance to catch up with this thread." That said, I think that I see
> > >the direction that you're going with "environment or framework"
> > >below, and think that this may be a productive direction to pursue.
> > >More below.
> > >
> > >At 10:34 PM 2/26/2008 +0000, Sean Hayes wrote:
> > > >Not sure I followed the entire thread here, but I could live with
> > > >
> > > >"Authoring tools with a user interface must provide, either directly or
> > > >through a third-party tool, a mode which prompts authors to create
> > > >accessible content."
> > > >
> > > >And leave it up to subpart D, 2C to ensure the agency sets it up
> > correctly.
> > > >
> > > >However one subtlety which I was trying to explain, is that the
> > > >environment or framework, while meeting the definition of an
> > > >authoring tool, may not be able to provide prompting for a plug in
> > > >tool which is the authoring environment for a specific format, and
> > > >that the plug in would have to provide any prompting for that
> > format itself.
> > >
> > >Sean, this is a a concern even with the qualification that this
> > >provision only applies to an authoring tool with a user interface?
> > >This is an interesting example; can you provide more information
> > >about how that would work? For the examples that I can think of that
> > >meet the situation that you describe, the requirement would be null
> > >because there would not be a user interface (though perhaps that's a
> > >flaw that might be better addressed by other language).
> > >
> > > >This could be addressed by clarifying that an authoring tool may be
> > > >a component of a larger suite or framework into the definition of
> > > >authoring tool:
> > > >
> > > ><proposal>
> > > >Any software intended to create or modify content for publication.
> > > >This definition covers authoring tools which are able to create or
> > > >modify content in a format such that the format supports compliance
> > > >with the user interface and content provisions.
> > > >
> > > >Note: Such software may be a component, either built in or added
> > > >later as a plug in, of a larger software environment; in which case
> > > >it is the component that is for the purposes of this definition the
> > > >authoring tool and not the containing environment, even if the
> > > >containing environment may also be considered an authoring tool in
> > > >its own right.
> > > ></proposal>
> > >
> > >Interesting. Thanks for this idea. Poking at it a bit, I'm not sure
> > >that you want the time-restriction of "later"... you could just drop
> > >that word, and leave the rest there. Also, everything after "that is
> > >for this purposes of this definition" gets extremely difficult to
> > >parse. Any possibility of taking another pass at it in the morning?
> > >
> > >- Judy
> > >
> > >
> > > >Sean Hayes
> > > >Incubation Lab
> > > >Accessibility Business Unit
> > > >Microsoft
> > > >
> > > >Office: +44 118 909 5867,
> > > >Mobile: +44 7875 091385
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: = EMAIL ADDRESS REMOVED =
> > > >[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > >Andrew Kirkpatrick
> > > >Sent: 26 February 2008 21:35
> > > >To: TEITAC Committee
> > > >Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > >
> > > > > It might save us a turn or two if you could say a little more here;
> > > > > for instance, am I correct in assuming that, with regard to Sean's
> > > > > proposal, which was:
> > > >
> > > >Sure, but I might be less terse if I wasn't also trying to pay attention
> > > >to the TEITAC call or the next conference call I'm on...
> > > >
> > > > > you would support (?):
> > > > >
> > > > > "Authoring tools with a user interface must provide, either alone or
> > > > > with additional tools, a mode which prompts authors to create
> > > > > accessible content."
> > > >
> > > >Authoring tools with a user interface must provide, either directly or
> > > >through a third-party tool, a mode which prompts authors to create
> > > >accessible content.
> > > >
> > > >AWK
> > > >
> > > >