Re: Custom text fields not working with VoiceOver.
Re: Custom text fields not working with VoiceOver.
- Subject: Re: Custom text fields not working with VoiceOver.
- From: David Tseng <email@hidden>
- Date: Wed, 27 Apr 2011 14:27:20 -0700
That did the trick. The missing attribute
NSAccessibilityStringForRange is the minimum necessary to get things
behaving properly (also returning nil for all other parameterized text
attributes). What had been deceptive had been VoiceOver reading *one*
of the characters and being able to echo through arrowed keys without
these attributes.
Thanks for the help!
On 4/27/11, Chris Fleizach <email@hidden> wrote:
> I suspect your problem is that you're not supporting any of the
> parameterized attributes
>
> Specifically
>
> #define kAXLineForIndexParameterizedAttribute CFSTR("AXLineForIndex")
> #define kAXRangeForLineParameterizedAttribute
> CFSTR("AXRangeForLine")
> #define kAXStringForRangeParameterizedAttribute
> CFSTR("AXStringForRange")
> #define
> kAXRangeForPositionParameterizedAttribute CFSTR("AXRangeForPosition")
> #define kAXRangeForIndexParameterizedAttribute CFSTR("AXRangeForIndex")
> #define kAXBoundsForRangeParameterizedAttribute CFSTR("AXBoundsForRange")
> #define kAXRTFForRangeParameterizedAttribute CFSTR("AXRTFForRange")
> #define kAXAttributedStringForRangeParameterizedAttribute
> CFSTR("AXAttributedStringForRange")
> #define
> kAXStyleRangeForIndexParameterizedAttribute CFSTR("AXStyleRangeForIndex")
>
> You'll see that WebCore objects implement most of these
>
> This is probably the most important
>
> #define kAXStringForRangeParameterizedAttribute
> CFSTR("AXStringForRange")
>
>
> On Apr 27, 2011, at 1:25 AM, Dominic Mazzoni wrote:
>
>> 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.zip
>>
>>> Also 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
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden