feat(FocusMonitor): Add optional `checkActiveDescendant` option to `FocusMonitor.monitor`

[zelliott]

Feature Description

Today, FocusMonitor listens for focus changes and attributes them to a particular input modality. It would also be useful to be able to listen for changes in aria-activedescendant changes and attribute them appropriately as well. To support this, we can extend FocusMonitor.monitor with an optional checkActiveDescendant parameter that, when true, will listen for changes in the focused element's aria-activedescendant property with a MutationObserver.

Use Case

In my app, we render strong keyboard focus indicators only on keyboard focus. We determine this by attaching a FocusMonitor to body with checkChildren = true. When the class .cdk-keyboard-focused is present on the body, we know that keyboard input modality has been detected.

This works for most cases. However, consider the following scenario with the MatAutocomplete component.

1. User clicks on MatAutocomplete input.
2. Autocomplete options render below the input.
3. User presses down arrow to navigate to the first option.

At step 1, we do not want to render a strong focus indicator (as the user is interacting with mouse). At step 3, we do want to render a strong focus indicator on the first option (as the user is now interacting with keyboard). However, FocusMonitor does not support this scenario today, as no focus change has occurred. Instead, the aria-activedescendant on the focused <input /> element has updated. We want to be able to detect this change.

Implementation Details

I'm thinking we can support this in FocusMonitor via the following changes:

• On FocusMonitor._onFocus, create a new MutationObserver that listens for aria-activedescendant changes on the focused element (if checkActiveDescendant is true). Additionally, if a created MutationObserver already exists, disconnect the existing observer. This means that there should only ever be one MutationObserver at any point in time, as we only need to observe the document.activeElement. This also means that if aria-activedescendant changes on an element that is not focused, this will not be detected (I think this is fine).
• When the observer callback is fired, update the focus origin accordingly.
• On FocusMonitor._onBlur, disconnect the existing observer (again if checkActiveDescendant is true).

[zelliott]

@crisbeto, @mmalerba, any thoughts? Happy to contribute this myself.

[crisbeto]

Assuming that you clear aria-activedescendant when none of the descendants are active, wouldn't the proposed feature be the equivalent of targeting .foo[aria-activedescendant] in the your CSS?

[zelliott]

You might need to clarify your proposal, but if I understand correctly, I think there are a few issues:

• The host element with [aria-activedescendant] isn't guaranteed to be a parent of the active option (take MatAutocomplete and MatSelect, for example). Thus, in step 3 of the use case above, even though [aria-activedescendant] is present on the host (actually it's present at step 2), there's still no way to write a CSS selector for the option that only selects when [aria-activedescendant] is present.
• As mentioned above, [aria-activedescendant] is present on the host when the options dropdown render, at least for MatAutocomplete and MatSelect. This means that if a user clicks on a MatAutocomplete input, [aria-activedescendant] will be present on the host (rightly so)... but we don't want to render strong focus indicators. So the existence of [aria-activedescendant] doesn't quite map nicely with whether a user is using a keyboard input modality.

[crisbeto]

I suppose I'm confused about which element would have the focused class. If we take MatSelect as an example, would it be on the select trigger or the MatOption which is the active descendant, given that FocusMonitor.monitor is called on the select?

[zelliott]

The document.body actually has the focused class, in our case. From the use case above:

In my app, we render strong keyboard focus indicators only on keyboard focus. We determine this by attaching a FocusMonitor to body with checkChildren = true. When the class .cdk-keyboard-focused is present on the body, we know that keyboard input modality has been detected.

[crisbeto]

So at a high level, the new option would look for any child with aria-activedescendant and set the appropriate focus class on the monitored parent? If that's the case, my concerns are:

1. Performance could suffer since we can end up monitoring a very deep DOM tree (potentially the entire DOM) with a MutationObserver.
2. Can we actually guarantee that the focus origin will be picked up correctly? The current approach works because all the events are synchronous. I don't know if we can make the same assumptions with MutationObserver.

[zelliott]

Not quite, the MutationObserver will only need to monitor changes in aria-activedescendant on the currently focused element (my assumption here is that changes in aria-activedescendant on an element when that element isn't focused is an a11y smell and not something we need to handle). Only a single node will ever be monitored with the MutationObserver (per instance of FocusMonitor). I tried to spell this out in the "Implementation Details" section in my original post.

1. For the reason above, performance shouldn't be a concern.
2. I'll have to test, but I think it should be fine? The MutationObserver's callback shouldn't fire until the aria-activedescendant property actually changes, and the property shouldn't change until the user clicks, keyboards to, or touches a given option, which would cause the associated keydown/mousedown/touchstart event to be fired, and for the focus origin to be set appropriately.

[jelbourn]

Thinking about this, my instinct is that FocusMonitor probably shouldn't get into the business of looking at the things that aren't, well, focus. An alternative would be introducing a second type of observer like ActiveDescendantObserver. We've got the foundation for something like this in CdkContentObserver; it would be about the same thing from an implementation standpoint.

That got me thinking, though, do we really need to monitor activedescendant changes, since we should ostensibly have control over the components that are setting that attribute in the first place? Would it accomplish the same goal if FocusMonitor had an API like focusMonitor.reset() that would clear cdk-keyboard-focus from whatever has it, hiding the indicator for the autocomplete case you described?

[zelliott]

Thinking about this, my instinct is that FocusMonitor probably shouldn't get into the business of looking at the things that aren't, well, focus.

Yeah, this is probably my biggest hesitation to this FR. It's worth mentioning however that, as you know, focus and aria-activedescendant are intimately related. The latter doesn't even make sense without the former. aria-activedescendant is really "an alternative means of managing focus" (https://www.w3.org/TR/wai-aria-1.1/#aria-activedescendant). It's a shame that their names are so differently... maybe aria-activedescendant should've been aria-focused or something. It's a bummer that, if I use FocusMonitor with a Select widget that moves DOM focus between its options, the FocusMonitor will work wonderfully, but if I use FocusMonitor with a Select widget that moves aria-activedescendant between its options, I have no mechanism for determining input modality.

An alternative would be introducing a second type of observer like ActiveDescendantObserver.

Hm... if we introduced an ActiveDescendantObserver that did basically the same thing as FocusMonitor but tracked aria-activedescendant, it wouldn't really make sense for it to apply the same set of cdk-{keyboard|mouse|touch}-focused classes (it doesn't make sense for ActiveDescendantObserver to apply "focus" classes). You'd want to either rename the classes to be non-focus related (i.e. change from cdk-keyboard-focused -> cdk-keyboard-origin), or have ActiveDescendantObserver apply its own set of "input modality" classes. The two services would also essentially share all of the logic to determine input modality. Is this inline with what you are proposing or something different?

Would it accomplish the same goal if FocusMonitor had an API like focusMonitor.reset() that would clear cdk-keyboard-focus from whatever has it, hiding the indicator for the autocomplete case you described?

I may be missing something, but I don't see how this addresses the use case in my original post. At step 3, when the user presses down arrow to navigate to the first option, how exactly does focusMonitor.reset() allow us to attribute the change in aria-activedescendant as "keyboard", and thus render a focus indicator on the option?