W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 1999

MINUTES: WAI User Agent Telecon 14 April 1999

From: Jon Gunderson <jongund@staff.uiuc.edu>
Date: Thu, 15 Apr 1999 01:12:44 -0500
Message-Id: <199904141811.NAA13191@staff1.cso.uiuc.edu>
To: w3c-wai-ua@w3.org
Attendance
Chair: Jon Gunderson

Scribe: Ian Jacobs

Harvey Bingham
Rich Schwerdtfeger (RS)
Kitch Barnicle 
Al Gilman 
Marja Koivunen 
Charles McCathieNevile 
Jim Allan

Regrets
Mark Novak


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

Completed Action Items
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.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0036.html 

Editors: Integrate checklist subgrouping into next working draft based on
JRGs proposal
(http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0254.html),
individual comments can be sent to the list for discussion

RS: Write a proposal for the Techniques Document for loading an assistive
technology for direct access to the browsers DOM.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0022.html 

AG: Turn 7.2.1 into a guideline with checkpoint.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0003.html 

CMN: Rewrite 7.2.2 the way CMN would like to see it.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0031.html 

CMN: Write a proposal to address different navigation functionalities.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0034.html 

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

IJ: Write Danny Weitzner to find out of ecommerce folks (fee links) have
requirements on UAs. 

IJ: Write Danny Weitzner an email about this. ii) Resolved: Make 6.1.11 a
priority 2. Agenda Item 3) Navigation/Search Functionality review. Refer to
list of checkpoints in the agenda [1] that involve navigation and searching. 

Editors: Add Cross link in 5.2.4 (and 5.2.6) to 7.3.3. 

New Action Items 
JG: Revise proposal on sectin 7.2 and send it to the group for continued
discussion

Announcements
Good luck to Kitch on her dissertation defense!!!


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

Minutes
RS: Looks like MS is already doing what I had suggested. My concern:
re-entry issue with DOM. 

JG: Is this something we need at a checkpoint level "Provide a means to
automatically load assistive technology with the user agent." 

RS: Yes, I think this should be a checkpoint. And we have a technique for
doing so. See my note [1] [1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0038.html 

AG: The key thing is that it's in the same address space with direct access
to the DOM. 

IJ: This seems techniquey to me. What's the functionality desired? 

RS: Auto-loading is good since any UA that comes along can load the AT with
it. 

KB: And if the AT has already been loaded? 

RS: The AT I'm talking about is almost distributed - you provide access to
legacy systems (direct access for them). 

AG: Two programs communicating - if they're not linked to load in the same
address space, there's a severe performance hit. 

KB: "Load" here means a piece of AT gets loaded into the same address space. 

AG: Like a placenta... 

IJ: Where's this interface defined? What's the functionality? 

AG: Performance requirement. Sounds techniquey, but scenario of dynamic
linking is cross-os. 

RS: The issue is primarily one of performance. 

JG: Propose changing "interface to DOM" to "high-performance interface to
DOM". 

IJ: This is the first time that performance has been raised to the level of
checkpoint. 

AG: Yes, but it's a show-stopper. P3 or P2. 

MK: Is there a UI in the user agent for specifying which AT you use,
whether you want it loaded directly? 

/* Rich reads from his email to the group */ 

AG: What if we turn it around and say that latency between the AT and the
document object is controlled? 

RS: Ok. 

JG: We need to address this issue in the document. Sense that this is a
potential checkpoint. NO RESOLUTION about exactly where to add this
performance information (separate checkpoint? existing checkpoint?) However
CONSENSUS that we need to talk about timely access to the document object
model by ATs. 

RS: Do we need to allow an AT to "register" with a UA? 

JG: Put that in techniques document. --------- Making 7.2.1 its own
Guideline. 

AG: Make this a guideline. 

Checkpoints: 1) Read document info: P1 

2) Originate any UA action about the document: P1 

3) Use conventions to do so: P2 

4) Use W3C approach where applicable: P3. 

AG: I think John's draft is responsive to my proposal [2] But, e.g., only
visual is mentioned but shouldn't be singled out. [2]
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0037.html 

/* John reads [2] */ 

RS: For 7.2.c, add technique Java Accessibility API. 

RS: For 7.2.e, where would we put monitoring carat movement? 

JG: Wouldn't that be the focus? 

KB: Is this for UAs or ATs? 

AG: UA must allow AT to do this. 

IJ: 7.2.a: What does "content rendered mean"? 

JG: That which is rendered on the screen. Addresses concerns of AT people.
Tension between AT developers who don't want to special case UAs. 

IJ: How do we refer to a standard interface for this case? 

JG: Just refer to existing conventions. 

RS: Some platforms don't have them. No access in XWindows to that
information. 

AG: There is an accessibility API in some version of X. 

JG: Also DAC-X. But no display-side stuff. 

RS: Are you assuming every platform has access to rendered content? 

JG: Not sure Mac has accessible API. But they have guidelines for building
accessible software. (Jon mentions a couple of companies as well). 

AG: Most basic requirement is to expose the info. Then, following
conventions. Then, follow W3C conventions. 

AG: Change "to content rendered on graphical displays:" to "information
presented to the user". 

7.2.d: Allow ATs to be alerted of changes in focus and selection 

7.2.x: Allow ATs to read the focus and selection 

7.2.x: Allow ATs to modify the focus and selection 

7.2.d: Allow ATs to be alerted of changes in events 

7.2.x: Allow ATs to simulate events. 

RS: DOM 2 lets you know when a document changes. 

Ian starts to reduce: Allow AT to: - be alerted to changes in: 

a) document tree 

b) user interface: selection, focus, carat 

c) rendered content

/* This one for screen readers who use accessibility API */ 

RS: I think they should implement the DOM. 

JG: Maybe in the future. 

AG: ATs want to know, e.g., that alt text is being displayed on the screen
while an image is downloading. If you have low vision, you use the display
but also want the AT to do more. 

IJ: In short, my understanding of the AT position is that you won't ensure
interoperability by just requiring the DOM. You need to ensure it through
other, lower-level interfaces as well. 

RS: This is not a UA requirement, but an OS requirement. 

JG: Required by UA developers to follow these things. 

CMN: If you use hardware-poking or special graphics routines, bypassing
standard mechanisms, ATs are lost. 

IJ: That sounds like a checkpoint to me: use standard, documented system
interfaces for everything: events, rendering. Proposed checkpoint: use
documented os interfaces to render content, handle events, etc. 

IJ: What about cursor coordinates? 

CMN: This is an implementation detail. On my cell phone, the cursor doesn't
exist. 

JA: Need to separate what's going on in the UA from what's going on in the
OS. 

KB: If you use standard controls, not particular to accessibility. If
everyone used standard controls, a lot of our points would be moot. Does
the UA only need to do one of these interfaces? 

RS: If you use MSAA, if you use standard controls, should be implemented on
those controls. 

IJ: My sense is that doing "standard controls" is not an interface burden
like DOM. So not exclusive. 

RS Proposes: For each platform, the UA must implement the accessibility API
on that platform for controls used. If the component already implements the
accessibility API, you're done. Otherwise, you have to implement it on your
custom component. Common controls are probably a technique. You need to
implement the accessibility API for controls. 

JG: a) Follow OS/platform guidelines for rendering and controls to make
applications accessible (Would replace 7.2.a)

b) In addition, expose the document object model. 

c) Implement the DOM 

RS: Platform developers have to document how to make software accessible.
MS does this, but I don't know where to find this for the Mac. - write a)
document tree b) user interface: selection, focus, carat c) events
(simulate keyboard input, mouse clicking) - Use W3C specs where applicable. 

ACTION Jon: Rewrite a proposal for these checkpoints. Regrets for next
week: Rich, Ian.


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


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 Wednesday, 14 April 1999 14:11:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:48:57 GMT