368191 - Support ARIA activedescendant

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

Currently our solution for keyboard accessibility in DHTML requires actual focus to move to an element, instead of just styling it. This means using tabindex to make things like div/span focusable.

However, many apps such as Gmail don't move actual focus to the active item (such as a message in a message list). It would be a lot of work (probably a nightmare) to reengineer focus in these apps, which simply use CSS to put the appearance of focus on the item.

For this reason ARIA has borrowed the activedescendant concept from ATK/AT-SPI/IA2 etc. In those APIs usually a managesdescendants state is on the container, and the activedescendants is on the currently active child. Focus is on the container when the activedescendant child is taking keyboard input.

Howeve in ARIA this is simplified to just put an activedescendant="[id]" on the container.

We can:
1) Map this to focus in the various APIs, which will allow it to also work with MSAA-only screen readers.
2) Or we can map it to activedescendant in the ATK and the new IA2

I see #1 as the best choice because it will create consistency in how we expose our widgets, and not cause backward compatibility issues.

Comment 1

[Aaron Leventhal]

Attachment: Implement ARIA activedescendant

Comment 2

[Aaron Leventhal]

Testcase here (should work in about an hour when NOWRAP file gets updated):
http://www.mozilla.org/access/dhtml/listbox

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 258015 [details] [diff] [review]
Implement ARIA activedescendant

OK, looks good. I notice you've done a little Spring cleaning here which looks good too. I'm giving a conditional + because I'm not confident in my knowledge on a few things. I had to go read up on nsCOMPtr again because I was starting to get used to the getter_AddRefs + outparam pattern of functions. In other words I had to look up already_AddRefed<> as a return type which I am now liking. I'm asking some trivial questions below that may only result in my own benefit:

>+    // ARIA attributes
>+    if (aAttribute == nsAccessibilityAtoms::disabled ||
>+        aAttribute == nsAccessibilityAtoms::required ||
>+        aAttribute == nsAccessibilityAtoms::invalid) {
>+      // Universal boolean properties that don't require a role

What does universal mean in this context?

>+      eventType = nsIAccessibleEvent::EVENT_STATE_CHANGE;
>+    }
>+    else if (aAttribute == nsAccessibilityAtoms::activedescendant) {
>+      // The activedescendant universal property redirects accessible focus events
>+      // to the element with the id that activedescendant points to

Possible nit: I think the code speaks to some of this comment already. Maybe just put "// redirect focus event to activedescendant"?  Your preference.

>+  // Check for aaa:activedescendant, which changes which element has focus
>+  nsCOMPtr<nsIDOMNode> finalFocusNode = aNode;
>+  nsCOMPtr<nsIAccessible> finalFocusAccessible = aAccessible;
>+  nsCOMPtr<nsIContent> finalFocusContent  = do_QueryInterface(aNode);

Less than a nit: "final" gave me pause as it is a keyword in some languages. But its OK. I don't have a better prefix to offer as an alternative.

Comment 4

[Aaron Leventhal]

> What does universal mean in this context?
Some ARIA properties are only relevant for some roles. For example, the aaa:expanded  property is relevant for treeitem and perhaps a few others.
Other ARIA properties are usable with any role, and in fact don't even require that a role is present. An example is required. You can use it even on a plan HTML input without using any role attribute.

I didn't see anything from the nits that looked like something I felt compelled to change, but thanks for the ideas.

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

Aaron, thanks for the explanation.

Comment 6

[Aaron Leventhal]

This broke. Patch coming up.

Comment 7

[Aaron Leventhal]

Attachment: Updated the wrong variable

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 262928 [details] [diff] [review]
Updated the wrong variable

trival fix. looks harmless.

Comment 9

[David Bolter [:davidb] (NeedInfo me for attention)]

Aaron, by the way, I think activedescendant implies a descendant relation and the ARIA specs should require that. If a node has an activedescendant that is not a true descendant, then assigning focus becomes an issue and I think things may become unwieldy.

Comment 10

[Aaron Leventhal]

We resolved in PFWG that the UA shouldn't spend processing time to verify that it's a descendant. It's up to the author and testing tools to do that.