Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inclusion of table rows in focus ancestry causes extraneous information to be reported #482

nvaccessAuto opened this issue Jan 1, 2010 · 5 comments


Copy link

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:

  1. Don't ever present rows in the ancestry.
    • This would break the Thunderbird example above.
  2. 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.
  3. 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.

Copy link

Comment 1 by jteh on 2009-11-27 04:14
Mick, thoughts appreciated.

Copy link

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?

Copy link

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.

Copy link

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.

Copy link

Comment 5 by jteh on 2009-11-27 08:05
Committed in r3391.
State: closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants