downshift-js
Please don't add help text to live region when combobox drops down
Remove the a11y status message functionality from the hooks
- [ ] remove getA11yStatusMessage from useSelect.
- [ ] remove getA11ySelectionMessage from useSelect.
- [ ] remove getA11yStatusMessage from useCombobox.
- [ ] remove getA11ySelectionMessage from useCombobox.
- [ ] remove getA11yRemovalMessage from useMultipleSelection.
- [ ] check that status message still works in Downshift.
- [ ] update documentation to instruct developers to use onStateChange and any aria-live technique if they wish to maintain the previous functionality.
- [ ] merge to v9 branch with migration guide updated.
Original Message:
Please do not add the following "help/hint text" to the a11y-status-message live region when a combobox is dropped down:
"6 results are available, use up and down arrow keys to navigate. Press Enter key to select."
Screen reader users can usually turn off the help/hint text for their screen reader (as soon as they become proficient with it) in order to reduce verbosity, and since they wouldn't be able to turn this off, it would get annoying pretty quickly. :)
Regarding "6 results are available":
- Browsers are required to calculate aria-setsize and aria-posinset for things like options in a listbox. This allows AT to say things like "Beans, 3 of 6", "Rice, 4 of 6". So this info is already available to the screen reader user.
Regarding "use up and down arrow keys to navigate. Press Enter key to select.":
- role="combobox" communicates this fully without adding any words, i.e. as soon as the user hears "combobox", they already know to use up/down arrow and enter (plus some other keys as well, like home/end).
Please also see this comment, which contains screen reader output showing that this particular live region content is verbose and unnecessary.
This is great feedback @carmacleod! I believe this feature is based on a JQuery combobox implementation which was probably added before this was supported. We should move forward and remove the status text.
I see that you are still using Downshift. What's preventing your from moving to useCombobox? Issues or lack of support for some features?
Hey @silviuaavram! 👋 I can definitely answer from the Carbon side of things.
For context, Carbon is a design system built by IBM and we are currently on our v10.x release (10.0.0 was released ~2 years ago). One of our constraints for this release was that we needed to maintain the current major version for a couple of years. Thankfully we'll be able to move forward to v11 this year 🥳
As a result of this constraint, when updating downshift to newer major versions we had to be careful about doing it in a backward-compatible way. Thankfully most of our components that leverage Downshift have shifted over to the hooks variant with combobox being the last one to move over.
Also, just wanted to say thanks to all the contributors and maintainers of this library and ecosystem. It really helped us out over the years and we all appreciate the hard work that went into this project by everyone involved ❤️
Thank you for the feedback, I'm really happy that it is helping you.
I will keep this task to track the removal of the a11y status message, for the hooks. I prefer to leave Downshift as it is in terms of functionality, and move forward with the hooks.
Will update on the status of this work. Thanks again!
Just wanted to +1 the idea of removing the live region - I get announcements No results are available before a network query has finished fetching the results for the combobox.
Looking for a way to work around this at the moment with a custom environment - would be nice to have the a11y status message removed altogether.
You already have a prop getA11yStatusMessage that you can use to customise your use case. Feel free to use our default implementation and also add a case for your network condition: if (network.isLoading) return ‘loading results’.
On Thu 5. 8. 2021 at 12:33, Domantas Jurkus @.***> wrote:
Just wanted to +1 the idea of removing the live region - I get announcements No results are available before a network query has finished fetching the results for the combobox.
Looking for a way to work around this at the moment with a custom environment - would be nice to have the a11y status message removed altogether.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/downshift-js/downshift/issues/1244#issuecomment-893312416, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWAZAHVBPCV35KUGLLDG3TT3JLGVANCNFSM4YNS35RA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
getA11yStatusMessage fits my needs perfectly, thank you - oddly, the live docs page do not describe the prop, although I can see it in the readmes for the hooks 🤔 maybe some documentation got stale? (apologies for side-tracking the original issue)
Is there any way to remove the <div id="a11y-status-message" ...> element entirely? We're using useCombobox but also don't have a need for this live region. I'm currently returning an empty string from getA11yStatusMessage, but the element is still rendered.
We will remove this functionality from all hooks, since it's not considered necessary anymore. Since it's going to be breaking, it will land in v9. WIP for now.
We will remove the props (all getA11y callbacks) and the status div generated by the hook.
If developers would still need a status aria message announcement, they can add their own using the onStateChange callback and any aria live technique. We will also mention this in the documentation, as well as in the next migration guide.
Thanks eveyone!
For what it's worth, I have just come across an issue with the existing a11y-message implementation and specifically how updateA11yStatus is debounced. In my application, I have one dropdown on a page that modifies the available options for another dropdown further down the page. (This isn't ideal from an accessibility standpoint, but the WCAG docs do say we can do that if we warn users that it's going to happen, and it will take a while before we can design out all the instances of it across multiple applications.) I wanted to write a custom getA11ySelectionMessage function that would determine when it's one of those incidentally changed dropdowns rather than the one the user is interacting with so that only the desired ${itemToString(selectedItem)} has been selected. gets printed to the a11y-message div. However, due to the debouncing, none of the other getA11ySelectionMessage functions even get called except for the last one, which is the one I don't want to announce. If Downshift called those getA11yMessage functions instead of passing them to updateA11yStatus and then ignored them if they returned, say, undefined, this plan would work. But right now the agency from each individual dropdown is taken from it to determine whether its status message should be announced. It's getting lost in the debounce.
We're on track with this change. It should be done in a few days, and will involve releasing an alpha version, then if all is good, a major version (v9 most probably).
We keep the getStatusMessage prop, for all hooks, which will be called with the state values, but without any default implementation. If user does not pass any function for building an a11y message, nothing will happen. If they do, then we will show it in the status aria-live div, then clean it up, then remove the div on unmount.
This is a middle ground between removing it completely and keeping it this way. The docs will be updated as well and also a migration guide. If there are more tips on this, please go ahead. Thank you!