Thread Subject: Re: Proposal (updated) on authoring tools

From: Judy Brewer
Date: Wed, Jun 13 2007 10:05 AM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Judy Brewer: "Re: Proposal (updated) on authoring tools"
• Previous message in thread: William Loughborough: "Re: Proposal (updated) on authoring tools"
• Messages sorted by: Author | Thread | Date

At 11:54 AM 6/13/2007 +0100, Sean Hayes wrote:
>#1 - I understand what you are trying to achieve, but it seems to have
>gone too far. As worded it would prevent some useful scenarios, such as
>printing to FAX. Or using tools which produce content formats like PNG
>(e.g. an image editor), which by themselves cannot pass the content
>provisions (but as part of an overall set would do so). I think we should
>retain the original wording because "authoring tools" may be a collection,
>and it is the collective output of the tool suite that must be accessible
>(see #8), not every point along the chain.

This is the kind of feedback that I was hoping for -- to note in advance
any potentially unintended consequences of adding "for each content format
that individual tools are capable of producing." The concern that Jim
Tobias had pointed out with the original language though is that otherwise
one wouldn't necessarily get accessible content options for the full range
of formats that a tool was able to produce. Is there any other way to make
sure that "Authoring tools must have the ability to produce content which
passes the electronic content provisions" can't just be interpreted as
having the ability to churn out a .txt dump of the content that the tools
produce?

>#3 I don't think the 'exclusively' has quite captured the issue of where
>the accessibility information needs human judgement.
>Maybe:
>"Authoring tools must provide a mode so that any content that can be
>generated by the tool without requiring author input will pass the
>electronic content provisions".

That seems a little closer to the intended meaning. However, I have to read
it a few times to get the meaning. Can someone try scrubbing it up further
for readability before our meeting today?

>#4 I think default should be removed. Tools that behave in this way by
>default are very frustrating for users and tend not to be successful. Some
>more clarity around what is meant by 'prompt' seems to be needed.

Note that there is some guidance on the meaning of "prompt" under B.2.1 at
http://www.w3.org/WAI/AU/2007/WD-ATAG20-20070530/WD-ATAG20-20070530.html#gl-support-author

and
http://www.w3.org/TR/2007/WD-ATAG20-TECHS-20070423/tech2.html#check-prompt-assist-user

>#5 Shares much with #4 and could be combined with it?

We've tried a few rounds of combining that already; can you suggest
specific wording?

>#6 I think a template is just a special case of 'content that can be
>generated' and should be covered by #3 as proposed above.

It does seem related, but are you proposing removing any reference to
templates, or combining it in some way with the current wording of #3? If
so, can you propose wording?

>#7 should be dropped unless someone can provide a testable definition of
>"most accessible"

Note that this has been proposed as "should" rather than "must"; I'd posed
a question back earlier in our thread (perhaps during our small-group
discussion) as to whether the advisory nature of the provision removes the
concern about testing. Note though that it's an open question whether there
would be advisory provisions.

>#8 seems to have the concept of 'for publication' which I think may be
>part way to resolving #1

Please clarify or expand?

Thanks,

- Judy


>Sean Hayes
>Standards and Policy Team
>Corporate Accessibility Group
>Microsoft
>Phone:
> mob +44 7977 455002
> office +44 117 9719730
>
>-----Original Message-----
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy Brewer
>Sent: 13 June 2007 05:53
>To: = EMAIL ADDRESS REMOVED =
>Subject: [teitac-websoftware] Proposal (updated) on authoring tools
>
>Dear All,
>
>Please review the following updated proposal on authoring tools in
>preparation for our meeting tomorrow.
>
>I have included the text brought forward from the small group discussion
>onto the Web/Software mailing list last week as the "WAS" text below. The
>"UPDATED" text represents my efforts to capture the sense of the discussion
>on the Web/Software mailing list over the past week. The "BECAUSE"
>information summarizes some of the input contributing to the proposed
>updated text. If I have missed key input or paraphrased your input
>inaccurately; please clarify. I have noted "DISCUSS" where there are
>specific issues needing discussion.
>
>Please continue to add your comments to the mailing list, and also be
>prepared to discuss this during our meeting tomorrow. Thank you for the
>active discussion on this thread over the past week.
>
>#1. [WAS] Authoring tools must have the ability to produce content which
>passes the electronic content provisions.
> [UPDATED] Authoring tools must have the ability to produce content
>which passes the electronic content provisions for each content format that
>individual tools are capable of producing.
> [BECAUSE] Otherwise one wouldn't necessarily get accessible content
>options for the full range of formats that a tool was able to produce
>(noted by Jim Tobias).
> [DISCUSS] Is the additional wording sufficiently clear, and does the
>additional specificity help or hurt the intent of this provision?
>
>#2. [WAS] Authoring tools must, except by explicit user action, preserve
>accessibility information necessary for meeting the electronic content
>provisions.
>[UPDATED] Authoring tools must preserve accessibility information necessary
>for meeting the electronic content provisions unless the user explicitly
>indicates otherwise.
>[BECAUSE] Improved readability (suggestion by Sailesh)
>[DISCUSS] Do we need to specify that this is for accessibility information
>"imported into, assembled by, or produced by a tool" or is it sufficient,
>or perhaps even better, to leave the source of the accessibility
>information unspecified? (from exchange between Jim T and Judy)
>
>#3. [WAS] Authoring tools must allow the author to augment
>automatically-generated content with accessibility information.
>[UPDATED] Authoring tools must provide a mode in which any content that is
>specified exclusively by the authoring tool must be accessible.
>[BECAUSE] This provision was drawn by the small group out of an ATAG
>provision which stated: "Ensure
>automatically generated content is accessible," because, if accessibility
>is not taken into account at the time of content generation, it is
>difficult for humans to go back later and retrofit that content. So the
>original proposal (the "WAS" version above) does not address the same
>concern which ATAG was addressing. The rewording proposed here (the
>"UPDATED" version above) attempts to address the original problem more
>clearly and directly (from explanation by Jan Richards).
>[DISCUSS] Does the proposed updated text capture the more essential need?
>
>#4. [WAS] For authoring tools with a user interface, authoring tools must
>provide a mode which prompts authors to create accessible content.
>[UPDATED] For authoring tools with a user interface, authoring tools must
>provide a default mode which prompts authors to create accessible content.
>[BECAUSE] (1) There were some requests to drop "authoring tools with a user
>interface," however, not all authoring tools have a user interface -- for
>instance, unattended, automated tools that operate on content. If prompting
>is required as a feature within all authoring tools, this would result in a
>requirement that could not always be met (from discussion between Peter,
>Sailesh, Sean, others).
>(2) A few people noted that "prompts" may be inadequate. Recommendations
>included "forced," though others noted problems with that; or required
>production of accessible content with prompting only being used to address
>ambiguities, but it is unclear how this would be determined (from
>discussion between William, David, Peter.) This updated proposal instead
>adds "default" before "mode" (from discussion between Jim T and Judy).
>(3) It was also noted that "prompting" may be insufficiently clear (from
>comments by Kate W.)
>[DISCUSS] Does "provide a default mode" work here? Is the term "prompting"
>sufficiently clear?
>
>#5. [WAS] For authoring tools with a user interface, authoring tools must
>provide a mode which assists authors in checking for accessibility problems.
>[UPDATED] (none yet)
>[BECAUSE] There was debate about whether authoring tools should be required
>to provide a mode which assists authors in checking for accessibility
>problems, or whether it should be sufficient for authoring tools to
>interoperate with evaluation tools. If "authoring tool" is defined as
>"software or a collection of software components" (as in ATAG 2.0), then
>perhaps any products used together (e.g., base tool and plug-in) or
>separately (e.g., markup editor, image editor, validation tool) would count
>regardless of whether there's formal collaboration between product
>developers... in which case, does this provision make any sense? It was
>also suggested that this requirement be a "should" instead of a "must," or
>that it be dropped. But it was also noted that authoring tools already have
>spelling, syntax and grammar checking built in, and that we can get
>standalone tools for them as well.
>[DISCUSS] Should authoring tools be required to provide a checking mode,
>and if so, how do we best interpret and capture that requirement?
>
>#6. [WAS] Authoring tools, when providing templates or other pre-authored
>content, should provide templates that facilitate production of accessible
>content, and pre-authored content that is accessible.
>[UPDATED] (none yet)
>[BECAUSE] It was suggested that this be a "must" rather than a "should"
>(William). It was suggested that the ability for authors to also create
>accessible templates should be included in this provision (from Kate W.),
>however isn't this already possible in most tools that have collections of
>templates? A clarification was requested for "pre-authored content" -- the
>description of this in ATAG is "Pre-authored content, such as templates,
>images, and videos,..." It was also suggested to specify that authoring
>tools should provide pre-coded accessible objects such as buttons, tables,
>templates, CSS files, form components (from Katie). A clarification was
>asked regarding "how many of the templates, how much facilitation?"
>[DISCUSS] (1) Should this be required instead of advised? (2) Is
>"pre-authored content" sufficiently clear? (3) Can this provision be made
>testable?
>
>#7. [WAS] Authoring tools should give prominence to the most accessible
>authoring action for achieving an authoring outcome.
>[UPDATED] (none)
>[BECAUSE] A clarification was requested for "prominence," and was provided
>from ATAG 2.0. It was suggested that this be changed from "should" to
>"must"; but conversely it was suggested by several people that this be
>dropped.
>[DISCUSS] Keep or drop?
>
>#8. [DEFINITION] Several people asked and others discussed the definition
>of authoring tools. The following definition was drawn from ATAG 2.0:
>"...any software, or collection of software components, that authors use to
>create or modify Web content for publication." It was also suggested that
>this definition be broadened beyond Web-related authoring tools.
>[DISCUSS] Does this definition work for authoring tools within TEITAC? Does
>the definition still work if "Web" is dropped?
>
>Regards,
>
>- Judy
>
>
>--
>Judy Brewer +1.617.258.9741 http://www.w3.org/WAI
>Director, Web Accessibility Initiative (WAI), World Wide Web Consortium (W3C)
>MIT/CSAIL Building 32-G526
>32 Vassar Street
>Cambridge, MA, 02139, USA
>
>

• Next message in Thread: Judy Brewer: "Re: Proposal (updated) on authoring tools"
• Previous message in Thread: William Loughborough: "Re: Proposal (updated) on authoring tools"