Re: Persistency of accessibilityActionNames
Re: Persistency of accessibilityActionNames
- Subject: Re: Persistency of accessibilityActionNames
- From: Victor Tsaran <email@hidden>
- Date: Sun, 22 Dec 2013 00:34:35 -0800
Marco.
Have you ever received any response from Josh on this?
Asking, because I haven’t seen anything. :)
Happy holidays!
Victor
On Oct 29, 2013, at 9:48 PM, Marco Zehe <email@hidden> wrote:
> Hi Josh,
>
> please provide the pointer to the sample code! I got a question recently on how actions can be exposed to VoiceOver, and this would really help!
>
> Thanks!
>
> Marco
>
> Am 30.10.2013 um 05:21 schrieb Josh Scotland <email@hidden>:
>
>> Hi Ilya,
>>
>>> The question is what additional steps do I need to do to tell an older system that list of actions is changed?
>>
>> You shouldn’t need to do anything additional to have the system (AppKit) see the new list of actions. You can verify that your list of actions isn’t static by looking at the element in Accessibility Inspector after each state change. If the list of actions are changing, but VoiceOver isn’t seeing the new list, then it’s a VoiceOver bug.
>>
>>> More precisly, in default state my control looks like a button. Once clicked ui is changed to alternate, in which the conrol looks li search field and have 3 actions: receive some input, cancel and clear.
>>
>> If you’re having trouble doing this, remember that there are three action methods you should keep in sync:
>> 1. accessibilityActionNames - returns the list (array) of actions. In your case, each state will return something different
>> 2. accessibilityActionDescription - returns a user description of each action
>> 3. accessibilityPerformAction - performs the action that has been requested
>>
>> I can point you to some sample code if this isn’t clear.
>>
>> On Oct 28, 2013, at 11:12 PM, Ilya Kulakov <email@hidden> wrote:
>>
>>> Hi Josh,
>>>
>>> Thank you for the answer.
>>> It's clear that in 10.9 a control will be re-asked for list of actions after a user performed alternate ui action.
>>> The question is what additional steps do I need to do to tell an older system that list of actions is changed?
>>>
>>> More precisly, in default state my control looks like a button. Once clicked ui is changed to alternate, in which the conrol looks li search field and have 3 actions: receive some input, cancel and clear.
>>>
>>> Best regards,
>>>
>>> Ilya Kulakov
>>> From my iPhone
>>>
>>> 29.10.2013, в 12:07, Josh Scotland <email@hidden> написал(а):
>>>
>>>> Hey Ilya,
>>>>
>>>>> Can UI element return different actions for accessibilityActionNames the same element?
>>>> Yes, depending on the state of the element, it can have different actions and associated action names.
>>>>
>>>> This is exactly how the new ‘alternate UI’ actions work. When the element is in the default (shown) state, it’ll have the ‘hide’ action. When the element is in the alternate (hidden) state, it’ll have the ‘show’ action. Check out this year’s WWDC for sample code.
>>>>
>>>> Having different actions depending on state should work for 10.8 and 10.7. 10.9 just adds the NSAccessibilityShowAlternateUIAction and NSAccessibilityShowDefaultUIAction constants.
>>>>
>>>>
>>>> Aside: If you’re testing with VO, on 10.9 you can pull up the custom actions menu by doing VO+command+space on the element. This will have a list of all your actions. On 10.8 and 10.7, I think you pull it up with VO+command+enter.
>>>>
>>>> On Oct 25, 2013, at 12:01 PM, Ilya Kulakov <email@hidden> wrote:
>>>>
>>>>> Can UI element return different actions for accessibilityActionNames the same element?
>>>>>
>>>>> E.g. element may have multiple states. In one state it can only be pressed (show alternate UI action on 10.9) in another state it can receive cancel and delete actions. Should accessibilityActionNames return different actions depending on state or it should return list of all supported actions?
>>>>>
>>>>> I’m primarily interested in behaviour under 10.9, but will very appreciate if you add note regarding 10.8 and 10.7
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Ilya Kulakov
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
>
> _______________________________________________
> 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