On Tue, Apr 26, 2011 at 2:21 PM, Chris Fleizach <
email@hidden> wrote:
Where's the latest chrome that can test this?
This version demonstrates the problem:
http://build.chromium.org/f/chromium/snapshots/Mac/77250/chrome-mac.zipAlso what is the AXFocusedUIElement that the AXApplication returns? it should be the object that has focus. If not, you might have trouble.
Just checked, it returns the AXTextField.
The only relevant-sounding attributes we're not implementing now are
AXStartTextMarker, AXEndTextMarker, and AXSelectedTextMarkerRange. Is
it possible to implement these without using wkCreateAXTextMarker
(which appears to be a private API that we can't access)?
These are not used in text fields, so that should not matter.
Oh good, thanks.
One other thing I'm noticing is that VoiceOver is not browsing
Chrome's contents like it's web content. If I change the role of the
main container from AXWebArea to something else, it behaves
identically in VoiceOver. Most content other than editable text boxes
is perfectly accessible, but it behaves as if the content was in a
generic (non-web) app, where something like a list is hierarchical,
rather than like in Safari, where by default a list is announced first
and then browsed linearly.
What is the bundle identifier for chrome that's being used? Safari is treated specially. Chrome might need to be as well.
com.google.Chrome or org.chromium.Chromium. I tried changing the
bundle identifier to com.apple.Safari and didn't see an obvious
difference, but I'll play around with it some more.
If necessary, I guess we'd like VoiceOver to treat Chrome specially,
though of course it'd be even better if there was an API for any
potential web browser to use. Isn't Firefox making progress on Mac
accessibility?
Thanks!
- Dominic