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

Minutes from 15 December ATAG WG teleconference

From: Ian Jacobs <ij@w3.org>
Date: Wed, 15 Dec 1999 17:15:20 -0500
Message-ID: <385812F8.E56C63C6@w3.org>
To: w3c-wai-au@w3.org

Minutes online at [1] and in text below. Please note deadlines
at the end of the minutes.

 - Ian

[1] http://www.w3.org/WAI/AU/telecon-15dec99.html

   [1]W3C [2]Web Accessibility Initiative

      [1] http://www.w3.org/WAI/
      [2] http://www.w3.org/WAI/

   [3]WAI Authoring Tool Guidelines Working Group

      [3] http://www.w3.org/WAI/AU

                   WAI AU Teleconference - 15 December 1999


   Chair: Jutta Treviranus

   Date: Wednesday 15 December 1999

   Time: 3.30pm - 5:00pm Boston time (1830Z - 2100Z)

   Phone number: Tobin Bridge, +1 (617) 252 7000


   The Latest Draft is the working draft dated 10 december, available at
     * [5]Ian's review comments
     * Are there outstanding issues?

      [4] http://www.w3.org/WAI/AU/PR-WAI-AUTOOLS-19991210/


     * Jutta
     * Jan
     * Gregory
     * William
     * Ian
     * Phill
     * Charles
     * Dick

