Re: Custom Control with AXSlider Role
Re: Custom Control with AXSlider Role
- Subject: Re: Custom Control with AXSlider Role
- From: Chris Suter <email@hidden>
- Date: Tue, 10 Mar 2009 12:32:05 +1100
Hi James,
Thanks for your response.
On Tue, Mar 10, 2009 at 12:01 PM, James Dempsey <email@hidden> wrote:
> Those functions/methods are not documented because they are not public.
> Like any use of private functions/methods, there is the risk that your app
> will break in some fashion with a future release of the operating system.
I realise that, but I didn't want the hassle of making them NSView
derivatives. WebKit also uses those methods so you've got some
incentive not to change them. We can also push out updates to our
applications pretty quickly (within a day or so) and I don't think we
have many customers that need it. Anyway, my point is that it's a risk
we're willing to take.
> That is probably because VoiceOver is not expecting an AXSlider to change
> size or position when its value changes, since that is not how AXSliders
> typically behave.
I must say it seems slightly odd when there are moved and resized notifications.
> One thing that might get the behavior you are looking for is to post the
> NSAccessibilityFocusedUIElementChanged notification for the slice element
> after it is resized. I believe this will cause VoiceOver to refocus on the
> same element again, and fetch its new size and position.
I'm sure I tried that and I just tried it again. It doesn't look like
that works.
> In the end, an AXList of AXSliders is not ideal to represent a pie chart
> with adjustable slices, but given the current set of AX roles, it is
> probably the best fit.
Yes, that was the conclusion I came to.
> Every time we introduce a new role, it is another kind of element that
> assistive applications need to update to include, and assistive app users,
> such as VoiceOver users, need to learn about how to interact with a new type
> of element. So, it's always a balance between where we define as a role and
> where we use existing roles in somewhat different ways than their original
> intent.
I don't think there's a need for a new role. I think the slider role
is fineāit just needs tweaking a bit. The obvious way you could fix it
would be to add a third orientation value, e.g. not applicable or
circular perhaps.
> Since these elements are reporting themselves as sliders, VoiceOver is going
> to treat them like sliders, and sliders have an orientation.
Well, I reminded myself the other day that you do actually have a
circular slider. I haven't checked to see how that behaves.
> Remember that
> a VoiceOver user is going to understand this control as a list of sliders,
> since that is what it is described as. Pick an orientation for the list
> (AXVerticalOrientation maybe) and one for the sliders
> (AXHorizontalOrientation, maybe), and that is probably the best way to go.
It doesn't seem to complain if I omit the attribute which is what I've
done for now. It's just annoying to hear VoiceOver insert the words
"horizontal" or "vertical".
> Definitely file a bug requesting roles for chart elements, they may be
> common enough elements to warrant a set of roles and attributes.
I've filed a whole bunch of bug reports for these issues. As I say, I
think tweaking the slider role would be better for us rather than
adding a new role.
BTW: there's one other bug that I reported that others might want to
be aware of: the accessibility title that you set in IB doesn't work
for NSTextField subclasses. At least for this, there's an easy enough
workaround.
Regards,
Chris
_______________________________________________
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