MINUTES: 31 March Telecon

I applogize for the delay of the in posting the mintues of last weeks
meetings.
Jon


Attendance
Chair: Jon Gunderson

Scribe: Ian Jacobs

Lauren Wood (LW) 
Arnaud Le Hors (AL) 
Harvey Bingham (HB) 
Rob Relyea (RR) 
Tom Wlodkowski (TW) 
Madeleine Rothberg (MR) 
Mark Novak (MN) 
Kitch Barnicle (KB) 
Rich Schwerdtfeger (RS) 
Mark Hakkinen (MH) 
Scott Leubking (SL) 
Charles McCathieNevile (CMN) 
Al Gilman (AG) 
David Poehlman (DP) 
Jim Allan (JA)


----------------------------------------------------------------------------
----

Action Items and Conclusions
Actions
RS: Write a proposal for the Techniques Document for loading an assistive
technology for direct access to the browsers DOM. DEADLINE: One week. 

RR: Write a description of how a browser could expose its internal object
model to other processes including the ability to run a module of the AT to
run in the process. DEADLINE: One week. 

RR: Rewrite 7.2.2 as you want it (centered around information). 

CMN: Rewrite 7.2.2 the way CMN would like to see it. 

AG: Turn 7.2.1 into a guideline with checkpoint. 

IJ: Discuss comments with Judy Brewer and Jon Gunderson: COMMENTS from
BORIUS: http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0341.html

Resolutions
IJ: Publish WD without modifications due to intervening WG decisions. 


----------------------------------------------------------------------------
----

Minutes
Agenda [1]
[1]http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0377.html For
9 March 1999 Guidelines [2] [2]
http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19990309/ Agenda 1) Review of
current Checkpoints related to Assistive Technology Compatibility /*
Background information */ JG: MS IE exports DOM through COMM. Are there any
interfaces for exporting the DOM? Guidelines for doing so? 

LW: DOM defines interface only. Doesn't define how will be exposed. We call
this the "DOM implementation". The "DOM application" is the script or
program that accesses the document through the interface. E.g., MS
typically uses COMM, someone else might use Java beans. 

RS: My concern about using other interaces - ATs need direct access to the
DOM. LW: Nothing stops ATs adding on top of what the DOM provides. You're
talking about a certain class of DOM implementations and applications. DOM
is handling a more general class of operations (e.g., server running in
background) that aren't interesting to ATs. 

RS: I agree. But twofold concern: a) Some features not provided that may be
provided in IE or NN that may benefit ATs. - Think they need direct access
to DOM implementation b) Performance issues. Don't want to have to go
through a different process space. Don't want to give user undue delays. 

JG: (Summarizing) Nothing in the current DOM or proposed to allow other
applications to use. 

LW: Clarification - we don't specify how this is done. That's part of our
platform/language neutrality. Can't specify COMM or CORBA. 

JG: (Summarizing) DOM WG says this is an implementation detail. 

RS: Is it possible to define (and in which spec?) that you should be able
to access the DOM in the same process space as the source application? 

LW: As long as you specify what you mean... 

RR: SOunds like you're talking about interprocess communication and the
performance issue. You want something inside the browser's code space that
can communicate more quickly. 

RS: I'd like the AT to register with the browser and for the browser to
launch the AT in its process space. Possibly on a different thread. With
caching. 

JG: Can you write a proposal for the Techniques Document. 

ACTION RS: Write a proposal for the Techniques Document for loading an
assistive technology for direct access to the browsers DOM. DEADLINE: One
week. 

DP: Normally, our AT's already running. What happens then? (e.g., browser
starts after AT). 

RS: We had to do this on OS/2. Different "environment". The client
software, loaded as DLL, notifies the server application three that it's
live. The AT talks to the DLL. 

JG: Given range of ATs, there are two main classes: a) Screen reader model
(general access). User agents are only one type of software to be
communicated with. b) Specialized browser (e.g., speech-based). Concerns
expressed by AT developers that using the DOM requires "subgrouping" (more
than one interface). 

RS: (More detailed discussion of AT/Browser communication techniques to
improve performance). This launch-in my-process-space design will work in
Unix. 

JG: Will we provide, in techniques document, examples of how to expose
information? How on different platforms? 

AG: I think DOM WG avoids this issue due to politics. If we can get an
example from Rich (a scenario, even if technology-specific) you might
extract a technology-neutral checkpoint. I can see a checkpoint to provide
"timely" access to information. (E.g., going through the COMM is too slow). 

RR: The way I'm looking at this is that browser vendors need to enable AT
tools to get information. E.g., some vendors try to parse and cache the
entire document before processing. But starting a second thread improves
user experience. Our goal is to enable that and other techniques. 

