search

LeaVerou / awesomplete

Ultra lightweight, usable, beautiful autocomplete with zero dependencies.
http://leaverou.github.io/awesomplete/
MIT License
6.97k stars 611 forks source link

Make an option to totally hide `visible-hidden` elements #17193

Closed vbaranov closed 4 years ago

vbaranov commented 5 years ago

"awesomplete": "1.1.4"

Make an option to totally hide visible-hidden elements like this

<span class="visually-hidden" role="status" aria-live="assertive" aria-atomic="true" hidden="">No results found</span>

Because in some use-cases it can break HTML pages adding a horizontal scroll. The workaround is to downgrade to 1.1.2.

fuzzbomb commented 5 years ago

@vbaranov Awesomplete only uses the visually-hidden approach in one place currently - the ARIA live region you mention cite. Adding the HTML hidden attribute to this element is a bad idea for accessibility, because it will stop screen readers from conveying the number of matches in the drop-down listbox.

The typical use of a visually-hidden class (a.k.a. sr-only in some other libraries) is to hide an element in the visual rendering, but retain it in the browser's accessibility tree which is made available to assistive technologies.

Adding the HTML hidden attribute (or CSS display:none or visibility:hidden) will remove the element from the accessibility tree completely. I confirmed this in Firefox and Chrome (on macOS and Linux). This is correct behaviour per the W3C HTML 5.2 recommendation, the WHATWG HTML Living Standard, and the HTML Accessibility API Mappings (W3C working draft).

In this case, adding the hidden attribute to the element will remove this ARIA live region from the accessibility tree, so the "2 results found" message will not be conveyed to assistive tech users. I confirmed this manually using macOS VoiceOver with Chrome and Safari. (I haven't got around to testing it with assistive tech on other operating systems yet, but I would expect the same result.)

I suggest the Awesomplete maintainers close this feature request as won't-fix / works as designed.

About the problem you reported:

Because in some use-cases it can break HTML pages adding a horizontal scroll. The workaround is to downgrade to 1.1.2.

awesomplete.css includes it's own implementation of the visually-hidden class. This could conceivably conflict or overlap with the visually-hidden rules defined in your own project (or other libraries) in unexpected ways. Rathen that try to completely hide this ARIA live region element, look for a solution that improves the visually-hidden technique, or change how your own container CSS works.

I took a look at the commits between 1.1.2 and 1.1.4 to see if there was an obvious culprit. I didn't see any change to the way the visually-hidden class is used or implemented in Awesomplete.

Maybe Awesomplete could use different selectors in it's library CSS, to avoid overlapping with the .visually-hidden implementation in other libraries? Perhaps a BEM-style .awesomplete__result-announcer class, say.

vbaranov commented 4 years ago

Thanks for the thorough reply. There were no additional rules for visually-hidden class in my case. I managed to fix the "horizontal scroll" issue by setting the additional rule for visually-hidden class:

.visually-hidden {
  display: block;
}

https://github.com/poanetwork/blockscout/pull/3319/files#diff-61880061dceb66cdae139759030140c0R291-R293.

Closing this issue.