Expose object attribute on cell accessible for html:td to provide cell index

VERIFIED FIXED in mozilla1.9

Status

()

Core
Disability Access APIs
P2
major
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: MarcoZ, Assigned: surkov)

Tracking

(Blocks: 1 bug, {access, dev-doc-complete})

Trunk
mozilla1.9
access, dev-doc-complete
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: orca:urgent)

Attachments

(1 attachment)

13.55 KB, patch
Evan Yan
: review+
Mike Schroepfer
: approval1.9+
Details | Diff | Splinter Review
(Reporter)

Description

10 years ago
This is a spin-off off bug 416742. To recap, here's what Joanie and I discovered (see also that bug's comment 48). The original testcase is a table with a caption, one row and two cells in that row.

On Linux, the hierarchy looks like this:

table
  caption
  cell 0
  cell 1

The testcase fails.

On Windows, the IAccessible2 hierarchy, viewed in AccProbe, looks like this:

table
  caption
    text leaf of caption
  textframe
    table cell 0
      text leaf of table cell 0
  textframe
    table cell 1
      text leaf of table cell 1

On Windows, the testcase always is true, because getIndexInParent always
returns 0, because the only child of the textframe parent *is* the table cell.

So, why are we creating textframes in IAccessible2 for each table cell while we
don't do it on Linux where aparently there is no such thing as textframes?
Flags: blocking1.9?

Comment 1

10 years ago
The hierarchies can be different than expected on Linux as well, if a <tr>, <tbody>, <thead> or <tfoot> is focusable or has something else "interesting" about it like an ARIA property. In that case we have no choice but to expose the extra object. The table impl has to deal with that.

Updated

10 years ago
Blocks: 374212
Whiteboard: orca:urgent

Comment 2

10 years ago
Marco, thanks for filing this bug and for spending the time at CSUN to go over this stuff with me!  Question:  Looking at the summary "... bogus values on Windows", I was wondering if this bug will also address the original problem I filed in bug 416742 or if we should open a new bug for that issue.
(Assignee)

Comment 3

10 years ago
We may want to have similar accessibles trees for table but we can't guarantee as Aaron said the cell accessibles only are presented in the table. Therefore getIndexInParent() and cell index are different things. If we will expose 'cell-index' attribute on cell then will it help?
(Reporter)

Comment 4

