- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 15 Feb 2001 11:11:56 -0600
- To: Jon Gunderson <jongund@uiuc.edu>
- Cc: w3c-wai-ua@w3.org
Jon, >Can you tell us if there is any interest or plans in the HPR group to >implement this type of functionality? I would prefer to not talk about plans if I don't have to. Attached is the code to do what you want in IE. Is this adequate? Rich Rich Schwerdtfeger Senior Technical Staff Member IBM Accessibility Center Research Division EMail/web: schwer@us.ibm.com "Two roads diverged in a wood, and I - I took the one less traveled by, and that has made all the difference.", Frost ---------------------- Forwarded by Richard Schwerdtfeger/Austin/IBM on 02/15/2001 09:41 AM --------------------------- Tom Brunet 02/14/2001 04:17 PM To: Richard Schwerdtfeger/Austin/IBM@IBMUS cc: From: Tom Brunet/Austin/IBM@IBMUS Subject: Re: Mouse activate JavaScript (Document link: Richard Schwerdtfeger) If I understand the question right.. This would use the same method that we used for onchange events. I have included the code from CNodeSelector::InvokeScriptEvent below. Calling node.InvokeScriptEvent ("onmouseover") would execute the javascript code on that node. I don't particularly remember the details of how everything fits together exactly.. I remember that it was mostly a matter of trial and error to get it to work. Tom bool CNodeSelector::InvokeScriptEvent(CString strEvent) const { HRESULT hr; // Note: For more JS invocation see pg 1158 of Programming Windows with MFC BSTR bstr = strEvent.AllocSysString(); DISPID dispid; hr = GetDomNode()->GetIDsOfNames(IID_NULL,&bstr,1,::GetUserDefaultLCID (),&dispid); SysFreeString(bstr); if (!SUCCEEDED(hr)) throw CDomException(__FILE__,__LINE__); // No parameters DISPPARAMS params = { NULL,NULL,0,0 }; hr = GetDomNode()->Invoke( dispid, // The dispID retrieved IID_NULL, // Documentation requires IID_NULL ::GetUserDefaultLCID(), // ### DISPATCH_METHOD, ¶ms, NULL, // ignore the return val NULL, // and exceptions NULL); // and this too // Note: If there isn't a strEvent on this node, the Invoke will NOT succeed. return SUCCEEDED(hr); } Richard Schwerdtfeger 02/14/2001 01:53 PM To: Kip Harris/Austin/IBM@IBMUS cc: Tom Brunet/Austin/IBM@IBMUS, Pete Brunet/Austin/IBM@IBMUS From: Richard Schwerdtfeger/Austin/IBM@IBMUS Subject: Re: Mouse activate JavaScript (Document link: Tom Brunet) Thanks Kip. I will pass off to the W3C working group. Rich Rich Schwerdtfeger Senior Technical Staff Member IBM Accessibility Center Research Division EMail/web: schwer@us.ibm.com "Two roads diverged in a wood, and I - I took the one less traveled by, and that has made all the difference.", Frost Kip Harris 02/14/2001 11:15 AM To: Richard Schwerdtfeger/Austin/IBM@IBMUS cc: Tom Brunet/Austin/IBM@IBMUS, Pete Brunet/Austin/IBM@IBMUS From: Kip Harris/Austin/IBM@IBMUS Subject: Re: Mouse activate JavaScript (Document link: Richard Schwerdtfeger) Rich, I played around with this for about a half hour and wasn't able to get to the bottom of this. My gut sense is that it is possible, though not straightforward. Although we can automate clicks on a page element, it doesn't cause the javascript stuff to get invoked. I think we could probably do this by the approach you suggest, that is, obtaining the javascript method and figuring out how to invoke the script interpreter to process it. Kip Harris IBM Accessibility Center Voice: 512-838-9902, IBM Tie 678-9902; Fax: 512-838-0070 Internet: hkip@us.ibm.com Richard Schwerdtfeger 02/13/2001 01:28 PM To: Tom Brunet/Austin/IBM@IBMUS, Kip Harris/Austin/IBM@IBMUS cc: Pete Brunet/Austin/IBM@IBMUS From: Richard Schwerdtfeger/Austin/IBM@IBMUS Subject: Mouse activate JavaScript Tom and/or Kip, Question: Does HPR have the ability to activate JavaScript atteched to an element that responds to html 1.0 device dependent events? Examples are onclick, onmouseover. From the attached it would seem not. If the reason is no is it because IE does not provide a function to do so? If I were to research this I'd assume IE would do so through some sort of object activation mechanism, a function provided by IE requiring a DOM associated CDATA JavaScript block, or even better an event activation scheme such as a method to fire an event on an element. The reason I as is the the W3C WAI User Agents group is determining whether it should be priority 1 requirement to have a user agent support activation of device dependent event activation. To do this we would have to show a prior implementation. Note: in another WAI working group I am involved in I am trying to get rid of device dependent events and make them device independent. Rich Rich Schwerdtfeger Senior Technical Staff Member IBM Accessibility Center Research Division EMail/web: schwer@us.ibm.com "Two roads diverged in a wood, and I - I took the one less traveled by, and that has made all the difference.", Frost ---------------------- Forwarded by Richard Schwerdtfeger/Austin/IBM on 02/13/2001 01:17 PM --------------------------- From: Pete Brunet on 02/13/2001 10:40 AM To: Richard Schwerdtfeger/Austin/IBM@IBMUS cc: From: Pete Brunet/Austin/IBM@IBMUS Subject: Rendering invisible drop-downs on Microsoft.com Rich, This is somewhat related to the mouseover question you asked last week. Hopefully Tom or Kip got in touch with you about the mouseover question you asked. Pete ===== Pete Brunet -- IBM Accessibility Center, 11400 Burnet Road, MS 9151, Austin, TX 78758 voice (512) 838-4594, TL 678-4594, fax (512) 838-2212, brunet@us.ibm.com, http://www.ibm.com/able, ws4g ---------------------- Forwarded by Pete Brunet/Austin/IBM on 02/13/2001 10:39 AM --------------------------- Kip Harris 02/13/2001 09:54 AM To: thatch@attglobal.net cc: Catherine Laws/Austin/IBM@IBMUS, Pete Brunet/Austin/IBM@IBMUS From: Kip Harris/Austin/IBM@IBMUS Subject: Rendering invisible drop-downs on Microsoft.com Importance: Normal Regarding drop-down boxes that appear on www.microsoft.com on mouseover. We're not doing anything intelligent here, and in this case, perhaps it works a little to our advantage. The links in the drop-down boxes that activate on mouseovers are actually present at all times in the DOM, even when they are not visible. HPR doesn't do anything with visibility attribututes, so we just render them. I suspect the mouseover events just flip a visibility attribute. Also, we don't do anything to figure out where they (the mouseover drop-down's) should appear in the document, we just render them where we find them. Kip Harris IBM Accessibility Center Voice: 512-838-9902, IBM Tie 678-9902; Fax: 512-838-0070 Internet: hkip@us.ibm.com Jim Thatcher <thatch@attglobal.net> on 02/12/2001 03:59:24 PM Please respond to thatch@attglobal.net To: Kip Harris/Austin/IBM@IBMUS cc: Catherine Laws/Austin/IBM@IBMUS, Pete Brunet/Austin/IBM@IBMUS Subject: Hi Kip, I have a question that relates to how HPR sees content that has been rendered to an internal frame (I believe) by JavaScript and is not visible. On http://www.microsoft.com all the links in mouseover dropdown menus are listed by HPR between the last visible menu item (msn.com) and the Search dialog. These links are, of course, not visible. My question is do you do anything special so that HPR sees those links? If it isn't special, do you know what you do in HPR that screen readers don't do to cause those links to be seen? Jim jim@jimthatcher.com Accessibility Consulting http://jimthatcher.com 512-306-0931
Received on Thursday, 15 February 2001 12:12:22 UTC