Action Items and Resolutions


   JT: In [6]WAI CG meeting, discussion of WHO/NIST terms "disability",
   "impairment", etc. WAI CG decided not to use the WHO/NIST definitions
   in the Guidelines. Conclusion:
     * Take the functional perspective, not medical perspective
     * Don't talk about "impairment." in the document.
     * Refer also to [7]question raised by Phill about definition of
       PJ: I dont' want to delete existing definitions. Just need to add
       definition of "disability" to the glossary.
       GR: I find the term "disabled" perjorative.
       IJ: We avoided the term in WCAG.
       JT: WAI CG felt strongly about not using a medical-based
       PJ: I think this applies more to WCAG to define accessibility of
       content. We don't need to define it independently. Also UI
       Resolved: No need to add definition of "disability" in the ATAG.


   Action editors:
     * Ensure that "impairment" doesn't appear in the ATAG.

   [8]Issues raised by Ian


  Issue 1) Section 1.3 (Conformance to these Guidelines).

   Form 1 describes what information must be made available in a
   conformance claim (AUGL version, conformance level, checklist, etc.).
   In the UA WG, we have been discussing ways to deliver this
   (this was discussed at the 10 December UAGL face-to-face in Austin
   as[9] issue 136). would like the methods used by the AU Guidelines
   UA Guidelines to be the same, even if details of the claim vary


   Proposed: In Form 1, explain that the information required for the
   claim (the bulleted list) may be provided in the software
   documentation or on the Web. In the latter case, the claim would be
   accompanied by a URI to the claim information on the Web.

   JT: Discussed yesterday in [10]WAI CG meeting.


   Action Ian: Propose wording that will work across all Guidelines to
   all WGs.

  Issue 2) Editorial change to checkpoint 2.2: change "inform" to

   Old text: "If markup generated by the tool does not conform to W3C
   specifications, inform the author."

   The term "alert" is well-defined, while "inform" is not. The term
   "alert" is defined as "draw the author's attention to an event or
   situation." Invalid markup is a situation.

   JT: Alert is perceived as something that people are familiar with
   (e.g,. with dialog boxes).

   PJ: Propose to subsitute "alert" with "inform" globally.

   DB: I don't think we should use "alert" in 2.3 due to common usage in

     * Define "inform" as a superset of "alert", "prompt", etc.
     * Use "inform" in 2.2 and 4.1 and link to its definition.
     * Link to "prompt" in note after 4.1
     * Leave "alert' as is.
     * Add an "s" to problems at the end of the Note in 4.1

  Issue 3) Checkpoint 3.3

   a) In the Note, it is not clear that "movies" are movies that come
   with the tool. I propose adding the word "prepackaged" before

     * Add "prepackaged"
     * Add more links to definitions.

   b) Make "auditory descriptions" plural in the Note.

   Resolved: Yse.

  Issue 4) Checkpoint 3.4:

   Both the checkpoint and note are unclear to me. Old text: "Do not
   insert automatically generated or place-holder equivalent

   a) The term "automatically" is redundant since "generate" in this
   document means the tool created the content on its own.

   b) "place-holder" is not clear to me and is not explained in the
   Techniques document. I don't think it's necessary because either:

   1) The tool generated the place-holder and therefore it's subsumed by
   "don't generate equivalent alternatives", or

   2) The tool is reusing a previously authored equivalent. In this
   the requirement may be "Don't reuse previously authored equivalents
   without confirmation from the author."

   c) The first example in the checkpoint note is unclear and should be

   Proposed new checkpoint text and note:

   Checkpoint 3.4 Do not automatically generate equivalent alternatives.
   Do not reuse previously authored alternatives without author
   confirmation, except when the function is known with certainty.

   Note: For example, prompt the user for a text equivalent of an image.
   If the author has already provided a text equivalent for the same
   image used in another document, offer to reuse that text and prompt
   the author for confirmation. If the tool automatically generates a
   "Search" icon it would be appropriate to automatically reuse the
   previously authored text equivalent for that icon. Refer also to
   checkpoints 3.3 and 3.5.

   CMN: No, you lose the ability to reuse an equivalent when the
   functionality is known with certainty.

   IJ: 19 instances of "generate" without 'automatic' in the document
   without 'generate'

     * Adopt Ian's change (using "automatically generate")
     * Add to end of the checkpoint "except when the function is known
       with certainty".
     * Review the document for the term "generate" and either substitute
       "produce" (e.g., in the abstract) or "automatically generate".
     * Don't add a definition of "generate" or "produce" to the

  Issue 5) Proposed edit to checkpoint 3.5

   Old text: Provide a mechanism to manage alternative information for
   multimedia objects, that retains and offers for editing pre-written
   previously linked equivalent alternative information.

   New text: Allow the author to manage, edit, and reuse alternative
   equivalents for multimedia objects. Note: These alternative
   equivalents may be packaged with the tool, written by the author,
   retrieved from the Web, etc.

   CMN: Change "allow" to "assist".

   JR: "Allow" means "don't prevent".

   CMN: We've used "assist" in 4.2 to allow the giving of clues.

     * Provide functionality for managing, editing, and reusing
       alternative equivalents for multimedia objects. Note: These
       alternative equivalents may be packaged with the tool, written by
       the author, retrieved from the Web, etc.

  Issue 6) Checkpoint 4.5

   Old text: "Allow the author to transform presentation markup that is
   misused to convey structure into structural markup, and to transform
   presentation markup that is stylistic into style sheets."

   I don't understand "presentation markup that is stylistic". Isn't
   what "presentation markup" means? I propose dropping "that is

   CMN: I prefer to leave the redundancy. And define "presentation

     * Add definitions of "structural" and "presentation" markup. Refer
       to definitions by CMN as modified by CMN.
     * change "presentation markup that is stylistic" to "presentation
       markup used for style"

  Issue 7) Checkpoint 5.1

   Old text: "Ensure that functions related to accessible authoring
   practices are naturally integrated into the tool."

   a) I think "features" or "functionalities" would be better than

   New text: "Ensure that features related to accessible authoring
   practices are naturally integrated into the tool."

     * Change "functions" to "functionality" (and "are" to "is") in 5.1
     * Change "into the tool" to "into the overall look and feel of the

   (Ian Note: I am tempted to suggest "into the user interface" as a
   specific substitute for "into the tool." But I think I'll be shot

  Issue 8) Guideline 7 rationale question:

   Old text: "When custom interface components are created it is
   essential that they are accessible through standard access

   What are "standard access mechanisms?" How do they apply to custom


  Issue 9) The note after checkpoint 7.2 should be deleted.

   Text about being able to author with one style and publish with
   another appears three times:

   a) Paragraph 2 of Guideline 7 rationale

   b) Checkpoint 7.2

   c) The note after 7.2 (which offers little more information than the

   Proposed: Delete the note after 7.2



   Resolved: Incorporate editorial suggesions.

  Process for putting the document to sleep.

     * Editorial issues wil be incorporated into the document unless
       opposition on the list
     * We're done when the issues list is empty.
     * Deadline for comments on editorial proposals is end of day (ET)
       (Charles' friday)
     * Charles will publish a draft on Friday.
     * People must sign off explicitly to end the document editorial
       process. If we get signoff from everyone on the list by end of
       Monday 20 December, no meeting 22 December.
     * Otherwise signoff at 22 December meeting.

   [11]Copyright    1999 [12]W3C ([13]MIT, [14]INRIA, [15]Keio ), All
   Rights Reserved. W3C [16]liability, [17]trademark, [18]document use
   and [19]software licensing rules apply. Your interactions with this
   site are in accordance with our [20]public and [21]Member privacy

     [11] http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright
     [12] http://www.w3.org/
     [13] http://www.lcs.mit.edu/
     [14] http://www.inria.fr/
     [15] http://www.keio.ac.jp/
     [16] http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal
     [17] http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C
     [18] http://www.w3.org/Consortium/Legal/copyright-documents.html
     [19] http://www.w3.org/Consortium/Legal/copyright-software.html

   Last Modified $Date: 1999/12/15 22:12:12 $
Received on Wednesday, 15 December 1999 17:15:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:28:22 UTC