aria-activedescendant and focus events

[pkra]

This is possibly more appropriate for https://github.com/w3c/uievents but that spec seems to currently focus on cataloguing UA behavior (cf. w3c/uievents#242 (comment)) so I'm hoping to start on this end (where it might just end).

The ARIA spec https://w3c.github.io/aria/#aria-activedescendant doesn't actually say anything about User Agent behavior but it seems to imply that aria-activedescendant should put the target in focus; it's specifically a technique to reduce the need of having to "manually" move focus (e.g., setting tabindex).

UI Events Spec https://w3c.github.io/uievents/#event-type-focus says a user agent "MUST dispatch this event when an event target receives focus".

From a quick test (Firefox, Chrome), focus events are not triggered if the element becomes the active descendant. I'm wondering if this is intentional or something that the group could work to improve long term.

[JAWS-test]

I think it should be clear to every developer that aria-activedescendant does not focus on the referenced object and therefore cannot trigger any events. The attribute can only be used to tell the AT which object is the active child element. It is the developer's job to take care of all other things, such as focus visibility, scrolling into the visible area, and event handling. This is also clearly defined for the first two points (see below). For the events this could be added.

When the container element receives DOM focus, draw a visual focus indicator on the active element and ensure the active element is scrolled into view (https://w3c.github.io/aria-practices/#kbd_focus_activedescendant)

Authors SHOULD also ensure that the currently active descendant is visible and in view (or scrolls into view) when focused (https://w3c.github.io/aria/#aria-activedescendant)

I don't think it's a good idea to change that. So far, all ARIA attributes and roles have no effect on the operation and output of web content as long as no AT is used. If aria-activedescendant would be able to trigger events on the referenced element, this would also affect keyboard users without AT. This would obsolete the current separation (between HTML, CSS and JS for users without AT and in addition ARIA for users with AT), which would cause a lot of confusion.

[pkra]

Thanks for the comment, @JAWS-test. It helped me realize that I was not unclear in my OP. I'm aware of the current status but wrote it as if I wasn't; my apologies for that.

I raised the issue primarily to talk about future improvements in this area but perhaps this was a poor attempt to do so.

This area has improved a lot in the past and other specs continue to improve authoring as well, so I see a lot of opportunity to simplify authoring and reduce potential issues.

[JAWS-test]

Hi Peter, there's no need to apologize at all. It's just my personal opinion that it's better that ARIA shouldn't change operation and visual output without AT. But maybe in the future ARIA will not only be for AT, but can influence the look and handling of HTML like CSS and JS.

This is a general discussion, which of course is especially useful for aria-activedescendant, because it would make a lot easier for the developers (besides events, also focus visibility and display in the visible area). Nevertheless, I'm sceptical whether it makes sense to follow such a path...

[jnurthen]

Not sure how well this is covered by core-aam but doesn't this kind of detail belong there rather than the ARIA spec?

[mcking65]

@jnurthen commented:

Not sure how well this is covered by core-aam but doesn't this kind of detail belong there rather than the ARIA spec?

No, this is squarely part of ARIA, and currently covered by 2.3.2 Information for User Agents.

I agree with @JAWS-test that we should not change the existing contract between ARIA and browsers.

In ARIA 2.0, when we consider control patterns, we might be able to negotiate a new contract that lets browsers do more lifting for widgets. We could do it in a way that would not impact any existing code by allowing authors to request that browsers provide keyboard and focus behaviors. This would give authors choices: 1) provide all the behaviors in JS or 2) request the browser provide some of the behaviors via specific attribute values.

[pkra]

@mcking65 @jnurthen thanks for your comments! ARIA 2.0 sounds like the right milestone to me.

[pkra]

More a note for myself: #1051 (currently) contains several relevant changes to this issue.

[carmacleod]

In case it's helpful, the ARIA spec does have a subsection on Information for User Agents to support aria-activedescendant (in the Managing Focus and Supporting Keyboard Navigation section). The events that must be fired are accessibility API focus events.

[pkra]

Closing this as part of #2151.