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
I think a human can guess which inputs each button belongs to, but it's not entirely clear. It's also annoying to write unit tests if (for some reason) the unit tests wants to (for example) click the decrement button of the second NumberInput.
(2) VoiceOver
Although JAWS and NVDA will skip over the buttons, VoiceOver will not. This seems suboptimal for VoiceOver users that have no interest in those buttons.
Possible solutions
(3) How about setting aria-hidden around the buttons?
I don't think this works, it's problematic to have interactive controls inside an aria-hidden block.
(4) How about wrapping the whole thing in a <fieldset>?
Package
@carbon/react
Browser
Chrome
Operating System
MacOS
Package version
1.69.0
React version
18
Automated testing tool and ruleset
VoiceOver
Assistive technology
No response
Description
NumberInput explicitly renders the increment and decrement buttons using the
<button>
element.These buttons are useless to keyboard users since keyboard users can increment/decrement the value with the up and down arrow keys.
The buttons have
tabindex=-1
so they aren't in the tab-navigation, but they still have various accessibility issues.Acccessibility issues
(1) Ambiguity
If we have multiple
NumberInput
components they will essentially render like this:I think a human can guess which inputs each button belongs to, but it's not entirely clear. It's also annoying to write unit tests if (for some reason) the unit tests wants to (for example) click the decrement button of the second NumberInput.
(2) VoiceOver
Although JAWS and NVDA will skip over the buttons, VoiceOver will not. This seems suboptimal for VoiceOver users that have no interest in those buttons.
Possible solutions
(3) How about setting
aria-hidden
around the buttons?I don't think this works, it's problematic to have interactive controls inside an
aria-hidden
block.(4) How about wrapping the whole thing in a
<fieldset>
?I don't like that either, it's problematic because the label is repeated twice.
(5) Styling buttons
Therefore, my suggestion is to the browser's native buttons, but style them how carbon wants them, i.e. NumberInput simply becomes
And then all the magic happens in
cds--number__input
.See https://stackoverflow.com/questions/45396280/customizing-increment-arrows-on-input-of-type-number-using-css.
It sure looks possible.
WCAG 2.1 Violation
No response
Reproduction/example
https://react.carbondesignsystem.com/?path=/story/components-numberinput--default
Steps to reproduce
N/A
Suggested Severity
None
Code of Conduct
The text was updated successfully, but these errors were encountered: