- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 07 Jul 1999 16:57:45 -0400
- To: w3c-wai-au@w3.org
7 July AU Teleconference
Chair: Jutta Treviranus
Scribe: Ian Jacobs
Present:
Charles McCathieNevile
William Loughborough
Dick Brown
Jan Richards
Kynn Bartlett
Gregory Rosmaita
Jim Allan
Wendy Chisholm
Agenda [1]
[1] http://www.w3.org/WAI/AU/telecon-30jun99
Document in review [2]
[2] http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990624
SUMMARY OF ACTION ITEMS:
All: Review techniques as assigned.
CMN: Review 25 Feb draft to propose verbiage for the
following points (related to 2.2.2):
- Use accessible standards.
- If possible, use applicable W3C standards
- Ensure that proprietary extensions to formats used
by the authoring tool do not make content inaccessible.
Ian: Propose clarifying Note to 1.5 that includes
information about selection, editing e.g.,
of a block, ease of selection.
Ian: Send proposal for introductory text
to WG (already sent to CMN).
Gregory: Review tersification of 1.3
Agenda 1) Review of techniques (DEADLINE: ONE WEEK)
William/Gregory: Guideline 1.
Charles: Guideline 2.
Ian: Guideline 3.
Dick: Guideline 4.
Jan: Guideline 5.
Jutta: Guideline 6.
Kynn: Guideline 7.
Agenda 2) Wording of 6.2
http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0393
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 if he can come up with something
better, otherwise "nature".
Agenda 3) Priority of 1.1
http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0418
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.
Agenda 4) Scope of 2.2
http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0384
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:
- Use accessible standard.
- If possible, use applicable W3C standards
- Ensure that proprietary extensions to formats used
by the authoring tool do not make content inaccessible.
Agenda 5) Wording of 1.4 and 1.5
http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0413
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:
a) 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 "vi", which
distinguishes viewing from editing mode. The two
cursors don't move together (which is 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 this wording.
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:
a) Want to pick up a piece of structure and move/copy/paste
as that structure. (Retains is properties as that object).
b) 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.3
Agenda 6) Introductions to guidelines
http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0385
Action: Send proposal to WG (already sent to CMN).
Agenda 7) Moving forward to last call.
a) 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) Accessibility of Amaya.
http://www.w3.org/Amaya/
CMN: We recognize accessibility problems. I'm going to
Grenoble next week to talk to Amaya Team.
Next meeting: 14 July 1999
Received on Wednesday, 7 July 1999 16:55:42 UTC