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)
Core
Disability Access APIs
Tracking
()
RESOLVED
FIXED
People
(Reporter: dipalerm, Assigned: aaronlev)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(2 files, 1 obsolete file)
1.58 KB,
patch
|
surkov
:
review+
beltzner
:
approvalM10-
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
6.03 KB,
patch
|
Details | Diff | Splinter Review |
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 | ||
Updated•17 years ago
|
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
Comment 1•17 years ago
|
||
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.
Assignee | ||
Comment 2•17 years ago
|
||
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?
Reporter | ||
Comment 3•17 years ago
|
||
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.
Assignee | ||
Comment 4•17 years ago
|
||
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.
Comment 5•17 years ago
|
||
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
Assignee | ||
Comment 6•17 years ago
|
||
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.
Assignee | ||
Comment 7•17 years ago
|
||
We've decided to use STATE_ACTIVE for the current item.
Comment 8•17 years ago
|
||
Assignee: aaronleventhal → surkov.alexander
Status: NEW → ASSIGNED
Attachment #291712 -
Flags: review?(aaronleventhal)
Comment 9•17 years ago
|
||
This bug may be related to bug #395041 .
Assignee | ||
Comment 10•17 years ago
|
||
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-
Comment 11•17 years ago
|
||
(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?
Comment 12•17 years ago
|
||
(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 :(
Assignee | ||
Comment 13•17 years ago
|
||
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.
Comment 14•17 years ago
|
||
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).
Assignee | ||
Comment 15•17 years ago
|
||
Wre already fire focus event when activedescendant changes. The only thing we don't do is mark the current item with ACTIVE. - Aaron
Assignee | ||
Updated•17 years ago
|
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
Assignee | ||
Comment 16•17 years ago
|
||
Attachment #291712 -
Attachment is obsolete: true
Attachment #291880 -
Flags: review?(surkov.alexander)
Comment 17•17 years ago
|
||
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?
Assignee | ||
Comment 18•17 years ago
|
||
> 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.
Assignee | ||
Comment 19•17 years ago
|
||
> 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 20•17 years ago
|
||
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+
Assignee | ||
Updated•17 years ago
|
Attachment #291880 -
Flags: approval1.9?
Assignee | ||
Comment 21•17 years ago
|
||
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 22•17 years ago
|
||
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+
Comment 23•17 years ago
|
||
(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.
Assignee | ||
Comment 24•17 years ago
|
||
Assignee | ||
Comment 25•17 years ago
|
||
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.
Description
•