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: Sun, Mar 16 2008 11:35 PM

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

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

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

Regards,

- Judy

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

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