LW: Taking RS's Java example as a possible techniques is a good idea. Also
look at the Automation part of COMM. It's probably interesting to look at
for techniques. 

AG: Is this the same interface as Office Automation? 

LW: Yes. RR: Formerly known as OLE Automation. 

LW: Softquad is implementing on Automation interface. 

RR: There are other methods besides COMM that AT vendors might want to use.
I'm exploring how this can be done in IE today. 

ACTION RR: Write a description of how a browser could expose its internal
object model to other processes including the ability to run a module of
the AT to run in the process. DEADLINE: One week. 

IJ: Can we make a statement as we do in 7.2.2? If you do what DOM does,
conform to DOM. How do we say this? 

AL: Everthing is built on top of DOM core. 

IJ: DOM may not be a strict subset. 

AL: Why not say "Do DOM"? You can add stuff on top. 

RS: Our goal is to make Web browsers accessible. 100% compliance with the
DOM doesn't guarantee accessible. 

AG: I think that 7.2.2 is a red-herring. Someone will have to implement DOM
core to be useful. You must have a DOM-centric view - you build on top of
DOM. 

JG: To Rob and Mark. What do you think about 7.2.2 (conforming to DOM
interfaces). 

MH: I agree with 7.2.2 as stated. Not sure that stated effectively, but we
want this functionality. 

RR: As 7.2.2 reads currently, sounds sensible. 

LW: Have you discussed what part of the DOM they don't want to implement? 

JG: We've talked about the information included by DOM that needs to be
made available. LW: Perhaps there's some misinterpretation of the DOM. 

DP: My impression is that development community has its own current and
future strategies that include only parts of DOM. Want that to occur
without leading to interoperability problems. 

LW: You would need to identify DOM subsets. 

IJ: Not for the UA WG to do. 

LW: To comply with DOM, you have to implement all of the fundamental
interfaces and at least one HTML extension. DOM 2 is split into more
modules. You must implement core and the rest are optional. 

HB: "Cooked" vs. "Original" versions. Some browsers may only provide cooked
stuff. Is this accurate? LW: E.g., if your XML parser rips out comments,
then the Comment Interface is useless since there aren't any. We don't
define what the "cooking" is. DOM acts on the browsers internal
implementation, which a priori the DOM doesn't know about. 

HB: I raise this issue since ATs want to assume a certain amount of
cooking/non-cooking. 

LW: Not possible with DOM spec, but UA Guidelines could specify this. 

AG: I'm concerned that 7.2.1 is too broad. 

/* Export programmatic interfaces to ATs and follow operating system
conventions to do so (e.g., Microsoft Active Accessibility, Sun
Microsystems Java Accessibility) */ 

RR: I'm concerned if this is left out. 

AG: To make this checkpoint verifiable, it would be too broad. I think
there are critical methods that must be listed explicitly. The user needs
to be able to monitor and control the browser process. They need to be able
to through that through the exported interface. This is too broad for a
checkpoint, but could be part of rationale for a guideline. PROPOSED
GUIDELINE: (former 7.2.1) Checkpoints would list methods/information to be
exported. [E.g., survey what's there and produce a summary from that
information.] E.g., for rules: form submits must be confirmed - classifying
actions. 

JG: Timeliness could be a checkpoint. 

DP: Where does that leave 7.2.2. 

MN: I'm not so sure that the ATs should expect anything less than other
developers. Access to DOM should be standardized. It's a pain to special
case. PROPOSED: Say specifically for 7.2.2 that DOM core is a minimum. So,
7.2.2 as written does not promote interoperability. 

MH: I agree. 

RS: I agree. 

JG: Screen reader people think that looking at object models is
special-casing. They's rather see MS AA improved so that they don't have to
subset. 

CMN: The problem is one of the UA charter. We are required to address
what's necessary for user agents, but don't have the scope for generic
software interfaces. 

RS: Today, ATs are using a lot of different interfaces to access
applications. E.g., Windows - they'd like to have a standard interface
(e.g., MS AA), but there's so much legacy software, they rely a lot on
offscreen models. I don't think that we should use the old technology for
doing something better. We're talking about Web access, but if we have a
good model, they will prefer this in the long run. 

DP: This doesn't prohibit ATs from using whatever techniques they want. I
would emphasize building on DOM as much as possible. 

RR: I think that given our core goal, the current checkpoints are
sufficient. We do need to know what information is required. Applications
should support platform-specific accessibility interfaces. These are just
as important as DOM to enable accessibility. 

LW: These are different parts of a large problem : DOM is not more
important than MS AA or vice versa. 

