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

Return to this mailing list's archives

From: Andrew Kirkpatrick
Date: Tue, Mar 18 2008 10:45 AM
Subject: Re: 7-C Prompts (in authoring tools)

I have concerns about this language.

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

I'm concerned that this hinges together tools from different companies
or organizations and makes the evaluation of one dependent on the other,
even though there may not be a relationship between the companies. This
will cause difficulties for federal procurement agents in assessing
compliance.

An example: Adobe has a tool called Presenter. The main function of
Presenter is to import Microsoft PowerPoint files and generate an
accessible web-based Flash presentation that utilizes accessibility
information contained in the PowerPoint file (e.g. equivalents for
images, content order). I can see contracting officers wondering if the
fact that Presenter doesn't prompt for this information makes it not
compliant - should PowerPoint provide the prompting, or should Presenter
prompt for the information when it is missing, or should presenter
prompt for the information _always_ since it _might_ not be correct?

There is already ambiguity in this language related to what should be
prompted for, I don't think that adding ambiguity over where this is
assessed is desired.

AWK


> >
> >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#804
> 8
> >
> >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
> > > > > >
> > > > > >

From: Hoffman, Allen
Date: Tue, Mar 18 2008 12:00 PM
Subject: Re: 7-C Prompts (in authoring tools)

Can you propose more scoped language?



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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Tuesday, March 18, 2008 12:39 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)

I have concerns about this language.

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

I'm concerned that this hinges together tools from different companies
or organizations and makes the evaluation of one dependent on the other,
even though there may not be a relationship between the companies. This
will cause difficulties for federal procurement agents in assessing
compliance.

An example: Adobe has a tool called Presenter. The main function of
Presenter is to import Microsoft PowerPoint files and generate an
accessible web-based Flash presentation that utilizes accessibility
information contained in the PowerPoint file (e.g. equivalents for
images, content order). I can see contracting officers wondering if the
fact that Presenter doesn't prompt for this information makes it not
compliant - should PowerPoint provide the prompting, or should Presenter
prompt for the information when it is missing, or should presenter
prompt for the information _always_ since it _might_ not be correct?

There is already ambiguity in this language related to what should be
prompted for, I don't think that adding ambiguity over where this is
assessed is desired.

AWK


> >
> >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#804
> 8
> >
> >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
> > > > > >
> > > > > >

From: Judy Brewer
Date: Tue, Mar 18 2008 12:20 PM
Subject: Re: 7-C Prompts (in authoring tools)

Hi Andrew,

Thanks for your reply. Comments below.

At 09:39 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
>I have concerns about this language.
>
> >"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."
>
>I'm concerned that this hinges together tools from different companies
>or organizations and makes the evaluation of one dependent on the other,
>even though there may not be a relationship between the companies. This
>will cause difficulties for federal procurement agents in assessing
>compliance.

Just to be clear about one thing, the intent of this language was not
to force an association between tools where a given vendor was not
intending to offer a specific package of tools. Instead it was to
allow a vendor the flexibility to offer a package that combines their
own products with second or third party products that might having
prompting capabilities that their own products lacked. If one of your
concerns is that your products might be forced into a suite by
someone on the procurement side, this seems correctable with a note
indicating something along these lines:
"Note: Such a suite would only be defined by the vendor"
or it could be integrated, as follows:
"or suite of tools used to author content" could become "or
suite of tools as defined by the vendor, and used to author content"

(more comments below)

>An example: Adobe has a tool called Presenter. The main function of
>Presenter is to import Microsoft PowerPoint files and generate an
>accessible web-based Flash presentation that utilizes accessibility
>information contained in the PowerPoint file (e.g. equivalents for
>images, content order). I can see contracting officers wondering if the
>fact that Presenter doesn't prompt for this information makes it not
>compliant - should PowerPoint provide the prompting, or should Presenter
>prompt for the information when it is missing, or should presenter
>prompt for the information _always_ since it _might_ not be correct?

I believe that this general issue is addressed in the following phrase:
"...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, ..."

As currently written, if Presenter had the capability to analyze or
correct specific accessibility problems when converting from
PowerPoint to Flash, then it would need to have a mode in which it
could prompt for accessibility information; but if it did not have
the capability to analyze or correct info within PowerPoint or Flash,
then it would not need to prompt for that information within some mode.

Furthermore, since prompting is not required except in one mode, then
I believe that there is no requirement for it to _always_ prompt, as
you suggest above.

As for whether the tool, when prompting, should only prompt for
missing information, or also prompt for corrections, this seems
strongly linked to the question of which accessibility issues the
tool is capable of analyzing. For instance, if equivalents are
missing for an image, it is straightforward to prompt for the missing
equivalents. But if an equivalent is a single word followed by a
filename extension, many authoring tools have the capability to
analyze that equivalent text and prompt for something more meaningful
than a filename alone.

>There is already ambiguity in this language related to what should be
>prompted for, I don't think that adding ambiguity over where this is
>assessed is desired.

I'm not clear what your last concern here is ("ambiguity over where
this is assessed"). If your specific concern is regarding the phrase
"...for accessibility problems that the tool or suite has the capability
to analyze or correct..."
then I think that this is important to keep, to ensure that the
provision is not applied to authoring for formats that the tool is
unable to do anything about.

Had that phrase been your concern; and if so, do my comments above
address your concern; and if they don't, can you suggest a change
that would address your concern?

Regards,

- Judy

>AWK
>
>
> > >
> > >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#804
> > 8
> > >
> > >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
> > > > > > >
> > > > > > >

From: Andrew Kirkpatrick
Date: Tue, Mar 18 2008 12:25 PM
Subject: Re: 7-C Prompts (in authoring tools)

That's the challenge that we've been struggling with all along. I'm not
sure that I can. My concern is that the overall ecosystem for how
content is created by 'authoring tools' is sufficiently complex as to
make this a larger challenge than we initially anticipated.

AWK



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:teitac-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman, Allen
> Sent: Tuesday, March 18, 2008 1:48 PM
> To: TEITAC Committee
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
>
> Can you propose more scoped language?
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
> Kirkpatrick
> Sent: Tuesday, March 18, 2008 12:39 PM
> To: TEITAC Committee
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
>
> I have concerns about this language.
>
> >"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."
>
> I'm concerned that this hinges together tools from different companies
> or organizations and makes the evaluation of one dependent on the
other,
> even though there may not be a relationship between the companies.
> This
> will cause difficulties for federal procurement agents in assessing
> compliance.
>
> An example: Adobe has a tool called Presenter. The main function of
> Presenter is to import Microsoft PowerPoint files and generate an
> accessible web-based Flash presentation that utilizes accessibility
> information contained in the PowerPoint file (e.g. equivalents for
> images, content order). I can see contracting officers wondering if
> the
> fact that Presenter doesn't prompt for this information makes it not
> compliant - should PowerPoint provide the prompting, or should
> Presenter
> prompt for the information when it is missing, or should presenter
> prompt for the information _always_ since it _might_ not be correct?
>
> There is already ambiguity in this language related to what should be
> prompted for, I don't think that adding ambiguity over where this is
> assessed is desired.
>
> AWK
>
>
> > >
> > >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#804
> > 8
> > >
> > >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
> > > > > > >
> > > > > > >

From: Andrew Kirkpatrick
Date: Tue, Mar 18 2008 12:50 PM
Subject: Re: 7-C Prompts (in authoring tools)

My comments below
> Just to be clear about one thing, the intent of this language was not
> to force an association between tools where a given vendor was not
> intending to offer a specific package of tools. Instead it was to
> allow a vendor the flexibility to offer a package that combines their
> own products with second or third party products that might having
> prompting capabilities that their own products lacked. If one of your
> concerns is that your products might be forced into a suite by
> someone on the procurement side, this seems correctable with a note
> indicating something along these lines:
> "Note: Such a suite would only be defined by the vendor"
> or it could be integrated, as follows:
> "or suite of tools used to author content" could become "or
> suite of tools as defined by the vendor, and used to author content"

I'm not sure that this resolves the issue, which is that we can have a
tool that is able to comply with the standards as long as a separate
tool is used correctly, and the result is complications in procurement.
I'm hearing you say that the suite could made to be only defined by the
vendor, but if it is still evaluated against this standard we are
potentially requiring that vendors bundle their software with other
vendors even if the tool is doing what it should already. Maybe I'm
misreading this, but this is my concern.

> >An example: Adobe has a tool called Presenter. The main function
of
> >Presenter is to import Microsoft PowerPoint files and generate an
> >accessible web-based Flash presentation that utilizes accessibility
> >information contained in the PowerPoint file (e.g. equivalents for
> >images, content order). I can see contracting officers wondering if
> the
> >fact that Presenter doesn't prompt for this information makes it not
> >compliant - should PowerPoint provide the prompting, or should
> Presenter
> >prompt for the information when it is missing, or should presenter
> >prompt for the information _always_ since it _might_ not be correct?
>
> I believe that this general issue is addressed in the following
phrase:
> "...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, ..."

How do we determine if a piece of software has this ability? If a tool
works with an evaluation tool to examine compliance with the standards
is that evaluation tool now part of the authoring tool or authoring tool
suite?

AWK

From: Hoffman, Allen
Date: Tue, Mar 18 2008 1:05 PM
Subject: Re: 7-C Prompts (in authoring tools)

I believe this can be resolved at representation time:

In an accessibility statement a vendor might say:

XXX meets this provision without aid of other products.

or

XXX when used with yyy meets this provision.

or

XXX does not meet this provision, and at time of writing, no add-on
tools are known that allow xxx to meet this provision.

The vendor may not have to bundle the applications, but providing this
information of add-on known products does tell the purchaser that the
capacity is available in the market. Alternately a vendor can just
build this functionality in, bundle products to meet this, or not meet
it.






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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Tuesday, March 18, 2008 2:45 PM
To: Judy Brewer; TEITAC Committee
Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)

My comments below
> Just to be clear about one thing, the intent of this language was not
> to force an association between tools where a given vendor was not
> intending to offer a specific package of tools. Instead it was to
> allow a vendor the flexibility to offer a package that combines their
> own products with second or third party products that might having
> prompting capabilities that their own products lacked. If one of your
> concerns is that your products might be forced into a suite by someone

> on the procurement side, this seems correctable with a note indicating

> something along these lines:
> "Note: Such a suite would only be defined by the vendor"
> or it could be integrated, as follows:
> "or suite of tools used to author content" could become "or
> suite of tools as defined by the vendor, and used to author content"

I'm not sure that this resolves the issue, which is that we can have a
tool that is able to comply with the standards as long as a separate
tool is used correctly, and the result is complications in procurement.
I'm hearing you say that the suite could made to be only defined by the
vendor, but if it is still evaluated against this standard we are
potentially requiring that vendors bundle their software with other
vendors even if the tool is doing what it should already. Maybe I'm
misreading this, but this is my concern.

> >An example: Adobe has a tool called Presenter. The main function
of
> >Presenter is to import Microsoft PowerPoint files and generate an
> >accessible web-based Flash presentation that utilizes accessibility
> >information contained in the PowerPoint file (e.g. equivalents for
> >images, content order). I can see contracting officers wondering if
> the
> >fact that Presenter doesn't prompt for this information makes it not
> >compliant - should PowerPoint provide the prompting, or should
> Presenter
> >prompt for the information when it is missing, or should presenter
> >prompt for the information _always_ since it _might_ not be correct?
>
> I believe that this general issue is addressed in the following
phrase:
> "...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, ..."

How do we determine if a piece of software has this ability? If a tool
works with an evaluation tool to examine compliance with the standards
is that evaluation tool now part of the authoring tool or authoring tool
suite?

AWK

From: Judy Brewer
Date: Tue, Mar 18 2008 2:15 PM
Subject: Re: 7-C Prompts (in authoring tools)

Comments below:

At 11:45 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
>My comments below
><...>
>I'm hearing you say that the suite could made to be only defined by the
>vendor, but if it is still evaluated against this standard we are
>potentially requiring that vendors bundle their software with other
>vendors even if the tool is doing what it should already. Maybe I'm
>misreading this, but this is my concern.

Please note the first three words of the proposed provision:

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

A vendor is under no obligation to bundle their software with other
vendors' software, regardless of whether their tools do everything
that they should. The option of a suite was there to give flexibility
to vendors who need or want other tools to supplement the
capabilities of their own tools.

(more below)

> > >An example: Adobe has a tool called Presenter. The main function of
> > >Presenter is to import Microsoft PowerPoint files and generate an
> > >accessible web-based Flash presentation that utilizes accessibility
> > >information contained in the PowerPoint file (e.g. equivalents for
> > >images, content order). I can see contracting officers wondering if the
> > >fact that Presenter doesn't prompt for this information makes it not
> > >compliant - should PowerPoint provide the prompting, or should
> > Presenter
> > >prompt for the information when it is missing, or should presenter
> > >prompt for the information _always_ since it _might_ not be correct?
> >
> > I believe that this general issue is addressed in the following
>phrase:
> > "...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, ..."
>
>How do we determine if a piece of software has this ability? If a tool
>works with an evaluation tool to examine compliance with the standards
>is that evaluation tool now part of the authoring tool or authoring tool
>suite?

Hmmm. Restoring my subsequent text, which provided an example of this:

>>As for whether the tool, when prompting, should only prompt for
>>missing information, or also prompt for corrections, this seems
>>strongly linked to the question of which accessibility issues the
>>tool is capable of analyzing. For instance, if equivalents are
>>missing for an image, it is straightforward to prompt for the
>>missing equivalents. But if an equivalent is a single word followed
>>by a filename extension, many authoring tools have the capability
>>to analyze that equivalent text and prompt for something more
>>meaningful than a filename alone.

Andrew, are you suggesting the removal of "to analyze" from the text
of this provision? Sean had suggested this wording with "analyze",
but it does imply on-board evaluation function. By removing
"analyze," it would remove an implied availability of an evaluation
function, and focus more clearly on prompting for things that the
tool has the ability to correct. This might be easier to understand,
to comply with, and to evaluate. The proposed text would then read:

