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

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

Details

   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
     _________________________________________________________________

Agenda

   The Latest Draft is the working draft dated 10 december, available at
   [4]http://www.w3.org/WAI/AU/PR-WAI-AUTOOLS-19991210.
     * [5]Ian's review comments
     * Are there outstanding issues?
     _________________________________________________________________

      [4] http://www.w3.org/WAI/AU/PR-WAI-AUTOOLS-19991210/
      [5]
http://lists.w3.org/Archives/Public/w3c-wai-au/1999OctDec/thread.html#295

Attendance

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

Action Items and Resolutions
     _________________________________________________________________

Minutes

   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
       "disability"
       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
       definition.
       PJ: I think this applies more to WCAG to define accessibility of
       content. We don't need to define it independently. Also UI
       standards.
       Resolved: No need to add definition of "disability" in the ATAG.

      [6]
http://lists.w3.org/Archives/Member/w3c-wai-cg/1999OctDec/0053.html
      [7]
http://lists.w3.org/Archives/Public/w3c-wai-au/1999OctDec/0314.html

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

   [8]Issues raised by Ian

      [8]
http://lists.w3.org/Archives/Public/w3c-wai-au/1999OctDec/0295.html

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

   Form 1 describes what information must be made available in a
detailed
   conformance claim (AUGL version, conformance level, checklist, etc.).
   In the UA WG, we have been discussing ways to deliver this
information
   (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
and
   UA Guidelines to be the same, even if details of the claim vary
   slightly.

      [9]
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#136

   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.

     [10]
http://lists.w3.org/Archives/Member/w3c-wai-cg/1999OctDec/0053.html

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

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

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

   Resolved:
     * 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
   "movies".

   Resolved:
     * 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
   alternatives."

   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
case,
   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
   deleted.

   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'

   Resolved:
     * 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
glossary.

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

   Resolved:
     * 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
that
   what "presentation markup" means? I propose dropping "that is
   stylistic".

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

   Resolved:
     * 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
   "functions".

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

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

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

  Issue 8) Guideline 7 rationale question:

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

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

   NOT DISCUSSED

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

   Proposed: Delete the note after 7.2

   NOT DISCUSSED

  OTHER EDITORIAL COMMENTS and SUGGESTIONS

   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)
16
       December.
       (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
day
       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
   statements.
     _________________________________________________________________

     [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
Disclaimer
     [17] http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C
Trademarks
     [18] http://www.w3.org/Consortium/Legal/copyright-documents.html
     [19] http://www.w3.org/Consortium/Legal/copyright-software.html
     [20]
http://www.w3.org/Consortium/Legal/privacy-statement.html#Public
     [21]
http://www.w3.org/Consortium/Legal/privacy-statement.html#Members

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:52:56 GMT