Closed Bug 367905 Opened 18 years ago Closed 15 years ago

Harmonize accessible tree and treegrid implementations

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: aaronlev, Assigned: surkov)

References

(Blocks 4 open bugs)

Details

(Keywords: access) 

This came out of a challenging, detailed discussion of tree views at W3C PF meeting about tree grids. See some of the amazingly complex use cases we need to support at http://turboajax.com/demos/grid3/  -- not these are not currently tagged with ARIA markup.

We need to harmonize the accessible tree interfaces and implementations:
1) So that ARIA tables can be exposed correctly
2) So that IA2 AT's can get better info about tree grids
3) So that ATK AT's have an easier time getting positional info
4) So Firefox tree implementation is not so insane

ARIA has 3 ways to expose trees:
1) Using level, posinset, setsize (always works)
2) Using the owns relation (the inverse of RELATION_NODE_OF) -- only works for preloaded. Can point to individual ROLE_TREEITEMS or a ROLE_GROUP, ROLE_TABLE or ROLE_ROW which contains the invdidual items
3) Using nested ROLE_GROUP or ROLE_TABLE to group items of the same level. (role="group" currently works this way for ARIA trees in Firefox) -- but only works for single column preloaded trees 

-------------------------------------------------------------------
|           | Multi-column              |   Single-column         |
-------------------------------------------------------------------
| Dynamic   |   Level/setsize/posinset  | Level/setsize/posinset  |
-------------------------------------------------------------------
| Preloaded |   Level/setsize/posinset  | Level/setsize/posinset  |  
|           |   Owns relation           | Owns relation           |
|           |                           | role="group"            |
-------------------------------------------------------------------
We might deprecate the "group" method which would simplify things (for the documentation at least).

ATK:
ROLE_TREE_TABLE (supports Table interface)
-   keycell    cell    cell    cell    cell    cell
-   keycell    cell    cell    cell    cell    cell
-   keycell    cell    cell    cell    cell    cell
-   keycell    cell    cell    cell    cell    cell
-   keycell    cell    cell    cell    cell    cell
The key cell holds states, relations and fires events
Uses RELATION_NODE_CHILD_OF to imply depth, by pointing to another keycell

MSAA
ROLE_TABLE
-   treeitem
-   treeitem
-   treeitem
-   treeitem
-   treeitem
Cells are not indivudually exposed. The name of each tree item is a contatenated verison of everything.
In MSAA, providing positional info is done via the description field, which is overriden (this is a formatted string hack)

IAccessible2
In IA2 we have the positionInGroup() method to return that info and avoid the description hack.

Proposal:
Combine the two, so mostly backward compatible
ROLE_TREE_TABLE  -- Supports Table interface
-   treeitem,       can have table cell children
-   treeitem,       can have table child
-   treeitem
-   treeitem
-   treeitem

Each table cell can implement the Text interface or have children that describe it's contents,
such as checkbox, image, progressmeter, button

IAccessible2
ROLE_TABLE  -- Supports table interface
-   treeitem
       cell   cell   cell   cell    [optional]
-   treeitem
       cell   cell   cell   cell    [optional]
-   treeitem
       cell   cell   cell   cell    [optional]
-   treeitem
       cell   cell   cell   cell    [optional]

The treeitems will support the follwowing properties when they can be calulated:
- NODE_CHILD_OF relation
- positionInGroup and object attributes for level, posinset, setsize
- Tree items can support CHECKED/CHECKABLE/SELECTED/SELECTABLE/EXPANDED/EXPANDABLE
- Cells can support CHECKED/CHECKABLE/SELECTED/SELECTABLE
- Tree items and cells can both support selectedm focused and state change events
- For HTML tables, TR's will need accessible objects ROLE_ROW
- We will need to fix XUL tree tables
- We will need to make sure various ARIA options work
- We will need to make sure these changes are backward compatible with current AT's. It should be backward compatible with JAWS and Window-Eyes, since they still simply receive an event on a tree item and look for the description to see if they can get the positional info.

ATK:
- Do things the same as for IA2, use object attributes for positional info
- Basically this is adding row objects to contain cells. Will this break AT's on Linux? I think it will, but since Mozilla is not well supported yet we may need to do this.

(Note to me, need to talk to Al about how HTML <tbody> fits in)
Blocks: 365973
One addition to the current ATK implementation:

In gtk/gail, a particular cell in a row sometimes has no content itself, but instead has accessible text, image, etc. children. This case occurs when, for     instance, a cell has both an icon and text falling into the same logical table     column. The bookmark tree is a perfect example. The cells in the first column     "Name" have both an icon and text.

Could you support this with the proposed IA2 design?


Yes, in fact, buttons, progressmeters -- lots of things should be able to be inside of cell.
This bug sounds like very important work.

(In reply to comment #0)
> This came out of a challenging, detailed discussion of tree views at W3C PF
> meeting about tree grids. See some of the amazingly complex use cases we need
> to support at http://turboajax.com/demos/grid3/  -- not these are not currently
> tagged with ARIA markup.
> 
> We need to harmonize the accessible tree interfaces and implementations:
> 1) So that ARIA tables can be exposed correctly
> 2) So that IA2 AT's can get better info about tree grids
> 3) So that ATK AT's have an easier time getting positional info
> 4) So Firefox tree implementation is not so insane
<snip>

Will this (#4) involve significant refactor? And if so, when? I wondering how it might impact other work, like bug 365866 for example.
From LSR's standpoint, as long as we're still:

1) getting selection (on table cell), active descendant (on active table cell), focus (on the table) events,
2) getting property and state change events from table cells, and
3) able to use the table interface fully (mostly for review mode navigation by cell)

