GNOME Bugzilla – Bug 376015
[a11y] time-admin time servers table is not accessible.
Last modified: 2008-07-22 19:27:13 UTC
See also Orca bug #358467 (comments #21, #23-#25) for more details. With the time-admin application, if you click on the "Select Servers" button it brings up a table of time servers that you can synchronize with. Because this table contains table cells which in turn contain two more table cells, this renders them inaccessible to screen readers such as Orca. at-poke can't see them either. The list of messages in Evolution mail view has an accessible table and table cells. Perhaps you can check the code there to see how they did it.
Maybe the code of GailTreeView should be improved to take this into consideration? I may have a look at the code I'm thinking this because the table (and the one in users-admin) is just a plain GtkTreeView which happens to have 2 cell renderers inside one column, so the fix should be more generic
Maybe it should. Adding Padraig (a gail expert), for his thoughts on this.
This looks like a bug in gail so I am transferring it there. The strange thing is that there is code in gailtreeview.c to deal with the case when a column contains more than one cell renderer and that seems to be working as I would expect. Need to look further.
When you run at-poke click on Edit | Preferences. Unset the toggle don't poke at widgets marked private (MANAGES DESCENDANTS) The table has the state MANAGES_DESCENDANTS set and has about 60 children. This will allow at-poke to show the children of the table to be shown in at-poke. Trnasferring to orca.
We currently have code in the users-admin script (with the time-admin script mapped to it) that works around this "two table cells in a table cell" problem. Will, do we want to move this code up into _getBrailleRegionsForTableCell() and _getBrailleRegionsForTableCellRow() in braillegenerator.py and _getSpeechForTableCell() and in speechgenerator.py ?
Rich - until we get a good set of regression tests in place, I'm hesitant to bump this up to the more general speech and braille generators for fear that we might break something. However, if we end up pushing it up higher, we might make it a very specific fix along the lines of: If this table cell has 2 children and one of them is has a 'toggle' action and the other does not, then present this as a checkbox where: 1) we get the checked state from the cell with the 'toggle' action 2) we get the label from the other cell We have done very specific heuristics for other things, such as when we come across a panel or filler and want to see if it has a label. That check sees if the panel/filler has 2 children and one of them is a label that is not labelling anything. Kind of hacky, we need to do these kind of things when we find that kind of practice is popular in the wild. Will
> if we end up pushing it up higher, we might > make it a very specific fix along the lines of: > > If this table cell has 2 children and one of them is has a 'toggle' action and > the other does not, then present this as a checkbox where: > > 1) we get the checked state from the cell with the 'toggle' action > 2) we get the label from the other cell I'd say shoot for this fix to keep it relatively safe.
Created attachment 88766 [details] [review] Patch to implement the suggested fix in comment #7. Patch not committed yet. Please test.
(In reply to comment #8) > Created an attachment (id=88766) [edit] > Patch to implement the suggested fix in comment #7. > > Patch not committed yet. Please test. > The speech portion seems OK, but the braille portion seems to only show the label and not the check box. In addition, once the braille checkbox state is showing, it should be the first thing on the line and not the last thing on the line (which is what I think it might be doing now): BRAILLE LINE: 'time-admin Application Time servers Dialog ScrollPane Table ntp1.cmc.ec.gc.ca (Eastern Canada)' This doesn't look like a slam dunk. I put some debug in the code and it looks like it is returning the correct regions. So, it seems like whatever might be calling this might need further debugging. Thanks!
Created attachment 88815 [details] [review] Revised patch Revised patch does the following: 1/ Puts both the checkbox state and the label on the braille display (checkbox state first). The problem was in _getBrailleRegionsForTableCellRow(), where we needed to extend all of CellRegions rather then append CellRegion[0] if orca.settings.readTableCellRow was True. 2/ Don't speak the label if just the checkbox state has changed. Patch not committed yet. Please test.
This definitely looks much better. The only question I have is about why we were appending CellRegion[0] in the first place. While I was on my ride today, I was thinking that maybe this wasn't a mistake, but perhaps some way to avoid putting something on the line, such as the rolename. I'm not sure about this, though. Rich, Mike, do either of you remember anything along those lines?
Sorry, I'm not remembering anything related to this.
I've committed the latest revision of this patch as we're getting close to agreement on how it should work. Changing bug status to "[pending]. Note that this patch removed .../orca/src/orca/scripts/users-admin.py so either checkout Orca completely again from SVN, or remember to run autogen.sh
Thanks for the verification Mike. Closing as FIXED.