Full Keyboard Access support for custom MKAnnotationView in MKMapView

Question

FrancescoCanciani OP

Created 2d

Replies 3

Boosts 0

Participants 3

We’re working on improving the accessibility of a MKMapView that displays custom MKAnnotationView instances.

Our implementation is fully accessible with VoiceOver:

The custom annotation views expose the correct accessibility information.
Users can navigate between annotations using custom accessibility rotors.
The overall VoiceOver experience works as expected.

However, we’re unable to make the custom MKAnnotationView instances accessible through Full Keyboard Access (FKA).

Despite configuring the annotation views as accessibility elements and experimenting with focus-related APIs, the annotations never become reachable through keyboard navigation. They appear to be skipped entirely by the FKA focus system.

Is there a supported way to make custom MKAnnotationView instances participate in Full Keyboard Access navigation?

If this scenario is currently unsupported, is there a recommended approach or any plans to expose public APIs that would allow developers to provide a keyboard-accessible experience for custom annotations in MKMapView?

Any guidance would be greatly appreciated.

Answer 1

Engineer OP

Apple

2d

Keyboard focus is driven by canBecomeFocused so if you override that or accessibilityRespondsToUserInteraction then FKA should be able to find your elements.

Answer 2

FrancescoCanciani OP

1d

Thanks for the reply, but we already tried that and nothing changes.

Looks that the issue is only related to MKAnnotationView, because the rest of our app is working properly using accessibilityRespondsToUserInteraction.

Any other possible solution?

Answer 3

vattanak OP

16h

Dear Apple Support Team, I am writing to report a long-standing issue affecting Khmer (Cambodia) text recognition in Live Text and the Vision Framework OCR. Based on my testing, this issue has persisted for more than two years—from iOS 17 through iOS 27 Beta 3—and is also reproducible on iPadOS and macOS. I would appreciate clarification on the following points:

Is Apple aware of an issue where Live Text incorrectly recognizes Khmer script as Thai script, causing copied text to output as Thai characters instead of Khmer?
Has this issue been officially logged as a bug within the Vision Framework or Live Text teams?
Since this behavior has remained reproducible since iOS 17, why has it not yet been resolved?
Is the problem caused by automatic language detection, the OCR recognition model, the Vision Framework, or another component of Apple's AI pipeline?
Does Apple currently have a dedicated OCR and language recognition model for the Khmer script, or is Khmer being inferred through another language model?
Is there an estimated timeline for improving Khmer OCR and preventing Khmer text from being misidentified as Thai?
Can Apple confirm whether this issue affects all products using the Vision Framework, including Live Text, Photos Preview, Screenshot OCR, and APIs provided to third-party developers?
How can Apple work with the Khmer technology community to improve OCR accuracy and language support for Cambodia?

This issue is more than a simple OCR bug. When Khmer text is automatically converted into Thai characters, users lose access to the original text, developers receive incorrect OCR output, and it negatively impacts the digital representation of the Khmer language. For reference, I have documented the issue in detail here: https://app.notion.com/p/Inaccurate-OCR-Language-Inference-Khmer-Script-Misidentified-as-Thai-in-Vision-Framework-2d8a24f4ee6680fcbc49d989f8bb606f I hope Apple will investigate this issue and prioritize improving Khmer language support across the Vision Framework and Live Text. Thank you, Vattanak Khun