"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 correct, for formats authored by that tool or suite
which support compliance as explained in the definition of authoring tool."

Andrew, Sean, would this work?

- Judy




>AWK

From: whitneyq@wqusability.com
Date: Wed, Mar 19 2008 6:25 AM
Subject: Re: 7-C Prompts (in authoring tools)

I see the issues that Version 5 is trying to solve, but the wording is so convoluted that it's hard to understand what it's saying. A revised version follows

Version 5 says:

"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,]]...'

- If there is a definition of authoring tool (suggested in the final words), why do we need such a lot of verbiage here. Let's put this phrase into the definition.

"...must provide a mode which prompts authors to create accessible content..."
- Here's the meat of the provision

"...for accessibility problems that the tool [[or suite]] has the capability to correct,..."
- I don't understand this phrase: it sounds like an authoring tool can decide not to support something, and is then relieved of all responsibility. It's a chicken-and-egg problem, but if the format includes a capability, surely the tools should either support it, or at least inform users that they do not.

"...for formats authored by that tool [[or suite]]..."
- OK. This allows a product to define its features and only support the format it supports. As above, don't need the "or suite".

"...[[which support compliance as explained in the definition of authoring tool.]]"
- Why do we need to restate (and reference) a definition that provides this scope (compliance with UI and content provisions) more clearly.



Here's my suggestions for both the definition and provision:

DEFINITION: AUTHORING TOOL
Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. An authoring tool may be a single product, or a suite of tools from a single vendor or multiple vendors.

Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.


7-C - PROMPTS
An authoring tool must provide a mode which prompts authors to create accessible content for formats authored by that tool.

Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.

Note 2: Authoring tools are primarily responsible for accessibility problems that they have the capability to correct, but may provide prompts for other problems as well.





> -------- Original Message --------
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> From: Judy Brewer < = EMAIL ADDRESS REMOVED = >
> Date: Tue, March 18, 2008 1:07 pm
> To: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >, "Sean Hayes"
> < = EMAIL ADDRESS REMOVED = >, "TEITAC Committee"
> < = EMAIL ADDRESS REMOVED = >
>
> Comments below:
>
> At 11:45 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
> >My comments below
> ><...>
> >I'm hearing you say that the suite could made to be only defined by the
> >vendor, but if it is still evaluated against this standard we are
> >potentially requiring that vendors bundle their software with other
> >vendors even if the tool is doing what it should already. Maybe I'm
> >misreading this, but this is my concern.
>
> Please note the first three words of the proposed provision:
>
> "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."
>
> A vendor is under no obligation to bundle their software with other
> vendors' software, regardless of whether their tools do everything
> that they should. The option of a suite was there to give flexibility
> to vendors who need or want other tools to supplement the
> capabilities of their own tools.
>
> (more below)
>
> > > >An example: Adobe has a tool called Presenter. The main function of
> > > >Presenter is to import Microsoft PowerPoint files and generate an
> > > >accessible web-based Flash presentation that utilizes accessibility
> > > >information contained in the PowerPoint file (e.g. equivalents for
> > > >images, content order). I can see contracting officers wondering if the
> > > >fact that Presenter doesn't prompt for this information makes it not
> > > >compliant - should PowerPoint provide the prompting, or should
> > > Presenter
> > > >prompt for the information when it is missing, or should presenter
> > > >prompt for the information _always_ since it _might_ not be correct?
> > >
> > > I believe that this general issue is addressed in the following
> >phrase:
> > > "...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, ..."
> >
> >How do we determine if a piece of software has this ability? If a tool
> >works with an evaluation tool to examine compliance with the standards
> >is that evaluation tool now part of the authoring tool or authoring tool
> >suite?
>
> Hmmm. Restoring my subsequent text, which provided an example of this:
>
> >>As for whether the tool, when prompting, should only prompt for
> >>missing information, or also prompt for corrections, this seems
> >>strongly linked to the question of which accessibility issues the
> >>tool is capable of analyzing. For instance, if equivalents are
> >>missing for an image, it is straightforward to prompt for the
> >>missing equivalents. But if an equivalent is a single word followed
> >>by a filename extension, many authoring tools have the capability
> >>to analyze that equivalent text and prompt for something more
> >>meaningful than a filename alone.
>
> Andrew, are you suggesting the removal of "to analyze" from the text
> of this provision? Sean had suggested this wording with "analyze",
> but it does imply on-board evaluation function. By removing
> "analyze," it would remove an implied availability of an evaluation
> function, and focus more clearly on prompting for things that the
> tool has the ability to correct. This might be easier to understand,
> to comply with, and to evaluate. The proposed text would then read:
>
> "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 correct, for formats authored by that tool or suite
> which support compliance as explained in the definition of authoring tool."
>
> Andrew, Sean, would this work?
>
> - Judy
>
>
>
>
> >AWK
>
>
>

From: Hoffman, Allen
Date: Wed, Mar 19 2008 6:30 AM
Subject: Re: 7-C Prompts (in authoring tools)

I think this is a great improvement, thanks Whitney.
Here is only a minor change to the wording of the provision to improve
readability.

Whitney's original:
7-C - PROMPTS
An authoring tool must provide a mode which prompts authors to create
accessible content for formats authored by that tool.

My suggested change:
7-C - PROMPTS
Authoring tools must provide a mode which prompts authors to assist in
creation of accessible content for formats authored by that tool.

The difference from my perspective is that the tools should "help"
authors, not prompt them only. So, for example the meaning of prompt
authors to create accessible content might mean for some that a prompt
"make sure its accessible' would be sufficient, when clearly that isn't
what we intended. A tool that allows an author to get prompted for
adding attributes to columnar information, or tables for reading
sequence is more in line with our thinking, than a simple prompt to make
it accessible which could be some folks mis-interpretation. A not of
this type might help clear this up without provision change, but
hopefully my suggested change does the trick for all.

Thanks.




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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Wednesday, March 19, 2008 8:20 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)

I see the issues that Version 5 is trying to solve, but the wording is
so convoluted that it's hard to understand what it's saying. A revised
version follows

Version 5 says:

"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,]]...'

- If there is a definition of authoring tool (suggested in the final
words), why do we need such a lot of verbiage here. Let's put this
phrase into the definition.

"...must provide a mode which prompts authors to create accessible
content..."
- Here's the meat of the provision

"...for accessibility problems that the tool [[or suite]] has the
capability to correct,..."
- I don't understand this phrase: it sounds like an authoring tool can
decide not to support something, and is then relieved of all
responsibility. It's a chicken-and-egg problem, but if the format
includes a capability, surely the tools should either support it, or at
least inform users that they do not.

"...for formats authored by that tool [[or suite]]..."
- OK. This allows a product to define its features and only support the
format it supports. As above, don't need the "or suite".

"...[[which support compliance as explained in the definition of
authoring tool.]]"
- Why do we need to restate (and reference) a definition that provides
this scope (compliance with UI and content provisions) more clearly.



Here's my suggestions for both the definition and provision:

DEFINITION: AUTHORING TOOL
Any software intended to create or modify electronic content for
publication in one or more formats that support compliance with the user
interface and content provisions. An authoring tool may be a single
product, or a suite of tools from a single vendor or multiple vendors.

Note: Simple text editors that can only create or modify content in
conforming formats by directly editing the code are not considered
authoring tools under this definition.


7-C - PROMPTS
An authoring tool must provide a mode which prompts authors to create
accessible content for formats authored by that tool.

Note 1: It is neither expected nor possible that prompts be available
for every type of accessible content.

Note 2: Authoring tools are primarily responsible for accessibility
problems that they have the capability to correct, but may provide
prompts for other problems as well.





> -------- Original Message --------
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> From: Judy Brewer < = EMAIL ADDRESS REMOVED = >
> Date: Tue, March 18, 2008 1:07 pm
> To: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >, "Sean Hayes"
> < = EMAIL ADDRESS REMOVED = >, "TEITAC Committee"
> < = EMAIL ADDRESS REMOVED = >
>
> Comments below:
>
> At 11:45 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
> >My comments below
> ><...>
> >I'm hearing you say that the suite could made to be only defined by
> >the vendor, but if it is still evaluated against this standard we are

> >potentially requiring that vendors bundle their software with other
> >vendors even if the tool is doing what it should already. Maybe I'm
> >misreading this, but this is my concern.
>
> Please note the first three words of the proposed provision:
>
> "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."
>
> A vendor is under no obligation to bundle their software with other
> vendors' software, regardless of whether their tools do everything
> that they should. The option of a suite was there to give flexibility
> to vendors who need or want other tools to supplement the capabilities

> of their own tools.
>
> (more below)
>
> > > >An example: Adobe has a tool called Presenter. The main
function of
> > > >Presenter is to import Microsoft PowerPoint files and generate an

> > > >accessible web-based Flash presentation that utilizes
> > > >accessibility information contained in the PowerPoint file (e.g.
> > > >equivalents for images, content order). I can see contracting
> > > >officers wondering if the fact that Presenter doesn't prompt for
> > > >this information makes it not compliant - should PowerPoint
> > > >provide the prompting, or should
> > > Presenter
> > > >prompt for the information when it is missing, or should
> > > >presenter prompt for the information _always_ since it _might_
not be correct?
> > >
> > > I believe that this general issue is addressed in the following
> >phrase:
> > > "...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, ..."
> >
> >How do we determine if a piece of software has this ability? If a
> >tool works with an evaluation tool to examine compliance with the
> >standards is that evaluation tool now part of the authoring tool or
> >authoring tool suite?
>
> Hmmm. Restoring my subsequent text, which provided an example of this:
>
> >>As for whether the tool, when prompting, should only prompt for
> >>missing information, or also prompt for corrections, this seems
> >>strongly linked to the question of which accessibility issues the
> >>tool is capable of analyzing. For instance, if equivalents are
> >>missing for an image, it is straightforward to prompt for the
> >>missing equivalents. But if an equivalent is a single word followed
> >>by a filename extension, many authoring tools have the capability to

> >>analyze that equivalent text and prompt for something more
> >>meaningful than a filename alone.
>
> Andrew, are you suggesting the removal of "to analyze" from the text
> of this provision? Sean had suggested this wording with "analyze", but

> it does imply on-board evaluation function. By removing "analyze," it
> would remove an implied availability of an evaluation function, and
> focus more clearly on prompting for things that the tool has the
> ability to correct. This might be easier to understand, to comply
> with, and to evaluate. The proposed text would then read:
>
> "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 correct, for formats authored by that tool or
> suite which support compliance as explained in the definition of
authoring tool."
>
> Andrew, Sean, would this work?
>
> - Judy
>
>
>
>
> >AWK
>
>
>

From: Sean Hayes
Date: Wed, Mar 19 2008 7:25 AM
Subject: Re: 7-C Prompts (in authoring tools)

I'm Ok with rolling the suite/vendor idea into the definition, if we change the term to something like "a toolset used to author content".

I'm not OK with making the scope phrase a note. The issue is exemplified by a tool which combines content (say an HTML editor), where it is possible to drag a video onto the page, but the tool has no ability to edit or analyse the video. The HTML tool can be expected to prompt for a text alternative but not to add captions, or check for potential seizure inducing Flashes

Based on that, I could live with something like:

DEFINITION: TOOLSET USED TO AUTHOR CONTENT
Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. Such tools may be a single product, or a suite of tools from a single vendor or multiple vendors.

Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.


7-C - PROMPTS
A Toolset used to author content must provide a mode which prompts authors to create accessible content for formats authored by those tools and for accessibility problems that the tools have the capability to correct.
Tools may provide prompts for other problems as well.

Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.


Sean Hayes
Media Acessibility Strategist
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 = EMAIL ADDRESS REMOVED =
Sent: 19 March 2008 12:20
To: TEITAC Committee
Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)

I see the issues that Version 5 is trying to solve, but the wording is so convoluted that it's hard to understand what it's saying. A revised version follows

Version 5 says:

"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,]]...'

- If there is a definition of authoring tool (suggested in the final words), why do we need such a lot of verbiage here. Let's put this phrase into the definition.

"...must provide a mode which prompts authors to create accessible content..."
- Here's the meat of the provision

"...for accessibility problems that the tool [[or suite]] has the capability to correct,..."
- I don't understand this phrase: it sounds like an authoring tool can decide not to support something, and is then relieved of all responsibility. It's a chicken-and-egg problem, but if the format includes a capability, surely the tools should either support it, or at least inform users that they do not.

"...for formats authored by that tool [[or suite]]..."
- OK. This allows a product to define its features and only support the format it supports. As above, don't need the "or suite".

"...[[which support compliance as explained in the definition of authoring tool.]]"
- Why do we need to restate (and reference) a definition that provides this scope (compliance with UI and content provisions) more clearly.



Here's my suggestions for both the definition and provision:

DEFINITION: AUTHORING TOOL
Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. An authoring tool may be a single product, or a suite of tools from a single vendor or multiple vendors.

Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.


7-C - PROMPTS
An authoring tool must provide a mode which prompts authors to create accessible content for formats authored by that tool.

Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.

Note 2: Authoring tools are primarily responsible for accessibility problems that they have the capability to correct, but may provide prompts for other problems as well.





