Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure that library works well with screen readers #7

Closed
alexreardon opened this issue Aug 10, 2017 · 11 comments
Closed

Ensure that library works well with screen readers #7

alexreardon opened this issue Aug 10, 2017 · 11 comments

Comments

@alexreardon
Copy link
Collaborator

It would be worth auditing how well this library works with screen readers and if there are any improvements that can be made

@svinkle
Copy link

svinkle commented Aug 24, 2017

As mentioned over in a11yproject/a11yproject.com#513 (comment), here are a few instructions/audible cues that would be beneficial for people who rely on screen readers:

  • How to pick up and put down items
  • Which order items are now in after dropping
  • How many items there are in total
  • Semantic meaning for each item (currently announced as, "link")

I just did a quick pass to check things over with Chrome + VoiceOver on maxOS. This needs to be tested with other browser/screen reader combinations as well.

Time permitting, I'd like to jump in and conduct more testing and dive into the code to see where these types of announcements and semantics could be added.

All that said, the keyboard support is really fantastic! 👍

@alexreardon
Copy link
Collaborator Author

Thanks for looking into this @svinkle !!

@alexreardon
Copy link
Collaborator Author

@alexreardon
Copy link
Collaborator Author

Thanks @seancurtis for the link!

@alexreardon
Copy link
Collaborator Author

@alexreardon
Copy link
Collaborator Author

alexreardon commented Feb 8, 2018

I am looking into api options for this. Currently:

onDragStart(start: DragStart, {announce: (message) => void})

where you call announce with your message. If you do not call it then we use a default message

or

onDragStart(start: DragStart): string

We use the string you return from the handler as the message. If not is returned then we use a default. This is clean, but it might be a bit confusing to return a string from an event handler

@alexreardon
Copy link
Collaborator Author

@svinkle this will be shipping in v5 👍

@svinkle
Copy link

svinkle commented Feb 22, 2018

@alexreardon Awesome! Any method available where I could test the work being done so far?

@alexreardon
Copy link
Collaborator Author

alexreardon commented Feb 22, 2018 via email

@alexreardon
Copy link
Collaborator Author

alexreardon commented Feb 22, 2018 via email

@alexreardon
Copy link
Collaborator Author

This has been completed as a part of #321

It feels (and sounds) great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants