Conversation
|
Do we want to clear |
|
@DataTriny Can you please add a comment in the winit examples explaining the reason for the announcement delay? |
mwcampbell
left a comment
mwcampbell
left a comment
There was a problem hiding this comment.
This is a good, thorough implementation of phase 1. The delay isn't ideal, but the better solution, if there is one, isn't obvious, so I won't block on that.
| } | ||
|
|
||
| pub(crate) fn from_cg_point(view: &UIView, node: &Node, point: CGPoint) -> Point { | ||
| let local_point = unsafe { view.convertPoint_fromView(point, None) }; |
There was a problem hiding this comment.
The coordinate conversion uses convertPoint_fromView(point, None) / convertRect_toView(rect, None), which converts to/from window coordinates. accessibilityFrame is expected to return screen coordinates. On fullscreen iPhone apps these are the same, but on iPad with Split View the window doesn't fill the screen, so VoiceOver could get incorrect element positions.
You should be able to use this to convert to screen space:
https://developer.apple.com/documentation/uikit/uiaccessibility/converttoscreencoordinates(_:in:)-9ziiu
There was a problem hiding this comment.
Also, we might not need to handle safe area here. If a view's frame is within the safe area, then we'd want the accessibilityFrame to match the view's frame exactly.
There was a problem hiding this comment.
I went back and forth on how to handle the safe area. Ultimately I think you're right, the adapter should not guess it. This adds a bit more complexity to our examples but that's really something every iOS app would have to do anyway.
|
I am happy with the current state of this pull request. I am going to merge this tomorrow if there are no objections. |
|
Actually I noticed that VoiceOver takes way more time to focus the first node of an AccessKit app than it does for a stock app. I want to see if this is related to the adapter initialization being fully dependent on VoiceOver making the first query. |
|
It is indeed very slow (~1.5-2 seconds) to wait for VoiceOver to perform its first query on a view. I have implemented essentially what Flutter does: observe the ATs and check their current state as soon as possible to decide whether to activate the adapter. With that infrastructure in place we can support deactivation. The old path is kept for third-party ATs. The examples had to be modified again because we weren't applying the scale factor. This caused obvious positionning issues on landscape orientation. As a bonus they now demonstrate the good pattern of applying a transform to the root. |
3 participants
Phase 1 of #565
Implements the adapter for iOS and other Apple systems that use the UIKit runtime.
The adapter comes in two flavours: a low-level adapter suitable when the user owns the UIView and a subclassing adapter useful when integrating with third-party libraries that don't let the user manipulate the UIView, such as winit.
This first version is able to expose simple widgets like labels, buttons, checkboxes, switches, sliders... Live regions are also supported.
Necessary infrastructure is in place to run tests on a simulator, the CI is modified to take advantage of this and run the unit tests.
accesskit_winit now use the iOS subclassing adapter on appropriate targets. The examples have been modified and can be used to manually test the adapter.
The Slint toolkit is already compatible and its Gallery example can be used for further manual testing, although issues in its layout make VoiceOver refuse to focus certain widgets. Please use this branch where the AccessKit crates are patched.
Editable text is not yet implemented and focusing such a widget can confuse VoiceOver, depending on how the view is set up.