Closed Bug 403260 Opened 17 years ago Closed 17 years ago

ARIA Tree Views do not display the Active state

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dipalerm, Assigned: aaronlev)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110405 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110405 Minefield/3.0a9pre

Screen Readers require the MSAA Selected attribute in order to know which tree item is selected when the tree does not have the visual focus.

Reproducible: Always

Steps to Reproduce:
1.Open a page with an ARIA tree.
2.Focus on a tree item.
3.Note that Inspect does not show a selected state.
Actual Results:  
No selected attribute

Expected Results:  
Expected selected attribute
Assignee: nobody → aaronleventhal
Blocks: aria, fox3access
Component: Disability Access → Disability Access APIs
Keywords: access
OS: Windows XP → All
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Hardware: PC → All
I tested http://www.mozilla.org/access/dhtml/tree.

There when item is fouces then it looks like selected but in general it can be not correct. I mean focused is not selected because item can be current which isn't exposed as selected. It's rather bug of aria tree that should use selected attribute explicitly.
Surkov, I agree that's a possibility.

The idea I'm toying with is that for single select containers I'm thinking of mirroring selection to the last focus. That would save the authors some work. Many will forget to make selection mirror last focus.

We can find the last focused item in 3 ways:
1. Activedescendant, if that's used will point to it
2. If they use tabindex, it should be the item with tabindex="0" (all the other items would be tabindex="-1")
3. Once the container has had focus on a descendant once, we could cache the last focus and remember it on a per-container widget basis.

What do you think?
Aaron,
If I read you correctly, the selected state would be automatic.  Shouldn't it be author controlled.  I note that in Windows Explorer, selected happens with focus and the contents of the tree item are displayed automatically.  However, in the Dojo app, the contents are only displayed when the user presses Enter.  I think that the selected state should only be there when the content is actually displayed.
I'm proposing that for a single select container, the author would only need to control what the active item is in one place.

Many tree views do not require the pressing of a key to reveal content. It's contrary to what I've seen in tree views make the selected state depend on that. I also didn't hear Rob suggest that. What I heard on the call is they really want to know what the currently active item is.
How can I know the tree has single selection?

Why do we need to find last focused item? It's not the same like focused item, right?
Status: UNCONFIRMED → NEW
Ever confirmed: true
You can tell if it's a single select tree view if it doesn't have STATE_MULTISELECTABLE (in ARIA via aria_multiselectable="true")

In general we still need to think about this one. We might want to use STATE_ACTIVE for the last focused item, I we need to talk about the right approach, possibly with PFWG standards group.

We've decided to use STATE_ACTIVE for the current item.
Attached patch patch (obsolete) — Splinter Review
Assignee: aaronleventhal → surkov.alexander
Status: NEW → ASSIGNED
Attachment #291712 - Flags: review?(aaronleventhal)
This bug may be related to bug #395041 .
Comment on attachment 291712 [details] [diff] [review]
patch

1) It's not really just about tree views -- it's about any descendant widget of a container widget
2) The item or container might not actually currently be FOCUSED. This is the item that *would* get focused if the container is tabbed into.

There are 2 ways to determine this:
1) There is an ancestor which points to an item with activedescendant="[descendant-id]"
2) There is a container 0 or more items of tabindex="-1" and only one item of tabindex="0". This indicates which item will be tabbed when the user moves into the contaner.

For #2 I'm not sure when to consider a tabindex="0" item as active. I think it's okay if we support this only for case #1. After all, #2 seems a bit hacky. I'm not sure I want to document that we've done that.
Attachment #291712 - Flags: review?(aaronleventhal) → review-
(In reply to comment #10)
> (From update of attachment 291712 [details] [diff] [review])
> 1) It's not really just about tree views -- it's about any descendant widget of
> a container widget

What is a container widget? How can I recognize it?
(In reply to comment #11)
> (In reply to comment #10)
> > (From update of attachment 291712 [details] [diff] [review] [details])
> > 1) It's not really just about tree views -- it's about any descendant widget of
> > a container widget
> 
> What is a container widget? How can I recognize it?
> 

Ah, #1 and #2? I'm sleeping already :(
A container widget is something that typically has child/descendant widgets, such as a tree, a spreadsheet, a listbox, a tabpanel, a radio group, etc.

Type #1 use activedescendant to manage focus in the descendants. See http://www.mozilla.org/access/dhtml/listbox for an example

For type #2, a script ensures that all focusable descendants of the container get tabindex="-1", except for the current item which has tabindex="0". As the user moves around the script must update the tabindex property. Here's an example: http://www.mozilla.org/access/dhtml/tree

When activedescendant is used (#1), it is set on a container. Therefore whenever activedescendant points to some ID, the object with that ID should be marked with the ACTIVE state. If that can be done efficiently it takes care of #1

In the tabindex case (#2), we don't currently have a good way of know what is a container. We could make each widget and nsRoleMapEntry for declaring that. However, for now I don't think we should handle the tabindex case.
I'm not sure we should expose the tabindex magic in Firefox. It seems to be too smart. If ARIA widget is complex enough to work with tabindex then it can work easy with activedescendant too. For this I would suggest to map activedescedant into active state. Should we fire focus event as we do now when activedescedant is changed? Does focus in browser is changed as well?

Another problem we should recognize container widgets to set active state on its descendant. Probably it's worth to check roles. In that case we will handle XUL widgets as well. (for example, in my patch ARIA and XUL trees are handled both).
Wre already fire focus event when activedescendant changes.

The only thing we don't do is mark the current item with ACTIVE.

- Aaron
Assignee: surkov.alexander → aaronleventhal
Status: ASSIGNED → NEW
Summary: ARIA Tree Views do not display the Selected Attribute → ARIA Tree Views do not display the Active state
Attachment #291712 - Attachment is obsolete: true
Attachment #291880 - Flags: review?(surkov.alexander)
Patch looks ok. But it isn't bug fix, right? because here neither ARIA nor XUL widget are addressed. If their items has a focus then we should report active state.

Also when activedescedant attribute is changed then we fire focus event. So we can get easy we report about wrong focus change since real focus is somewhere else. Should we ensure the focus is on the right node?
> Also when activedescedant attribute is changed then we fire focus event. So we
> can get easy we report about wrong focus change since real focus is somewhere
> else. Should we ensure the focus is on the right node?
We already do that. The activedescendant mapping to focus already works the way it should. Only if the element with the activedescendant attribute has focus does the activedescendant attribute matter.
> neither ARIA nor XUL widget are addressed. 
> If their items has a focus then we should report active state.

XUL isn't important for now. We need this for the virtual buffer modes of screen readers. In that case they allow the user to review the widgets in a page even when they are not actually focused.

ARIA is addressed by this patch.

It's true that for completeness we can do more, but from a practical point of view, I think this patch is a good start and is all we really need now.
Comment on attachment 291880 [details] [diff] [review]
Support ACTIVE state when ancestor's aria-activedescendant points to ARIA object

(In reply to comment #19)

> It's true that for completeness we can do more, but from a practical point of
> view, I think this patch is a good start and is all we really need now.
> 

Sure. Would you like to post new bug(s) or will I do this?
Attachment #291880 - Flags: review?(surkov.alexander) → review+
Attachment #291880 - Flags: approval1.9?
That would be great if you would file it. Please mark it as blocking the "nice to haves" accessibility bug (bug 376943, short name nicea11y)
Comment on attachment 291880 [details] [diff] [review]
Support ACTIVE state when ancestor's aria-activedescendant points to ARIA object

a=drivers for when trunk opens after Fx3 Beta 2 freeze
Attachment #291880 - Flags: approvalM10-
Attachment #291880 - Flags: approval1.9?
Attachment #291880 - Flags: approval1.9+
(In reply to comment #21)
> That would be great if you would file it. Please mark it as blocking the "nice
> to haves" accessibility bug (bug 376943, short name nicea11y)
> 

the bug 407597.
Fixed.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: