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
Tabs accessibility #1446
Comments
Long time fan, first time caller. I want to figure out what makes the most sense, since I’ve never contributed here. The To satisfy this issue it might make sense to make a new Thankfully, the components are all flexible enough that the developer can (and should?) add and manage the necessary WCAG compliant attributes and behavior. I also took a look at the thread for #1013, which seems to align with this way of thinking. Perhaps this is just a matter of adding documentation and/or showing an example of a WCAG compliant implementation. Thoughts? TL;DR: This might just be a matter of adding documentation and/or examples as discussed on #1013. This project is great because of its flexibility. I would argue that the developer should be in control of WCAG compliant attributes and behavior in this case. A possible alternative would be a new |
Many points mentioned by @hoslersk are important, e.g.:
There are a few things that should be handled by reactstrap where possible. Ensure
|
Hey guys, I have a few doubts in regards to this issue. I would also consider implementing new components for affording tab and tablist roles for the elements. However, this still leaves the issue description part in regards to keyboard interaction. In order to implement standard ARIA keyboard interaction for this component, I think we would need a container element which aggregates the tab list, tab and tabpanel elements. And this component should manage all the interaction for the Tab Widget, with clicks, keyboard interaction and focus management. I think this behavior would dramatically change the behavior of the current Tab Widget, which lets up to developers to implement the Widget behavior. Even so, do you guys think this would be still cool for the project? If you guys agree to this, I can try to implement that. |
TabContent
,TabPane
,Nav
7.1.0
^16
^4
What is happening?
Tab panels created using existing components doesn't follow w3c recommendations.
What should be happening?
It should follow https://www.w3.org/TR/wai-aria-practices/#tabpanel
To summarize:
tablist
,tab
,tabpanel
, and have aria attributes to indicate relationships.Dropdown
currently has.Steps to reproduce issue
The text was updated successfully, but these errors were encountered: