You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rather than stating that making this proposal accessible would be intractable, which might be wrong, I would like instead to provide some resources that explain accessibility requirements for at least two patterns, so they can be contrasted.
My current concerns include at least the following:
that aria-controls and aria-activedescendant are difficult to maintain, because they depend on selectors that do not yet match.
it's not always clear when an element is aria-selected when it's the element which sets the toggle (or whether the element is aria-selected or aria-expanded.
supporting keyboard interactions are very important for these patterns to be accessible, but it seems difficult to do with the current proposal, or at least would still have to be manual, which the current input:checked pattern supports by default due to the nature of the input element.
I'd also like to mention that our group in open ui chose not to ship and propose our functional element which did all of this because there was some accessibility concern that perhaps many many of examples found in the wild where we expected this would be deployed might be made worse by using the aria tabs pattern. There's some support for a differently named pattern for this, tho we've not entirely worked out the details which could let us test this openui/open-ui#559
Rather than stating that making this proposal accessible would be intractable, which might be wrong, I would like instead to provide some resources that explain accessibility requirements for at least two patterns, so they can be contrasted.
Tab Panel:
Radiogroup:
Accordion:
We can discuss here how these things should be achieved?
The text was updated successfully, but these errors were encountered: