Minutes from AUWG telecon, 05 May 03
Attendance
jt Jutta Treviranus
br Bob Regan
tb Tim Boland
mm Matt May
Minutes
Combining checkpoints in Guideline 1
jt: These used to be one checkpoint. They were divided some time ago in the history of the document. But in creating success criteria, it became clear there were shared rationales. Proposal is to bring them back together, but word it clearly as navigating and using structure.
tb: The word "easily" is hard to test. Subjective. Something more objective like measuring steps?
jt: Could "easily" be defined as the presence of a hotkey, or something like that?
br: Something like the outline form in Word where you can expand or collapse. Or Find and Replace in Dreamweaver. In both cases, the idea of easily moving is using single keystrokes to move or collapse/expand.
jt: And that need not be a visual effect. Just need confirmation.
br: We discussed that this fit in hierarchical relationships, but in other systems, it becomes more difficult to navigate. How do you navigate an SGML file?
jt: Set x number of keystrokes or menus, or some other metric?
tb: Should vs. must?
jt: Not decided. Some discussion on CG.
mm: Other Recs use the RFC to determine must, should, may, etc. WAI uses some different rules. I would suggest that we use the RFC-based approach because our potential audience knows how to read it.
br: Some people would say that using Code View in Flash would satisfy a keystroke requirement. I think that "easily" has more of the core of the requirement.
jt: How would you reword this?
br: "Author should be able to move between structural elements without moving focus through the content of those elements.
tb: Do we have use cases?
jt: No, but we've brought up several of them in the discussion. And we have many ways this can be achieved, such as tree view, and other ways to move through hierarchy.
br: In a text-only find and replace, would we expect the end user to know what the specific code would be?
jt: We wouldn't. We want more, and we say what kind of functionality that would be.
br: Even with a more fully-featured find and replace, we assume that the user has some knowledge of the structure.
jt: Right. Find and replace doesn't allow you to have that recognition of the document. A sighted user wouldn't need to know where the end of a paragraph is, because they have visual clues. Non-sighted users would need the same level of functionality.
br: Dreamweaver probably wouldn't qualify. But I think that with an advanced find and replace, and some knowledge of the document structure, we could have comparable functionality. It's a big challenge, and I think that if someone is going to make a tool that's screen-reader-friendly, this would be needed. But I don't know if anyone does it now.
jt: XMetal and XMLSpy do it now.
br: It'd be good to get vendors on the hook. But requiring this right away would be a dealbreaker.
jt: With that advanced functionality, you are having the functional equivalent of some of this.
mm: Searching on an XPath would work.
br: Is adding this feature going to be a requirement for conformance?
jt: This could be a template for advanced search, allowing users to search structure.
tb: We'd need to understand what those visual clues are that we'd need to emulate.
jt: This points out that we need to be clearer in the success criteria.
ACTION jt: Requirements for people who don't have access to visual cues.
:
Face-to-face planning
jt: The proposed meeting date is 13-14 June at the eGov conference. Phill suggested using the conference to recruit.
tb: I have space reserved at NIST.
br: Not sure if I'll be able to make it.
:
Next meeting
jt: 19 May
br: Probable regrets.
jt: Test suite criteria on the agenda.