RR: Don't implement either badly. 

LW: Smaller companies can't implement everything at once, but over time,
the goal is to implement all. 

RS: Since we are talking about direct access to DOM: what about multithread
access? Is that a DOM issue? 

LW: It should be in the DOM, but we are not tackling it yet. 

AG: We will need to identify fragements (XML fragments). Multithreading in
general will be more important then. 

RS: We will also have to deal with multiple threads changing data. Need
locking mechanism. 

LW: Coming from a small vendor, being told you need to do MS AA and DOM is
one thing. Doing multithreading on top is another ball of wax. 

IJ: How to submit requirements? 

LW: HTML CG 

AL: Write a requirements document and send through HTML CG. 

/* Lauren and Arnaud go to DOM call. Jim leaves. Mark Hakkinen leaves. */ 

JG: (Looking for resolution on 7.2.1 and 7.2.2). I'm concerned that if we
break up 7.2.1, the checkpoints may become dated. Also concerned that the
WG doesn't have resources to pursue this in detail. 

MN: I like 7.2.1. I would suggest removing the two examples, however. We're
already dating ourselves by listing these examples. I think 7.2.1 is fine
as is as long as the Techniques are good. For 7.2.2, want baseline DOM. 

DP: It's the only non-proprietary standard we have. PROPOSED: Use DOM's
conformance statement. 

RR: The absolute is that we need to provide the information and that we
need to be consistent. Going beyond that is unnecessary. 

IJ: W3C promotes interoperability through its specs. 

DP: MS AA doesn't provide accessibility for Unix. 

MN: Proposed: Support DOM and MS AA (or another way). In other words,
ensure DOM at least, allow other means. 

JG: From the standpoint of the guidelines, the consensus is that if we say
you have to do something, there needs to be an accessibility reason for it.
The techniques should talk about what information must be made available
and what interfaces are available for that. 

AG: It seems to me that the Priority 1 requirement is to expose the
information. Any information that is presented to the user in a built-in
visual UA - or - to which it responds programmatically, needs to be
exposed. For content types pertinent to DOM, must use DOM. 

IJ: How is this different from today's 7.2.2? 

AG: Doesn't address scripts. For info in a document that is not covered by
a W3C spec (e.g., scripts), still need to make that information available
to ATs. Or BLINK. A UA doesn't have to provide what it ignores. If it uses
it in any way, it must make it available to ATs. 

RR: Whether a browser happens to throw out comments, does this impact
accessibility. 

CMN: If you hide the comments so that an AT can't get at them, you affect
what can be done with them. In a UA, I need to get at the source, not just
what's rendered. 

DP: If I'm an AT user, I want an application to provide the same
information it would to a non-AT user. 

RR: Using the script example -if a UA does not use SCRIPT, it can throw it
out. 

CMN: I disagree. I use an external image viewer with Lynx. Lynx should
still provide access to the images. 

MN: I think this is an implementation issue... 

CMN: Lynx + braille display is a common scenario. If Lynx doesn't handle a
script but it's important, you should be able to plug in a javascript
interpreter. 

IJ: Always parsed info, not always rendered. 

/* Summarizing */ 

JG: Are 7.2.1 and 7.2.2 sufficient for guidelines? a) Who wants DOM to be a
minimum expressed in 7.2.2: RR: no, since not required for accessibility.
CMN, MN, DP: yes. 

DP: Would be helpful to name the accessibility portions of DOM. CMN: That
would satisfy me. 

MN: I don't like that idea. Not so easy. I want everything in the tree at
all times. --- 

Al: does 7.2.2 belong in 7.1 instead? 

CMN: structurally perhaps, but developers seem to want it said explicitly. 

RR: Identify list of things that AT vendors need and say that there are
multiple ways to get that information. I'd like to understand the
information that's required and examine my product to find out what we're
not exposing. 

ACTION RR: Rewrite 7.2.2 as you want it (centered around information). 

ACTION CMN: Rewrite 7.2.2 the way CMN would like to see it. 

ACTION AG: Turn 7.2.1 into a guideline with checkpoint. 

COMMENTS from BORIUS:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0341.html 

ACTION Ian: Discuss comments with Judy Brewer and Jon Gunderson

IAN: Should the document going to TR take into account recent decisions? 

CMN: I don't think so. 

HB: I think that we should take into account WG comments. 

IJ: I don't have time. 

Resolved: Ian will publish WD without modifications due to intervening WG
decisions. /* Adjourned 13:36 ET */


Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
	http://www.als.uiuc.edu/InfoTechAccess

Received on Tuesday, 6 April 1999 12:33:45 UTC