RS: Where this originated - in Windows, they want you to use the COM. Since
you can only do this from another process, you are affected by system
scheduling priorities. Access is then slow. We found in tests that in-process
response times were 12 times faster.

RS: You can't assume synchronization with fast APIs. Suppose that while the
AT is traversing the DOM tree, if the location in memory is deleted, or the
element members are distorted, accessing those memory locations could lead to a
crash. This is a separate issue.

DP: An example of timeliness: an AT starts rendering *before* a new page is
loaded.

RS: The "helper" facility from IE is one technique for being
in-process. Another is to embed the browser in your application.

RS: I'd like to see "in-process" happen. It would take
significant changes to MSAA to make that happen.

IJ: I think that if in-process is required, the problem of no standard for
access to the DOM falls away.

IJ: I propose asking PF two questions:
- Should we change "timely" to "in-process"?
- What kind of synchronization necessary?

Need feedback by 18 Feb.

Action RS: Take these issues to WAI PF. Get input from
MSAA developers as well. Craft email to PF WG with Ian.

IJ: I spoke with Håkon Lie about the DOM requirement.
- Issue of open-ended spec. I propose that we limit to Recs that exist at time
of publication. We can update later.
- Also issue of when the spec becomes available. What happens when DOM 2 comes
out? You can't expect any implementations. We had this in ATAG 1.0; took the
approach of clarifying in the spec. You don't want conformance to the same spec
to change over time as much as possible.

IJ: We might want to add the word "available" to 6.2.

IJ: Same for 11.1 (WCAG). I think we need to limit to WCAG 1.0.

JG: Also want to be sure that DOM includes features that will benefit
accessibility.

RS: DOM 2 gives you a standardized event model.

Resolved:
1) Change 11.1 to refer to WCAG 1.0 specifically.

Action Ian: For 6.2, propose some wording to address the
"when available" issue.

Proposed:
1) Reduce the scope of 5.1 to say "write access only for that which you
can do through the UI." This would apply for form controls, style sheets.
In short, give the same write access to everyone.

HB: You need to be able to "undo" as well.

RS: DOM 2 includes some style abilities.

IJ: How does an AT get notified of content changes? (Checkpoint 5.4).

RS: Add an event listener. MS has reams of documents on this. Our group is
doing work with this.