Add visually hidden comma after search items #4063
Conversation
✅ You can preview this change here:
To edit notification comments on pull requests, go to your Netlify site configuration. |
owenatgov
force-pushed
the
search-results-section-semantics-comma
branch
from
0afe9f8
to
9670108
Compare
owenatgov
force-pushed
the
search-results-section-semantics-comma
branch
from
9670108
to
6e80175
Compare
|
I'm not sure if this solution completely fixes the issue. While a comma helps separating the two strings, I don't think it says the same as what the visuals convey. But it is somewhat equivalent to what DAC suggested, so maybe it's fine. (To be fair, DAC's solution does similarly not represent the visuals 100% either.) |
|
@selfthinker I'm gonna answer this comment in tandem with #4066 (comment) as they're both related. I wonder if there's an issue here around the design of the search results themselves in that they're confusing by themselves. You can get context clues that the metadata of a search result is typically one of the website nav sections but we're including headings in pages as well which changes the context of the results. The way we get around this is with the '[site section] > [page]' metadata pattern but I'm not sure that's actually helpful. As you said in your other comment, the result is intended to be a heading whilst the metadata for heading results are intended to be like a breadcrumb. I would take this further and say that for instances where a result is a page, not a heading, the metadata is more intended to be a subheading. We've got changing contexts in our search results with not very much clear indication. I think the problems for screen readers are potentially just a symptom of the overall poor conveyance of these search results. I was chatting about this to @hazalarpalikli in relation to work she's been doing on #4015 and we're wondering if there's an opportunity to iterate the whole site search, taking this into account as well. From your comments, I wonder if the answer is to go back to DAC's original implied suggestion and just spell the results out in text, no visually hidden text, which would involve reorganising these results which I was maybe too nervous to do. A bone-headed idea I suggested was something as blunt as:
I think this solution I've put together in this PR is a minimum viable solution but I think it'd be worth revisiting it soon. |
What
Adds a visually hidden comma to search result rendering, after search results and before search result section information.
Why
This is to address an issue raised by DAC during an audit of the GOV.UK Design System website, in which they noted that search results and search result section info was not adequetly deliminated for screen reader users, currently being dictated as a single phrase. This solution adds a pause to screen reader dictation between the result and the section info, resolving the issue.
This solution has been chosen following testing of multiple solutions, including DAC's own proposal.
Resolves #4006
Notes
Something implicit in DAC's recommendation to add parentheses around section info was for it to be visual, like so:
This is also true of the colon solution where we could've adjusted the render output to position the section info above the result visually.
I haven't explored these further this time based on the results of the same solutions when they're visually hidden. I'm going to opt to leave them be for now. I could be prompted to re-explore this as it's not impossible that they could be different, especially if it means we can simplify the search output.
Testing has also found that instances where section info includes a section and a page aren't ideal for screen reader users. Screen readers don't interpret the greater than sign, intenteded as a visual arrow to associate a section with a page, as punctuation and announce this a s a single phrase. I'll fix this in a separate PR.