SDK/Theme Update: WCAG Updates for Autocomplete & No Results

[Liz_Frailey]

We’ve made several WCAG updates to the autocomplete.

• Added role=listbox to the div containing the autocomplete

• All autocomplete items (<li>s) now have unique IDs and role="option" . You can find the ID within each autocomplete <div> tag under id.

• We’ve added a series of new aria attributes to the search bar (yxt-SearchBar-input), including:.

  -aria-autocomplete="list"
  -aria-controls="yxt-SearchBar-autocomplete"
  -aria-haspopup="listbox"
  -aria-expanded, whose value is set to true or false based on whether or not the autocomplete is exposed

All links in the no results module now have default focus state for WCAG:

The current default is an underline:

.yxt-AlternativeVerticals-universalLink:focus, .yxt-AlternativeVerticals-universalLink:hover {
    text-decoration: underline;
  }

If you’d like to change the default, you can add the above snippet to your answers.scss, and modify the styling.

[DJ_Corbett]

Hello!

Following up on this post, I have a few additional WCAG-related questions. A client recently shared some WCAG concerns linked to the Yext Search Bar which were brought to their attention by accessible360.com. I believe two of the issues are addressed by the autocomplete updates in 1.6.0 as described in this post, but there are two additional issues I wanted to ask about. I’ve listed them below, as described by accessible360.com:

1. “Number of autocomplete results available is not announced to screen reader users.” Accessible360 says to ensure the current number of available results is read out to screen reader users.

2. “This autocomplete lacks instructions for screen reader users.” Accessible360 advised adding instructions as screen-reader only text and associating them with the input field using the aria-describedby attribute.

Any ideas on how best to address these concerns would be greatly appreciated!

Thanks,
DJ

[roser]

Hi DJ,

Accessibility is definitely a priority for the product so very appreciative of the feedback!

1. Attaching a screenshot of the yext answers experience (which is on the most recent version of the theme and SDK). We currently have sr-only text on the options and an aria-live: assertive tag – If they have additional guidance on how to surface this info to SRs we’re definitely open to it.

   

2. We actually do have a label associated with the input field, however it’s using aria-labelledby instead, based on guidance from MDN, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute, “A label provides essential information about an object, while a description provides extended information that the user might need.” Would be curious if Accessible360 interprets this differently, though! Screenshot of this label here:

Thanks,
Rose