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
Just for a bit of context, the company I'm working for is using the react-select component, and recently, we've gone through an accessibility review in hopes of getting WCAG certified (2.0 version, A level). The reviewers flagged a few issues on our end, and some of the issues flagged concern our usage of the react-select component. We managed to resolve most of the issues by overriding default components, and the only thing we haven't been able to resolve is the aria-activedescendant attribute not having the correct value set. It should be set to the id of the focused option.
So the next step was to look into the code and see if we can fix it in react-select itself, but then we realized that react-select handles accessibility in a different way, not really following ARIA guidelines. That in turn means it's not compliant with the standard certification we plan to achieve (as far as we can tell, that is, by looking at the combobox example that matches our use case).
We found that we can fix our issue: I can open a PR in a somewhat worthy state that deals with the missing attribute and achieves compliance in that regard, but the solution doesn't deal with removing the custom messages that are being put in ARIA live region when options are focused (presuming that this is actually the complete, desirable solution). This leads to option label being read by the screen reader before reading the option selected message (more details on the eventual PR).
All of the above boils down to 2 questions really:
Is it possible to be WCAG compliant (version 2.0, A level) if using the react-select component?
Is it actually worth opening a PR that essentially deals with ARIA/WCAG compliance but leads to (not much, but still) worse screen reader experience?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello everyone!
Just for a bit of context, the company I'm working for is using the react-select component, and recently, we've gone through an accessibility review in hopes of getting WCAG certified (2.0 version, A level). The reviewers flagged a few issues on our end, and some of the issues flagged concern our usage of the react-select component. We managed to resolve most of the issues by overriding default components, and the only thing we haven't been able to resolve is the
aria-activedescendant
attribute not having the correct value set. It should be set to the id of the focused option.So the next step was to look into the code and see if we can fix it in react-select itself, but then we realized that react-select handles accessibility in a different way, not really following ARIA guidelines. That in turn means it's not compliant with the standard certification we plan to achieve (as far as we can tell, that is, by looking at the combobox example that matches our use case).
We found that we can fix our issue: I can open a PR in a somewhat worthy state that deals with the missing attribute and achieves compliance in that regard, but the solution doesn't deal with removing the custom messages that are being put in ARIA live region when options are focused (presuming that this is actually the complete, desirable solution). This leads to option label being read by the screen reader before reading the option selected message (more details on the eventual PR).
All of the above boils down to 2 questions really:
Thank you in advance.
Beta Was this translation helpful? Give feedback.
All reactions