Minutes Jan 29, 2001

Here's the minutes - text here, attached as HTML. They probably need
correction/clarification, let me know if any issues.

Michael

WAI ER Meeting Jan 29, 2001

Present: Len Kasday, Chris Ridpath, William Loughborough, Michael Cooper,
Wendy Chisholm, Dick Brown
Minutes: Michael Cooper

Action item summary

LK: Propose to AU that ATAG incorporate way to identify which Checkpoints
have been checked, using anchors in AERT or AU

LK: Look where in ATAG a checkpoint to store manual check results is/would
go

LK: Recommend to AU that ATAG include keeping track of changes to state of
manual check-related items

DB: Check proposed accessibility features for Word.

Discussion

LK: Anybody implementing EARL?

WL: Anything to implement

LK: Just a spec

WL:

CR: looking at, interested but no resources

LK: Implement in larger tool like APrompt or Bobby is larger task (goes
through every checkpoint)

WL: Example of Open Issues - click a link to go to different items. In EARL,
will have a pointer to the instance (fragment ID) in a document that we're
interested in. Inherent in EARL as a principle. Required for it to be of
use.

LK: Having fragment IDs is required already

WL: Do we have a way to do that? E.g., XLINK or something - we "wave the
magic wand" - have we worked out exactly how something like this will be
done? If I try now, need a "name" anchor to point to - can I do it without
being dependent on that?

LK: Any browser does this?

WC: IE5 might

LK: Even if supported, no easy way to define an XPointer corresponding to a
section of doc via a user highlighted section of doc

WC: No auto tools, but auto evaluator could do

WL: Would it be possible to create a document that users can open, follow a
link, goes to right place (without special browser support), e.g., link to
relevant meeting minutes in open issues list

WC: Put resolutions at top of minutes, that's what I track, not the
discussion

WL: Can move on to discussion?

WC: Yes, will do

LK: Even w/o EARL, we might use XPointers in output of tool. E.g., Bobby
uses line numbers. W/ DOM access, should be straightforward to use. Should
add an XPointer address to output.

MC: What about documents that change, XPointers no longer valid?

LK: An issue

WL: But ok in same session

LK: APrompt?

CR: Doesn't refer to line numbers, refer to object you're dealing with. Same
XPointer problem - change doc and things can be invalid.

LK: A statement that tools that make statements about a doc should give an
XPointer, independent of anything else in EARL, maybe that should be part of
AERT requirements - send suggestion to AU?

CR: Things may change. If image missing ALT, need image name (SRC), don't
need XPointer or line number, that's more stable. Not sure XPointer is good
long-term way to refer to something.

WL: Better to snip out offending item and present in report, separate from
its original context

LK: Leading to maybe we should use something entirely different than
XPointer in certain cases

MC: But really difficult to do with multiple element types

CR: Can't leave to tool?

WC: but then can't share infomation. I think we decided we're not gonna find
a way, unless we figure out something other than XPointer. Unless we have
some way to distinguish states (a diff utility?), maybe we just run eval
again.

LK: If we have a doc, there's text that's just there in between tags. If
just text doesn't change, just tags, we can identify things pretty well by
relation to text

MC: Unlikely for one to change w/o other

WC: Unless there's been a repair e.g. blockquote to something else

LK: Right now tools are pretty tag-based. Bobby, Wave, APrompt... Could use
all that stuff between tags. Is a text fragment a special case of XPointer?

MC: DOM2 has a way to identify ranges

LK: Even if spans multiple subbranches of tree? Couldn't legally mark up
with SPAN.

MC: Pretty sure, but haven't read yet.

WL: Al Gilman would know

LK: Would like some resolution - a new requirement to pass on to AU, or
explicitly no requirement. General statement that tools point to what
they're talking about.

MC: How is EARL used? Thought of it as general description language. If used
for tool sharing, will people implement it?

LK: Think of tool as helping user to perform the evaluation.

MC: Different tools work in different ways that complement each other?

LK: Or multiple users of one tool.

WC: Maybe EARL can't serve all our needs, but a bit of it. Just save results
of eval in one tool. Figure out later how to communicate betweent tools.
Need a doc that boils down all the possible checks, all the things a
particular tool has checked. Refer to Charles' earlier work... {missed some
stuff here}

LK: So create a referencable list of the checks a tool performs?

WC: Relevant to manual checks, since there's so many. Relevant to WCAG - how
can you determine if doc has passed checkpoint? Didn't consider in WCAG 1
but considering in 2. So for now, let's just start making assertions.

LK: AERT checks already has anchors?

WC: Yes.

LK: Resolved: use AERT anchors as reference for stating what checkpoints
passed/failed.

WC: Would make AERT a normative document. Since incorporated into AU, should
be ok.

LK: Now uncomfortable - would rather point directly into WCAG than AERT. Are
there anchors in WCAG?

WC: Yes.

MC: AERT more fine grained

LK: What if tool had custom check?

MC: use a namespace

WC: Would still have to associated with WCAG checkpoint.

LK: 3 possibilities now - point to WCAG, point to AERT (with custom
exceptions), things not in WCAG at all. Try to get as close as you can to
established namespace, if you can't use your own. *resolved* (as proposal to
ATAG *action*)

LK: A tool that supports manual checks should be able to store results of
checks, so doesn't have to do again.

WL: So will fill up with old reports?

WC: Where does this requirement go?

LK: Would go into authoring tools.

WC: Where fit into ATAG? We need to look at that.

LK: *action* Will look, report next joint meeting.

CR: May be more complex than recording that check done - if doc changes,
would have to repeat check. Maybe some checks can be unrepeated - e.g., if
text changes, don't need to repeat blink check.

WC: Would like a way to record, for every change in an object, what other
evals need to happen. Event handling model.

LK: Needs to be built into AU tool?

WC: Yes.

LK: Makes this an integral part of tools, not separable.

WC: Can be processing intensive. But most robust.

LK: For Object Oriented tool, not a big deal.

MC: We're recording changes, not triggering immediate evaluations?

WC: Yes, triggering changes to state of EARL doc in backend.

LK: Part of recommendation to AU becomes keeping note of manual
check-related items. *action*

WL: We can propose, but people who have to dispose (AU tool writers) we
don't have much contact with.

WC: Something APrompt could do.

WL: But word processors...

LK: Take Word's track changes features -

MC: But not OO - just marking changes. What we want is more like multiple
undo buffer.

WL: will Word have an accessibility feature?

DB: Being talked about for Frontpage, not really on horizon for Word, but
could happen down road. Can check *action*

- light discussion, discussion of adjournment -

WL: Made some progress on some of these abstract concepts that are relevant
to us.


Michael Cooper
Bobby Project Manager
Technical Designer
CAST, Inc.
39 Cross St.
Peabody, MA  01960
Tel +1 978-531-8555 x265
TTY +1 978-538-3110
Fax +1 978-531-0192
Email mcooper@cast.org
http://www.cast.org/
http://www.cast.org/bobby/