10 years ago
(In reply to comment #3)
> If we will expose
> 'cell-index' attribute on cell then will it help?

Joanie, in other words, if we gave you the cell-based index in an attribute for the cell, would that be good for Orca so you can then query the row and columns by getRowAtIndex and getColumnAtIndex?
TM --> mozilla1.9, this won't block beta 5. If you disagree, please reset the TM to beta5 and explain why it needs to block beta.
Target Milestone: mozilla1.9beta5 → mozilla1.9

Updated

10 years ago
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2

Comment 6

10 years ago
Given we are past RC1 freeze and there has been no bug activity this has to wait until a dot release...
Flags: wanted1.9.0.x?
Flags: blocking1.9-
Flags: blocking1.9+
(Reporter)

Comment 7

10 years ago
We have an idea of an interim fix, which is giving Orca the actual cell number it needs to ask the table for, in an attribute string. That would, for now, work around the problem of GetIndexInParent and the reverse lookup of GetColumnAtIndex and GetRowAtIndex not working consistently in HTML tables.

Alexander, since nobody responded to either the newsgroup or on the Wiki page where you proposed the solution possibilities, please move forward with implementing the cellNumber attribute string that contains the index of the cell.

Mike, I request that this be taken for FX3 when ready, because this not being able to give users the accurate column and row numbers is a major table reading problem on Linux. Things like speaking the correct column header stands and falls with this implementation problem. So please allow us to give the screen reader this workaround to work with.

Comment 8

10 years ago
Exposing a cell-number object attribute is certainly a low risk fix. I agree we should take it.
(Assignee)

Comment 9

10 years ago
Created attachment 315239 [details] [diff] [review]
patch

modified mochitest fails on cellRefAt but it's different issue which we should have a deal in another bug with.
Attachment #315239 - Flags: review?(Evan.Yan)

Comment 10

10 years ago
Comment on attachment 315239 [details] [diff] [review]
patch

Some nits:

>-ACCESSIBILITY_ATOM(lineNumber, "line-number")
>-ACCESSIBILITY_ATOM(containerRelevant, "container-relevant")
>-ACCESSIBILITY_ATOM(containerLive, "container-live")
>-ACCESSIBILITY_ATOM(containerChannel, "container-channel")
>-ACCESSIBILITY_ATOM(containerAtomic, "container-atomic")
>-ACCESSIBILITY_ATOM(containerBusy, "container-busy")

Why we move these?

>+  while (parentAcc) {
>+    if (Role(parentAcc) == nsIAccessibleRole::ROLE_TABLE) {
>+      // Table accessible must implement nsIAccessibleTable interface but if
>+      // it isn't happen (for example because of ARIA usage) we shouldn't fail
>+      // another attributes on table cell.

I guess you mean "we shouldn't fail on getting other attributes"
Attachment #315239 - Flags: review?(Evan.Yan) → review+
(Assignee)

Comment 11

10 years ago
(In reply to comment #10)
> (From update of attachment 315239 [details] [diff] [review])
> Some nits:
> 
> >-ACCESSIBILITY_ATOM(lineNumber, "line-number")
> >-ACCESSIBILITY_ATOM(containerRelevant, "container-relevant")
> >-ACCESSIBILITY_ATOM(containerLive, "container-live")
> >-ACCESSIBILITY_ATOM(containerChannel, "container-channel")
> >-ACCESSIBILITY_ATOM(containerAtomic, "container-atomic")
> >-ACCESSIBILITY_ATOM(containerBusy, "container-busy")
> 
> Why we move these?

to keep them in alphabetical order like we do in nsAccessibilityAtoms
Status: NEW → ASSIGNED
(Assignee)

Updated

10 years ago
Attachment #315239 - Flags: approval1.9?

Updated

10 years ago
Attachment #315239 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 12

10 years ago
changing summary. If we really want to keep trees in sync on different platforms (that should be nice of course imo) then let me know and I'll file new bug to track this.
Summary: Accessible hierarchies different in Windows and Linux for tables, causes getIndexInParent for table cells to return bogus values on Windows. → Expose object attribute on cell accessible for html:td to provide cell index
(Assignee)

Comment 13

10 years ago
/cvsroot/mozilla/accessible/src/base/nsAccessibilityAtomList.h,v  <--  nsAccessibilityAtomList.h
new revision: 1.91; previous revision: 1.90
done
Checking in accessible/src/html/nsHTMLTableAccessible.cpp;
/cvsroot/mozilla/accessible/src/html/nsHTMLTableAccessible.cpp,v  <--  nsHTMLTableAccessible.cpp
new revision: 1.62; previous revision: 1.61
done
Checking in accessible/src/html/nsHTMLTableAccessible.h;
/cvsroot/mozilla/accessible/src/html/nsHTMLTableAccessible.h,v  <--  nsHTMLTableAccessible.h
new revision: 1.33; previous revision: 1.32
done
Checking in accessible/tests/mochitest/test_table_indexes.html;
/cvsroot/mozilla/accessible/tests/mochitest/test_table_indexes.html,v  <--  test_table_indexes.html
new revision: 1.2; previous revision: 1.1
done

Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Comment 14

10 years ago
Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041506 Minefield/3.0pre.

Alexander, can you document this on our Wiki (how to use the cell-index attribute instead of GetIndexInParent? Thanks!
Status: RESOLVED → VERIFIED
Keywords: dev-doc-needed
(Assignee)

Comment 15

10 years ago
Marco, I put already some documentation at http://developer.mozilla.org/en/docs/Accessibility:AT-APIs:Gecko:Attrs#Table_related_attributes. If you think it should be improved let me know.
Keywords: dev-doc-needed → dev-doc-complete
(Reporter)

Comment 16

10 years ago
No, that is fine, thanks!
Flags: wanted1.9.0.x?
You need to log in before you can comment on or make changes to this bug.