414656 - If an HTML table has a role of "log", expose it as a data table

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

Currently, esp after fix for bug 404881 landed, an HTML table with an ARIA role of "log" does not get exposed as a data table. It is assumed to be a layout table, and accessibles are not created for it. The result is that all text nodes within the ChatZilla output window is run together, making it extremely difficult to read.
I suggest to always expose an HTML table with a role of "log" as a data table. A log usually is something structured where navigating a table-like structure makes a lot of sense.

Comment 1

[alexander :surkov (:asurkov)]

it's because accessibles with unrecognized role has landmark role map entry that is treated as ROLE_NOTHING in GetFinalRole.

1) nsAccUtils::GetRoleMapEntry() return nsnull instead landmark role map entry, it shouldn't force not to create accessibles actually
or
2) if we have role nothing in GetFinalRole() then we should try GetRole as we did before bug 404881

Comment 2

[:Gijs (he/him)]

Requesting blocking-1.9 - this is important for proper support of tables with aria roles, which includes ChatZilla accessibility - without it, the latter will be either extremely hard or impossible.

Comment 3

[alexander :surkov (:asurkov)]

Aaron, would you consider to use role from used accessibility object rather than to return role nothing if landmark role is used?

Comment 4

[Aaron Leventhal]

Yes, that's what we need to do :)

Comment 5

[Aaron Leventhal]

But, in the case of a table cell with no parent table we can't.

Comment 6

[Aaron Leventhal]

Because of comment 5, the easiest way might be to have 2 different ways to have a landmark role entry. One allows the native role alongside it, and one returns ROLE_NOTHING/UNKNOWN.

Comment 7

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 8

[Aaron Leventhal]

Comment on attachment 301252 [details] [diff] [review]
patch

This looks perfect. Thanks!

Comment 9

[Aaron Leventhal]

Checked in for Alexander.

Comment 10

[Marco Zehe (:MarcoZ)]

Verified using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008020604 Minefield/3.0b4pre. I'm very happy with this change since it makes ChatZilla usable again!

Comment 11

[Scott Haeger]

All AT-SPI ARIA support was lost from the 2/05 (good) and 2/06 (bad) nightly builds.  Aaron informed me that this was the only commit for this period, so it is probably the culprit.  Please look at any of the ARIA widgets (Mozilla, UIUC, Dojo) linked from http://live.gnome.org/Orca/Firefox/ARIAWidgets to verify.

Aaron, the Dojo widgets are not supported either.  I mistook an entry for a combobox.

Comment 12

[Aaron Leventhal]

I'm seeing the problem on Windows as well. The ARIA checkbox is getting exposed as "checkbox" instead of ROLE_CHECKBOX. Backing out.

Comment 13

[Aaron Leventhal]

Attachment: Minor tweak to patch

was:
+    if (mRoleMapEntry == &nsARIAMap::gEmptyRoleMap) {

now:
+    // gLandmarkRoleMap: can use role of accessible class impl
+    // gEmptyRoleMap and all others: cannot use role of accessible class impl
+    if (mRoleMapEntry != &nsARIAMap::gLandmarkRoleMap) {

Comment 14

[alexander :surkov (:asurkov)]

Comment on attachment 301745 [details] [diff] [review]
Minor tweak to patch

right, thank you for the fix

Comment 15

[Marco Zehe (:MarcoZ)]

Verified again, this time using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008020708 Minefield/3.0b4pre. I also checked the Mozilla ARIA widgets, and th ose I tested worked as expected.