On Thu, 19 Nov 2020 07:09:33 GMT, Alexander Zuev <kiz...@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
