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

[Post] Charting Library Scorecard #1588

Open
3 tasks done
julianna-langston opened this issue Feb 16, 2024 · 0 comments
Open
3 tasks done

[Post] Charting Library Scorecard #1588

julianna-langston opened this issue Feb 16, 2024 · 0 comments
Labels
post Article submissions and edits.

Comments

@julianna-langston
Copy link
Contributor

Thank you for your interest in writing a post! Please fill out the following information:

Your idea

Please describe the post you'd like to write in 2–4 sentences, and how that post would be a good match for The A11Y Project.

I'll review popular, javascript-based charting libraries. The review will cover what you need to do to enable accessibility while using these libraries. The intended audience is developers who are either currently using these libraries, or are evaluating different libraries before adopting one to their projects.

Outline (optional)

Optionally include a proposed outline for the post.

  1. Accessibility considerations - what accessibility features are we looking for, and why we use them
    1. Color blind
    2. Keyboard-only
    3. Low vision
    4. Screen reader users
  2. Grade A: Accessible by default
  3. Grade B: Accessibility Switch - they come with the feature, but you have to know to turn them on
  4. Grade C: Accessibility Plugins - you can get accessibility through 3rd party plugins
  5. Grade D: Bring Your Own Accessibility - you have to build out your own customizations, but the library provides all the tools you need to do that
  6. Grade F: Hacks/Inaccessible - you have to work around the library, if that's even an option

I will include links to documentation and/or codepens, so that readers can walk away knowing exactly what they need to make their charts accessible.

Additional information (optional)

Is there anything else we should know?

There is an item in the content style guide that I can only meet with creative interpretation:

Aim for brief, succinct post lengths.

The sections for each library will be quick and to-the-point. However, the whole post is probably going to be pretty long, because I'm evaluating a lot of libraries. I don't intend for many people to actually sit down and read everything, just to consolidate a lot of information in one place.

Is that ok?

Terms

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
post Article submissions and edits.
Projects
None yet
Development

No branches or pull requests

1 participant