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

[Sergey Bylokhov]

On Thu, 19 Nov 2020 04:20:58 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 140:
>> 
>>> 138: // Please see https://developer.apple.com/documentation/appkit/nsaccessibilityprotocol
>>> 139: // for more details.
>>> 140: @interface CommonComponentAccessibility : JavaComponentAccessibility <NSAccessibilityElement> {
>> 
>> I remember we had a plan to implement this step by step, replacing the parts of the old API with some new parts.
>> 
>> If the plan still in place then why we do not implement `NSAccessibilityElement` in the `JavaComponentAccessibility ` class, so the usage of current (old) methods like `accessibilityPositionAttribute/accessibilitySizeAttribute/accessibilityFocusedAttribute` could be replaced by the new methods from the NSAccessibilityElement protocol like accessibilityParent/accessibilityFrame/isAccessibilityFocused.
>> 
>> If we plan to implement it from scratch then why the CommonComponentAccessibility extends JavaComponentAccessibility?
>> 
>> It is not obvious from the change since the `accessibilityFrame()` is implemented from scratch mostly duplicate `accessibilityPositionAttribute+accessibilitySizeAttribute`, but the `accessibilityParent()` uses the code from the `JavaComponentAccessibility `
>
> Implementing it step by step is exactly why i did it - if i make JavaComponentAccessibility implementing the NSAccessibilityElement it triggers mac os to stop using the old property based API on all of it and we are not ready for that. I'm planning to keep CommonComponentAccessibility implementation minimal so once all of our bases are covered we can just swap JavaComponentAccessibility to implementing NSAccessibilityElement and switching all the subcomponent's peers to extend it and then we will be able to drop CommonComponentAccessibility altogether (or just leave it so we can swap to older API easier for comparison testing).

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/

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

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