> -------- Original Message --------
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> From: Judy Brewer < = EMAIL ADDRESS REMOVED = >
> Date: Tue, March 18, 2008 1:07 pm
> To: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >, "Sean Hayes"
> < = EMAIL ADDRESS REMOVED = >, "TEITAC Committee"
> < = EMAIL ADDRESS REMOVED = >
>
> Comments below:
>
> At 11:45 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
> >My comments below
> ><...>
> >I'm hearing you say that the suite could made to be only defined by the
> >vendor, but if it is still evaluated against this standard we are
> >potentially requiring that vendors bundle their software with other
> >vendors even if the tool is doing what it should already. Maybe I'm
> >misreading this, but this is my concern.
>
> Please note the first three words of the proposed provision:
>
> "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."
>
> A vendor is under no obligation to bundle their software with other
> vendors' software, regardless of whether their tools do everything
> that they should. The option of a suite was there to give flexibility
> to vendors who need or want other tools to supplement the
> capabilities of their own tools.
>
> (more below)
>
> > > >An example: Adobe has a tool called Presenter. The main function of
> > > >Presenter is to import Microsoft PowerPoint files and generate an
> > > >accessible web-based Flash presentation that utilizes accessibility
> > > >information contained in the PowerPoint file (e.g. equivalents for
> > > >images, content order). I can see contracting officers wondering if the
> > > >fact that Presenter doesn't prompt for this information makes it not
> > > >compliant - should PowerPoint provide the prompting, or should
> > > Presenter
> > > >prompt for the information when it is missing, or should presenter
> > > >prompt for the information _always_ since it _might_ not be correct?
> > >
> > > I believe that this general issue is addressed in the following
> >phrase:
> > > "...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, ..."
> >
> >How do we determine if a piece of software has this ability? If a tool
> >works with an evaluation tool to examine compliance with the standards
> >is that evaluation tool now part of the authoring tool or authoring tool
> >suite?
>
> Hmmm. Restoring my subsequent text, which provided an example of this:
>
> >>As for whether the tool, when prompting, should only prompt for
> >>missing information, or also prompt for corrections, this seems
> >>strongly linked to the question of which accessibility issues the
> >>tool is capable of analyzing. For instance, if equivalents are
> >>missing for an image, it is straightforward to prompt for the
> >>missing equivalents. But if an equivalent is a single word followed
> >>by a filename extension, many authoring tools have the capability
> >>to analyze that equivalent text and prompt for something more
> >>meaningful than a filename alone.
>
> Andrew, are you suggesting the removal of "to analyze" from the text
> of this provision? Sean had suggested this wording with "analyze",
> but it does imply on-board evaluation function. By removing
> "analyze," it would remove an implied availability of an evaluation
> function, and focus more clearly on prompting for things that the
> tool has the ability to correct. This might be easier to understand,
> to comply with, and to evaluate. The proposed text would then read:
>
> "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 correct, for formats authored by that tool or suite
> which support compliance as explained in the definition of authoring tool."
>
> Andrew, Sean, would this work?
>
> - Judy
>
>
>
>
> >AWK
>
>
>

From: whitneyq@wqusability.com
Date: Wed, Mar 19 2008 7:45 AM
Subject: Re: 7-C Prompts (in authoring tools)

"A toolset used to author content"? That sounds like the definition, not the term. What do we gain by replacing a simple term with a tongue twister? Will simple tools think they are excluded?

I agree with the point about an HTML editor handing video. I completely agree with your point. But you are assuming that an authoring tool can only prompt for something it can then execute. There's no reason why the prompt can't include the option of captioning the video EVEN IF that particular authoring tool doesn't support captions. If the term "toolset" is critical to you, perhaps:

DEFINITION: AUTHORING TOOL
Any software or toolset intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. Such tools may be a single product, or a suite of tools from a single vendor or multiple vendors.

Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.

7-C - PROMPTS
An authoring tool must provide a mode which prompts authors to create accessible content in formats authored by those tools, for accessibility problems that the tool can correct. Tools may provide prompts for other problems as well.

Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.

> -------- Original Message --------
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> Date: Wed, March 19, 2008 6:20 am
> To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
>
> I'm Ok with rolling the suite/vendor idea into the definition, if we change the term to something like "a toolset used to author content".
>
> I'm not OK with making the scope phrase a note. The issue is exemplified by a tool which combines content (say an HTML editor), where it is possible to drag a video onto the page, but the tool has no ability to edit or analyse the video. The HTML tool can be expected to prompt for a text alternative but not to add captions, or check for potential seizure inducing Flashes
>
> Based on that, I could live with something like:
>
> DEFINITION: TOOLSET USED TO AUTHOR CONTENT
> Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. Such tools may be a single product, or a suite of tools from a single vendor or multiple vendors.
>
> Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.
>
>
> 7-C - PROMPTS
> A Toolset used to author content must provide a mode which prompts authors to create accessible content for formats authored by those tools and for accessibility problems that the tools have the capability to correct.
> Tools may provide prompts for other problems as well.
>
> Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.
>
>
> Sean Hayes
> Media Acessibility Strategist
> 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 = EMAIL ADDRESS REMOVED =
> Sent: 19 March 2008 12:20
> To: TEITAC Committee
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
>
> I see the issues that Version 5 is trying to solve, but the wording is so convoluted that it's hard to understand what it's saying. A revised version follows
>
> Version 5 says:
>
> "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,]]...'
>
> - If there is a definition of authoring tool (suggested in the final words), why do we need such a lot of verbiage here. Let's put this phrase into the definition.
>
> "...must provide a mode which prompts authors to create accessible content..."
> - Here's the meat of the provision
>
> "...for accessibility problems that the tool [[or suite]] has the capability to correct,..."
> - I don't understand this phrase: it sounds like an authoring tool can decide not to support something, and is then relieved of all responsibility. It's a chicken-and-egg problem, but if the format includes a capability, surely the tools should either support it, or at least inform users that they do not.
>
> "...for formats authored by that tool [[or suite]]..."
> - OK. This allows a product to define its features and only support the format it supports. As above, don't need the "or suite".
>
> "...[[which support compliance as explained in the definition of authoring tool.]]"
> - Why do we need to restate (and reference) a definition that provides this scope (compliance with UI and content provisions) more clearly.
>
>
>
> Here's my suggestions for both the definition and provision:
>
> DEFINITION: AUTHORING TOOL
> Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. An authoring tool may be a single product, or a suite of tools from a single vendor or multiple vendors.
>
> Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.
>
>
> 7-C - PROMPTS
> An authoring tool must provide a mode which prompts authors to create accessible content for formats authored by that tool.
>
> Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.
>
> Note 2: Authoring tools are primarily responsible for accessibility problems that they have the capability to correct, but may provide prompts for other problems as well.
>
>
>
>
>
> > -------- Original Message --------
> > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > From: Judy Brewer < = EMAIL ADDRESS REMOVED = >
> > Date: Tue, March 18, 2008 1:07 pm
> > To: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >, "Sean Hayes"
> > < = EMAIL ADDRESS REMOVED = >, "TEITAC Committee"
> > < = EMAIL ADDRESS REMOVED = >
> >
> > Comments below:
> >
> > At 11:45 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
> > >My comments below
> > ><...>
> > >I'm hearing you say that the suite could made to be only defined by the
> > >vendor, but if it is still evaluated against this standard we are
> > >potentially requiring that vendors bundle their software with other
> > >vendors even if the tool is doing what it should already. Maybe I'm
> > >misreading this, but this is my concern.
> >
> > Please note the first three words of the proposed provision:
> >
> > "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."
> >
> > A vendor is under no obligation to bundle their software with other
> > vendors' software, regardless of whether their tools do everything
> > that they should. The option of a suite was there to give flexibility
> > to vendors who need or want other tools to supplement the
> > capabilities of their own tools.
> >
> > (more below)
> >
> > > > >An example: Adobe has a tool called Presenter. The main function of
> > > > >Presenter is to import Microsoft PowerPoint files and generate an
> > > > >accessible web-based Flash presentation that utilizes accessibility
> > > > >information contained in the PowerPoint file (e.g. equivalents for
> > > > >images, content order). I can see contracting officers wondering if the
> > > > >fact that Presenter doesn't prompt for this information makes it not
> > > > >compliant - should PowerPoint provide the prompting, or should
> > > > Presenter
> > > > >prompt for the information when it is missing, or should presenter
> > > > >prompt for the information _always_ since it _might_ not be correct?
> > > >
> > > > I believe that this general issue is addressed in the following
> > >phrase:
> > > > "...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, ..."
> > >
> > >How do we determine if a piece of software has this ability? If a tool
> > >works with an evaluation tool to examine compliance with the standards
> > >is that evaluation tool now part of the authoring tool or authoring tool
> > >suite?
> >
> > Hmmm. Restoring my subsequent text, which provided an example of this:
> >
> > >>As for whether the tool, when prompting, should only prompt for
> > >>missing information, or also prompt for corrections, this seems
> > >>strongly linked to the question of which accessibility issues the
> > >>tool is capable of analyzing. For instance, if equivalents are
> > >>missing for an image, it is straightforward to prompt for the
> > >>missing equivalents. But if an equivalent is a single word followed
> > >>by a filename extension, many authoring tools have the capability
> > >>to analyze that equivalent text and prompt for something more
> > >>meaningful than a filename alone.
> >
> > Andrew, are you suggesting the removal of "to analyze" from the text
> > of this provision? Sean had suggested this wording with "analyze",
> > but it does imply on-board evaluation function. By removing
> > "analyze," it would remove an implied availability of an evaluation
> > function, and focus more clearly on prompting for things that the
> > tool has the ability to correct. This might be easier to understand,
> > to comply with, and to evaluate. The proposed text would then read:
> >
> > "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 correct, for formats authored by that tool or suite
> > which support compliance as explained in the definition of authoring tool."
> >
> > Andrew, Sean, would this work?
> >
> > - Judy
> >
> >
> >
> >
> > >AWK
> >
> >
> >

From: Sean Hayes
Date: Wed, Mar 19 2008 10:50 AM
Subject: Re: 7-C Prompts (in authoring tools)

Well it won't be the first time I've been accused of sacrificing clarity to the casual reader for accuracy. But when writing standards and laws, accuracy is to me more important than ease of reading.

The reason I want toolset in the clause proper, is that if it just says tool, which is a commonly understood word, then notwithstanding a clever definition, the idea that a tool may in fact mean more than one tool is likely to be lost on the agencies. Whereas it is more likely that a reader is going to look up the definition of toolset, and find that a toolset may be one tool or many.

The second point is - sure a prompt can say all sorts of things, but if the tool has no idea whether what it is asking is relevant to the content at hand (because it can't tell whether the video already has captions or not), and even when it is (the video does not have captions), leaves the author with no way to do anything about it, then that prompt is worse than useless.



Sean Hayes
Media Acessibility Strategist
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 = EMAIL ADDRESS REMOVED =
Sent: 19 March 2008 13:41
To: TEITAC Committee
Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)


"A toolset used to author content"? That sounds like the definition, not the term. What do we gain by replacing a simple term with a tongue twister? Will simple tools think they are excluded?

I agree with the point about an HTML editor handing video. I completely agree with your point. But you are assuming that an authoring tool can only prompt for something it can then execute. There's no reason why the prompt can't include the option of captioning the video EVEN IF that particular authoring tool doesn't support captions. If the term "toolset" is critical to you, perhaps:

DEFINITION: AUTHORING TOOL
Any software or toolset intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. Such tools may be a single product, or a suite of tools from a single vendor or multiple vendors.

Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.

7-C - PROMPTS
An authoring tool must provide a mode which prompts authors to create accessible content in formats authored by those tools, for accessibility problems that the tool can correct. Tools may provide prompts for other problems as well.

Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.

