On Thu, 19 Nov 2020 09:20:51 GMT, Alexander Zuev <kiz...@openjdk.org> wrote:
>> 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? > >> 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? > > Yes. That's the way. I mean - that's the plan. I already tested it on couple > of components and it works just fine. > >> BTW don't you need to implement isAccessibilityFocused to cover old >> accessibilityFocusedAttribute? > > Not right now. I'm trying to do the minimal implementation and so far in my > testing i haven't found that anyone calls that selector under any > circumstances. OTOH the current implementation is in no way a complete one > and selectors will be added during the component peers implementation phase. > I'm trying to reuse as much code from the original class as possible but for > streamlining purposes if there's no corresponding function i can use i am > writing this function as a new one, because i do not want to modify the > behavior of the existing functions. This should streamline the last merge in > this feature which should be a general cleanup of the existing code and > removal of unused functions and refactoring of the used ones to the new API. Ok, let's see how it will work. ------------- PR: https://git.openjdk.java.net/jdk/pull/1290
