GNOME Bugzilla – Bug 137336
Gnopernicus doesn't have a correct behavior in case of tables
Last modified: 2009-08-15 18:40:50 UTC
In case of tables, gnopernicus should have following behavior (for speech): 1) When user moves to a new table (from another table or widget), following description will be outputed: " table, <table_name>, row header <row_header>(if exists), column header <column_header>(if exists), <current(selected/focused)_cell_content>(if exists)" In case of tables with focusable header, if the table header is focused when we move to the table (and not a table line), the table description will be just "table, <table_name>" (because we don't heve in this case a 'current cell'). The table description will be followed by the entire table header description. 2) When user moves inside a table: * if the table header is focused and (s)he moves to a new column (using left/right arrow keys), only the new column header will be presented. * if focus moves to a new line, the new row header (if exists) and the current cell content will be presented. * if focus moves to a new cell (in the same line), the new column header (if exists) and the current cell will be presented. * if user checks, expands etc a cell, only the new state will be presented. Are you agree with this behavior? I belive this is the required behavior in case of tables.
Created attachment 25687 [details] [review] proposed patch
*** Bug 132855 has been marked as a duplicate of this bug. ***
marking AP2 since the closed bug which duplicates this bug was marked AP2.
Dana: thanks; your description above sounds like the right behavior to me.
There are some tables (eg. gaim -> Accounts) which provide an empty selection when focus moves from another widget to this table. Also, there isn't a focused cell.Because we don't have a 'current cell', the only information which will be outputed is "table, <table name>". To have a correct behavior, we need a non-empty selection when the table is focused.
Are you saying that there is a problem with focusing an empty GtkTreeView? If so, that is bug #126295 which I hope will be fixed in GNOME 2.6.1.
I am not sure if it's the same problem. Yes, initially this is an empty GtktreeView but after I add some information this table has 'x' children. The problem is that no one of them seems to be selected and/or focused when focus moves from another widget to this table (using 'tab' key).
What we have here is a GtkTreeView containing a GtkTreeStore which supports multiple selection, i.e. GTK_SELECTION_MULTIPLE is set. When such a treeview receives focus a cell is not initially selected. Does this cause a problem?
The "focus" behavior of a table shouldn't depend on the selection, as far as I can tell. The "focussed" child of a table isn't always the same as the selection, even for tables/trees that don't allow MULTISELECT.
I agree with you Bill, but when this table receives focus, it doesn't have any focused child (cell or column header). Also there is no selection. What shold gnopernicus output in this case?
I suppose if no element and no header is focussed when the table receives focus, it would be enough to report "table" <table-name> if the table had a non-empty name. If there's no name, perhaps we should include a heuristic that tries to get the name from its parent (if it's the only child) or which reads column and/or row headers if they are available, even if there is no "currently active" row or column. But I hope this will not be true of many tables, and we can file bugs against tables without names.
Unfortunately this particular table has an empty name and the only description outputed is 'table'... But this is a particular situation, it's not a common case. Because the table name is a very usefull information in a table description,I think we should file bugs against tables without name.
For this table, for a sighted user the name of the dialog, "Accounts", functions as the name of the table. Perhaps the bug is that gaim does not call atk_object_set_name() on the table.
Removing AP2 from Status Whiteboard because because this bug offers to user only a way to get different information depending on situation (first/other focus events, etc).
Reinstating AP2 tag. As a rule please do not remove AP tags without discussion. AP tags should not be removed from accessibility bugs anyway - though if we agree that the priority should change, they may change from "AP2" to "AP1" or "AP3" (for instance). If gnopernicus' current behavior matches comments #1, #9, #11, then this bug can be closed. For tables with no name, or tables which do not have focussed children, etc. we should file bugs against the corresponding applications.
What table is known as being uniform so that I can properly assess the behaviour of gnopernicus and tables? The proposed behaviour is quite detailed and I need a good base to confirm. Using nautilus and 'list view', I'm not sure it is quite correct but it may just be nautilus. e.g. if I focus a table-line in the nautilus list view, it reports and lists '3 items' in the line when there are 4. The 'Name' cell is not getting reported.
Some examples of this kind of tables are : gedit-> Open, gedit->Edit->Preferences, Command Line applet-> Preferences->Macros page tab.
Patch applied to CVS. Since the problem described at #16 is the subject of a new bug (bug 139391), I will close this bug.
I observed that sometimes gnopernicus specks out more information that it should. Dana described the outputs for some cases. Gnopernicus gives that outputs and more. 1. Almost all times, when focus moves on a table from another object, gnopernicus outputs: * "table, <table_name>, row header <row_header>(if exists),..."-general description for table (this is OK) ** "table line <current_focused_table_cell>" -this should not be reported here 2. When switch between table line gnopernicus outputs the same thing as at 1. It should be reported only the table line description (**).
Scenario: - launch gnopernicus - 2 Preferences-> 1 Speech -> Voices There is a table: "Voice list". Focus the table => gnopernicus outputs table description (this is ok) In the table: * on a row => <table line...current_focused_table_cell> (this is ok) * change column => there are 2 cases: a) "column_header... <current_focused_table_cell>"(this is ok) or b) "table... <table_name> column header...<column_header> <current_focused_table_cell> table line...<current_focused_table_cell>" (this is not the correct behavior) * first time on a column + change line => 2 cases: a) "table line...<current_focused_table_cell>" (this is ok) or b) "table <table_name> column header...<column_header> <current_focused_table_cell> table line <current_focused_table_cell>" (this is not the correct behavior) See if this can be reproduced.
I cannot reproduce the behaviour in #20. However, "column_header" is barely comprehensible in all cases above at present, due to bug 142773 which is resetting voice values to default for this widget.
The behaviour described in comment #20 si not present on my computer.
Using gnopernicus from CVS HEAD may 24th, I cannot reproduce the 'wrong' behaviour described in comment #20.
I can no longer reproduce this bug, so I close it and I will reopen if it is necessary.