You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported by jteh on 2009-11-27 04:13
In real Mozilla tables in Firefox 3.6 and later, the parent of table cells is a row object. This row's name is a concatenation of the text content from all child cells. The reason for this is that in ARIA grids/treegrids, the row itself can gain focus and the entire row should be reported in that case. Unfortunately, this causes redundant information to be reported by NVDA when the row is a focus ancestor, as in the following examples:
Tabbing through a form which contains a table. The entire row is read before the form field.
Do we want to get rid of this behaviour? I think it's annoying, but perhaps it should be kept.
Moving up/down a column in an ARIA grid/treegrid; e.g. Firebug's Net panel. The entire row is read before the cell.
Note that this doesn't occur in Firebug in Firefox 3.6 and later because the rows are exposed as tree view items instead of rows.
In both of these cases, cell coordinates are reported by the cell, so the row really should not be presented in the ancestry.
Unfortunately, there are also cases where rows are used outside of real tables; e.g. the recipient address fields in Thunderbird's message composer. In this case, we do want the row to be presented because it includes position information which won't be reported by the cells (because they aren't real table cells).
There are three possible solutions:
Don't ever present rows in the ancestry.
This would break the Thunderbird example above.
Special case Mozilla rows, making isPresentableFocusAncestor return False if the parent has an IAccessibleTable object.
This works, but I feel like this shouldn't be specific to Mozilla. Or should it? After all, this name concatenation is unique to Mozilla at present.
Add some extra code to the base isPresentableFocusAncestor for rows/columns which returns False if the row/column is not part of a real table (i.e. table property is None or not implemented).
This seems like the most abstract solution.
The table property must return the real table object for row/column objects if they have one. This already happens for Mozilla, so this is fine.
The question is: again, should this actually be made specific to Gecko?
Note that I have implemented code for solutions 2 and 3, so it's just a matter of which we prefer, if any.
The text was updated successfully, but these errors were encountered:
Comment 2 by mdcurran on 2009-11-27 06:29
I like option 3: don't speak row in focusAncestors if its table has IAccessibleTable. Though of course it still depends on how these tree grids are handling their focus. Is it common for them to set focus to the row, or the first cell in the row?
Comment 3 by jteh on 2009-11-27 06:33
Note that we won't check for IAccessibleTable in option 3. We just use the table property to fetch the table NVDAObject if there is one. For real tables, their row should return the correct table NVDAObject. Using IAccessibleTable is less generic. This is the major difference between options 2 and 3.
Grids/treegrids can set focus to both rows and cells. When they set focus to a row, they expect the whole row to be spoken. This will still work, as we don't use isPresentableFocusAncestor for the focus itself.
Comment 4 by mdcurran on 2009-11-27 06:35
Sorry, my bad, I do mean option 3: more abstract than option 2. Or perhaps you might want to say: we'll only present a row in focus ancestors if it doesn't have table info, but it does have position info. Then that still filters out pointless presentation rows that may exist.
Reported by jteh on 2009-11-27 04:13
In real Mozilla tables in Firefox 3.6 and later, the parent of table cells is a row object. This row's name is a concatenation of the text content from all child cells. The reason for this is that in ARIA grids/treegrids, the row itself can gain focus and the entire row should be reported in that case. Unfortunately, this causes redundant information to be reported by NVDA when the row is a focus ancestor, as in the following examples:
In both of these cases, cell coordinates are reported by the cell, so the row really should not be presented in the ancestry.
Unfortunately, there are also cases where rows are used outside of real tables; e.g. the recipient address fields in Thunderbird's message composer. In this case, we do want the row to be presented because it includes position information which won't be reported by the cells (because they aren't real table cells).
There are three possible solutions:
Note that I have implemented code for solutions 2 and 3, so it's just a matter of which we prefer, if any.
The text was updated successfully, but these errors were encountered: