aria-activedescendent="" - what problem does this cause?

[jnurthen]

In a few of our frameworks aria-activedescendent is set to "" until the component takes focus. Once it gets focused then it gets set correctly to a valid idref.
I'm not sure from the spec whether an empty string is valid or not for aria-activedescendent, but I really don't think this causes an accessibility issue.
Any chance this error can be suppressed for aria-activedescendent unless the component actually has focus - when it of course needs to be valid.

[WilcoFiers]

Hi @jnurthen. Did you consider the scenario in which an AT users is reading though the page without shifting focus? Instructing NVDA for example to read from a given point on the page will not move focus automatically to elements it is reading.

[jnurthen]

Yes I have considered it. When the element does not have focus aria-activedescendent is not relevant. It is defined as being the currently active descendent of a composite widget. When the widget it not focussed there is no active descendent so the property is irrelevant.

It is not used when computing a value or selection for a widget (or at least it shouldn't be).

In any case, if this continues to give errors, the solution is to remove the attribute - which would clear the error, when there is no focus. I don't see how this would help any user and simply creates additional work for developers.

[MelSumner]

@jnurthen -

From the spec: The "undefined" value, when allowed on a state or property, is an explicit indication that the state or property is not set. The value is used on states and properties that support tokens, and the "undefined" value is a string that is one of the allowed tokens. It is also used on some states and properties that accept true/false values, when "undefined" has a different meaning than "false".

Based on that language, I would say that having an empty value for aria-activedescendent is therefore invalid, since it requires an ID and isn't a token or a true/false situation.

Here are some solutions to consider:

• if the element is dynamically introduced (triggered by something else), at the time when the element exists (and therefore the ID exists), the aria-activedescendant property should be added (along with the value) to the owning element.
• if the element is already rendered to the page when loaded, then there really is no reason to exclude the value for the aria-activedescendant property.

I hope this helps!

[jnurthen]

I agree that according to the spec as written it is not allowed - although the spec does make it clear in the text that aria-activedescendent is only relevant when the component has DOM focus. Its value is irrelevant when the component does not have focus.

I don't want to take up developer's time fixing issues which have no accessibility impact. Their time is better spent in other places.

I will log a bug against the ARIA spec to resolve it there.

[jnurthen]

Logged w3c/aria#501

[dylanb]

@jnurthen are you suggesting one of the following?

1. Look at document.activeElement and only validate aria-activedescendant for that element, or
2. That we ignore an empty aria-activedescendant only if the element is also not equivalent to document.activeElement but validate that non-empty values are valid even for elements that do not have current focus

I would be in favor of doing the second one because it would allow for useful testing of the end state of a bunch of focus behavior once whereas the first option would require calls to aXe sequentially for every element that could receive focus, or it would require us to set focus on each element that could receive it, before testing it (which has its own conditional usefulness/reliability issues).

Also, for context: are you using the extension or the API or both?

[jnurthen]

@dylanb The 2nd sounds reasonable.

Although I think it is potentially only a warning, not an error, for elements which aren't focused even if there is an invalid idref. I can see scenarios on combo boxes / autocomplete where the child elements get removed from the DOM once the list gets closed but the code doesn't clean up the invalid idref on the parent aria-activedescendant. Again - it would be better to clean it up - but I don't see what accessibility issue it would actually cause so long as everything gets reset once it gets focus again.

I really don't think aXe moving focus around the page is a good idea.

I'm normally using the extension.

[WilcoFiers]

I'm going to resolve this issue with #1007. @dylanb I'm not a fan of your suggestion to test that aria-activedescendant is non-empty when it's on document.activeElement. It's totally a smart idea, It also doesn't seem like a thing that we'll ever catch anything with. If you disagree we'll open an issue for it, but it should probably stay a low priority.

[carmacleod]

@WilcoFiers The APG combobox examples have empty aria-activedescendant on textbox when it is document.activeElement.

From Chrome DevTools Console:

document.activeElement
<input type=​"text" aria-autocomplete=​"list" aria-controls=​"ex1-listbox" id=​"ex1-input" aria-activedescendant>​

[Edit: Never mind - this comment in the ARIA spec issue says it's ok... sorry about that!]

[ediblecode]

Looks like that ARIA practices combox example has moved here for anyone reading this.