> It would be really nice if we could determine that this is 
> just a layout table.

Or in this case a bunch of nested layout tables:  four tables deep with the stuff near the beginning of the page! You know the html isn't going to be a fun read-and-weed when they've had to document the level of nesting via comments just to keep track themselves.  :-)

Created attachment 83761 [details]
test case which isolates the issue in the original report

The problem Mike is seeing seems to be the result of nested tables with empty summary information.

Using the attached test case, start from the top of the page and tab from link to link.  Orca will say "table" (sometimes multiple times) for each link.  Then edit the html to remove each instance of

    summary=""

from the tables, refresh and try again.  Orca won't say "table" as you tab.

I was chatting with Mike about this one.  He indicated that we're deciding what is a layout table versus a data table through at-spi.  So I did a little at-poking.  Here's what I discovered:

1. Any table with an empty summary is being identified as a data table via at-spi.

2. Any table with an empty caption -- along with all parent tables -- is being identified as a data table via at-spi.

While we could (presumably) do some proactive work to catch these cases, I don't think we should be getting this information via at-spi in the first place.  Therefore, I filed this bug with Firefox:  https://bugzilla.mozilla.org/show_bug.cgi?id=372545 and am adjusting the summary accordingly.

> 1. Any table with an empty summary is being identified as a data table via
> at-spi.
> 
> 2. Any table with an empty caption -- along with all parent tables -- is being
> identified as a data table via at-spi.

I agree we should always continue to try to get problems fixed at the source (Firefox in this case).  However, is there logic we could add to Gecko.py:isLayoutOnly to handle these kinds of tables?

Joanie - I think you mentioned that there might be some way we can work around this in Orca.  I have not wrapped my mind around this at all, though.  Can you describe the differences between an "empty summary" and an "empty caption" and how these are exposed to us via the AT-SPI?

Valid summary example:

<table summary="my nifty summary">
<tr><td>cell one</td><td>cell two</td></tr>
</table>

Valid caption example:

<table>
<caption>My Nifty Caption</caption>
<tr><td>cell one</td><td>cell two</td></tr>
</table>

"Empty" summary example:
<table summary="">....

"Empty" caption example:
<caption></caption>....

Given a table that would be judged a layout table by Firefox's heuristics, add an "empty" summary or an "empty" caption, and that table will now be judged as a data table.  Firefox does NOT currently equate  "empty" with "absent."

Other things that theoretically cause a table to get identified as a data table are the presence of one or more of the following:

* <thead>
* <tfoot>
* <th>
* <colgroup>

So with that background:

1. If a table has a non-zero-length summary, it's exposed via the table's name.  If a table has an empty summary, the name is None*.  I do not see the summary being exposed elsewhere (such as through table.summary).

2. If a table has a non-zero-length caption, it's exposed both via the table's name and by a child of ROLE_CAPTION. (Note: table.caption will also return an accessible, but that seems to be extraneous given the other ways in which captions are exposed, so I haven't pursued this any further). If a table has an empty caption, the table name is None* but there will still be a child of ROLE_CAPTION.

*If a table has BOTH a non-zero-length summary and a caption, and the caption is not empty, the name is taken from the caption.  If the caption is empty, the name is taken from the summary.

3. If a table has a non-zero-length caption, all of its "parent" tables will adopt that caption as their own name; they will not have a child of ROLE_CAPTION, however, unless they themselves have a caption.  BUT, it seems like caption adoption is sufficient to cause the parent tables to be identified as data tables. :-(

Thus for a given table, the absence of both a name and a child of ROLE_CAPTION tells us that this table lacks both a valid summary and a valid caption.  Then there's the matter of the other things that make something a potential data table:

4. We can get at <th> through the table cell's attributes.

5.  If the column header is in a <thead>, we can get it with table.getColumnHeader.  I still need to investigate row headers but with any luck we can get those with table.getRowHeader.

6. I have not yet found a way to get at the presence of a <tfoot> or <colgroup> I was hoping it would somehow be an attribute, but that does not *appear* to be the case.  I need to double check that, however.

So...... 

In light of the above, I'm thinking we can do our own "layout guess" until the Firefox folks fix their bug. If the only things we cannot get at are <tfoot> and <colgroup>, then I think our layout guess will be better than what we we are currently getting from Firefox.

Forgot to mention:  At CSUN Mike and I were talking about table chattiness.  He indicated that in the case of nested tables, we only care about the current table with focus and not all of its parent tables regardless of whether those parents are (valid) data tables or not.  The patch-in-progress will address that as well.

Created attachment 85877 [details] [review]
patch to do the "layout-guess" work ourselves

This patch addresses just the layout-guess aspect of the problem in this bug.   With the patch, the tables in the test case in this bug, along with those on the Bank of America page, are being identified as layout tables.  Because isLayoutOnly returns True, "table" is not being spoken.

As for not speaking the parent tables of nested tables:  With this patch, if the parent table is identified as a data table by us, we will still speak it.  Fortunately, there are not that many instances of tables nested inside data tables. <smile>  Because, as Will commented in bug #423439, what he's working on might cause table information to no longer be spoken and thus require some special handling to speak what table information should be spoken, I'm going to wait until #423439 is resolved before finishing work on this bug.

This just in: The bug I had filed against Firefox has just seen some action.  In particular, Aaron just added a patch so that "empty captions and summaries are no longer a factor in the layout vs. data heuristic."  Yea!

Hopefully we can get the "caption adoption" problem resolved too.  I'll comment on the firefox bug.

In the meantime, I say we wait on including my patch.

I chatted with Will about this via IM.  He suggested we go ahead and include the patch now.   Done.  When the Firefox fix gets committed, I'll revisit this to see if some (or all) of the work we're now doing can be removed.

After a complaint from Hermann and another chat with Will, I ripped this out.  On a really long page with a number of "data" tables that needed to be examined, there was some noticeable sluggishness.  Now we will potentially land on some fake "data" tables, but Aaron has theoretically fixed that bug on the Firefox side....

This seems to be fixed with orca from trunk.  

I say feel free to close it.  Thanks Joanie! (And thanks Mike for testing)