Re: Making children of StaticText accessible
Re: Making children of StaticText accessible
- Subject: Re: Making children of StaticText accessible
- From: Christiaan Hofman <email@hidden>
- Date: Tue, 22 Apr 2008 01:01:55 +0200
On 22 Apr 2008, at 12:39 AM, Mike Engber wrote:
On Apr 21, 2008, at 11:01 AM, Christiaan Hofman wrote:
The problem is that VoiceOver simply ignores any children I return,
because the view's role is StaticText, and that usually has no
children (so apparently VoiceOver and perhaps other assistive
devices assume it *never* has children).
It sounds like you're saying that you have an NSView subclass that
already is already accessorized like a NSTextView - except for
links? (If so, good job!)
I didn't, Apple did.
It also sounds like you're saying you've already figured out how to
successfully add the links in as children (which should have
required overriding a fair amount of the accessibility protocol?)
At least some objects that have AXLink as role (or whatever is
appropriate for the child object). But I may not have implemented
everything that could be done. Also, Link is not included in the list
of standard roles and attributes in the Accessibility Overview
Appendix B. I think I will file a documentation bug on that.
Is the only issue that assistive apps often ignore children of
StaticText? I can't say I'm surprised. But, that's really a matter
for the assistive apps to deal with, not you.
That's my main problem now, yes. But saying it's NMP would be like
giving up.
Anyway, I think I already found a ay to do that, by changing the role
of the view to AXGroup and adding a child that's just a proxy calling
the non-overridden implementations of the view.
As for the main text, it already implements full support for the
(parametrized) attributes for StaticText. This is also the reason
why I cannot change the role to Group, because I really don't want
to reimplement this (as this is a huge task, as you say).
You don't necessarily have to take this existing class and try to
remake it into a group. You could create an enclosing view (e.g. a
group) whose children are this existing class plus the children
you're adding.
No, I can't, as I have no control over the view hierarchy. I don't set
it up, I just get it as it is.
That doesn't sound like a great solution to me. But, if you're
absolutely determined to "force" assistive apps to pay attention to
your children it might be the only way to make it happen.
I think it's also likely that someone from the VoiceOver team would
have something (negative) to say about using a non-standard
accessibility hierarchy in order coerce as certain behavior from
VoiceOver.
-ME
Maybe, but it seems the only way to accomplish what I want. And a
flawed solution is always better than nothing. Anyway, I don't thin k
my solution really gives a non-standard accessibility hierarchy. But
it uses some dirty tricks to get it done, given that it's not my own
objects I'm patching.
Christiaan
_______________________________________________
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