- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 15 Dec 1999 17:15:20 -0500
- 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 UTC