quasar: QSelect input now fails WCAG 2.0 A standards

Describe the bug The changes introduced by #9983 cause QSelects to actively fail WCAG 2.0 A checks in axe-core now. Admittedly, the change is more accessible, but now fails standards checks whereas before it was less accessible but passed the check. 😃

The specific violations:

  • Ensures ARIA attributes are allowed for an element’s role: ARIA attribute is not allowed: aria-multiselectable=ā€œfalseā€
    • Likely Remedy: aria-multiselectable belongs on the element with role="listbox"
  • aria-labelledby or aria-label attribute does not exist, references elements that do not exist or references elements that are empty
    • Likely Remedy: Should add aria-label similar to how QInput behaves.
  • Invalid ARIA attribute value: aria-activedescendant=ā€œf_a1004b26-2180-4fad-8186-a3b48c387fe1_-1ā€
    • Likely Remedy: aria-activedescendant must be a descendant of the element or in the aria-owns comma-separated list. The current implementation puts the element with role="listbox" in the aria-owns attr rather than the individual elements that have role="option". Use comma-separated list of role="option" items in the aria-owns attribute. (This one is silly, the implementation here is cleaner, but this is what the spec says)

Codepen/jsFiddle/Codesandbox (required) Codepen doesn’t really describe the problem. The described violations occur when running Axe devtools on quasar.dev.

Expected behavior No accessibility violations.

Platform (please complete the following information): Quasar Version: 1.15.23

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 18 (7 by maintainers)

Commits related to this issue

Most upvoted comments

Wow, very nice report. Let me digest it over the weekend and I’ll be back with news. Thank you.