Re: Custom Control with AXSlider Role
Re: Custom Control with AXSlider Role
- Subject: Re: Custom Control with AXSlider Role
- From: James Dempsey <email@hidden>
- Date: Mon, 9 Mar 2009 19:36:25 -0700
On Mar 9, 2009, at 6:32 PM, Chris Suter wrote:
Hi James,
Thanks for your response.
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".
You could also use the value defined in AXValueConstants.h
kAXUnknownOrientationValue. The circular sliders in Cocoa do not
report this orientation in Leopard, but it is what would be correct
for them to report.
I forgot that was a publicly defined constant in Leopard. Note that
AXOrientation is a required attribute of an AXSlider, and although
VoiceOver may not complain, it isn't the only assistive application
that uses the API.
But also remember for a VoiceOver user, they will be building up a
conceptual model of the this control. Presenting it as a vertical
list of horizontal sliders is not a bad mental model to present.
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.
Great - although we can't make any comments about what issues might be
fixed, or when, we definitely find good bug reports very useful.
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.
It depends on what you do.
The accessibility information you set in IB on a control is associated
with the cell of that control. (For controls with one cell, the cell
is the accessibility element, its control is ignored by accessibility).
If you programmatically create a new cell and set it for the text
field, then it won't have the accessibility information you set in IB.
You can set both the text field subclass and the text field cell
subclass in IB 3, in which case the accessibility information you set
in IB should work.
-James
--------------------------------------------------
James Dempsey
AppKit Engineering
Apple
email@hidden
_______________________________________________
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