Re: MINUTES: W3C WAI User Agent 2 June 1999

hi all:

>ACTION: MN resources for x-windows exchanging information between
>applications and references for apple scripting

Per the teleconf. call action item above from Wednesday....


1.  info on Apple's scripting model can be found at:

http://developer.apple.com/technotes/tn/tn1095.html
http://developer.apple.com/technotes/tn/tn1164.html

and the best resource is of course, an Inside Macintosh chapter devoted
to: Interapplication Communication:

http://developer.apple.com/techpubs/mac/IAC/IAC-2.html



2.  info on X Windows apps. info exchange can be found at
a couple of places:

http://www.opengroup.org/
http://www.x.org/

there are a couple of protocols that should be mentioned regarding
inter client communication in X land.  Also, please keep in mind
that in X land, the idea/terminology of a client and server is reversed from
what you are used to thinking of in terms to the web.

there are at least two well known protocols, ICE and ICCCM,
and several lesser known protocols like RAP, K-edit, etc.

a. ICE, for inter-client exchange,  is a very low level protocol .


b.  ICCCM, for inter-client communication conventions manual
is a higher level protocol, and the spec. for ICCCM can be found at:

http://ftp.x.org/pub/R6.3/xc/doc/specs/ICCCM/


c.  RAP, for remote access protocol.  I used to have the direct URLs to RAP
at the X.ORG site, but they seemed to have changed.   Perhaps the best paper
to review both ICE and RAP, and how they work together is at:

http://trace.wisc.edu/docs/x_win_andice/x_andice.htm

RAP had alot in common with a protocol called EditRes2, and also
referred to as K-edit, which was spear headed by the BULL group out
of France.  I'm not sure if either version of these is in a formal X spec., but
I thought they were worth mentioning here.

How do these parts, ICE, ICCCM, RAP, etc., fit together?

ICE was meant to allow client-to-client communication.  RAP
is a protocol that is layered on top of ICE.  ICCCM comes into
all of this with the ICE X Rendezvous Protocol.  Before two
clients can talk to each other directly using ICE, they need
to learn about each other in some way.  Since RAP is meant
for use by X clients, the easiest way to make them aware of
each other (i.e., make them rendezvous) was to use ICCCM to
allow them to establish the ICE connection.  It's kind of
like a bootstrap mechanism.  RAP was designed to then work
with the "hooks" that were added to the underlying X libraries
for the transfer of accessibility related information, that
was also useful for such things as automated testing, verification
tools, etc., and thus fueling some of the renewed interest in RAP
development.

If anyone wants to dig into this more, we have lots of history
regarding access work in X at the trace web site, search
under DACX (disability action committee for X)



Another note regarding Wednesday's MTG minutes:

just to clarify some of what was discussed on COM.  There are several
pieces to the COM technology that Microsoft offers, and COM is not just
a Microsoft based technology.  In fact, if you visit the Mozilla site, and
review:

http://www.mozilla.org/docs/tplist/catFlow/extendmoz.html

you' ll discover that COM has roots in the Apollo's NCS System,
and was later developed by Digital and Microsoft as part of their
OLE/ActiveX architecture....wow!

Besides the COM implementation in Windows, there are other COM like
versions/platforms in development.  Again at the Mozilla site, there
is information on what they call XPCOM (cross platform COM).  At
the opengroup site, there is also info on what they call COMsource, an
open systems implementation of COM.  I've not searched extensively, but
I'd be willing to guess that there is some kind of COM development
underway for Apple as well, either from the MS side with their line of
Apple products or the MacOS X side.

how inter-compatible all these COM like technologies are or
will become, remains to be seen, but what I've read sounds very
encouraging...if anyone wants to discuss this further, please let
me know, either on or off the list.

i hope people find this information helpful.

enjoy

mark

