-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Improve accessibility of support search components #43617
Comments
That's definitely a
According to the WAI-ARIA docs, a A specific There's also this PR on Gutenberg that's adding a Combobox component using Downshift: WordPress/gutenberg#19657 And this excellent comment by @jeryj that definitely worth checking: WordPress/gutenberg#19657 (comment) |
I second @diegohaz!
This will be so useful! It looks like the arrow key interactions are there already. A few things to do based on a very quick review:
|
Thanks for your input @diegohaz that's great and aligns with my understanding. I'm not 100% sure. Should we be using Reakit or |
I tested this more in Safari using Voice Over and thought about it more closely. This is a complicated little box! Here are my suggestions: Support search section on
|
I spent too much time today digging in on this, and didn't come out with any clearer idea on what the end result should be. Here are my current, foggy thoughts on possible direction for the markup: 1. Should this use component arrow key navigation?I'm not 100% convinced it should. As slick as I think the interaction of a DOM focused input with a virtual focus on the selections, I don't know that it's really applicable in this case. I think this is a search input that dynamically populates a list of results. It's not meant to fill out a form. If we go with this as a list of links (soon to be divided into sections), then we can use markup like this:
This does a few things:
Implementation of this would be fast. Testing it out locally works fairly well IMO. Here's a non-interactive demo version of that markup: https://codepen.io/jeryj/pen/GRoxKPP 2. If we keep arrow-key navigation and go with a
|
Based on your comment above, I'd tend to agree that our use case has diverged too far for it to be considered a ARIA combobox equivalent (arguably it wasn't in the first place?). Your suggestion for an implementation alternative looks reasonable to me. |
After reading @jeryj's comments and thinking more deeply on this widget, I agree that this may not be a combobox. Although the combobox pattern would be useful when the user is interacting with the search box. The search box and the list of links are, at first, independent from each other. That is, the user could interact directly with the links without ever noticing the search box. And, because of this, I'd expect that a keyboard user could Tab through the links without having to interact with the search box. So, the links should be tabbable, or, at least, be a tab stop independent from the search box by using the I'm not sure though how <section>
<form role="search" aria-label="Search">
<label for="search">Search for Help</label>
<input id="search" type="search" />
</form>
<div>
<h3 id="section-1">Section 1</h3>
<ul role="group" aria-labelleddby="section-1">
<li><a href="#">Item 1</a></li>
<li><a href="#">Item 2</a></li>
</ul>
<h3 id="section-2">Section 2</h3>
<ul role="group" aria-labelledby="section-2">
<li><a href="#">Item 3</a></li>
<li><a href="#">Item 4</a></li>
</ul>
</div>
</section> When interacting with the search box though, I feel like the combobox pattern would be super useful. It's somehow similar to the interaction model I proposed to the block inserter on Gutenberg (WordPress/gutenberg#21080 (comment)), where normally the block list uses the grid pattern, but, when interacting with the search box, it's replaced by a combobox grid: But the simplest solution that would solve most of the current problems on this component in particular is what @jeryj suggested, without a combobox. So I would go for it for now. |
After discussing a bit more with @diegohaz, we've put together some clearer direction for how the markup and interactions should work. OverviewThe search input will operate independently of the results. There won't be any arrow key interactions on the results while focused on the search input. Instead, we can use a This would allow the support search component to take fewer tab stops in the flow and allow fo arrow key interactions on search results. Markup General Structure <section>
<form role="search" aria-label="Search">
<label for="search">Search for Help</label>
<input id="search" type="search" />
</form>
<div aria-label="Search Results">
<h3 id="section-1">Support articles</h3>
<ul role="grid" aria-labelleddby="section-1">
<li role="row"><span role="gridcell" tabindex="0"><a tabindex="-1" href="#">Item 1</a></span></li>
<li role="row"><span role="gridcell" tabindex="-1"><a tabindex="-1" href="#">Item 1</a></span></li>
</ul>
<h3 id="section-2">Show me where to</h3>
<ul role="grid" aria-labelledby="section-2">
<li role="row"><span role="gridcell" tabindex="0"><a tabindex="-1" href="#">Item 3</a></span></li>
<li role="row"><span role="gridcell" tabindex="-1"><a tabindex="-1" href="#">Item 4</a></span></li>
</ul>
</div>
</section> Keyboard interactions
Other Interactions
|
After working on implementing this in #43963, I've decided to first go with the simpler At the moment, I'm leaning towards not implementing the
The cons:
|
Read an article this weekend from Adrian Roselli on ARIA Grid as an Anti-Pattern which supports leaving the links as normal |
Currently, the support search components are not fully accessible to users of AT. This is because they:
Some specific issues:
input
and the search resultswp.speak()
or similar.Many of these issues could be solved by making use of Reakit by the excellent @diegohaz.
@diegohaz if you have time, I'd really appreciate some guidance on the best route forward in terms of:
The component we are referring to is:
The text was updated successfully, but these errors were encountered: