Closed Bug 414656 Opened 12 years ago Closed 12 years ago

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

Categories

(Core :: Disability Access APIs, defect, major)

defect
Not set
major

Tracking

()

VERIFIED FIXED

People

(Reporter: MarcoZ, Assigned: surkov)

References

(Blocks 2 open bugs)

Details

(Keywords: access)

Attachments

(2 files)

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.
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
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.
Flags: blocking1.9?
Aaron, would you consider to use role from used accessibility object rather than to return role nothing if landmark role is used?
Yes, that's what we need to do :)
But, in the case of a table cell with no parent table we can't.
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.
Attached patch patchSplinter Review
Attachment #301252 - Flags: review?(aaronleventhal)
Comment on attachment 301252 [details] [diff] [review]
patch

This looks perfect. Thanks!
Attachment #301252 - Flags: review?(aaronleventhal)
Attachment #301252 - Flags: review+
Attachment #301252 - Flags: approval1.9?
Assignee: aaronleventhal → surkov.alexander
Attachment #301252 - Flags: approval1.9? → approval1.9+
Checked in for Alexander.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
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!
Status: RESOLVED → VERIFIED
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.
I'm seeing the problem on Windows as well. The ARIA checkbox is getting exposed as "checkbox" instead of ROLE_CHECKBOX. Backing out.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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) {
Attachment #301745 - Flags: review?(surkov.alexander)
Comment on attachment 301745 [details] [diff] [review]
Minor tweak to patch

right, thank you for the fix
Attachment #301745 - Flags: review?(surkov.alexander) → review+
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Blocks: 418405
You need to log in before you can comment on or make changes to this bug.