W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2000

Re: LC#127: How to verify 5.7 (Provide programmatic exchange of information in a timely manner.)?

From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
Date: Tue, 25 Jan 2000 09:06:46 -0600
Message-Id: <4.1.20000125084356.019e1820@staff.uiuc.edu>
To: Charles McCathieNevile <charles@w3.org>
Cc: w3c-wai-ua@w3.org
Charles,
The original intent was to insure the use plateform specific standards that
promote the fastest possible exchange of information as possible.  The main
techniques currently known to the group that needs to be highlighted in the
techniques document is the capability of loading the AT and the User Agent
into shared address space.  IE allows this through at least the creation of
Browser Helper objects and I think there are other techniques available
that could be documented.  We need to move all or at least part of the
contents of Appendix 5 to be the techniques for examples of how to satisfy
Checkpoint 5.5.

There was never any discussion by the group of having a "stop"/"start" user
agent functionality for this checkpoint.  Unless there are some established
or demonstrable practices to show how this helps the exchange of
information I don't think group should consider this functionality as a
techniques at this time. 

Jon


At 08:30 PM 1/24/00 -0500, Charles McCathieNevile wrote:
>I discussed this further with some mebers of the IE team today. It is not
>clear what timely means, but my interpretation is that the exchange of
>information needs to keep pace with changes in the content, to the externt
>that a user can configure a user agent to pause transitions of (for example)
>focus, selection, or URI being rendered in order to allow their Assistive
>technology to render it completely according to their needs. If the User
>Agent's APIs provide the information sugfficiently fast the AT or the network
>itself will always be the limiting factor in the speed at which the user can
>navigate or browse. (If not, the user agent is unlikely to sell a lot of
>copies...)
>
>I am not sure how the user agent or assistive technolohgy communicates whren
>to pause. But it seems clear that while the intent of this checkpoint seems
>appropriate, it needs to be more clearly verifiable.
>
>Charles McCN
>
>On Mon, 24 Jan 2000, Jon Gunderson wrote:
>
>  Charles,
>  1. I am not sure what a "stop" means prgrammatically to a user agent, do
>  you have an example of a technology that does this?   
>  
>  2. How does an assistive technology know when it should use this "stop"
>  function and how does it know when it should "start" the user agent again?
>  
>  Jon
>  
>  
>  At 07:41 PM 1/22/00 -0500, Charles McCathieNevile wrote:
>  >I think the question is to make sure that there isn't a sequence of actions
>  >performed before the Assistive Technology catches up that result in the
user
>  >missing out on something that happened. SHould this be ahchieved by
allowing
>  >a stop to be put on actions of the user agent by an Assistive
technology? By
>  >blocking an input method while something is waiting? I think this makes it
>  >easier to verify the requirement (and I think the feature needs an off
>  >switch, although I suspect that is a lower priority).
>  >
>  >Charles McCN
>  >
>  >On Fri, 21 Jan 2000, mark novak wrote:
>  >
>  >  hi Jon:
>  >  
>  >  At 4:47 PM 1/19/00, Jon Gunderson wrote:
>  >  >I propose that we discuss this in the techniques document related to
this
>  >  >checkpoint.  Probably the easiest thing to do is to state programming
>  >  >examples on major plateforms that would be acceptable.
>  >  >
>  >  >Some technique issues:
>  >  >1. In process versus out of process access
>  >  >2. Microsoft COM technologies
>  >  >3. COBRA technologies
>  >  >4. Mac???
>  >  >5. UNIX???
>  >  >
>  >  >I think we will need some programming specialists to help fill out this
>  >  >list.  Maybe Rich Schwerdtfeger and Mark Novak could help out and maybe
>  >  >talking to some of the people in the Amaya team.
>  >  
>  >  
>  >  I noted this was still a "continued" action item from yesterday's UA mtg
>  >  (thursday), so I thought I'd try to toss out some ideas on this issue.
>  >  
>  >  Let me start by saying I fully agree that we must have timely access
>  >  to the exchange of information.  What I stumble on, is how to "verify"
>  >  the timely wording.
>  >  
>  >  First, without checking the list archives, I know this issue of "timely
>  >  access" has been around for a long time.  As I recall, this was a
question
>  >  which repeatedly was not satisfied when people were doing evaluaitons of
>  >  the early guidelines against current browsers.  Interestingly enough,
>  >  when I asked those reviewers what criteria they used for making this
>  >  statement, I heard everything from "no response"  to "well, so and so
>  >  said it was".  In other words, nothing quantitative.  This doesn't
>  >  surprise me.  I would expect that we each have a different concept
>  >  of what "timely" access would be.  Some of us may describe this
>  >  as "immediate" while others may have a perfectly usable UA/AT
>  >  that allowed a few seconds to lapse.  I don't think anyone knows what the
>  >  correct "value" might be that constitutes "timely", thus I'm concerned
>  of how
>  >  we will "verify" this.
>  >  
>  >  I know the system responds much faster (information exchange), when
>  switching
>  >  from an out-of process application which used COM to access the
>  >  IE DOM as compared to an in-process application which used COM (e.g.,
>  >  also referred to as a browser helper object [BHO]).  I also recall Rich
>  >  sent to the list some similar results they had quantified while testing
>  >  at IBM.   The technology used to access the information which needs to
>  >  be exchanged, can be done in any number of methods.  Some of these
methods
>  >  you have listed above, of which these and others are already in the
>  >  Techniques DOC, in Appendix 5.  AT developers will have to choose
>  >  which "method" best matches the needs of their technology and users, and
>  >  yes, there will be trade-offs in timeliness, robustness, reliability,
>  >  etc., for which again, I'd expect the AT and perhaps the UA developers
>  >  to understand and work with.  I think what is important in all this is
>  >  that there "is" a way to get the information exchanged, and provided
>  >  a AT or UA developer use the most current technology available for
>  >  the platform(s) they wish to support, then they have probably given
>  >  the user "timely" access.  If not, then I suspect the product won't
>  >  survive, since the users won't be satisfied and thus will or should go
>  >  somewhere else for a solution (I realize this isn't always possible).
>  >  
>  >  Can we do better than this to"verify" timely access.  Perhaps.  The
>  >  one other thought I had was to provide a "reference" design, maybe
>  >  as part of the Techniques DOC., or better yet as a tool off the ER page.
>  >  What I'm envisioning the "reference" design would be, is a fully
>  >  functional prototype that when run on a "very specific" platform
>  >  and operating system, would demonstrate the "timely" response to
>  >  making whatever information we deem necessary which shows how a
>  >  UA/AT ought to respond.  Then at least the UA group could say to 
>developers,
>  >  this "reference" design demonstrates what we feel is necessary.
>  >  
>  >  Before everyone decides this is a good idea, realize this will take a
>  >  considerable amount of work, and we would still have to "quantify" timely
>  >  access, and what information we'd exchange/show and many other
>  >  details, messy details.  ;)
>  >  
>  >  Anyway, just my quick thoughts.
>  >  
>  >  Regards
>  >  
>  >  Mark
>  >  
>  >  PS:  Note, there already exits in the Techniques DOC., a URL for
>  >  a BHO example, under Appendix 5 also.
>  >  
>  >  
>  >
>  >--
>  >Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 
>136
>  >W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>  >21 Mitchell Street, Footscray, VIC 3011,  Australia 
>  
>  Jon Gunderson, Ph.D., ATP
>  Coordinator of Assistive Communication and Information Technology
>  Chair, W3C WAI User Agent Working Group
>  Division of Rehabilitation - Education Services
>  College of Applied Life Studies
>  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
>  WWW: http://www.w3.org/wai/ua
>  
>  
>
>--
>Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
>W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>21 Mitchell Street, Footscray, VIC 3011,  Australia 

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
College of Applied Life Studies
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
WWW: http://www.w3.org/wai/ua
Received on Tuesday, 25 January 2000 10:09:02 GMT

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