Thread Subject: Re: 7-C Prompts (in authoring tools)
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, Feb 26 2008 2:20 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Andrew Kirkpatrick: "Re: 7-C Prompts (in authoring tools)"
- Previous message in thread: Andrew Kirkpatrick: "Re: 7-C Prompts (in authoring tools)"
- Messages sorted by: Author | Thread | Date
Thanks for your replies. More comments below.
At 12:43 PM 2/26/2008 -0800, Andrew Kirkpatrick wrote:
> > I'm not sure how you arrive at "mandating that tools are operated
> > with prompting active." It states "a mode which prompts". I had not
> > looked closely at Sean's wording because of my greater concerns about
> > the unclarity of what is available in a given package vs what
> > available among the universe of authoring tools. But does your
> > concern stem from Sean's phrasing of "procured and operated..."? My
> > understanding is that "a mode which..." would overdetermine that by
> > making the prompting just one among a variety of modes or
> > configurations. But perhaps it is just too confusing having both
> > there, in which case I would tend to remove the "and operated with"
> > since I think that the agency and/or user choice of selecting whether
> > the prompting mode is active or not is important to maintain.
>"must procured and operated" is the phrase. I'm not sure that procured
>is needed since this is a procurement standard, and my concern about
>"and operated" was what I was referring to in my last message.
It might save us a turn or two if you could say a little more here;
for instance, am I correct in assuming that, with regard to Sean's
proposal, which was:
>> > The proposed version from Sean, Jan 9, states:
>> > "Authoring tools with a user interface must procured and operated
>> > such that they provide, either alone or with additional tools, a mode
>> > which prompts authors to create accessible content."
you would support (?):
"Authoring tools with a user interface must provide, either alone or
with additional tools, a mode which prompts authors to create
> > Yes, that is what I meant, that if they provided any prompting
> > framework then they should also include prompting for accessibility
> > content, but that if they provided no prompting framework then they
> > would not need to. However, I had described some further concerns in
> > my original message on this today as I looked at additional scenarios
> > for what that might mean. I list those concerns again here (and then
> > after that I respond to your question about Peter's proposal):
>So you're arguing against your proposal. Got it.
Yes; after examining a number of different scenarios, I think that
all of the current and proposed versions have subtle problems, though
I am still thinking that this is fixable.
> > And then replying on your comment about Peter's proposal:
> > > > The version from Peter, Jan 9, states:
> > > > "An authoring tool, or suite of authoring tools used to
> > author
> > > > content, where that suite provides a user interface, must provide
> > > > mode which prompts authors to create accessible content."
> > >
> > >This also raises a concern that is avoided in Sean's, which is that
> > >sometimes 3rd party tools provide this function. I see this on the
> > wiki
> > >but not in your email.
> > Hmmm, was my email truncated? It looks to me as though it all came
> > through on the mailing list... I did list Peter's proposal in my
> > email -- or is this not what you mean by the "this" that is on the
> > wiki but not in my email?
>I'm referring to:
>Comments to resolve
>Request to add "or be compatible with additional tools that provide this
>Request to add "used in conjunction with"
>Request to make this a function that an administrator could turn on so
>that the tools be used.
>Or, "Authoring tools alone, or with a third-party tool"...
Ah. Some of those were from earlier discussions, and I believe were
addressed in meetings, but had not yet been removed from the list of
issues. Others I believe are encompassed in versions offered above,
and discussed on this thread, as well as in teleconfs. I had tried to
pull out the one that I did not think was already addressed, or
incorporated conceptually into some proposal that we were discussing
here. If you have remaining concerns, can you raise them specifically?
> > In any case, that is an interesting comment. Can't a suite of tools
> > include third party tools as well? I'm not sure that I understand
> > your concern about Peter's proposal. Could you please say more?
>Weeellll... I'm not sure. When I think of "third party" I think about a
>tool that is not part of the primary product directly. If it was it
>stops being a third party tool (becomes a 2nd party tool?).
Hmmm. Interesting issue. I was assuming that sometimes suites might
include, for instance, plug-ins or key utilities, for which one
vendor makes an arrangement with another, without actually acquiring
them. I guess that would be second party, indeed.
- Next message in Thread: Andrew Kirkpatrick: "Re: 7-C Prompts (in authoring tools)"
- Previous message in Thread: Andrew Kirkpatrick: "Re: 7-C Prompts (in authoring tools)"