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: Craig Hockenberry <email@hidden>
- Date: Fri, 03 Oct 2008 10:17:38 -0700
- Thread-topic: Accessibility problems with subviews in table cell
>> 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.
Yep, I heard good things about this list from James Craig :-)
>> 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.
Thanks for confirming my suspicions :-)
> 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.
VoiceOver currently just says "unknown" -- I'm guessing that's because the
table view row doesn't see into the row's subview.
I'm not too concerned about the buttons in the view. They're essentially
shortcuts for items available through menus or the keyboard.
> 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.
The only reason I used an editable text field in the sample was because I
wanted to get different text to be spoken while experimenting. In the
product, the text that I will be using comes from a non-editable
NSTextField.
I tried your suggestion of making the subview row return AXTextField with an
AXValue and it does workaround the problem well. I'll need to change the
code a bit so that the views have an accessor for the text that needs to be
vocalized, but that shouldn't be too hard.
> 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.
Agreed. One of the things I'm hearing from the blind users is that they love
the keyboard access in the application -- which isn't surprising since I
designed it for my own keyboard-centric use :-) I suspect that hearing
what's written in each view will solve their problems.
I'll put together a beta with these changes and run it by some users. Thanks
for all your help!
-ch
_______________________________________________
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