Skip to content

Conversation

@smhigley
Copy link
Contributor

@smhigley smhigley commented Jun 3, 2021

Resolves #1440

This is a proof of concept for allowing secondary actions in composite widget roles, and relies on the changes in #1454.

The relevant changes in this PR are these additional terms:

Controlled Element
A 'controlled element' is any element referenced by id via aria-controls.

Controlling Element
A 'controlling element' is any element with an aria-controls attribute which references the ID of the element.

And this addition to the allowed child roles of listbox, as an example:
<li><rref>button</rref> if <a>controlling</a> a child <rref>option</rref></li>


Preview | Diff

@smhigley smhigley marked this pull request as draft June 3, 2021 10:56
@JAWS-test
Copy link
Contributor

I don't understand the concept yet: the button should be on the same level in the DOM as option (as a child of listbox)? I assumed so far that the buttons should be child elements of option and the listbox contains only options.
For me the following questions would be open:

  • How is a listbox with option and buttons operated with the keyboard?
  • Can the Accessbility APIs handle buttons inside listbox at all?

@smhigley
Copy link
Contributor Author

smhigley commented Jul 1, 2021

Test page for support of nested vs. sibling action buttons is here: https://a11y-screenreader-demos.netlify.app/studies/secondary-actions/
(cc/ @joanmarie)

(updated w/ actual link, because I fail at copy/paste 😅)

@smhigley
Copy link
Contributor Author

Closing in favor of aria-actions (#1805)

@smhigley smhigley closed this Sep 16, 2022
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

Successfully merging this pull request may close these issues.

Secondary actions on items in composite widget roles

3 participants