At 2:10 PM 6/2/99, Jon Gunderson wrote:
>Minutes can also be found at:
>http://www.w3.org/WAI/UA/1999/06/wai-ua-telecon-19990602.html
>
>Attendance
>Chair: Jon Gunderson (JG)
>Scribe:Jim Allan (JA)
>Harvey Bingham (HB)
>Charles McCathieNevile (CMN)
>Mark Novak (MN)
>Denis Anson (DA, joined at 12:45 point)
>
>Regrets
>Ian Jacobs
>Rich Schwerdtfeger
>
>Completed Action Items
>JA: Check guidelines for information about tooltip control.
>JG: Techniques for 7.2.1.
>JG: Contact Peter Korn about techniques for java acessible design
>JG: Contact Rob Relyea about techniques for microsoft acessible design.
>MK: Propose navigation checkpoint to time-sensitive parts of a document.
>Review this issue in terms of stop/start/rewind/fast-forward checkpoints.
>IJ: Posting description of frame work to think about checkpoints and
>techniques
>Continued Action Items
>Editors: Incorporate resolutions into next draft of document.
>IJ: Write DJW about requirements T&S/WAI. Wrote thrice, no reply. Will
>follow up.
>IJ: Editorial action items
>CMN: Write techniques for 7.2.2 and 7.2.6 CMN deferred until publication of
>Note by Rich and Mark.
>JG: Techniques for 7.2.2.
>New Action Items
>MN: Post references to mechanisms that can be used for applications to
>exchange information for various operating systems: UNIX/X-Windows,
>Microsoft windows, Apple Macintosh and Java
>IJ: Implement proposal to simplify the guidelines, separate techniques from
>checkpoints, make checkpoints more global, move technichy checkpoints to
>technique document.
>IJ: Include specific navigation checkpoints for the following elements:
>forms, form controls, tables, in next draft
>Include checkpoint: Scripting events should be part of navigating to active
>content checkpoint
>Include checkpoint: Allow user to configure elements that are part of
>active contents
>Include checkpoint: Allow user to simulate event activator that an element
>could respond to
>Include checkpoint: Orient user to events an element can respond to
>Include checkpoint: Allow user to navigate to elements that can respond to
>events
>Include checkpoint:: Add checkpoint: turn on/off access key at priority 2
>level
>
>Minutes
>Opening statement by JG lack of participation by developers, Jaws folks,
>Webspeak folks, Ibm folks, MS folks perhaps have a special invitational
>telecon, if you have access to these people please encourage them to
>attend, what is happening at UA
>CMN: a problem here also, starting to participate regularly, Softquad
>reviews regularly
>JG: send ideas to Jon,
>Review of Open Action Items
>Editors: Incorporate resolutions into next draft of document.
>IJ: Write DJW about requirements T&S/WAI. Wrote thrice, no reply. Will
>follow up.
>IJ: Editorial action items
>CMN: Write techniques for 7.2.2 and 7.2.6 CMN deferred until publication of
>Note by Rich and Mark.
>JG: Techniques for 7.2.1.
>JG: Techniques for 7.2.2.
>JG: Contact Rob Relyea about techniques for Microsoft accessible design.
>JG: Contact Peter Korn for techniques related to Java accessible design.
>JA: Check guidelines for information about tooltip control.
>MK: Propose navigation checkpoint to time-sensitive parts of a document.
>Review this issue in terms of stop/start/rewind/fast-forward checkpoints.
>IJ: Posting description of frame work to think about checkpoints and
>techniques
>Discussion
>Ian's proposal for reformatting the guidelines and implications for
>checkpoints
>Scripting events (see last weeks minutes)
>JG: new draft on the way, sent Techniques for 7.2.1 to the list. who knows
>about x-window operating system and how it exchanges information between
>applications want to point to an existing resources for
>ACTION: MN resources for x-windows exchanging information between
>applications and references for apple scripting
>MN: COM covers this in windows
>JG: I will find pointers for windows maybe ask Peter Korn or Rich about
>Java resources
>MN: apple uses Apple Scripting
>JA: tooltips, spawning windows,
>editor: remove tooltip item from todo list
>JG: Maria - Propose navigation checkpoint to time-sensitive parts of a
>document. Review this issue in terms of stop/start/rewind/fast-forward
>checkpoints. (may 24 posting on list "time dependent items") ask lots of
>questions.
>editor: remove MK action item from list
>New business
>JG: Ian reviewing guidelines, especially about navigation guidelines
>currently have specific technique type recommendations as checkpoints these
>are useful if we are comparing user agents for accessibility talked about
>using GL for conformance Ian proposing to simplify, put technichy
>checkpoints in techniques, and make GL checkpoints more global JG responded
>with general suggestions-sequential access, searching, etc. would allow
>developers to create new techniques restructure doc checkpoint doc and
>technique doc, with links between
>CMN: like it
>JA: like it
>JG: allows innovation,
>HB: approves
>ACTION: IJ implement GL proposal, separate techniques from checkpoints,
>make checkpoints more global, move technichy checkpoints to technique
>document,
>JG: CP related to forms, links, etc, how global do we get, keep specifics
>for forms, tables, etc. useful guidelines to include nav to links, forms,
>tables,
>CMN: idea in head, may be different from Ian, need basic principals--get to
>various elements, specific requirements for elements and get a checkpoint
>because they are critical, important, or beneficial...i.e. anchors, forms
>JG: need some separate, forms, anchors is it useful to have these
>specifics, gave example about a poor page, need specific command like "move
>to next form control"
>CMN: need a new structure to document
>ACTION: Ian to include specific navigation checkpoints for the following
>elements: forms, form controls, tables, in next draft
>Scripting Events
>JG: scripting events are considered active content, should it be part of
>navigating to active content, with addition of user configurability--what
>do I want to nav to? user may have to nav to every element on a page. with
>separate commands for links and forms
>HB: possibility to put script on body, will you need to check every element
>JG: with event bubbling, then you would eventually arrive at top level,
>specific event handler, user doesn't know
>HB: these are controlled by event occurrence, rather than moving focus to it
>JG: UA could do this and provide keyboard access, mouseover may not be
>important. alternatives were
>1) separate checkpoint for nav scripting events - are they different from
>any other control?, thinks there are not differences functionally. longdesc
>needs a separate command.
>CMN: scripting are same as any other control
>JA: agree ms pull down example
>MN: devils advocate- ms site is good example of poor scripting, need script
>to use on focus, need to know what the event is going to be before you
>activate it.
>JG: explicit event handler, should nav to it. don't want to make people go
>to events that don't do anything,
>CMN: but if they can't go to the event
>HB: feed back from event is usually visual
>JG: ideally, use GL for device independence. won't need
>Dennis Anson joins
>JG: events are controls and handled as such, CP nav to active content,
>events should be part of this, other CP, nav to only elements with
>scripting events allow user to configure elements to navigate to simulate
>events, nav to element and expect something to happen but nothing happens
>DA: chuck opperman said it was difficult to determine what event was caused
>by what
>CMN: have to get to all events and turn things off
>JG: with event handler that bases events on occurrence of other event,
>bubbles up to main controller, if active web content, follow content
>guidelines, and application must be accessible not much concern about problem.
>ACTION:Include checkpoint: includes scripting events, responds to event,
>should be part of active content
>ACTION:Include checkpoint: Allow user to simulate event activator
>ACTION:Include checkpoint: Allow user to configure which elements are
>considered active content by the user
>ACTION:Include checkpoint: Orient user to operation of event, to what
>events the element responds
>JG: do we need separate CP - allow user to navigate to elements with
>scripting events
>HB: looking at ms page, (visac?),
>JG: skinner box, click anywhere and something will happen...
>DA: goal to make it possible to make all pages accessible
>JG: do we need separate CP - allow user to nav to elements with scripting
>events
>DA: to be consistent with other CP we should and make it p2
>HB: what is scope of scripts in head
>JG: code is in the head, elements do actual activation
>DA: are some onload scripts, that run when page loads
>JG: can scripts run in the head
>CMN: can execute in theory, proprietary, can run anywhere,
>JG: no user action to run script, user can't do anything except turn off
>scripts
>ACTION: Include a checkpoint to provide navigation to only the elements
>that can potentially respond to scripts
>CP allow user to nav to elements with scripting events
>CP allow user to simulate event activator
>CP orient user to operation of event, to what events the element responds
>JG: Ian's goal is to have new draft by Friday, not sure if possible.
>Accesskey feature
>JG: separate checkpoint, should be part of active content, consensus on
>line no need for specific cp.
>JA: explain how IE works with accesskey
>MN: problems with sticky key, changes os functioning for keyboard
>shortcuts, need a CP to turn off accesskey
>ACTION: Add checkpoint: turn on/off access key at p2
>MN: big usability problem with windows alt key
>DA: cognitive problem for users using alternate keyboard access, sticky keys,
>HB: issue raised - operability of more than one AT active at a time,
>accesskey could be a problem,
>JG: platform specific implementation issue, point to resources on how to
>make products more accessible.
>HB: send draft to developers after review and invite to attend meeting
>JG: silence does not mean agreement, want developer buy in.
>
>
>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 Thursday, 3 June 1999 10:49:17 UTC