Skip to content
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

ContentSwitcher causes accessibility violation #5580

Closed
lee-chase opened this issue Mar 10, 2020 · 5 comments
Closed

ContentSwitcher causes accessibility violation #5580

lee-chase opened this issue Mar 10, 2020 · 5 comments

Comments

@lee-chase
Copy link
Member

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 carbon-design-system/carbon-components-vue#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

https://able.ibm.com/tools/token/ee371489-9723-4a53-8d41-cf3343313f8d/c556363d-beec-4512-8cf8-a8809f3860bb/archives/2019JulyDeploy//doc/w3/help/en-US/idhi_accessibility_check_g1146.html

Steps to reproduce the issue

See https://codepen.io/lee-chase/pen/bGdaxeZ

Coedpen content shows
image

Not sure why https://codesandbox.io/s/8wlh0 only shows
image

@tw15egan
Copy link
Collaborator

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

@carmacleod
Copy link
Contributor

carmacleod commented Mar 10, 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!

@emyarod
Copy link
Member

emyarod commented Mar 12, 2020

it seems we will need some design confirmation on which keyboard navigation pattern we should implement here cc @carbon-design-system/design

@aagonzales
Copy link
Member

I think it would work similiar to what we defined in this tab issue: #4758

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.

@asudoh
Copy link
Contributor

asudoh commented Mar 19, 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 asudoh closed this as completed Mar 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants