W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 1999

Re: Comments on Introduction of 17 June AU Guidelines

From: Jutta Treviranus <jutta.treviranus@utoronto.ca>
Date: Sun, 20 Jun 1999 12:26:59 -0400
Message-Id: <v04011702b392c56b5a5d@[142.150.64.191]>
To: Ian Jacobs <ij@w3.org>, w3c-wai-au@w3.org
Ian,

I agree with and like the rewording of the introduction and abstract with
the exception of the proposed rewording of the paragraph on the benefits
and role of automation:

<BLOCKQUOTE>
>By automating some editing tasks, authoring tools
>can produce content known to be accessible at the
>same time they allow authors to concentrate
>on higher level authoring issues. Automation does not
>mean authors may ignore accessibility issues, but it
>does mean that authors can leave mechanical tasks
>up to the authoring tool.
></BLOCKQUOTE>

It still seems awkward and not to the point. The point we want to make is
that we want to free up the energies and attention of the author to
concentrate on accessible authoring practices that require human cognition
and judgement by automating or semi-automating tasks that can be carried
out by the machine.

Knowing our intention can you propose another revision?

Jutta

At 6:42 PM -0400 6/19/99, Ian Jacobs wrote:
>Reference document:
>  http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990617/
>
>1) Propose changing:
>
><BLOCKQUOTE>
>Authoring tools are used to
>automate the mechanical tasks that are part of producing Web pages. The
>power of this automation can enhance the accessibility of the Web if it
>is used to ensure that the code produced
>promotes accessibility, and frees the author to concentrate on the
>higher level problems of overall design, content, description, etc.
></BLOCKQUOTE>
>
>to:
>
><BLOCKQUOTE>
>By automating some editing tasks, authoring tools
>can produce content known to be accessible at the
>same time they allow authors to concentrate
>on higher level authoring issues. Automation does not
>mean authors may ignore accessibility issues, but it
>does mean that authors can leave mechanical tasks
>up to the authoring tool.
></BLOCKQUOTE>
>
>2) In the second paragraph, change "some features which"
>to "some features that".
>
>3) In the second paragraph, insert a reference (and link) to
>   [WAI-WEBCONTENT] after "Web Content Accessibility
>   Guidelines".
>
>4) In the second paragraph, propose changing:
>
>  <BLOCKQUOTE>
>  The accessibility of the content produced depends on the ability of
>the tool to be used in producing accessible markup, and on the user
>interface of the tool enabling, informing, and encouraging the use of
>accessible markup authoring practices. These Guidelines refer
>extensively to the Web Content accessibility Guidelines, which details
>accessibility requirements for markup itself, and include checkpoints
>which are basic requirements for the accessibility of the tool and its
>output. In addition, there are guidelines and checkpoints which are
>uniquely relevant to the role authoring tools play in guiding the author
>to produce accessible content.
>  </BLOCKQUOTE>
>
>to:
>
>  <BLOCKQUOTE>
>  Two factors affect the accessibility of content produced
>  by authoring tools: the quality of the markup created
>  by the tool and the success of the user interface
>  in enabling, informing, and encouraging accessible
>  authoring practices. For issues relating
>  to accessible markup, these Guidelines refer to
>  W3C's Web Content Accessibility Guidelines [WAI-WEBCONTENT],
>  which explain in detail how content developers can
>  construct accessible Web pages and sites. For authoring
>  tool accessibility, the current guidelines explain
>  how to create a user interface that is accessible and
>  promotes accessible authoring practices.
>  </BLOCKQUOTE>
>
>I propose dropping references to checkpoints and
>guidelines from the Introduction since they are
>explained two sections later.
Received on Monday, 21 June 1999 12:24:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:42 UTC