Carbon: ContentSwitcher causes accessibility violation
Use of aria-selected is inappropriate for a button (Switch element) we probably should be using aria-expanded. See https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role
Detailed description
10.10
Carbon Vue originally raise https://github.com/carbon-design-system/carbon-components-vue/issues/849
What did you expect to happen?
Not to have a violation reported
What happened instead?
One was reported
What WCAG 2.1 checkpoint does the issue violate?
The WAI-ARIA role(s) and/or attribute(s) must be valid for the relevant element
Steps to reproduce the issue
See https://codepen.io/lee-chase/pen/bGdaxeZ
Coedpen content shows
Not sure why https://codesandbox.io/s/8wlh0 only shows
lee-chase
All 5 comments
cc @carmacleod , would aria-expanded make sense on this button element? It seems like the button is triggering an adjacent HTML element to be visible, so I'm not sure how to properly convey this for a11y purposes
tw15egan
on 10 Mar 2020
Isn't this a tabpanel pattern, and the buttons are tabs?
If you put role="tab" on the button, the violation should go away because aria-selected attribute is allowed on an element with role tab.
But there's a bit more to it than that... ;)
Here's the tabpanel pattern in the APG (also called _Tabs_).
Please read through all of section _3.23 Tabs_ (including the _Examples_, _Keyboard Interaction_, and _ARIA Roles, States and Properties_ subsections) and decide if it's what you are creating.
If you go with this pattern, please carefully re-read that section about WAI-ARIA Roles, States, and Properties to make sure you get the aria markup just right, because screen readers are picky. ;)
The 2 example pages show slightly different keyboard handling, depending on whether or not the tabpanel content is shown when the button is "selected (focused)" or when it is "pressed" - you decide which one to use after reading the pattern information (fyi, your codepen example works like the "Manual Activation" one, which may or may not be what you want for your production content switcher). Remember to add arrow key handling for the buttons if you are going with this pattern (i.e. _instead of_ using tab key; i.e. the buttons need tabindex="-1" when they're not selected). Screen reader users will expect arrows to work as soon as they hear they are in a tablist or tabpanel, and keyboard users will know to use arrow keys to change the content, and they will expect that using the tab key navigates to the content instead of tabbing through all of the tabs in the tablist before getting to the content.
After trying out the examples, please scroll further down the example page to see the actual Keyboard Support for each example, followed by the Role, Property, State, and Tabindex Attributes used in the example, followed by the Source Code.
Good luck!
carmacleod
on 10 Mar 2020
it seems we will need some design confirmation on which keyboard navigation pattern we should implement here cc @carbon-design-system/design
emyarod
on 12 Mar 2020
I think it would work similiar to what we defined in this tab issue: https://github.com/carbon-design-system/carbon/issues/4758?email_token=ACZBKZVAPHXXZ32VOFBLUDLRG2YB3A5CNFSM4JQULO72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEONJESI#issuecomment-591662065
We'd want tabpanel content to be shown when the button is "pressed" so that the user can easily cycle through the tab options before reading/navigation the tabpanel content.
aagonzales
on 12 Mar 2020
The DAP error is not observed in https://carbon-components-react.netlify.com/iframe.html?id=contentswitcher--default or https://the-carbon-components.netlify.com/component/content-switcher--default.html as a11y roles are set as guided. Created #5657 for keyboard navigation (thanks @carmacleod and @aagonzales for the guidance!).
asudoh
on 19 Mar 2020
Related issues
JordanWSmith15
·
3Comments
jendowns
·
3Comments
antonmc
·
3Comments
skaparelos1
·
3Comments
AnthumChris
·
3Comments
Most helpful comment
Isn't this a tabpanel pattern, and the buttons are tabs?
If you put
role="tab"on the button, the violation should go away becausearia-selectedattribute is allowed on an element with roletab.But there's a bit more to it than that... ;)
Here's the tabpanel pattern in the APG (also called _Tabs_).
Please read through all of section _3.23 Tabs_ (including the _Examples_, _Keyboard Interaction_, and _ARIA Roles, States and Properties_ subsections) and decide if it's what you are creating.
If you go with this pattern, please carefully re-read that section about WAI-ARIA Roles, States, and Properties to make sure you get the aria markup just right, because screen readers are picky. ;)
The 2 example pages show slightly different keyboard handling, depending on whether or not the tabpanel content is shown when the button is "selected (focused)" or when it is "pressed" - you decide which one to use after reading the pattern information (fyi, your codepen example works like the "Manual Activation" one, which may or may not be what you want for your production content switcher). Remember to add arrow key handling for the buttons if you are going with this pattern (i.e. _instead of_ using tab key; i.e. the buttons need
tabindex="-1"when they're not selected). Screen reader users will expect arrows to work as soon as they hear they are in a tablist or tabpanel, and keyboard users will know to use arrow keys to change the content, and they will expect that using the tab key navigates to the content instead of tabbing through all of the tabs in the tablist before getting to the content.After trying out the examples, please scroll further down the example page to see the actual Keyboard Support for each example, followed by the Role, Property, State, and Tabindex Attributes used in the example, followed by the Source Code.
Good luck!