WAI Authoring Tool Guidelines Working Group
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 http://www.w3.org/WAI/AU/PR-WAI-AUTOOLS-19991210.
JT: In 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:
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.
Issues raised by Ian
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 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.
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 WAI CG meeting.
Action Ian: Propose wording that will work across all Guidelines to all WGs.
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.
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".
b) Make "auditory descriptions" plural in the Note.
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'
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.
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.
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."
(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.)
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?
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
Resolved: Incorporate editorial suggesions.
Last Modified $Date: 2000/11/08 08:11:51 $