[App Search] Result component - a11y enhancements #86841
Conversation
- Move toggle action to the bottom of the card content - [TODO] Action button to the right will be used for new link button (separate for accessibility/screen readers) - Use grid to get the layout we want without extra div wrappers
+ remove <a> tag on article content - should have onClick only - this allows screenreaders to granularly navigate through the card content while allowing mouse users the entire card to click - the new actionButton details link is accessible to both keyboard & screen reader users
- since the aria-label for the new detail button link is basically that
cee-chen
added
Feature:Plugins
release_note:skip
| snippet={value.snippet} | ||
| type={typeForField(field)} | ||
| /> | ||
| ))} |
There was a problem hiding this comment.
This didn't actually change, I just removed a wrapper. I recommend viewing the diff with whitespace changes off (?w=0)
There was a problem hiding this comment.
I think ?w=1 hides whitespace changes, right?
There was a problem hiding this comment.
oh derp haha, you're right 🤦♀️
| title={i18n.translate('xpack.enterpriseSearch.appSearch.result.title', { | ||
| defaultMessage: 'View document details', | ||
| defaultMessage: 'Document {id}', | ||
| values: { id: result[ID].raw }, |
There was a problem hiding this comment.
I'm not 100% sold on this change and if it improves the experience for screenreader users at all - happy to revert if people aren't a fan of this
|
@JasonStoltz Definitely would love to know what you think! From a general UI/UX perspective I'm a fan of the expand/collapse being on the bottom instead to the side and think that makes a lot of sense. 🤞 In that sense I don't think this is too big a compromise/sacrifice to get a better experience for screenreader users and is (hopefully) a net gain overall for everyone. I'm also curious to think if you'd be for or against removing the |
💚 Build SucceededMetrics [docs]Async chunks
Distributable file count
To update your PR or re-run it, just comment with: |
JasonStoltz
left a comment
JasonStoltz
left a comment
There was a problem hiding this comment.
This looks good.
I would remove the the link from the result body though. Feel free to do that in a separate PR.
|
Re: link/onClick on main body - for sure, I'm kinda leaning that way myself. Let me run that by @daveyholler when he gets back from OOO next year to see if he's down with that. |
* Refactor Result card layout - Move toggle action to the bottom of the card content - [TODO] Action button to the right will be used for new link button (separate for accessibility/screen readers) - Use grid to get the layout we want without extra div wrappers * Add action button link to document detail + remove <a> tag on article content - should have onClick only - this allows screenreaders to granularly navigate through the card content while allowing mouse users the entire card to click - the new actionButton details link is accessible to both keyboard & screen reader users * [Polish] Hover effects to help guide mouse users * [i18n] Add pluralization to fields copy * Update tests * [Cleanup] Remove unneeded wrapper * [??] More specific title for result group - since the aria-label for the new detail button link is basically that
3 participants
Summary
This PR is a follow-up to this conversation where we added links to document views. The issue with the wrapping
<a>tag around the article content was that it caused screen readers to read out all the content at once, resulting in a lot of overwhelming verbiage:This approach of changing our Result card markup/layout as a compromise to get working behavior for all kinds of users follows a pattern similar to EuiCard, where it balances the following trade-offs:
Screencaps
QA
Checklist