vue-simple-suggest icon indicating copy to clipboard operation
vue-simple-suggest copied to clipboard

Accessibility features

Open simeonkerkola opened this issue 6 years ago • 5 comments

I'm submitting a ...

  • [ ] bug report
  • [x] feature request
  • [ ] support request

What is the current behavior?

Keyboard control works great, but still lacking many accessibility features.

What is the expected behavior?

vue-simple-suggest to be more screen reader friendly.

Including:

  • Necessary aria tags
  • Using a ul and li tags for suggestions.
  • Clearing the hovered data when list closes or re-renders.
  • Note about accessibility when using custom inputs to README
  • Anything else?

What is the motivation / use case for changing the behavior?

Something closer to the WAI ARIA 1.1 spec

simeonkerkola avatar Feb 17 '19 20:02 simeonkerkola

I could submit a pull request.

simeonkerkola avatar Feb 18 '19 09:02 simeonkerkola

Hello, @sssmi. :) Sorry for late reply.

We plan to implement ARIA spec for the v2.0.

A PR to the current version would be highly welcome, though!

Raiondesu avatar Mar 12 '19 15:03 Raiondesu

Ok, so the PR is finally merged into dev! We're gonna make a minor release soon.

I'm going to keep the issue open for task-tracking purposes for the 2.0 version.

Raiondesu avatar Mar 28 '19 16:03 Raiondesu

Hi!

I am experiencing a drop in Lightouse accessibility score. vue-simple-suggest input element fails with error [aria-*] attributes do not have valid values

I think this is caused by the aria-controls attribute being present even when the actual list element with listId is not. This means there's no element with the id that the aria-controls is pointing to until the v-if condition of the list is fulfilled.

Should the aria-controls attribute maybe be added dynamically simultaneously with the v-if condition of the list element being fulfilled?

pyryhei avatar Jan 07 '21 09:01 pyryhei

In this case, I’d say the best solution would be to use v-show instead of v-if for the ul list element, and leave the aria labels intact. Then the screen reader would know that this input has a list it controls, even thou it is hidden initially.

Even if the screen reader can detect the dynamic changing of the aria labels when the user is typing, and that is an issue with some SRs in some cases, it wouldn’t make much sense to first announce that this input has no list connected, and then change it once it is interacted with.

simeonkerkola avatar Mar 22 '21 18:03 simeonkerkola