> -------- Original Message --------
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> Date: Wed, March 19, 2008 6:20 am
> To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
>
> I'm Ok with rolling the suite/vendor idea into the definition, if we change the term to something like "a toolset used to author content".
>
> I'm not OK with making the scope phrase a note. The issue is exemplified by a tool which combines content (say an HTML editor), where it is possible to drag a video onto the page, but the tool has no ability to edit or analyse the video. The HTML tool can be expected to prompt for a text alternative but not to add captions, or check for potential seizure inducing Flashes
>
> Based on that, I could live with something like:
>
> DEFINITION: TOOLSET USED TO AUTHOR CONTENT
> Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. Such tools may be a single product, or a suite of tools from a single vendor or multiple vendors.
>
> Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.
>
>
> 7-C - PROMPTS
> A Toolset used to author content must provide a mode which prompts authors to create accessible content for formats authored by those tools and for accessibility problems that the tools have the capability to correct.
> Tools may provide prompts for other problems as well.
>
> Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.
>
>
> Sean Hayes
> Media Acessibility Strategist
> 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 = EMAIL ADDRESS REMOVED =
> Sent: 19 March 2008 12:20
> To: TEITAC Committee
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
>
> I see the issues that Version 5 is trying to solve, but the wording is so convoluted that it's hard to understand what it's saying. A revised version follows
>
> Version 5 says:
>
> "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,]]...'
>
> - If there is a definition of authoring tool (suggested in the final words), why do we need such a lot of verbiage here. Let's put this phrase into the definition.
>
> "...must provide a mode which prompts authors to create accessible content..."
> - Here's the meat of the provision
>
> "...for accessibility problems that the tool [[or suite]] has the capability to correct,..."
> - I don't understand this phrase: it sounds like an authoring tool can decide not to support something, and is then relieved of all responsibility. It's a chicken-and-egg problem, but if the format includes a capability, surely the tools should either support it, or at least inform users that they do not.
>
> "...for formats authored by that tool [[or suite]]..."
> - OK. This allows a product to define its features and only support the format it supports. As above, don't need the "or suite".
>
> "...[[which support compliance as explained in the definition of authoring tool.]]"
> - Why do we need to restate (and reference) a definition that provides this scope (compliance with UI and content provisions) more clearly.
>
>
>
> Here's my suggestions for both the definition and provision:
>
> DEFINITION: AUTHORING TOOL
> Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. An authoring tool may be a single product, or a suite of tools from a single vendor or multiple vendors.
>
> Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.
>
>
> 7-C - PROMPTS
> An authoring tool must provide a mode which prompts authors to create accessible content for formats authored by that tool.
>
> Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.
>
> Note 2: Authoring tools are primarily responsible for accessibility problems that they have the capability to correct, but may provide prompts for other problems as well.
>
>
>
>
>
> > -------- Original Message --------
> > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > From: Judy Brewer < = EMAIL ADDRESS REMOVED = >
> > Date: Tue, March 18, 2008 1:07 pm
> > To: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >, "Sean Hayes"
> > < = EMAIL ADDRESS REMOVED = >, "TEITAC Committee"
> > < = EMAIL ADDRESS REMOVED = >
> >
> > Comments below:
> >
> > At 11:45 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
> > >My comments below
> > ><...>
> > >I'm hearing you say that the suite could made to be only defined by the
> > >vendor, but if it is still evaluated against this standard we are
> > >potentially requiring that vendors bundle their software with other
> > >vendors even if the tool is doing what it should already. Maybe I'm
> > >misreading this, but this is my concern.
> >
> > Please note the first three words of the proposed provision:
> >
> > "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."
> >
> > A vendor is under no obligation to bundle their software with other
> > vendors' software, regardless of whether their tools do everything
> > that they should. The option of a suite was there to give flexibility
> > to vendors who need or want other tools to supplement the
> > capabilities of their own tools.
> >
> > (more below)
> >
> > > > >An example: Adobe has a tool called Presenter. The main function of
> > > > >Presenter is to import Microsoft PowerPoint files and generate an
> > > > >accessible web-based Flash presentation that utilizes accessibility
> > > > >information contained in the PowerPoint file (e.g. equivalents for
> > > > >images, content order). I can see contracting officers wondering if the
> > > > >fact that Presenter doesn't prompt for this information makes it not
> > > > >compliant - should PowerPoint provide the prompting, or should
> > > > Presenter
> > > > >prompt for the information when it is missing, or should presenter
> > > > >prompt for the information _always_ since it _might_ not be correct?
> > > >
> > > > I believe that this general issue is addressed in the following
> > >phrase:
> > > > "...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, ..."
> > >
> > >How do we determine if a piece of software has this ability? If a tool
> > >works with an evaluation tool to examine compliance with the standards
> > >is that evaluation tool now part of the authoring tool or authoring tool
> > >suite?
> >
> > Hmmm. Restoring my subsequent text, which provided an example of this:
> >
> > >>As for whether the tool, when prompting, should only prompt for
> > >>missing information, or also prompt for corrections, this seems
> > >>strongly linked to the question of which accessibility issues the
> > >>tool is capable of analyzing. For instance, if equivalents are
> > >>missing for an image, it is straightforward to prompt for the
> > >>missing equivalents. But if an equivalent is a single word followed
> > >>by a filename extension, many authoring tools have the capability
> > >>to analyze that equivalent text and prompt for something more
> > >>meaningful than a filename alone.
> >
> > Andrew, are you suggesting the removal of "to analyze" from the text
> > of this provision? Sean had suggested this wording with "analyze",
> > but it does imply on-board evaluation function. By removing
> > "analyze," it would remove an implied availability of an evaluation
> > function, and focus more clearly on prompting for things that the
> > tool has the ability to correct. This might be easier to understand,
> > to comply with, and to evaluate. The proposed text would then read:
> >
> > "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 correct, for formats authored by that tool or suite
> > which support compliance as explained in the definition of authoring tool."
> >
> > Andrew, Sean, would this work?
> >
> > - Judy
> >
> >
> >
> >
> > >AWK
> >
> >
> >

From: whitneyq@wqusability.com
Date: Wed, Mar 19 2008 11:00 AM
Subject: Re: 7-C Prompts (in authoring tools)

Terminology: I don't think casual readers are the issue here. Nor do I think that "A toolset used to author content" adds clarity.

Prompts: Why is a prompt that reminds me that I must provide captions (etc) for the video not useful? This seems a particularly narrow view. At a minimum, it will remind me that I must do something to make this content accessible, whether I do it in one part of the suite of tools that I have assembled for authoring or another. It might even be that this is communication that happens entirely outside of anything electronic, as I shout across the room to the video editors "Yo, you forgot the captions on that video, when can I get them."

Whitney

> -------- Original Message --------
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> Date: Wed, March 19, 2008 9:44 am
> To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
>
> Well it won't be the first time I've been accused of sacrificing clarity to the casual reader for accuracy. But when writing standards and laws, accuracy is to me more important than ease of reading.
>
> The reason I want toolset in the clause proper, is that if it just says tool, which is a commonly understood word, then notwithstanding a clever definition, the idea that a tool may in fact mean more than one tool is likely to be lost on the agencies. Whereas it is more likely that a reader is going to look up the definition of toolset, and find that a toolset may be one tool or many.
>
> The second point is - sure a prompt can say all sorts of things, but if the tool has no idea whether what it is asking is relevant to the content at hand (because it can't tell whether the video already has captions or not), and even when it is (the video does not have captions), leaves the author with no way to do anything about it, then that prompt is worse than useless.
>
>
>
> Sean Hayes
> Media Acessibility Strategist
> 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 = EMAIL ADDRESS REMOVED =
> Sent: 19 March 2008 13:41
> To: TEITAC Committee
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
>
>
> "A toolset used to author content"? That sounds like the definition, not the term. What do we gain by replacing a simple term with a tongue twister? Will simple tools think they are excluded?
>
> I agree with the point about an HTML editor handing video. I completely agree with your point. But you are assuming that an authoring tool can only prompt for something it can then execute. There's no reason why the prompt can't include the option of captioning the video EVEN IF that particular authoring tool doesn't support captions. If the term "toolset" is critical to you, perhaps:
>
> DEFINITION: AUTHORING TOOL
> Any software or toolset intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. Such tools may be a single product, or a suite of tools from a single vendor or multiple vendors.
>
> Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.
>
> 7-C - PROMPTS
> An authoring tool must provide a mode which prompts authors to create accessible content in formats authored by those tools, for accessibility problems that the tool can correct. Tools may provide prompts for other problems as well.
>
> Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.
>
> > -------- Original Message --------
> > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> > Date: Wed, March 19, 2008 6:20 am
> > To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
> >
> > I'm Ok with rolling the suite/vendor idea into the definition, if we change the term to something like "a toolset used to author content".
> >
> > I'm not OK with making the scope phrase a note. The issue is exemplified by a tool which combines content (say an HTML editor), where it is possible to drag a video onto the page, but the tool has no ability to edit or analyse the video. The HTML tool can be expected to prompt for a text alternative but not to add captions, or check for potential seizure inducing Flashes
> >
> > Based on that, I could live with something like:
> >
> > DEFINITION: TOOLSET USED TO AUTHOR CONTENT
> > Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. Such tools may be a single product, or a suite of tools from a single vendor or multiple vendors.
> >
> > Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.
> >
> >
> > 7-C - PROMPTS
> > A Toolset used to author content must provide a mode which prompts authors to create accessible content for formats authored by those tools and for accessibility problems that the tools have the capability to correct.
> > Tools may provide prompts for other problems as well.
> >
> > Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.
> >
> >
> > Sean Hayes
> > Media Acessibility Strategist
> > 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 = EMAIL ADDRESS REMOVED =
> > Sent: 19 March 2008 12:20
> > To: TEITAC Committee
> > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> >
> > I see the issues that Version 5 is trying to solve, but the wording is so convoluted that it's hard to understand what it's saying. A revised version follows
> >
> > Version 5 says:
> >
> > "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,]]...'
> >
> > - If there is a definition of authoring tool (suggested in the final words), why do we need such a lot of verbiage here. Let's put this phrase into the definition.
> >
> > "...must provide a mode which prompts authors to create accessible content..."
> > - Here's the meat of the provision
> >
> > "...for accessibility problems that the tool [[or suite]] has the capability to correct,..."
> > - I don't understand this phrase: it sounds like an authoring tool can decide not to support something, and is then relieved of all responsibility. It's a chicken-and-egg problem, but if the format includes a capability, surely the tools should either support it, or at least inform users that they do not.
> >
> > "...for formats authored by that tool [[or suite]]..."
> > - OK. This allows a product to define its features and only support the format it supports. As above, don't need the "or suite".
> >
> > "...[[which support compliance as explained in the definition of authoring tool.]]"
> > - Why do we need to restate (and reference) a definition that provides this scope (compliance with UI and content provisions) more clearly.
> >
> >
> >
> > Here's my suggestions for both the definition and provision:
> >
> > DEFINITION: AUTHORING TOOL
> > Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. An authoring tool may be a single product, or a suite of tools from a single vendor or multiple vendors.
> >
> > Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.
> >
> >
> > 7-C - PROMPTS
> > An authoring tool must provide a mode which prompts authors to create accessible content for formats authored by that tool.
> >
> > Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.
> >
> > Note 2: Authoring tools are primarily responsible for accessibility problems that they have the capability to correct, but may provide prompts for other problems as well.
> >
> >
> >
> >
> >
> > > -------- Original Message --------
> > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > From: Judy Brewer < = EMAIL ADDRESS REMOVED = >
> > > Date: Tue, March 18, 2008 1:07 pm
> > > To: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >, "Sean Hayes"
> > > < = EMAIL ADDRESS REMOVED = >, "TEITAC Committee"
> > > < = EMAIL ADDRESS REMOVED = >
> > >
> > > Comments below:
> > >
> > > At 11:45 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
> > > >My comments below
> > > ><...>
> > > >I'm hearing you say that the suite could made to be only defined by the
> > > >vendor, but if it is still evaluated against this standard we are
> > > >potentially requiring that vendors bundle their software with other
> > > >vendors even if the tool is doing what it should already. Maybe I'm
> > > >misreading this, but this is my concern.
> > >
> > > Please note the first three words of the proposed provision:
> > >
> > > "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."
> > >
> > > A vendor is under no obligation to bundle their software with other
> > > vendors' software, regardless of whether their tools do everything
> > > that they should. The option of a suite was there to give flexibility
> > > to vendors who need or want other tools to supplement the
> > > capabilities of their own tools.
> > >
> > > (more below)
> > >
> > > > > >An example: Adobe has a tool called Presenter. The main function of
> > > > > >Presenter is to import Microsoft PowerPoint files and generate an
> > > > > >accessible web-based Flash presentation that utilizes accessibility
> > > > > >information contained in the PowerPoint file (e.g. equivalents for
> > > > > >images, content order). I can see contracting officers wondering if the
> > > > > >fact that Presenter doesn't prompt for this information makes it not
> > > > > >compliant - should PowerPoint provide the prompting, or should
> > > > > Presenter
> > > > > >prompt for the information when it is missing, or should presenter
> > > > > >prompt for the information _always_ since it _might_ not be correct?
> > > > >
> > > > > I believe that this general issue is addressed in the following
> > > >phrase:
> > > > > "...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, ..."
> > > >
> > > >How do we determine if a piece of software has this ability? If a tool
> > > >works with an evaluation tool to examine compliance with the standards
> > > >is that evaluation tool now part of the authoring tool or authoring tool
> > > >suite?
> > >
> > > Hmmm. Restoring my subsequent text, which provided an example of this:
> > >
> > > >>As for whether the tool, when prompting, should only prompt for
> > > >>missing information, or also prompt for corrections, this seems
> > > >>strongly linked to the question of which accessibility issues the
> > > >>tool is capable of analyzing. For instance, if equivalents are
> > > >>missing for an image, it is straightforward to prompt for the
> > > >>missing equivalents. But if an equivalent is a single word followed
> > > >>by a filename extension, many authoring tools have the capability
> > > >>to analyze that equivalent text and prompt for something more
> > > >>meaningful than a filename alone.
> > >
> > > Andrew, are you suggesting the removal of "to analyze" from the text
> > > of this provision? Sean had suggested this wording with "analyze",
> > > but it does imply on-board evaluation function. By removing
> > > "analyze," it would remove an implied availability of an evaluation
> > > function, and focus more clearly on prompting for things that the
> > > tool has the ability to correct. This might be easier to understand,
> > > to comply with, and to evaluate. The proposed text would then read:
> > >
> > > "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 correct, for formats authored by that tool or suite
> > > which support compliance as explained in the definition of authoring tool."
> > >
> > > Andrew, Sean, would this work?
> > >
> > > - Judy
> > >
> > >
> > >
> > >
> > > >AWK
> > >
> > >
> > >

From: Sean Hayes
Date: Wed, Mar 19 2008 1:20 PM
Subject: Re: 7-C Prompts (in authoring tools)

If it were just captions, OK we could live with it; but TEITAC requires a lot more than that, so as it places in a video you expect my HTML editor to ask:

Is this video captioned?
Is this video Audio Described?
Does this video contain seizure inducing flashing?
Is all text in the video adequate contrast?
Is any information in the video encoded in colour?
Blah blah blah...

And that's just video, what about all the other media types I might bring in.

Since the tool doesn't know what applies and what doesn't, it needs to ask everything, but worse it provides no way to help the user find out, so the prompt is meaningless anyway unless the author already knows (in which case the prompt was just slowing things down).

The author has two options.

If they are skilled in video editing, they might abandon the import and fire up a video tool that can help them determine the answers, where the prompts will make more sense, and might be based on some actual analysis, and where they can fix any problems. Then when they return to the HTML tool the prompts are simply a repeat and an annoyance.

Or they might just turn the prompts off (or mentally blank them out).

I can guess which is the most likely outcome.

So prompts become reduced to "this content may not be accessible, you sure you want to continue...", which will satisfy the letter of the law, without helping anyone.

Sean Hayes
Media Acessibility Strategist
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 = EMAIL ADDRESS REMOVED =
Sent: 19 March 2008 16:58
To: TEITAC Committee
Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)

Terminology: I don't think casual readers are the issue here. Nor do I think that "A toolset used to author content" adds clarity.

Prompts: Why is a prompt that reminds me that I must provide captions (etc) for the video not useful? This seems a particularly narrow view. At a minimum, it will remind me that I must do something to make this content accessible, whether I do it in one part of the suite of tools that I have assembled for authoring or another. It might even be that this is communication that happens entirely outside of anything electronic, as I shout across the room to the video editors "Yo, you forgot the captions on that video, when can I get them."

Whitney

