Re: Accessibility Issues with NSPopover (MacOS)
Re: Accessibility Issues with NSPopover (MacOS)
- Subject: Re: Accessibility Issues with NSPopover (MacOS)
- From: Jimgreen8 <email@hidden>
- Date: Mon, 21 May 2012 18:26:19 +0800
Sent from my iPhone
On May 21, 2012, at 3:30, Motti Shneor <email@hidden> wrote:
> Hello Patti Hoa and Eric Schlegel. Many thanks for your input. At least I know I'm not
>
> I will sure follow Eric's recommendation to file 2 bugs on NSPopover ( "no way to programmatically put keyboard focus on an NSPopover" and "no API available to access initialFirstResponder or other attributes of a popover's window"), but mind you, these are the "regular user" issues.
>
> I agree that "ideally" a popover should be dismissed when it loses its focus. But according to Apple's own guidelines --- there are 3 models for NSPopover (transient, semi-transient and application-defined).
>
> Having a popover open for several minutes, showing progress or incoming info for something, is not only common, but an Apple standard put-to-use in many Apple applications. Are Safari's downloads popover and iCal's inspector such "extreme" use of popovers?
>
> Currently, a VoiceOver user cannot be even hinted that some information is waiting there, and he has to GUESS that there is something somewhere, and use the VO-F2-F2 to look for lost windows. I am pretty sure this is not what Accessibility is about.
>
> Also, If a popover is considered to be an extension of its "anchor" view, why isn't there an accessible way to go from the anchor view/control directly into its contents --- i.e. the NSPopover? When I have VoiceOver focus on my Toolbar icon, that the user used to open the popover, there is no way to see (hear?) that there is a popover attached to it, or to jump somehow from the toolbar button to the NSPopover.
>
> However, when I press VO-F2-F2, VoiceOver will generously say that I have a popover attached to my toolbar-item! I consider this incomplete behavior, even if I agree with your basic assumptions (transient popovers and a popover being an extension to its anchor view).
>
> Usually, if one is willing to put in some work, Accessibility object (AX???????) can be customized and re-programmed to solve specific issues. But here, I could simply find nothing at all.
>
> Our product-guys insist on their UI decisions (semi-transient popovers), as they serve the vast majority of users well. However, our accessibility level is severely reduced. Have I known the level of accessibility support in NSPopover, I would program our own Popover implementation, without the use of it.
>
> On 17/05/2012, at 20:40, Patti Hoa wrote:
>
>>
>> On May 17, 2012, at 2:30 AM, Motti Shneor wrote:
>>
>>> 1. When NSPopover is first shown, VoiceOver will only report the CONTENTS of the popover (it will say: "3 items") never any title or any other attribute of the popover. if i hit VO-F2-F2 ("Window List" command) The popover is rightly named in the list. However, the help-tag I set on the popover remains null.
>>
>> That is the output behavior of VoiceOver, not controllable by the application. If you think VoiceOver should speak something else, file a radar bug and specify what other information the user should hear.
>>
>>> 2. Once my Semi-Transient popover loses user-focus (user clicks on the main window), I can never set it back on the popover. I need to do this programmatically, because focus can be lost after another dialog (sheet) pops on the main window following remote server message.
>>>
>>> The accessibility user who lost the focus can have very hard time to find it, and sometimes he doesn't even have a chance to know that this popover even exists onscreen.
>>
>> Ideally if another dialog gains keyboard focus, the popover should get dismissed. If you can detect that and programmatically dismiss the popover, that may be the workaround for now. Otherwise, VO user can only get back to the popover via control-option-F2-F2.
>>
>>>
>>> 3. As NSPopover manages its internal window in a very-opaque way, and I can't find a way THAT WORKS to set up the "initialFirstResponder" for it, or its window title, or any accessibility attributes on the popover's internal window.
>>
>> Why would you want to set accessibility attributes on the popover's internal window? To VoiceOver, a popover is simply treated like a child of the element that triggered it. Accessibility clients really should not know or care about how the NSPopover was constructed (via window or such).
>>
>>>
>>> 4. I failed to set up accessibility link from any view/control in my application to the popover. There must be some symbolic way to reach it! or to regain focus on it, after focus was lost.
>>
>> Perhaps control-option-shift-j can jump back and forth between popover and triggering window, like what it already does for word suggestion bubble and input methods. If it doesn't do that for popover right now, please file an enhancement bug for VoiceOver. You won't need to explicitly set up accessibility link then.
>>
>
>
> Thanks again ---
>
> Motti Shneor, Mac OS X Software Architect & Team Leader
> Spectrum Reflections Ltd.
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Accessibility-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden