Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow null value of aria-activedescendent when element does not have DOM focus #501

Closed
jnurthen opened this issue Dec 14, 2016 · 3 comments
Assignees
Milestone

Comments

@jnurthen
Copy link
Member

It is common practice when creating widgets using aria-activedescendent to set aria-activedescendent="" until the component gets DOM focus.
This is currently not allowed by the spec as aria-activedescendent needs to be an IDREF

aria-activedescendent is only relevant when the component has DOM focus as such I propose that we allow an undefined value when the component does not have focus.

I prefer this to the alternative of developers adding the attribute and its value the first time it gets focus, as it gives an easy way to browse the DOM in inspection tools and easily know which type of focus model each composite widget is using - even before they have been focused.

@mcking65
Copy link
Contributor

Why not even if it has focus?

Consider a combo where activedescendant is set on the text field and DOM focus is on the text field. When typing in the text field, activedescendant is null but when down arrow is pressed then it gets set to the idref of an element in the popup. Then, there can be a variety of conditions where we want AT focus to be back on the text field and activedescendant can be null again. The entire time, DOM focus is on the text field.

It seems like allowing null values in this case would be useful.

@AmeliaBR
Copy link
Contributor

This seems reasonable, but a question:

How would you describe the semantic meaning of having the attribute with an empty value? A kind of flag that this element can have active sub-components, even if none of them are currently active? Or should it just be treated as equivalent to the attribute not being there?

@mcking65
Copy link
Contributor

ARIA Section 7.6 State and Property Attribute Processing
states:

Sometimes states and properties are present in the DOM but have a zero-length string ("") as their value. This is equivalent to their absence. User agents should treat state and property attributes with a value of "" the same as they treat an absent attribute. For supported states and properties, this corresponds to the default value, but if it is a required attribute, it signals an author error, and the implicit value for the role is used.

Since aria-activedescendant is never a required property, shouldn't the empty string be treated as if the attribute is not present?

I don't see anything in the spec that disallows an undefined value for aria-activedescendant or any other non-required property that has an IDREF as its value.

@jnurthen jnurthen added this to the ARIA 1.2 milestone Dec 4, 2018
@jnurthen jnurthen self-assigned this Dec 4, 2018
jnurthen added a commit that referenced this issue Jan 11, 2019
jnurthen added a commit that referenced this issue Jan 23, 2019
e-cooper pushed a commit to pingidentity/astro that referenced this issue Dec 13, 2023
## Describe your changes
aria-activedescendant was not updating after the the popover closed, creating a a11y violation due to the property being set to an id that is not active on the DOM. This specific use case only happened after the popover menu was previously opened and the attribute being set. 

- changed default state to empty string instead of null, this [comment](w3c/aria#501 (comment)) in the ARIA spec issue says empty string is preferred to null.
- if popover closes, setting aria-activedescendant to empty string
- Created new test to account aria attributes updating after popover closes.
## Any testing tips
1. Go to [MultivaluesField](http://localhost:6006/?path=/story/form-multivaluesfield--default)
1. Click inside the field to expand the list.
1. Click “Run test” button in the right bottom corner.
    - also try closing popover menu after it's been open and an option had been previously highlighted and confirm tests pass without violation
1. Verify that the test completed without violations.

## Checklist before requesting a review
- [x] I have performed a self-review of my code
- [x] I have added tests for any new or fixed functionality to prevent regressions
- [ ] I have added clarifying code comments to blocks which other devs may have questions on

Closes UIP-6452
nico-amsterdam pushed a commit to nico-amsterdam/awesomplete that referenced this issue Apr 27, 2024
nico-amsterdam pushed a commit to nico-amsterdam/awesomplete that referenced this issue Apr 27, 2024
nico-amsterdam pushed a commit to nico-amsterdam/awesomplete-util that referenced this issue Apr 27, 2024
LeaVerou pushed a commit to LeaVerou/awesomplete that referenced this issue Jul 25, 2024
* fixes issus #17252. a11y improvements. fix Talkback item selection. i18n for the status text.

* fixes issues of #17252. a11y improvements. fix Talkback item selection. i18n for the status text.

* Make aria-activedescendant empty when none is selected. see w3c/aria#501 (comment)

* Make aria-activedescendant empty when none is selected. see w3c/aria#501 (comment)

* Transformation must end with visibility hidden. Fixes tab navigation to hidden li item

* Also in css leading tab characters. After css transition everything in the suggestion list must be hidden and for example links in suggestions should not be in the tab sequence anymore

* Fixes issue of #17255. Tab navigation when suggestions are shown is wrong

---------

Co-authored-by: Nico <[email protected]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants