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

[pdanpdan]

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

[pdanpdan]

Try “quasar”: “https://github.com/pdanpdan/quasar#quasar-pdan-v1.15.23-beta.3”