Steps to reproduce: 1. Launch Accerciser and use it to examine the table in the attached test case. Expected results: The parent of the table cell would be the table. Actual results: The parent of the table cell is an object of ROLE_TEXT 2. Remove the onclick from the table row, reload the page, and re-examine the hierarchy. Expected and Actual results: The parent of the table cell is the table.

1) table@onclick table (html:table) text container (html:tbody) text container (html:tr) cell (html:td) text leaf (text node) 2) table table (html:table) text container (html:tbody) cell (html:td) text leaf (text node) So I guess the problem we create accessible for html:tr whereas we shouldn't?

We can't guarantee that the table rows won't have accessibles, because they need an accessible object if they: - are focusable (need to be able to fire events) - have an action (like onclick) - have a relationship to another accessible etc. Does the table interface still work?

It looks this leads to problem described in http://groups.google.com/group/mozilla.dev.accessibility/browse_frm/thread/4f54984000b93b98 (windows eyes doesn't announce table headers)

I think this needs to be solved on the AT end.

Would be nice to get some tests on question from comment #2. I think if table interface still works then the bug is invalid.

The fact that accessibles on table rows currently break part of our table interface is documented in bug 410052, and a result of that is in bug 409439. So once bug 410052 is fixed, we should revisit this one and see if there's still a problem.

I've worked around this issue. Close it as INVALID if you'd like.

I want to keep it open and look at it after Firefox 3 ships.

bug 410052 has been landed on trunk.

When we land bug 493695 then this bug becomes worksforme because onclick and etc on row won't change table hierarchy.

fixed in bug 493695 because onclick and etc doesn't change hierarchy any more, row accessibles are exposed always.