Re: Accessibility problems with subviews in table cell
Re: Accessibility problems with subviews in table cell
- Subject: Re: Accessibility problems with subviews in table cell
- From: James Dempsey <email@hidden>
- Date: Tue, 30 Sep 2008 18:14:00 -0700
Craig,
On Sep 30, 2008, at 2:46 PM, Craig Hockenberry wrote:
I've been attempting to make my app (Twitterrific) more accessible
for blind
users: I've gotten a fair amount of support mail asking for it, so I
dove
into the Accessibility APIs last week (i.e. I'm a total noob.)
Great! We'll help as best we can.
The overwhelming majority of these users want to hear the text in
each row
in the table read aloud with VoiceOver as they use the arrow keys to
navigate.
I'm using Joar Wingfoars SubviewTableViewController in the
application. It
places an NSView into a table cell, allowing for a more complex UI
in each
table row.
Well, for someone just getting started, you've dived straight into one
of the more complex areas of accessibility in Cocoa.
Unfortunately you can't do what you are describing–table views in
Cocoa don't support accessibility subelements in cells. This is for
numerous reasons. One of the biggest reasons being is that unlike
most controls, table views reuse the same cell repeatedly for each row
in a column. On the other hand, the accessibility API is very much
geared towards each reported element being backed by a unique object,
and therefore a lot of complexity behind the scenes making it work
which does not lend itself to extensibility.
That said, there's definitely things you can do to improve the
experience for VoiceOver users, within the current limitations.
Looking at the app UI on your site, I'm guessing VoiceOver speaks the
name of the person but not the message itself (which obviously is a
most important part). It also looks like there are three buttons
available for the selected table.
I'm also hoping that the text fields in the table view are not
editable by the user (that makes things much easier). It looks like
the cell that you use is already reporting itself as an AXTextField, I
would suggest overridding -accessibiltyAttributeName: and return a
different value for AXValue. I'd suggest returning both the name of
the person, as well as the message as the value, separated by a
newline, as if the row contained a single text field with two lines of
text. This is definitely a workaround, but would give a user the
essential information in the row.
For the three buttons also in that row, again we can't expose them as
separate UI elements at present. If the actions of those buttons
could also be triggered by a menu/keyboard command when a row is
selected, that would make the functionality usable, even though the
buttons are not exposed.
-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