> -------- Original Message --------
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> Date: Wed, March 19, 2008 9:44 am
> To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
>
> Well it won't be the first time I've been accused of sacrificing clarity to the casual reader for accuracy. But when writing standards and laws, accuracy is to me more important than ease of reading.
>
> The reason I want toolset in the clause proper, is that if it just says tool, which is a commonly understood word, then notwithstanding a clever definition, the idea that a tool may in fact mean more than one tool is likely to be lost on the agencies. Whereas it is more likely that a reader is going to look up the definition of toolset, and find that a toolset may be one tool or many.
>
> The second point is - sure a prompt can say all sorts of things, but if the tool has no idea whether what it is asking is relevant to the content at hand (because it can't tell whether the video already has captions or not), and even when it is (the video does not have captions), leaves the author with no way to do anything about it, then that prompt is worse than useless.
>
>
>
> Sean Hayes
> Media Acessibility Strategist
> 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 = EMAIL ADDRESS REMOVED =
> Sent: 19 March 2008 13:41
> To: TEITAC Committee
> Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
>
>
> "A toolset used to author content"? That sounds like the definition, not the term. What do we gain by replacing a simple term with a tongue twister? Will simple tools think they are excluded?
>
> I agree with the point about an HTML editor handing video. I completely agree with your point. But you are assuming that an authoring tool can only prompt for something it can then execute. There's no reason why the prompt can't include the option of captioning the video EVEN IF that particular authoring tool doesn't support captions. If the term "toolset" is critical to you, perhaps:
>
> DEFINITION: AUTHORING TOOL
> Any software or toolset intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. Such tools may be a single product, or a suite of tools from a single vendor or multiple vendors.
>
> Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.
>
> 7-C - PROMPTS
> An authoring tool must provide a mode which prompts authors to create accessible content in formats authored by those tools, for accessibility problems that the tool can correct. Tools may provide prompts for other problems as well.
>
> Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.
>
> > -------- Original Message --------
> > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> > Date: Wed, March 19, 2008 6:20 am
> > To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
> >
> > I'm Ok with rolling the suite/vendor idea into the definition, if we change the term to something like "a toolset used to author content".
> >
> > I'm not OK with making the scope phrase a note. The issue is exemplified by a tool which combines content (say an HTML editor), where it is possible to drag a video onto the page, but the tool has no ability to edit or analyse the video. The HTML tool can be expected to prompt for a text alternative but not to add captions, or check for potential seizure inducing Flashes
> >
> > Based on that, I could live with something like:
> >
> > DEFINITION: TOOLSET USED TO AUTHOR CONTENT
> > Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. Such tools may be a single product, or a suite of tools from a single vendor or multiple vendors.
> >
> > Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.
> >
> >
> > 7-C - PROMPTS
> > A Toolset used to author content must provide a mode which prompts authors to create accessible content for formats authored by those tools and for accessibility problems that the tools have the capability to correct.
> > Tools may provide prompts for other problems as well.
> >
> > Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.
> >
> >
> > Sean Hayes
> > Media Acessibility Strategist
> > 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 = EMAIL ADDRESS REMOVED =
> > Sent: 19 March 2008 12:20
> > To: TEITAC Committee
> > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> >
> > I see the issues that Version 5 is trying to solve, but the wording is so convoluted that it's hard to understand what it's saying. A revised version follows
> >
> > Version 5 says:
> >
> > "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,]]...'
> >
> > - If there is a definition of authoring tool (suggested in the final words), why do we need such a lot of verbiage here. Let's put this phrase into the definition.
> >
> > "...must provide a mode which prompts authors to create accessible content..."
> > - Here's the meat of the provision
> >
> > "...for accessibility problems that the tool [[or suite]] has the capability to correct,..."
> > - I don't understand this phrase: it sounds like an authoring tool can decide not to support something, and is then relieved of all responsibility. It's a chicken-and-egg problem, but if the format includes a capability, surely the tools should either support it, or at least inform users that they do not.
> >
> > "...for formats authored by that tool [[or suite]]..."
> > - OK. This allows a product to define its features and only support the format it supports. As above, don't need the "or suite".
> >
> > "...[[which support compliance as explained in the definition of authoring tool.]]"
> > - Why do we need to restate (and reference) a definition that provides this scope (compliance with UI and content provisions) more clearly.
> >
> >
> >
> > Here's my suggestions for both the definition and provision:
> >
> > DEFINITION: AUTHORING TOOL
> > Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions. An authoring tool may be a single product, or a suite of tools from a single vendor or multiple vendors.
> >
> > Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.
> >
> >
> > 7-C - PROMPTS
> > An authoring tool must provide a mode which prompts authors to create accessible content for formats authored by that tool.
> >
> > Note 1: It is neither expected nor possible that prompts be available for every type of accessible content.
> >
> > Note 2: Authoring tools are primarily responsible for accessibility problems that they have the capability to correct, but may provide prompts for other problems as well.
> >
> >
> >
> >
> >
> > > -------- Original Message --------
> > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > From: Judy Brewer < = EMAIL ADDRESS REMOVED = >
> > > Date: Tue, March 18, 2008 1:07 pm
> > > To: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >, "Sean Hayes"
> > > < = EMAIL ADDRESS REMOVED = >, "TEITAC Committee"
> > > < = EMAIL ADDRESS REMOVED = >
> > >
> > > Comments below:
> > >
> > > At 11:45 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
> > > >My comments below
> > > ><...>
> > > >I'm hearing you say that the suite could made to be only defined by the
> > > >vendor, but if it is still evaluated against this standard we are
> > > >potentially requiring that vendors bundle their software with other
> > > >vendors even if the tool is doing what it should already. Maybe I'm
> > > >misreading this, but this is my concern.
> > >
> > > Please note the first three words of the proposed provision:
> > >
> > > "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."
> > >
> > > A vendor is under no obligation to bundle their software with other
> > > vendors' software, regardless of whether their tools do everything
> > > that they should. The option of a suite was there to give flexibility
> > > to vendors who need or want other tools to supplement the
> > > capabilities of their own tools.
> > >
> > > (more below)
> > >
> > > > > >An example: Adobe has a tool called Presenter. The main function of
> > > > > >Presenter is to import Microsoft PowerPoint files and generate an
> > > > > >accessible web-based Flash presentation that utilizes accessibility
> > > > > >information contained in the PowerPoint file (e.g. equivalents for
> > > > > >images, content order). I can see contracting officers wondering if the
> > > > > >fact that Presenter doesn't prompt for this information makes it not
> > > > > >compliant - should PowerPoint provide the prompting, or should
> > > > > Presenter
> > > > > >prompt for the information when it is missing, or should presenter
> > > > > >prompt for the information _always_ since it _might_ not be correct?
> > > > >
> > > > > I believe that this general issue is addressed in the following
> > > >phrase:
> > > > > "...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, ..."
> > > >
> > > >How do we determine if a piece of software has this ability? If a tool
> > > >works with an evaluation tool to examine compliance with the standards
> > > >is that evaluation tool now part of the authoring tool or authoring tool
> > > >suite?
> > >
> > > Hmmm. Restoring my subsequent text, which provided an example of this:
> > >
> > > >>As for whether the tool, when prompting, should only prompt for
> > > >>missing information, or also prompt for corrections, this seems
> > > >>strongly linked to the question of which accessibility issues the
> > > >>tool is capable of analyzing. For instance, if equivalents are
> > > >>missing for an image, it is straightforward to prompt for the
> > > >>missing equivalents. But if an equivalent is a single word followed
> > > >>by a filename extension, many authoring tools have the capability
> > > >>to analyze that equivalent text and prompt for something more
> > > >>meaningful than a filename alone.
> > >
> > > Andrew, are you suggesting the removal of "to analyze" from the text
> > > of this provision? Sean had suggested this wording with "analyze",
> > > but it does imply on-board evaluation function. By removing
> > > "analyze," it would remove an implied availability of an evaluation
> > > function, and focus more clearly on prompting for things that the
> > > tool has the ability to correct. This might be easier to understand,
> > > to comply with, and to evaluate. The proposed text would then read:
> > >
> > > "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 correct, for formats authored by that tool or suite
> > > which support compliance as explained in the definition of authoring tool."
> > >
> > > Andrew, Sean, would this work?
> > >
> > > - Judy
> > >
> > >
> > >
> > >
> > > >AWK
> > >
> > >
> > >

From: Andrew Kirkpatrick
Date: Wed, Mar 19 2008 1:55 PM
Subject: Re: 7-C Prompts (in authoring tools)

> 7-C - PROMPTS
> An authoring tool must provide a mode which prompts authors to create
> accessible content in formats authored by those tools, for
> accessibility problems that the tool can correct. Tools may provide
> prompts for other problems as well.

So I'm left wondering what is sufficient here for a tool that allows one
to edit HTML. Many issues can be prompted for (even if not positively
identified as an issue) if the user can edit the source code directly.

For HTML, is it sufficient to prompt in an HTML tool for:
Form labels
Table headings
Image equivalents
Frame titles

These are the things that Dreamweaver prompts for, and I believe it is
prompting for as much as any tool, if not more. Is this enough? If not,
is there no tool that does sufficient prompting? What is enough? I'm
getting concerned that the language is trending toward subjectivity.

> Note 1: It is neither expected nor possible that prompts be available
> for every type of accessible content.

Yeah, I saw this, but my comment and concern stands.

AWK

From: Judy Brewer
Date: Mon, Mar 24 2008 1:30 PM
Subject: Re: 7-C Prompts (in authoring tools)

Going back through the suggestions on 7-C Prompts (in authoring
tools), with reference to
http://teitac.org/wiki/EWG:OpenProvisions_March_12#7-D_-_Accessible_Templates_.28Discussed_Jan_9.29
and also with reference to the thread from last week, which is intact
in the message below, I proposed a rolled-together version of some of
these suggestions.

The two latest proposals were (see below for new proposal, if you
prefer to skip ahead):

Version 5, Judy, March 18:
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 correct, for formats authored by that tool or
suite that support compliance as explained in the definition of authoring tool.

Version 6, Whitney, March 19:
An authoring tool must provide a mode which prompts authors to create
accessible content in formats authored by those tools, for
accessibility problems that the tool can correct. Tools may provide
prompts for other problems as well.

Whitney, you identified several issues, including:

1. Whether to roll the description of authoring tool as suite or
toolset into the definition of authoring tool, rather than just into
this provision. I think we should not, because to do so would change
the scope of the authoring tool provisions that were already
consensed. And as for keeping it with the proposed prompting
provision, I think that the description of suite in the existing
proposed text makes more sense than calling it a toolset. As for the
single/multiple vendor part, while clunky, it did answer a long
string of discussion that otherwise was getting in our way of making
progress on this. We could however move that into a note.

2. Whether to remove the following scoping, "...for accessibility
problems that the tool [[or suite]] has the capability to
correct,..."... this was intended to not require prompting for things
that the tool wouldn't be able to do anything about, for instance
with certain kinds of imported content. I agree with Sean that this
is important to maintain.

So, going back to Whitney's proposal, I would add back in the part
about suites, and about only prompting for things that you can
correct, and take out the part about prompting for other things if
you want, since that goes without saying. That would leave us with:

Version 7:

"An authoring tool, or suite of tools used to author content, must
provide a mode which prompts authors to create accessible content for
formats authored by that tool, for accessibility problems that the
tool or suite has the capability to correct."

Note 1: It is neither expected nor possible that prompts be available
for every type of accessible content.

Note 2: A suite of authoring tools can be composed of tools from a
single vendor or multiple vendors.

Regards,

- Judy

At 07:14 PM 3/19/2008 +0000, Sean Hayes wrote:
>If it were just captions, OK we could live with it; but TEITAC
>requires a lot more than that, so as it places in a video you expect
>my HTML editor to ask:
>
>Is this video captioned?
>Is this video Audio Described?
>Does this video contain seizure inducing flashing?
>Is all text in the video adequate contrast?
>Is any information in the video encoded in colour?
>Blah blah blah...
>
>And that's just video, what about all the other media types I might bring in.
>
>Since the tool doesn't know what applies and what doesn't, it needs
>to ask everything, but worse it provides no way to help the user
>find out, so the prompt is meaningless anyway unless the author
>already knows (in which case the prompt was just slowing things down).
>
>The author has two options.
>
>If they are skilled in video editing, they might abandon the import
>and fire up a video tool that can help them determine the answers,
>where the prompts will make more sense, and might be based on some
>actual analysis, and where they can fix any problems. Then when they
>return to the HTML tool the prompts are simply a repeat and an annoyance.
>
>Or they might just turn the prompts off (or mentally blank them out).
>
>I can guess which is the most likely outcome.
>
>So prompts become reduced to "this content may not be accessible,
>you sure you want to continue...", which will satisfy the letter of
>the law, without helping anyone.
>
>Sean Hayes
>Media Acessibility Strategist
>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
> = EMAIL ADDRESS REMOVED =
>Sent: 19 March 2008 16:58
>To: TEITAC Committee
>Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
>
>Terminology: I don't think casual readers are the issue here. Nor do
>I think that "A toolset used to author content" adds clarity.
>
>Prompts: Why is a prompt that reminds me that I must provide
>captions (etc) for the video not useful? This seems a particularly
>narrow view. At a minimum, it will remind me that I must do
>something to make this content accessible, whether I do it in one
>part of the suite of tools that I have assembled for authoring or
>another. It might even be that this is communication that happens
>entirely outside of anything electronic, as I shout across the room
>to the video editors "Yo, you forgot the captions on that video,
>when can I get them."
>
>Whitney
>
> > -------- Original Message --------
> > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> > Date: Wed, March 19, 2008 9:44 am
> > To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
> >
> > Well it won't be the first time I've been accused of sacrificing
> clarity to the casual reader for accuracy. But when writing
> standards and laws, accuracy is to me more important than ease of reading.
> >
> > The reason I want toolset in the clause proper, is that if it
> just says tool, which is a commonly understood word, then
> notwithstanding a clever definition, the idea that a tool may in
> fact mean more than one tool is likely to be lost on the agencies.
> Whereas it is more likely that a reader is going to look up the
> definition of toolset, and find that a toolset may be one tool or many.
> >
> > The second point is - sure a prompt can say all sorts of things,
> but if the tool has no idea whether what it is asking is relevant
> to the content at hand (because it can't tell whether the video
> already has captions or not), and even when it is (the video does
> not have captions), leaves the author with no way to do anything
> about it, then that prompt is worse than useless.
> >
> >
> >
> > Sean Hayes
> > Media Acessibility Strategist
> > 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
> = EMAIL ADDRESS REMOVED =
> > Sent: 19 March 2008 13:41
> > To: TEITAC Committee
> > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> >
> >
> > "A toolset used to author content"? That sounds like the
> definition, not the term. What do we gain by replacing a simple
> term with a tongue twister? Will simple tools think they are excluded?
> >
> > I agree with the point about an HTML editor handing video. I
> completely agree with your point. But you are assuming that an
> authoring tool can only prompt for something it can then execute.
> There's no reason why the prompt can't include the option of
> captioning the video EVEN IF that particular authoring tool doesn't
> support captions. If the term "toolset" is critical to you, perhaps:
> >
> > DEFINITION: AUTHORING TOOL
> > Any software or toolset intended to create or modify electronic
> content for publication in one or more formats that support
> compliance with the user interface and content provisions. Such
> tools may be a single product, or a suite of tools from a single
> vendor or multiple vendors.
> >
> > Note: Simple text editors that can only create or modify content
> in conforming formats by directly editing the code are not
> considered authoring tools under this definition.
> >
> > 7-C - PROMPTS
> > An authoring tool must provide a mode which prompts authors to
> create accessible content in formats authored by those tools, for
> accessibility problems that the tool can correct. Tools may provide
> prompts for other problems as well.
> >
> > Note 1: It is neither expected nor possible that prompts be
> available for every type of accessible content.
> >
> > > -------- Original Message --------
> > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> > > Date: Wed, March 19, 2008 6:20 am
> > > To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
> > >
> > > I'm Ok with rolling the suite/vendor idea into the definition,
> if we change the term to something like "a toolset used to author content".
> > >
> > > I'm not OK with making the scope phrase a note. The issue is
> exemplified by a tool which combines content (say an HTML editor),
> where it is possible to drag a video onto the page, but the tool
> has no ability to edit or analyse the video. The HTML tool can be
> expected to prompt for a text alternative but not to add captions,
> or check for potential seizure inducing Flashes
> > >
> > > Based on that, I could live with something like:
> > >
> > > DEFINITION: TOOLSET USED TO AUTHOR CONTENT
> > > Any software intended to create or modify electronic content
> for publication in one or more formats that support compliance with
> the user interface and content provisions. Such tools may be a
> single product, or a suite of tools from a single vendor or multiple vendors.
> > >
> > > Note: Simple text editors that can only create or modify
> content in conforming formats by directly editing the code are not
> considered authoring tools under this definition.
> > >
> > >
> > > 7-C - PROMPTS
> > > A Toolset used to author content must provide a mode which
> prompts authors to create accessible content for formats authored
> by those tools and for accessibility problems that the tools have
> the capability to correct.
> > > Tools may provide prompts for other problems as well.
> > >
> > > Note 1: It is neither expected nor possible that prompts be
> available for every type of accessible content.
> > >
> > >
> > > Sean Hayes
> > > Media Acessibility Strategist
> > > 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
> = EMAIL ADDRESS REMOVED =
> > > Sent: 19 March 2008 12:20
> > > To: TEITAC Committee
> > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > >
> > > I see the issues that Version 5 is trying to solve, but the
> wording is so convoluted that it's hard to understand what it's
> saying. A revised version follows
> > >
> > > Version 5 says:
> > >
> > > "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,]]...'
> > >
> > > - If there is a definition of authoring tool (suggested in the
> final words), why do we need such a lot of verbiage here. Let's put
> this phrase into the definition.
> > >
> > > "...must provide a mode which prompts authors to create
> accessible content..."
> > > - Here's the meat of the provision
> > >
> > > "...for accessibility problems that the tool [[or suite]] has
> the capability to correct,..."
> > > - I don't understand this phrase: it sounds like an authoring
> tool can decide not to support something, and is then relieved of
> all responsibility. It's a chicken-and-egg problem, but if the
> format includes a capability, surely the tools should either
> support it, or at least inform users that they do not.
> > >
> > > "...for formats authored by that tool [[or suite]]..."
> > > - OK. This allows a product to define its features and only
> support the format it supports. As above, don't need the "or suite".
> > >
> > > "...[[which support compliance as explained in the definition
> of authoring tool.]]"
> > > - Why do we need to restate (and reference) a definition that
> provides this scope (compliance with UI and content provisions) more clearly.
> > >
> > >
> > >
> > > Here's my suggestions for both the definition and provision:
> > >
> > > DEFINITION: AUTHORING TOOL
> > > Any software intended to create or modify electronic content
> for publication in one or more formats that support compliance with
> the user interface and content provisions. An authoring tool may be
> a single product, or a suite of tools from a single vendor or multiple vendors.
> > >
> > > Note: Simple text editors that can only create or modify
> content in conforming formats by directly editing the code are not
> considered authoring tools under this definition.
> > >
> > >
> > > 7-C - PROMPTS
> > > An authoring tool must provide a mode which prompts authors to
> create accessible content for formats authored by that tool.
> > >
> > > Note 1: It is neither expected nor possible that prompts be
> available for every type of accessible content.
> > >
> > > Note 2: Authoring tools are primarily responsible for
> accessibility problems that they have the capability to correct,
> but may provide prompts for other problems as well.
> > >
> > >
> > >
> > >
> > >
> > > > -------- Original Message --------
> > > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > > From: Judy Brewer < = EMAIL ADDRESS REMOVED = >
> > > > Date: Tue, March 18, 2008 1:07 pm
> > > > To: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >, "Sean Hayes"
> > > > < = EMAIL ADDRESS REMOVED = >, "TEITAC Committee"
> > > > < = EMAIL ADDRESS REMOVED = >
> > > >
> > > > Comments below:
> > > >
> > > > At 11:45 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
> > > > >My comments below
> > > > ><...>
> > > > >I'm hearing you say that the suite could made to be only
> defined by the
> > > > >vendor, but if it is still evaluated against this standard we are
> > > > >potentially requiring that vendors bundle their software with other
> > > > >vendors even if the tool is doing what it should already. Maybe I'm
> > > > >misreading this, but this is my concern.
> > > >
> > > > Please note the first three words of the proposed provision:
> > > >
> > > > "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."
> > > >
> > > > A vendor is under no obligation to bundle their software with other
> > > > vendors' software, regardless of whether their tools do everything
> > > > that they should. The option of a suite was there to give flexibility
> > > > to vendors who need or want other tools to supplement the
> > > > capabilities of their own tools.
> > > >
> > > > (more below)
> > > >
> > > > > > >An example: Adobe has a tool called Presenter. The
> main function of
> > > > > > >Presenter is to import Microsoft PowerPoint files and generate an
> > > > > > >accessible web-based Flash presentation that utilizes
> accessibility
> > > > > > >information contained in the PowerPoint file (e.g. equivalents for
> > > > > > >images, content order). I can see contracting officers
> wondering if the
> > > > > > >fact that Presenter doesn't prompt for this information
> makes it not
> > > > > > >compliant - should PowerPoint provide the prompting, or should
> > > > > > Presenter
> > > > > > >prompt for the information when it is missing, or should presenter
> > > > > > >prompt for the information _always_ since it _might_ not
> be correct?
> > > > > >
> > > > > > I believe that this general issue is addressed in the following
> > > > >phrase:
> > > > > > "...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, ..."
> > > > >
> > > > >How do we determine if a piece of software has this ability? If a tool
> > > > >works with an evaluation tool to examine compliance with the standards
> > > > >is that evaluation tool now part of the authoring tool or
> authoring tool
> > > > >suite?
> > > >
> > > > Hmmm. Restoring my subsequent text, which provided an example of this:
> > > >
> > > > >>As for whether the tool, when prompting, should only prompt for
> > > > >>missing information, or also prompt for corrections, this seems
> > > > >>strongly linked to the question of which accessibility issues the
> > > > >>tool is capable of analyzing. For instance, if equivalents are
> > > > >>missing for an image, it is straightforward to prompt for the
> > > > >>missing equivalents. But if an equivalent is a single word followed
> > > > >>by a filename extension, many authoring tools have the capability
> > > > >>to analyze that equivalent text and prompt for something more
> > > > >>meaningful than a filename alone.
> > > >
> > > > Andrew, are you suggesting the removal of "to analyze" from the text
> > > > of this provision? Sean had suggested this wording with "analyze",
> > > > but it does imply on-board evaluation function. By removing
> > > > "analyze," it would remove an implied availability of an evaluation
> > > > function, and focus more clearly on prompting for things that the
> > > > tool has the ability to correct. This might be easier to understand,
> > > > to comply with, and to evaluate. The proposed text would then read:
> > > >
> > > > "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 correct, for formats authored by that
> tool or suite
> > > > which support compliance as explained in the definition of
> authoring tool."
> > > >
> > > > Andrew, Sean, would this work?
> > > >
> > > > - Judy
> > > >
> > > >
> > > >
> > > >
> > > > >AWK
> > > >
> > > >
> > > >

