WAI Authoring Tool Guidelines Working Group
Chair: Jutta treviranus, <email@example.com>
Date: Wednesday 7 July 1999
Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990624.
Note that in most cases there is a thread of discussion following the message which has been referred to here.
DB: Don't like "presentation". Is this style?
CMN: Prefer "nature"
GR: Prefer "nature"
DB: What are we trying to get at? Severity? Type?
JR: Prefer "nature"
Resolved: Ian will repropose change to 6.2 if he can come up with something better.
CMN: Knowing relative importance is not entirely a minus. Developers must understand their own guidelines. Will encourage development of good guidelines. Checkpoints needs a priority since must be checked. Should be relative. Intelligent people will have to make intelligent decisions.
JR: "Use" is sufficiently vague. Should only be "absolute" Priority 1.
DB: I like wording of CMN's proposal.
Resolved: Adopt CMN's (relative wording) proposal for 1.1.
Resolved: Change first sentence of Guideline 2.2 from "The first step towards producing content is conformance with standards, which promotes interoperability." to "Conformance with standards promotes interoperability and accessibility."
Resolved: Checkpoint 2.2.2: Change "Extensions to W3C Recs" to "Proprietary extensions to W3C Recs".
IJ: I'm not sure why this is limited to W3C Recommendations, in fact.
CMN: I agree that can be generalized.
JR: Is this in scope.
CMN: Yes. You could extend GIF and create accessibility features, and this would be in the scope of the WG.
IJ: Proposed: "Ensure that proprietary extensions to formats used by the authoring tool do not make content inaccessible."
GR: Perhaps we need to resurrect version from 25 Feb Draft.
CMN: We know that W3C specs don't cover everything.
Action CMN: Review 25 Feb draft to propose verbiage for the following points:
IJ: Checkpoint 2.1.3: Propose changing from "Enable navigation and editing via the structure of the document" to "Allow the author to navigate and edit the document based on its structure."
CMN: Proposes clarification: Allow the author to navigate the document based on its structure. NOTE: Minimal satisfation of this checkpoint means allowing the user to navigate element by element. Once the user has navigated, the user must be able to edit the document.
DB: What does navigate mean exactly here?
CMN: Move insertion point around. Think of a proram like "vi", which distinguishes viewing from editing mode. The two cursors don't necessarily move together (although that would be odd). In MS Word, you move scroll bars, which doesn't move insertion point. You need to be able to do both together.
DB: Are we trying to tell people how to navigate?
CMN: We're requiring a certain functionality. Others can co-exist, but you must be able to navigate and then edit. Need to be able to move (and edit) more than character by character or line by line. Might move paragraph to paragraph.
DB: Proposes: "Ensure that the editing view allows navigation by document structure."
Resolved: Adopt "Ensure that the editing view allows navigation by document structure." for 1.4.
IJ: What is the difference between editing the document and editing the structure of the document?
CMN: Gross level editing. Need more than to be able to extend the selection more than by character by character.
IJ: I think the term is "structured editing"
DB: We're talking more about selection than editing. Need a means for the user to be able to set the selection easily.
CMN: I think you need to mention editing since selection not always bound to editing. IJ: Proposes: "Ensure that the editing view allows structured editing."
IJ: How easy is it to verify this checkpoint? When have you satisfied the checkpoint (e.g., you can select tables but not headers)?
DB: And how easy must it be? We want accessible selection and editing.
CMN: Want to pick up a piece of structure and move/copy/paste as that structure. (Retains is properties as that object). Second requirement is being able to do this in a useful way.
GR: "Allow the user to user to edit a structured tree view (or linearized version) of the document."
DB: By the way, navigation from header to header is not obvious. Type A to type A navigation not obvious.
CMN: Not required. Element to element sufficies. HotMeTal, Amaya, Word have outline views you can navigate. Word lets you move paragraph to paragraph. That would do the trick.
Action Ian: Propose clarifying Note to 1.5 that includes information about selection, editing e.g., of a block, ease of selection.
Action Gregory: Review tersification of 1.3Agenda 6) Introductions to guidelines
Action IJ: Send proposal for introduction to WG (already sent to CMN)
Techniques need to be fleshed out before document goes to last call (Tim Berners-Lee requirement).
CMN: Working on the techniques is really helpful to clarify the document. For this reason alone, well worth ensuring that techniques are fleshed out.
Jutta: After techniques review next week, will estimate last call date.
William: When does Director review?
IJ: No formal program for the Director to read the document.
CMN: But the Director review comes after AC Member Review. (and before PR as well).Agenda 8)
CMN: We recognize accessibility problems. I'm going to Grenoble next week to talk to Amaya Team.
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile