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: Hoffman, Allen
Date: Tue, Mar 18 2008 12:00 PM

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

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