-
Notifications
You must be signed in to change notification settings - Fork 125
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
Comments
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. |
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? |
ARIA Section 7.6 State and Property Attribute Processing
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. |
## 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
* 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>
It is common practice when creating widgets using
aria-activedescendent
to setaria-activedescendent=""
until the component gets DOM focus.This is currently not allowed by the spec as
aria-activedescendent
needs to be an IDREFaria-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.
The text was updated successfully, but these errors were encountered: