User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070302 Minefield/3.0a3pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070302 Minefield/3.0a3pre If a table has an empty summary (via summary=""), that table is being identified as a data table via at-spi. If a table has an empty caption (via <caption</caption>), that table -- along with any table that contains it -- is being identified as a data table via at-spi. Reproducible: Always Steps to Reproduce: 1. Examine the sample file (to be attached) using at-poke 2. Remove the empty summary from table 1.1.1.1 and re-examine in at-poke 3. Remove the empty caption from table 1.1.1 and re-examine in at-poke Actual Results: When you remove the empty summary, table 1.1.1.1 is no longer identified as a data table. When you remove the empty caption from table 1.1.1, tables 1, 1.1, and 1.1.1 are no longer identified as data tables. Expected Results: Table 1.1.1.1 should have not been identified as a data table in the first place because it has an empty summary. Table 1.1.1 should not have been identified as a data table in the first place because it has an empty caption. Personally, I think that parents of tables with captions (even proper, non-zero length captions) -- in this example, tables 1 and 1.1 -- should not be identified as data tables based merely on their children being identified as data tables. But others may disagree on that point(??).

When you say identified as a table, are you talking about the role we expose for the table or the "layout-guess" object attribute?

The latter (I believe). In at-poke it's under "description"; not "role". The role of table is appropriate. It's the data-versus-layout thing that's not quite right.

The description is there for debugging purposes until we have testing tools that will show object attributes on all platforms. BTW, you might want to consider trying Accerciser -- it already does some things at-poke doesn't: http://live.gnome.org/Accerciser

Anyway, if you're writing a script for Mozilla support, make sure you look at the object attribute "layout-guess" instead of that description. Here's a list of the object attributes we currently support: http://developer.mozilla.org/en/docs/Accessibility/ATSPI_Support#Supported_AT-SPI_Object_Attributes We'll update that list as we go. Here's a list of some more attributes we intend to support later: http://wiki.mozilla.org/Accessibility/Attributes and http://wiki.mozilla.org/Accessibility/Datatypes

Orca currently uses the layout-guess attribute and it definitely helps a lot (thanks!). I think what might help is including logic to detect the particular construct in the opening comment for this bug. If it's detected, then set the layout-guess attribute. Does that sound about right, Joanie?

> Does that sound about right, Joanie? Yes Will. Thanks for interpretting for me. :-) Aaron, thanks so much for the links to the docs!!

> If it's detected, then set the layout-guess attribute. No matter what? An explicitly empty summary or caption always means that something is for layout?

Perhaps not "no matter what" and "always" but.... Looking at the docs you pointed me to, layout_guess is described as: > "true" when Gecko's heuristic determines that it is a table that is probably > used for layout, not for a data table. Value not set means it is probably a > data table. If it's all based on the *likelihood* of something being a layout table versus a data table, why does a zero-length summary or caption make a table less likely to be a layout table than the complete absence of summary or caption? And why does the presence of a caption of any sort in a nested table make it more likely that the parent table(s) is not a layout table? With respect to summary, after looking at the Bank of America site (which is what sparked this bug report) I'm wondering if it's the new alt: i.e. you have to have an alt for each image so now we see alt=""....

At the risk of asking (another) silly question: If layout-guess is all about probability, rather than "true" or "not set" what about providing a number that reflects the probability? Then screen readers -- and individual users -- could set their own thresholds based on experience.

I believe a non-empty caption would only be used for a true table. But, if that's proved to be a bad rule we can remove it. As for empty caption or summary, I agree -- they're just trying to pass validation. But, I'd rather make an empty caption or summary a non-factor and let the other rules determine layout/data in that case.

> But, I'd rather make an empty caption or summary a non-factor and > let the other rules determine layout/data in that case. Totally agreed. If you could equate empty caption with absence of caption and empty summary with absence of summary -- which is what you are suggesting, correct? -- life would be good. Thanks!!

I don't want to do the probability thing right now, because I'm not sure how to do it, honestly. And, I don't feel it's worth the effort, when there's this alternative: the screen reader can still allow the user to manually turn on/off table navigation for all tables or a given table for a given page.

Comment on attachment 260941 [details] [diff] [review] Empty captions and summaries are no longer a factor in the layout vs. data heuristic cool

Comment on attachment 260941 [details] [diff] [review] Empty captions and summaries are no longer a factor in the layout vs. data heuristic cool