Re: inaccessible treeviews and tables

Hello,
I did some experiments what revealed some more questions.
I have found out the treeview in question contains only one column and 
that's rendered using the cell renderer.
So I guess when my overridden render() method is called on the cell 
renderer, I should be able to create a empty atk object, set it name, 
description etc . However what I am unable to figure out is how to 
connect that atk object to the tree column widget.
Originally I assumed I will be able to retrieve the proper atk object by 
calling gtk_get_accessible passing the tree column widget however in 
this case I only receive its parent atk object and unfortunatelly that's 
not what I am looking for.
Please note I am not creating my own atk implementation I am using 
existing objects I just need to find a way on how to make it connect 
together.
Or am I completelly missunderstanding how this is all implemented? Does 
what I am trying to explain here make some sense to anyone please?
Is this kind of discussion tolerated here or is there a better place for 
this type of questions please?

Thanks and greetings

Peter


On 05.07.2014 18:20, Peter Vágner wrote:
> Hello,
> A while ago I was trying to get some understanding on how to make 3rt 
> party gtk apps accessible. At that time Alejandro Piñeiro pointed me 
> to some docs and bugzilla entries describing the current situation.
> Unfortunatelly I haven't still mastered that. I have at least realized 
> and hopefully understood at least some verry basic things related to 
> this.
> For example currently I am able to set accessible labels and I am able 
> to add / tweak relations between labels and the interactive controls 
> they are supposed to label. I know this is not a big deal but I have 
> already tweaked an app or two this way and I know it works fine.
> Another thing what's currently on my radar are widgets that are often 
> reported as tables or treeviews. Individual rows appear to be keyboard 
> focusable however orca is unable to report their role and text.
> I guess the common scenario is that the app developers tend to 
> subclass Gtk.CellRenderer to create more visually appealing design. In 
> this case if I understand correctly the content is directly drawn to 
> the widget surface and proper accessibility related properties are 
> skipped from the implementation entirely.
> By reading gtk reference docs I have came accross a method 
> gtk_cell_renderer_class_set_accessible_type () . That appears to be 
> only info I was able to find related to Gtk.CellRenderer and 
> accessibility. Can anyone please give me a hint so I might try move 
> forward and try learning how to implement accessibility for a widget 
> where Gtk.CellRenderer is used?
> Do I need to care about Gtk.CellRenderer or should I just set 
> accessibility related properties such as label and description for the 
> affected widgets without looking at Gtk.CellRenderer? How do I refer 
> to multiple treeview colums or table cells in such implementation? Is 
> there an app or just a code example I should look into to see this in 
> action?
> I have seen widgets with incomplete accessibility like this in many 
> apps but if my explanation is not accurate enough here are two from 
> the top of my head. One is the list of torrents in the 
> transmission-gtk svn://svn.transmissionbt.com/Transmission/trunk and 
> the other is a contact list widget in a gtk3 based tox client called 
> venom https://github.com/naxuroqa/Venom .
> I will be looking into this some more, it may take me a while like it 
> took me ages to figure out and get used to labelling and related stuff 
> so I am just trying maybe with some hint I might master it better this 
> time.
>
> Thanks
>
> Peter
>

_______________________________________________
gnome-accessibility-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list