GNOME Bugzilla – Bug 132855
table navigation speech output ignores row and column headers
Last modified: 2004-12-22 21:47:04 UTC
using gnopernicus from CVS HEAD 28 Jan. - when switching between tables, like 'Pick a Font' for example, there is no report of which table one is navigating. the output should be: "switch table, <table name>, table line, <number of items>, <table item name>" currently the output is: "table line, <number of items>, <table item name>" regardless of table switch.
*** Bug 118294 has been marked as a duplicate of this bug. ***
*** Bug 134955 has been marked as a duplicate of this bug. ***
*** Bug 133204 has been marked as a duplicate of this bug. ***
*** Bug 134930 has been marked as a duplicate of this bug. ***
From a meeting yesterday, it was decided that the following behavior is what is desired: Gnopernicus should speak: "Table <table name> table line <# lines> <table item name>" the first time the table is visited, and thereafter should speak: "Table <table name>" the second and later times visited. The precise text spoken will be based on entries in the user's selected XML presentation file of course. What is critical is that Gnopernicus is able to detect both situations (first visit vs. subsequent visits), and use two different XML presentation descriptions in the two cases. A fix for this should NOT cause a string freeze breakage, so long as no new translatable strings are introduced in the XML presentation files after this change for 2.6.
(For the record, I do not agree with the proposal above) I believe that a better solution would be to speak the table name _whenever_ context "enters" a table. That includes switching into a table for the first time, and also switching _between_ tables. Without this information, if there are several tables in a UI (which is not uncommon in GNOME, since "lists" are considered tables), it could be difficult for the user to know which table is being navigated. This is especially important in cases where similar or identical contents can exist in more than one table. for instance: imagine a "mixer" applet with lists (tables) for volume control Master Headphones Left Right ====== ========== ==== ===== loud loud loud loud louder louder louder louder loudest loudest loudest loudest the problem should be obvious now. We already use "LABELLED_BY" to label tables/lists like the above, or sometimes the tables are have proper "accessible names" themselves. If we don't speak the accessible name when moving between them, the user doesn't get feedback about which table is being navigated. Of course, as long as we stay in the 'same' table, we shouldn't keep repeating the table name, I agree. Now, imagine that the above set of 4 tables gets re-worked by the "HIG" team or maintainer, in favor of one table with four columns. We have a very similar situation except: * the blind user at least can count on left and right arrows moving sensibly, which isn't true for the 'four list' case, since sometimes TAB order between tables isn't logical. * we now need to speak the "column header" when switching columns. So I propose the following: * when switching tables, speak the table name (and its LABELLED_BY names); * when switching columns within a table (including switching into a new table, as above), speak the column header * when switching rows within a table (or switching tables), speak the row header. in all cases, speak something sensible for the currently focussed/active table cell, of course.
*** Bug 135368 has been marked as a duplicate of this bug. ***
Bill, I think we may be in violent agreement. I'm saying that we should be more verbose the first time a table is seen by Gnopernicus in the tab order of a given life of a window/dialog, and less verbose the second time and all times thereafter. Specifically the first time the user brings focus to an item within a particular table (where previously focus was NOT on any object in that table), I propose that Gnopernicus speak (somewhat refined from above): "Table <table name> has <# lines> lines, on <table item name>" and the second time and all thereafter that the user brings focus to an item in a table (where previously focus ws NOT on any object in that specific table), Gnopernicus speak: "Table <table name>" Movement within cells/rows of a table would *always* be spoken, reading the table column header/row header as appropriate to the movement. So, applying this logic to your table example, the initial TAB into the "Master" table (selecting the item "loud"), Gnopernicus would read: "Table Master, has 3 lines, on loud" TAB again brings focus to "loudest" of table "Headphones", and Gnopernicus would read: "Table Headphones, has 3 lines, on loudest" Shift-TAB to go back to the first table, "loud" still selected, has Gnopernicus read: "Table Master" Make sense? We'll want to massage the strings so they work with the I18N stuff already in place for GNOME 2.6 to not violate the string freeze.
Peter: We do not agree, it seems. We should NOT base the heuristic on "the first time a table is seen", the proposal should be "when the focussed-table context changes". We do not have time to implement the more complex/fragile heuristic ("first time seen") for 2.6, but there is time for the "on context change" heuristic.
Created attachment 25164 [details] [review] partial patch - proposed presentation (general information) in case of tables
Previous patch provides a temporary solution for tables presentation. According to Peter comments (2004-03-02 20:08), gnopernicus will report following information (without distinction between first/second or later focus for the moment): "Table <table name> <#lines> <table item name>" If the focused table doesn't have an accessible name and/or a relation with an appropriate label: *if it's a single column table, this table column header will be presented as a table name *if the table has many columns, the current focused table column header will be presented as a table name. This is a partial patch. It solves only the presentation problem. The remain issue is event filtering (in progress).
Bill, as per our meeting yesterday, I agree: we shouldn't apply separate heuristics for "first time" vs. "all other times" a table is visited for GNOME 2.6, but to look at that functionality later.
Created attachment 25286 [details] [review] new proposed patch
Patch applied to CVS. Because now user is notified when he moves to a new table I will decrease the severity of this bug. Remaining issue is to make distinction between first/later focus.
the patch above, and Dana's proposal, doesn't implement the plan we agreed to in our meeting. I do not agree with Peter's proposal - in our meeting we agreed to the following: all table focus events on table cells should result in the following output: <table-name-if-different> <row-header-if-different> <column-header-if-different> <cell content> where "if different" means that the table-parent, row, or column differ from the recent "table context". Table context always change when moving from/to a table to another type of object or container, or when moving between tables, and row/column "context" changes are probably obvious. Please read my lengthy explanation regarding the use case(s) of a volume control mixer for some reasons why I think the above presentation is better than the one Peter proposes and which Dana provides in the patch. Also my discussions with the test team lead me to believe that my proposal would resolve a number of test failures which the above patch may not fully address.
changing summary to indicate remaining issue; though perhaps this should be opened as a separate bug, since the patch (above) is already in cvs.
To avoid the confusion, I will close this bug. The entire description of the required behavior in case of tables is presented in bug 137336.
Hi Dana; this bug I think should not have been "closed fixed" because it hasn't been fixed. However in order to avoid duplication, perhaps it should be closed as a duplicate of the (new) bug 137336. Why didn't you just put the 137366 comments here?
*** This bug has been marked as a duplicate of 137336 ***