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

From: whitneyq@wqusability.com
Date: Wed, Mar 19 2008 11:00 AM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Sean Hayes: "Re: 7-C Prompts (in authoring tools)"
• Previous message in thread: Sean Hayes: "Re: 7-C Prompts (in authoring tools)"
• Messages sorted by: Author | Thread | Date

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

• Next message in Thread: Sean Hayes: "Re: 7-C Prompts (in authoring tools)"
• Previous message in Thread: Sean Hayes: "Re: 7-C Prompts (in authoring tools)"