From: Whitney Quesenbery
Date: Mon, Mar 24 2008 2:15 PM
Subject: Re: 7-C Prompts (in authoring tools)

Judy,

I have added your version 7 and the notes, and have removed my version 6,
which this supercedes.

Can any of the other versions be removed at this point?

Whitney

At 02:21 PM 3/24/2008, you wrote:
>Going back through the suggestions on 7-C Prompts (in authoring
>tools), with reference to
>http://teitac.org/wiki/EWG:OpenProvisions_March_12#7-D_-_Accessible_Templates_.28Discussed_Jan_9.29
>and also with reference to the thread from last week, which is intact
>in the message below, I proposed a rolled-together version of some of
>these suggestions.
>
>The two latest proposals were (see below for new proposal, if you
>prefer to skip ahead):
>
>Version 5, Judy, March 18:
>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 correct, for formats authored by that tool or
>suite that support compliance as explained in the definition of authoring
>tool.
>
>Version 6, Whitney, March 19:
>An authoring tool must provide a mode which prompts authors to create
>accessible content in formats authored by those tools, for
>accessibility problems that the tool can correct. Tools may provide
>prompts for other problems as well.
>
>Whitney, you identified several issues, including:
>
>1. Whether to roll the description of authoring tool as suite or
>toolset into the definition of authoring tool, rather than just into
>this provision. I think we should not, because to do so would change
>the scope of the authoring tool provisions that were already
>consensed. And as for keeping it with the proposed prompting
>provision, I think that the description of suite in the existing
>proposed text makes more sense than calling it a toolset. As for the
>single/multiple vendor part, while clunky, it did answer a long
>string of discussion that otherwise was getting in our way of making
>progress on this. We could however move that into a note.
>
>2. Whether to remove the following scoping, "...for accessibility
>problems that the tool [[or suite]] has the capability to
>correct,..."... this was intended to not require prompting for things
>that the tool wouldn't be able to do anything about, for instance
>with certain kinds of imported content. I agree with Sean that this
>is important to maintain.
>
>So, going back to Whitney's proposal, I would add back in the part
>about suites, and about only prompting for things that you can
>correct, and take out the part about prompting for other things if
>you want, since that goes without saying. That would leave us with:
>
>Version 7:
>
>"An authoring tool, or suite of tools used to author content, must
>provide a mode which prompts authors to create accessible content for
>formats authored by that tool, for accessibility problems that the
>tool or suite has the capability to correct."
>
>Note 1: It is neither expected nor possible that prompts be available
>for every type of accessible content.
>
>Note 2: A suite of authoring tools can be composed of tools from a
>single vendor or multiple vendors.
>
>Regards,
>
>- Judy
>
>At 07:14 PM 3/19/2008 +0000, Sean Hayes wrote:
> >If it were just captions, OK we could live with it; but TEITAC
> >requires a lot more than that, so as it places in a video you expect
> >my HTML editor to ask:
> >
> >Is this video captioned?
> >Is this video Audio Described?
> >Does this video contain seizure inducing flashing?
> >Is all text in the video adequate contrast?
> >Is any information in the video encoded in colour?
> >Blah blah blah...
> >
> >And that's just video, what about all the other media types I might
> bring in.
> >
> >Since the tool doesn't know what applies and what doesn't, it needs
> >to ask everything, but worse it provides no way to help the user
> >find out, so the prompt is meaningless anyway unless the author
> >already knows (in which case the prompt was just slowing things down).
> >
> >The author has two options.
> >
> >If they are skilled in video editing, they might abandon the import
> >and fire up a video tool that can help them determine the answers,
> >where the prompts will make more sense, and might be based on some
> >actual analysis, and where they can fix any problems. Then when they
> >return to the HTML tool the prompts are simply a repeat and an annoyance.
> >
> >Or they might just turn the prompts off (or mentally blank them out).
> >
> >I can guess which is the most likely outcome.
> >
> >So prompts become reduced to "this content may not be accessible,
> >you sure you want to continue...", which will satisfy the letter of
> >the law, without helping anyone.
> >
> >Sean Hayes
> >Media Acessibility Strategist
> >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
> > = EMAIL ADDRESS REMOVED =
> >Sent: 19 March 2008 16:58
> >To: TEITAC Committee
> >Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> >
> >Terminology: I don't think casual readers are the issue here. Nor do
> >I think that "A toolset used to author content" adds clarity.
> >
> >Prompts: Why is a prompt that reminds me that I must provide
> >captions (etc) for the video not useful? This seems a particularly
> >narrow view. At a minimum, it will remind me that I must do
> >something to make this content accessible, whether I do it in one
> >part of the suite of tools that I have assembled for authoring or
> >another. It might even be that this is communication that happens
> >entirely outside of anything electronic, as I shout across the room
> >to the video editors "Yo, you forgot the captions on that video,
> >when can I get them."
> >
> >Whitney
> >
> > > -------- Original Message --------
> > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> > > Date: Wed, March 19, 2008 9:44 am
> > > To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
> > >
> > > Well it won't be the first time I've been accused of sacrificing
> > clarity to the casual reader for accuracy. But when writing
> > standards and laws, accuracy is to me more important than ease of reading.
> > >
> > > The reason I want toolset in the clause proper, is that if it
> > just says tool, which is a commonly understood word, then
> > notwithstanding a clever definition, the idea that a tool may in
> > fact mean more than one tool is likely to be lost on the agencies.
> > Whereas it is more likely that a reader is going to look up the
> > definition of toolset, and find that a toolset may be one tool or many.
> > >
> > > The second point is - sure a prompt can say all sorts of things,
> > but if the tool has no idea whether what it is asking is relevant
> > to the content at hand (because it can't tell whether the video
> > already has captions or not), and even when it is (the video does
> > not have captions), leaves the author with no way to do anything
> > about it, then that prompt is worse than useless.
> > >
> > >
> > >
> > > Sean Hayes
> > > Media Acessibility Strategist
> > > 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
> > = EMAIL ADDRESS REMOVED =
> > > Sent: 19 March 2008 13:41
> > > To: TEITAC Committee
> > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > >
> > >
> > > "A toolset used to author content"? That sounds like the
> > definition, not the term. What do we gain by replacing a simple
> > term with a tongue twister? Will simple tools think they are excluded?
> > >
> > > I agree with the point about an HTML editor handing video. I
> > completely agree with your point. But you are assuming that an
> > authoring tool can only prompt for something it can then execute.
> > There's no reason why the prompt can't include the option of
> > captioning the video EVEN IF that particular authoring tool doesn't
> > support captions. If the term "toolset" is critical to you, perhaps:
> > >
> > > DEFINITION: AUTHORING TOOL
> > > Any software or toolset intended to create or modify electronic
> > content for publication in one or more formats that support
> > compliance with the user interface and content provisions. Such
> > tools may be a single product, or a suite of tools from a single
> > vendor or multiple vendors.
> > >
> > > Note: Simple text editors that can only create or modify content
> > in conforming formats by directly editing the code are not
> > considered authoring tools under this definition.
> > >
> > > 7-C - PROMPTS
> > > An authoring tool must provide a mode which prompts authors to
> > create accessible content in formats authored by those tools, for
> > accessibility problems that the tool can correct. Tools may provide
> > prompts for other problems as well.
> > >
> > > Note 1: It is neither expected nor possible that prompts be
> > available for every type of accessible content.
> > >
> > > > -------- Original Message --------
> > > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > > From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> > > > Date: Wed, March 19, 2008 6:20 am
> > > > To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
> > > >
> > > > I'm Ok with rolling the suite/vendor idea into the definition,
> > if we change the term to something like "a toolset used to author content".
> > > >
> > > > I'm not OK with making the scope phrase a note. The issue is
> > exemplified by a tool which combines content (say an HTML editor),
> > where it is possible to drag a video onto the page, but the tool
> > has no ability to edit or analyse the video. The HTML tool can be
> > expected to prompt for a text alternative but not to add captions,
> > or check for potential seizure inducing Flashes
> > > >
> > > > Based on that, I could live with something like:
> > > >
> > > > DEFINITION: TOOLSET USED TO AUTHOR CONTENT
> > > > Any software intended to create or modify electronic content
> > for publication in one or more formats that support compliance with
> > the user interface and content provisions. Such tools may be a
> > single product, or a suite of tools from a single vendor or multiple
> vendors.
> > > >
> > > > Note: Simple text editors that can only create or modify
> > content in conforming formats by directly editing the code are not
> > considered authoring tools under this definition.
> > > >
> > > >
> > > > 7-C - PROMPTS
> > > > A Toolset used to author content must provide a mode which
> > prompts authors to create accessible content for formats authored
> > by those tools and for accessibility problems that the tools have
> > the capability to correct.
> > > > Tools may provide prompts for other problems as well.
> > > >
> > > > Note 1: It is neither expected nor possible that prompts be
> > available for every type of accessible content.
> > > >
> > > >
> > > > Sean Hayes
> > > > Media Acessibility Strategist
> > > > 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
> > = EMAIL ADDRESS REMOVED =
> > > > Sent: 19 March 2008 12:20
> > > > To: TEITAC Committee
> > > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > >
> > > > I see the issues that Version 5 is trying to solve, but the
> > wording is so convoluted that it's hard to understand what it's
> > saying. A revised version follows
> > > >
> > > > Version 5 says:
> > > >
> > > > "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,]]...'
> > > >
> > > > - If there is a definition of authoring tool (suggested in the
> > final words), why do we need such a lot of verbiage here. Let's put
> > this phrase into the definition.
> > > >
> > > > "...must provide a mode which prompts authors to create
> > accessible content..."
> > > > - Here's the meat of the provision
> > > >
> > > > "...for accessibility problems that the tool [[or suite]] has
> > the capability to correct,..."
> > > > - I don't understand this phrase: it sounds like an authoring
> > tool can decide not to support something, and is then relieved of
> > all responsibility. It's a chicken-and-egg problem, but if the
> > format includes a capability, surely the tools should either
> > support it, or at least inform users that they do not.
> > > >
> > > > "...for formats authored by that tool [[or suite]]..."
> > > > - OK. This allows a product to define its features and only
> > support the format it supports. As above, don't need the "or suite".
> > > >
> > > > "...[[which support compliance as explained in the definition
> > of authoring tool.]]"
> > > > - Why do we need to restate (and reference) a definition that
> > provides this scope (compliance with UI and content provisions) more
> clearly.
> > > >
> > > >
> > > >
> > > > Here's my suggestions for both the definition and provision:
> > > >
> > > > DEFINITION: AUTHORING TOOL
> > > > Any software intended to create or modify electronic content
> > for publication in one or more formats that support compliance with
> > the user interface and content provisions. An authoring tool may be
> > a single product, or a suite of tools from a single vendor or multiple
> vendors.
> > > >
> > > > Note: Simple text editors that can only create or modify
> > content in conforming formats by directly editing the code are not
> > considered authoring tools under this definition.
> > > >
> > > >
> > > > 7-C - PROMPTS
> > > > An authoring tool must provide a mode which prompts authors to
> > create accessible content for formats authored by that tool.
> > > >
> > > > Note 1: It is neither expected nor possible that prompts be
> > available for every type of accessible content.
> > > >
> > > > Note 2: Authoring tools are primarily responsible for
> > accessibility problems that they have the capability to correct,
> > but may provide prompts for other problems as well.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -------- Original Message --------
> > > > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > > > From: Judy Brewer < = EMAIL ADDRESS REMOVED = >
> > > > > Date: Tue, March 18, 2008 1:07 pm
> > > > > To: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >, "Sean Hayes"
> > > > > < = EMAIL ADDRESS REMOVED = >, "TEITAC Committee"
> > > > > < = EMAIL ADDRESS REMOVED = >
> > > > >
> > > > > Comments below:
> > > > >
> > > > > At 11:45 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
> > > > > >My comments below
> > > > > ><...>
> > > > > >I'm hearing you say that the suite could made to be only
> > defined by the
> > > > > >vendor, but if it is still evaluated against this standard we are
> > > > > >potentially requiring that vendors bundle their software with other
> > > > > >vendors even if the tool is doing what it should already. Maybe I'm
> > > > > >misreading this, but this is my concern.
> > > > >
> > > > > Please note the first three words of the proposed provision:
> > > > >
> > > > > "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."
> > > > >
> > > > > A vendor is under no obligation to bundle their software with other
> > > > > vendors' software, regardless of whether their tools do everything
> > > > > that they should. The option of a suite was there to give flexibility
> > > > > to vendors who need or want other tools to supplement the
> > > > > capabilities of their own tools.
> > > > >
> > > > > (more below)
> > > > >
> > > > > > > >An example: Adobe has a tool called Presenter. The
> > main function of
> > > > > > > >Presenter is to import Microsoft PowerPoint files and
> generate an
> > > > > > > >accessible web-based Flash presentation that utilizes
> > accessibility
> > > > > > > >information contained in the PowerPoint file (e.g.
> equivalents for
> > > > > > > >images, content order). I can see contracting officers
> > wondering if the
> > > > > > > >fact that Presenter doesn't prompt for this information
> > makes it not
> > > > > > > >compliant - should PowerPoint provide the prompting, or should
> > > > > > > Presenter
> > > > > > > >prompt for the information when it is missing, or should
> presenter
> > > > > > > >prompt for the information _always_ since it _might_ not
> > be correct?
> > > > > > >
> > > > > > > I believe that this general issue is addressed in the following
> > > > > >phrase:
> > > > > > > "...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, ..."
> > > > > >
> > > > > >How do we determine if a piece of software has this ability? If
> a tool
> > > > > >works with an evaluation tool to examine compliance with the
> standards
> > > > > >is that evaluation tool now part of the authoring tool or
> > authoring tool
> > > > > >suite?
> > > > >
> > > > > Hmmm. Restoring my subsequent text, which provided an example of
> this:
> > > > >
> > > > > >>As for whether the tool, when prompting, should only prompt for
> > > > > >>missing information, or also prompt for corrections, this seems
> > > > > >>strongly linked to the question of which accessibility issues the
> > > > > >>tool is capable of analyzing. For instance, if equivalents are
> > > > > >>missing for an image, it is straightforward to prompt for the
> > > > > >>missing equivalents. But if an equivalent is a single word followed
> > > > > >>by a filename extension, many authoring tools have the capability
> > > > > >>to analyze that equivalent text and prompt for something more
> > > > > >>meaningful than a filename alone.
> > > > >
> > > > > Andrew, are you suggesting the removal of "to analyze" from the text
> > > > > of this provision? Sean had suggested this wording with "analyze",
> > > > > but it does imply on-board evaluation function. By removing
> > > > > "analyze," it would remove an implied availability of an evaluation
> > > > > function, and focus more clearly on prompting for things that the
> > > > > tool has the ability to correct. This might be easier to understand,
> > > > > to comply with, and to evaluate. The proposed text would then read:
> > > > >
> > > > > "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 correct, for formats authored by that
> > tool or suite
> > > > > which support compliance as explained in the definition of
> > authoring tool."
> > > > >
> > > > > Andrew, Sean, would this work?
> > > > >
> > > > > - Judy
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >AWK
> > > > >
> > > > >
> > > > >

From: Judy Brewer
Date: Mon, Mar 24 2008 2:50 PM
Subject: Re: 7-C Prompts (in authoring tools)

Whitney,

Thanks for replacing this. Looking back at the reference (and
correcting the link I gave below):

<http://teitac.org/wiki/EWG:OpenProvisions_March_12#7-C_-_Prompts_.28Discussed_Dec_4.2C_11.2C_Jan_9.29>

I think you can remove proposals 2, 3, and 4. I think that both
proposals #1 and #5 are useful background at least through tomorrow.

Thank you,

- Judy

At 04:11 PM 3/24/2008 -0500, Whitney Quesenbery wrote:
>Judy,
>
>I have added your version 7 and the notes, and have removed my version 6,
>which this supercedes.
>
>Can any of the other versions be removed at this point?
>
>Whitney
>
>At 02:21 PM 3/24/2008, you wrote:
> >Going back through the suggestions on 7-C Prompts (in authoring
> >tools), with reference to
> >http://teitac.org/wiki/EWG:OpenProvisions_March_12#7-D_-_Accessible
> _Templates_.28Discussed_Jan_9.29
> >and also with reference to the thread from last week, which is intact
> >in the message below, I proposed a rolled-together version of some of
> >these suggestions.
> >
> >The two latest proposals were (see below for new proposal, if you
> >prefer to skip ahead):
> >
> >Version 5, Judy, March 18:
> >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 correct, for formats authored by that tool or
> >suite that support compliance as explained in the definition of authoring
> >tool.
> >
> >Version 6, Whitney, March 19:
> >An authoring tool must provide a mode which prompts authors to create
> >accessible content in formats authored by those tools, for
> >accessibility problems that the tool can correct. Tools may provide
> >prompts for other problems as well.
> >
> >Whitney, you identified several issues, including:
> >
> >1. Whether to roll the description of authoring tool as suite or
> >toolset into the definition of authoring tool, rather than just into
> >this provision. I think we should not, because to do so would change
> >the scope of the authoring tool provisions that were already
> >consensed. And as for keeping it with the proposed prompting
> >provision, I think that the description of suite in the existing
> >proposed text makes more sense than calling it a toolset. As for the
> >single/multiple vendor part, while clunky, it did answer a long
> >string of discussion that otherwise was getting in our way of making
> >progress on this. We could however move that into a note.
> >
> >2. Whether to remove the following scoping, "...for accessibility
> >problems that the tool [[or suite]] has the capability to
> >correct,..."... this was intended to not require prompting for things
> >that the tool wouldn't be able to do anything about, for instance
> >with certain kinds of imported content. I agree with Sean that this
> >is important to maintain.
> >
> >So, going back to Whitney's proposal, I would add back in the part
> >about suites, and about only prompting for things that you can
> >correct, and take out the part about prompting for other things if
> >you want, since that goes without saying. That would leave us with:
> >
> >Version 7:
> >
> >"An authoring tool, or suite of tools used to author content, must
> >provide a mode which prompts authors to create accessible content for
> >formats authored by that tool, for accessibility problems that the
> >tool or suite has the capability to correct."
> >
> >Note 1: It is neither expected nor possible that prompts be available
> >for every type of accessible content.
> >
> >Note 2: A suite of authoring tools can be composed of tools from a
> >single vendor or multiple vendors.
> >
> >Regards,
> >
> >- Judy
> >
> >At 07:14 PM 3/19/2008 +0000, Sean Hayes wrote:
> > >If it were just captions, OK we could live with it; but TEITAC
> > >requires a lot more than that, so as it places in a video you expect
> > >my HTML editor to ask:
> > >
> > >Is this video captioned?
> > >Is this video Audio Described?
> > >Does this video contain seizure inducing flashing?
> > >Is all text in the video adequate contrast?
> > >Is any information in the video encoded in colour?
> > >Blah blah blah...
> > >
> > >And that's just video, what about all the other media types I might
> > bring in.
> > >
> > >Since the tool doesn't know what applies and what doesn't, it needs
> > >to ask everything, but worse it provides no way to help the user
> > >find out, so the prompt is meaningless anyway unless the author
> > >already knows (in which case the prompt was just slowing things down).
> > >
> > >The author has two options.
> > >
> > >If they are skilled in video editing, they might abandon the import
> > >and fire up a video tool that can help them determine the answers,
> > >where the prompts will make more sense, and might be based on some
> > >actual analysis, and where they can fix any problems. Then when they
> > >return to the HTML tool the prompts are simply a repeat and an annoyance.
> > >
> > >Or they might just turn the prompts off (or mentally blank them out).
> > >
> > >I can guess which is the most likely outcome.
> > >
> > >So prompts become reduced to "this content may not be accessible,
> > >you sure you want to continue...", which will satisfy the letter of
> > >the law, without helping anyone.
> > >
> > >Sean Hayes
> > >Media Acessibility Strategist
> > >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
> > > = EMAIL ADDRESS REMOVED =
> > >Sent: 19 March 2008 16:58
> > >To: TEITAC Committee
> > >Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > >
> > >Terminology: I don't think casual readers are the issue here. Nor do
> > >I think that "A toolset used to author content" adds clarity.
> > >
> > >Prompts: Why is a prompt that reminds me that I must provide
> > >captions (etc) for the video not useful? This seems a particularly
> > >narrow view. At a minimum, it will remind me that I must do
> > >something to make this content accessible, whether I do it in one
> > >part of the suite of tools that I have assembled for authoring or
> > >another. It might even be that this is communication that happens
> > >entirely outside of anything electronic, as I shout across the room
> > >to the video editors "Yo, you forgot the captions on that video,
> > >when can I get them."
> > >
> > >Whitney
> > >
> > > > -------- Original Message --------
> > > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > > From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> > > > Date: Wed, March 19, 2008 9:44 am
> > > > To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
> > > >
> > > > Well it won't be the first time I've been accused of sacrificing
> > > clarity to the casual reader for accuracy. But when writing
> > > standards and laws, accuracy is to me more important than ease
> of reading.
> > > >
> > > > The reason I want toolset in the clause proper, is that if it
> > > just says tool, which is a commonly understood word, then
> > > notwithstanding a clever definition, the idea that a tool may in
> > > fact mean more than one tool is likely to be lost on the agencies.
> > > Whereas it is more likely that a reader is going to look up the
> > > definition of toolset, and find that a toolset may be one tool or many.
> > > >
> > > > The second point is - sure a prompt can say all sorts of things,
> > > but if the tool has no idea whether what it is asking is relevant
> > > to the content at hand (because it can't tell whether the video
> > > already has captions or not), and even when it is (the video does
> > > not have captions), leaves the author with no way to do anything
> > > about it, then that prompt is worse than useless.
> > > >
> > > >
> > > >
> > > > Sean Hayes
> > > > Media Acessibility Strategist
> > > > 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
> > > = EMAIL ADDRESS REMOVED =
> > > > Sent: 19 March 2008 13:41
> > > > To: TEITAC Committee
> > > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > >
> > > >
> > > > "A toolset used to author content"? That sounds like the
> > > definition, not the term. What do we gain by replacing a simple
> > > term with a tongue twister? Will simple tools think they are excluded?
> > > >
> > > > I agree with the point about an HTML editor handing video. I
> > > completely agree with your point. But you are assuming that an
> > > authoring tool can only prompt for something it can then execute.
> > > There's no reason why the prompt can't include the option of
> > > captioning the video EVEN IF that particular authoring tool doesn't
> > > support captions. If the term "toolset" is critical to you, perhaps:
> > > >
> > > > DEFINITION: AUTHORING TOOL
> > > > Any software or toolset intended to create or modify electronic
> > > content for publication in one or more formats that support
> > > compliance with the user interface and content provisions. Such
> > > tools may be a single product, or a suite of tools from a single
> > > vendor or multiple vendors.
> > > >
> > > > Note: Simple text editors that can only create or modify content
> > > in conforming formats by directly editing the code are not
> > > considered authoring tools under this definition.
> > > >
> > > > 7-C - PROMPTS
> > > > An authoring tool must provide a mode which prompts authors to
> > > create accessible content in formats authored by those tools, for
> > > accessibility problems that the tool can correct. Tools may provide
> > > prompts for other problems as well.
> > > >
> > > > Note 1: It is neither expected nor possible that prompts be
> > > available for every type of accessible content.
> > > >
> > > > > -------- Original Message --------
> > > > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > > > From: Sean Hayes < = EMAIL ADDRESS REMOVED = >
> > > > > Date: Wed, March 19, 2008 6:20 am
> > > > > To: TEITAC Committee < = EMAIL ADDRESS REMOVED = >
> > > > >
> > > > > I'm Ok with rolling the suite/vendor idea into the definition,
> > > if we change the term to something like "a toolset used to
> author content".
> > > > >
> > > > > I'm not OK with making the scope phrase a note. The issue is
> > > exemplified by a tool which combines content (say an HTML editor),
> > > where it is possible to drag a video onto the page, but the tool
> > > has no ability to edit or analyse the video. The HTML tool can be
> > > expected to prompt for a text alternative but not to add captions,
> > > or check for potential seizure inducing Flashes
> > > > >
> > > > > Based on that, I could live with something like:
> > > > >
> > > > > DEFINITION: TOOLSET USED TO AUTHOR CONTENT
> > > > > Any software intended to create or modify electronic content
> > > for publication in one or more formats that support compliance with
> > > the user interface and content provisions. Such tools may be a
> > > single product, or a suite of tools from a single vendor or multiple
> > vendors.
> > > > >
> > > > > Note: Simple text editors that can only create or modify
> > > content in conforming formats by directly editing the code are not
> > > considered authoring tools under this definition.
> > > > >
> > > > >
> > > > > 7-C - PROMPTS
> > > > > A Toolset used to author content must provide a mode which
> > > prompts authors to create accessible content for formats authored
> > > by those tools and for accessibility problems that the tools have
> > > the capability to correct.
> > > > > Tools may provide prompts for other problems as well.
> > > > >
> > > > > Note 1: It is neither expected nor possible that prompts be
> > > available for every type of accessible content.
> > > > >
> > > > >
> > > > > Sean Hayes
> > > > > Media Acessibility Strategist
> > > > > 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
> > > = EMAIL ADDRESS REMOVED =
> > > > > Sent: 19 March 2008 12:20
> > > > > To: TEITAC Committee
> > > > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > > >
> > > > > I see the issues that Version 5 is trying to solve, but the
> > > wording is so convoluted that it's hard to understand what it's
> > > saying. A revised version follows
> > > > >
> > > > > Version 5 says:
> > > > >
> > > > > "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,]]...'
> > > > >
> > > > > - If there is a definition of authoring tool (suggested in the
> > > final words), why do we need such a lot of verbiage here. Let's put
> > > this phrase into the definition.
> > > > >
> > > > > "...must provide a mode which prompts authors to create
> > > accessible content..."
> > > > > - Here's the meat of the provision
> > > > >
> > > > > "...for accessibility problems that the tool [[or suite]] has
> > > the capability to correct,..."
> > > > > - I don't understand this phrase: it sounds like an authoring
> > > tool can decide not to support something, and is then relieved of
> > > all responsibility. It's a chicken-and-egg problem, but if the
> > > format includes a capability, surely the tools should either
> > > support it, or at least inform users that they do not.
> > > > >
> > > > > "...for formats authored by that tool [[or suite]]..."
> > > > > - OK. This allows a product to define its features and only
> > > support the format it supports. As above, don't need the "or suite".
> > > > >
> > > > > "...[[which support compliance as explained in the definition
> > > of authoring tool.]]"
> > > > > - Why do we need to restate (and reference) a definition that
> > > provides this scope (compliance with UI and content provisions) more
> > clearly.
> > > > >
> > > > >
> > > > >
> > > > > Here's my suggestions for both the definition and provision:
> > > > >
> > > > > DEFINITION: AUTHORING TOOL
> > > > > Any software intended to create or modify electronic content
> > > for publication in one or more formats that support compliance with
> > > the user interface and content provisions. An authoring tool may be
> > > a single product, or a suite of tools from a single vendor or multiple
> > vendors.
> > > > >
> > > > > Note: Simple text editors that can only create or modify
> > > content in conforming formats by directly editing the code are not
> > > considered authoring tools under this definition.
> > > > >
> > > > >
> > > > > 7-C - PROMPTS
> > > > > An authoring tool must provide a mode which prompts authors to
> > > create accessible content for formats authored by that tool.
> > > > >
> > > > > Note 1: It is neither expected nor possible that prompts be
> > > available for every type of accessible content.
> > > > >
> > > > > Note 2: Authoring tools are primarily responsible for
> > > accessibility problems that they have the capability to correct,
> > > but may provide prompts for other problems as well.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -------- Original Message --------
> > > > > > Subject: Re: [teitac-committee] 7-C Prompts (in authoring tools)
> > > > > > From: Judy Brewer < = EMAIL ADDRESS REMOVED = >
> > > > > > Date: Tue, March 18, 2008 1:07 pm
> > > > > > To: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >, "Sean Hayes"
> > > > > > < = EMAIL ADDRESS REMOVED = >, "TEITAC Committee"
> > > > > > < = EMAIL ADDRESS REMOVED = >
> > > > > >
> > > > > > Comments below:
> > > > > >
> > > > > > At 11:45 AM 3/18/2008 -0700, Andrew Kirkpatrick wrote:
> > > > > > >My comments below
> > > > > > ><...>
> > > > > > >I'm hearing you say that the suite could made to be only
> > > defined by the
> > > > > > >vendor, but if it is still evaluated against this standard we are
> > > > > > >potentially requiring that vendors bundle their software
> with other
> > > > > > >vendors even if the tool is doing what it should
> already. Maybe I'm
> > > > > > >misreading this, but this is my concern.
> > > > > >
> > > > > > Please note the first three words of the proposed provision:
> > > > > >
> > > > > > "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."
> > > > > >
> > > > > > A vendor is under no obligation to bundle their software with other
> > > > > > vendors' software, regardless of whether their tools do everything
> > > > > > that they should. The option of a suite was there to give
> flexibility
> > > > > > to vendors who need or want other tools to supplement the
> > > > > > capabilities of their own tools.
> > > > > >
> > > > > > (more below)
> > > > > >
> > > > > > > > >An example: Adobe has a tool called Presenter. The
> > > main function of
> > > > > > > > >Presenter is to import Microsoft PowerPoint files and
> > generate an
> > > > > > > > >accessible web-based Flash presentation that utilizes
> > > accessibility
> > > > > > > > >information contained in the PowerPoint file (e.g.
> > equivalents for
> > > > > > > > >images, content order). I can see contracting officers
> > > wondering if the
> > > > > > > > >fact that Presenter doesn't prompt for this information
> > > makes it not
> > > > > > > > >compliant - should PowerPoint provide the prompting, or should
> > > > > > > > Presenter
> > > > > > > > >prompt for the information when it is missing, or should
> > presenter
> > > > > > > > >prompt for the information _always_ since it _might_ not
> > > be correct?
> > > > > > > >
> > > > > > > > I believe that this general issue is addressed in the following
> > > > > > >phrase:
> > > > > > > > "...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, ..."
> > > > > > >
> > > > > > >How do we determine if a piece of software has this ability? If
> > a tool
> > > > > > >works with an evaluation tool to examine compliance with the
> > standards
> > > > > > >is that evaluation tool now part of the authoring tool or
> > > authoring tool
> > > > > > >suite?
> > > > > >
> > > > > > Hmmm. Restoring my subsequent text, which provided an example of
> > this:
> > > > > >
> > > > > > >>As for whether the tool, when prompting, should only prompt for
> > > > > > >>missing information, or also prompt for corrections, this seems
> > > > > > >>strongly linked to the question of which accessibility issues the
> > > > > > >>tool is capable of analyzing. For instance, if equivalents are
> > > > > > >>missing for an image, it is straightforward to prompt for the
> > > > > > >>missing equivalents. But if an equivalent is a single
> word followed
> > > > > > >>by a filename extension, many authoring tools have the capability
> > > > > > >>to analyze that equivalent text and prompt for something more
> > > > > > >>meaningful than a filename alone.
> > > > > >
> > > > > > Andrew, are you suggesting the removal of "to analyze"
> from the text
> > > > > > of this provision? Sean had suggested this wording with "analyze",
> > > > > > but it does imply on-board evaluation function. By removing
> > > > > > "analyze," it would remove an implied availability of an evaluation
> > > > > > function, and focus more clearly on prompting for things that the
> > > > > > tool has the ability to correct. This might be easier to
> understand,
> > > > > > to comply with, and to evaluate. The proposed text would then read:
> > > > > >
> > > > > > "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 correct, for formats authored by that
> > > tool or suite
> > > > > > which support compliance as explained in the definition of
> > > authoring tool."
> > > > > >
> > > > > > Andrew, Sean, would this work?
> > > > > >
> > > > > > - Judy
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >AWK
> > > > > >
> > > > > >
> > > > > >