- From: James Craig <jcraig@apple.com>
- Date: Wed, 12 Sep 2012 14:19:25 -0700
- To: Greg Kraus <greg_kraus@ncsu.edu>
- Cc: Joshue O Connor <joshue.oconnor@cfit.ie>, "Schnabel, Stefan" <stefan.schnabel@sap.com>, Alexander Surkov <surkov.alexander@gmail.com>, Steve Faulkner <faulkner.steve@gmail.com>, W3C WAI-XTECH <wai-xtech@w3.org>, Richard Schwerdtfeger <schwer@us.ibm.com>, Marco Zehe <marco.zehe@googlemail.com>, James Teh <jamie@nvaccess.org>
On Sep 12, 2012, at 1:51 PM, Greg Kraus <greg_kraus@ncsu.edu> wrote: > That minimal test case was just to demonstrate the problem. Here is a > more robust implementation where I first discovered the problem. > > http://accessibility.oit.ncsu.edu/training/aria/modal-window/ > > This is still a work in progress, but the behavior in IE is there. Yes, that example works well with Safari and VoiceOver, too. The only bit I can see in your functional example that doesn't work is the events you're tracking on the "close dialog" link/button. For whatever reason, it's not accepting an AXPress (which in WebKit is more or less equivalent to 'mousedown/mouseup/click'). Is it possibly you're rejecting certain mouse or click events when capturing your specific key events? Also, your keycodes are catching Enter but not Spacebar, which is the HI-recommended keyboard activation for activating focused elements like buttons on OS X. Cheers, James
Received on Wednesday, 12 September 2012 21:19:48 UTC