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

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Judy Brewer
Date: Tue, Mar 18 2008 12:20 PM


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


WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University