<AWT Dev> RFR: 8256108: Create implementation for NSAccessibilityElement protocol peer [v2]

[Sergey Bylokhov]

On Thu, 19 Nov 2020 07:09:33 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Then it does not look like as step by step implementation, it just adding the code which does not necessarily work properly. Are you sure that the implementation of NSAccessibilityElement will block the old for all roles not only for the elemental role? It will be useful if we start to use the new accessibilityFrame/etc API instead of accessibilityPositionAttribute/etc attributes, but still, use the old attributes for other roles.
>> 
>> If the plan is to make the CommonComponentAccessibility as small as possible then the CommonComponentAccessibility.accessibilityFrame could be implemented on top of accessibilityPositionAttribute+accessibilitySizeAttribute or another way around, similar to accessibilityParent which is implemented via accessibilityParentAttribute. But in this case, the whole class will have 5 rows which are never executed? Probably it is possible to mix old/new?
>> 
>>> 
>> Note
>> 
>>> The new, method-based accessibility API is backward compatible with the previous, key-based API. This means, if you have controls that are already accessible, you can continue to use them. You can even convert a control to the method-based API in stages, implementing the new method-based API for some features, leaving others in the key-based API.
>> 
>>> If there’s a conflict between the method- and key-based APIs, the method-based API takes precedence. This is particularly important for frameworks that provides accessible controls. If you convert those controls to the method-based API, the system ignores any legacy code that modifies their attributes. For this reason, if you create third-party libraries, you may want to wait to upgrade your library until you’re sure that all your clients have updated their apps.
>> https://developer.apple.com/library/archive/documentation/Accessibility/Conceptual/AccessibilityMacOSX/
>
> It is step by step implementation since the component peers will inherit these functions and they will be called once we initialize these peers. It will be clear once you see simple peer like pushbutton peer implementation. And yes - i tested - once system detects that peer implement new protocol it stops calling the property retrieving methods giving out "unrecognized selector sent to instance" errors for not implemented functions.

So do you plan to return different a11y components depends on the type of the role? So for the old API, you will return JavaComponentAccessibility and for the new, you will return ButtonAccessibility which will extend CommonComponentAccessibility and implement NSAccessibilityButton, etc? WIll it work?

BTW don't you need to implement isAccessibilityFocused to cover old accessibilityFocusedAttribute?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1290