Normally, VoiceOver
correctly reads web contents loaded with WKWebView
and it is possible to read buttons and links.
However, when I added WKWebView
on UITableViewCell
and displayed in UITableVIew
, VoiceOver
could not recognize it.
According to the tableview document of apple, in order to make each content on UITableViewCell
recognized by VoiceOver
separately,
It is necessary to set isAccessibilityElement
of cell to false and set isAccessibilityElement
of view to be recognized to be true.
but if isAccesibilityElement
ofWKWebView
is set to true, view itself is focused and we can not recognize the inside web contents.
Also, when VoiceOver
was enabled for the first time after loading the Web content, it performed strange behavior that Web content could be recognized.
I suspected the problem of VoiceOver
content recognition timing, I tried running
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil)
or
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil)
after loading the web content, but it did not get a good result.
Is there a good way to handle contents in wkwebview
on tableView
to VoiceOver
?
So, I'll explain the behavior you're seeing. Essentially, VoiceOver will only focus the first accessibility element in a tree. So any view that is an Accessibility Element will not have its children that are accessibility elements be focused.
Now as for your situation, I'm curious as to your scenario. I find it likely that you need to provide more detail. When I picture a tableview, I picture multiple WKWebViews in one view, which would be weird indeed.
The typical markup for a webview would be to just have NOTHING set as an accessibility element, and let the WebView determine which elements within are accessible. WKWebView should take care of reporting HTML content as proper native accessibility elements for you. To do anything else is going to corrupt what WKWebView is going. HOWEVER, if you have multiple webviews in one app, this may muck things up. Ultimately, if it didn't work the way I outlined (just by leaving things alone, and marking everything as "not" an accessibility element), this would be a bug, but a bug that you would have to deal with.
The solution THEN becomes overriding the UIAccessibilityContainer protocol for your webview, and providing custom feedback for it. Not ideal, would be painful. More details would help, but at least now you can understand a little more about what is going on.
Another simple solution would be, if the content in your webview is very simple, you could set accessibility element to true, and provide a description of the content for the entire webview through the accessibilityLabel, accessibilityValue and accessibilityTraits. Just be sure you catch all of the information, and that any actions are still actionable!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With