...it doesn't really matter how it's implemented underneath.
Clarification on the summary: the term "dynamic" in the table above means that the entire tree's contents are often not loaded all at once.

In that case we must be able to provide object attributes for position because it can't be calculated by the client. Only the server knows that.
Peter, I wasn't thinking of using active descendant because in the DOM trees the actual item will be getting focus. In fact, focus, selection and checked now can apply either to rows or cells, along with their events. Is it a problem to support either way?

David, there is no schedule yet. Let's get everyone on the same page with the design first. I'll probably be the one doing the refactoring. It's still good if bug 365866 is fixed because that code will still get used, even if it's moved around somewhat.

Unrelated note: one thing that this work will enable is tree tables that allow both row or cell navigation or at least want to specify which is happening. We can differentiate what's getting focus now -- the row or a cell.
We also need to pay attention to <caption> of HTML table, see bug 360184.
The problem is, <caption> tag can be anywhere inside <table> tag, and can have multiple instances.
(In reply to comment #6)
> Peter, I wasn't thinking of using active descendant because in the DOM trees
> the actual item will be getting focus. In fact, focus, selection and checked
> now can apply either to rows or cells, along with their events. Is it a 
> problem to support either way?

In gail/gtk, the focus remains on the entire tree table container widget while active selection is used to indicate which cell in the table is currently active, typically represented with a dotted gray box. We will definitely have to code special support into a script for Firefox if it suddenly begins supporting focus on both entire rows and individual cells. It is a deviation from all other tree tables on GNOME.

> Unrelated note: one thing that this work will enable is tree tables that allow
> both row or cell navigation or at least want to specify which is happening. We
> can differentiate what's getting focus now -- the row or a cell.

I guess I'm not clear on the benefits of allowing the user to navigate by both row and cell in the tree table widget. How would a user switch between navigating by row and by cell? How is focusing by row any different than pressing up and down arrow right now? Can you give an example?
Blocks: xula11y
No longer blocks: keya11y
Blocks: lsr
I think we have a problem:
AtkSelection assumes direct child offsets.
http://developer.gnome.org/doc/API/2.2/atk/AtkSelection.html

So how can you have grand children of anything which implements that interface?
Blocks: orca
Should ARIA tables support nsIAccessibleTable?
Yes, and they already do if the ARIA table is built on top of an HTML table, e.g.
<table role="wairole:grid">
etc.

However, they really should still support nsIAccessibleTable if they're built on top of divs and spans, but that isn't as easy or very common. I'm not so concerned if we don't fix that until Firefox 4.
This may be more doable now that bug 423224 is fixed. I'd target the next release after Firefox 3.
Assignee: aaronleventhal → surkov.alexander
Blocks: aria
Flags: wanted1.9.2?
(In reply to comment #0)

Aaron, do you think we could we break this work up into these chunks:

chunk 1:

> Proposal:
> Combine the two, so mostly backward compatible
> ROLE_TREE_TABLE  -- Supports Table interface
> -   treeitem,       can have table cell children
> -   treeitem,       can have table child
> -   treeitem
> -   treeitem
> -   treeitem
> 
> Each table cell can implement the Text interface or have children that describe
> it's contents,
> such as checkbox, image, progressmeter, button
>

chunk 2:
 
> IAccessible2
> ROLE_TABLE  -- Supports table interface
> -   treeitem
>        cell   cell   cell   cell    [optional]
> -   treeitem
>        cell   cell   cell   cell    [optional]
> -   treeitem
>        cell   cell   cell   cell    [optional]
> -   treeitem
>        cell   cell   cell   cell    [optional]
> 
> The treeitems will support the follwowing properties when they can be
> calulated:

chunk 3:

> - NODE_CHILD_OF relation
> - positionInGroup and object attributes for level, posinset, setsize

chunk 4:

> - Tree items can support
> CHECKED/CHECKABLE/SELECTED/SELECTABLE/EXPANDED/EXPANDABLE
> - Cells can support CHECKED/CHECKABLE/SELECTED/SELECTABLE
> - Tree items and cells can both support selectedm focused and state change
> events

chunk 5:
> - For HTML tables, TR's will need accessible objects ROLE_ROW

chunk 6:
Can you explain this work?

> - We will need to fix XUL tree tables

chunk 7:

> - We will need to make sure various ARIA options work

chunk 8:

> - We will need to make sure these changes are backward compatible with current
> AT's. It should be backward compatible with JAWS and Window-Eyes, since they
> still simply receive an event on a tree item and look for the description to
> see if they can get the positional info.
> 

chunk 9:

> ATK:
> - Do things the same as for IA2, use object attributes for positional info
> - Basically this is adding row objects to contain cells. Will this break AT's
> on Linux? I think it will, but since Mozilla is not well supported yet we may
> need to do this.
>
Well, chunk it how you want. That's up to you guys.

The XUL tree table work would be to expose ROLE_CELL children of tree items on Windows. On Linux we'd need to add the TREEITEM objects. We should no longer need any special code for tables or trees in the *Wrap classes, because it should be the same on Windows and Linux.

The biggest concern I have will be whether this will all break Orca. It might make sense to talk to Will Walker before starting any work. We could meet to discuss it at CSUN.
Hey All:

A face-to-face at CSUN would be awesome.  If we need to meet sooner, though, a concall might be a way to get through this quickly.

Will
Blocks: tablea11y
Depends on: 503727
I really don't think we have any major issue we should address since we've made accessible table reorganization. So there is nothing to deal with here. Closing this bug.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.