A list of favorite resources. Please make an issue or PR to add!
This is a place to start if you're not familiar with web accessibility. It's also a good list of resources to send to your boss, coworker, or vendor if they give you a blank stare when you say something like "keyboard navigability."
-
Web user stories: stories about how people with different disabilities use the internet, and the barriers that may affect their experience
-
Applied accessibility tutorial for developers: practical introduction for writing good HTML
-
Posters about accessible design: short, clear explanations of how to design for a few different groups of users-- great for hanging in an office where people think accessibility is just about screen readers!
-
Don Norman on accessibility for older adults: the man who coined the term "human centered design" writes about his own experiences
-
Law blog with recent updates on US legal context: this particular article is about misconceptions with the recent Domino's pizza case
-
The Web Content Accessibility Guidelines themselves: I would encourage anyone to read them through at least once. Even if you don't memorize them, you'll be more likely to get a nagging feeling that you should research implementation methods when you're working on something they cover.
-
What you should ask vendors: an oldie but a goodie
In my experience, checklists are the most effective way to audit your code base and catch bugs.
-
Easy checks: not comprehensive, but a good place to start
-
Resources for different roles on a team: what each member of a web team should be considering in their role
Automated tools are useful to catch issues that a computer can detect programmatically like color contrast and header level, but catch only about 70% of accessibility issues. An automated tool cannot tell you if your content makes sense, if the order in which a user perceives it is helpful, or generally if what you've built is usable.
-
jest-axe: for writing jest tests using axe
The text below is an excerpt from an article that I wrote about the basics of web accessibility for data visualization. You can read the whole thing at the Data Visualization Society's blog, Nightingale.
The Web Content Accessibility Guidelines are limited in scope and do not explicitly address data visualization, other than using charts as an example of something for which you need to provide a text alternative. W3C’s tutorials recommend a short text alternative and a long description, which in their example is a table.
While the standards aren’t clear on the implementation details of charts or maps, they do discuss some of the techniques we use to convey meaning with data:
-
Color (standards 1.4.1, 1.4.3, 1.4.11): Use colors with a high contrast ratio and consider what additional visual cues (like patterns) could differentiate variables. Automated tools can be helpful to detect color contrast. Consider using a browser extension like Colorblinding to check your work.
-
Interaction (standards 2.1, 1.4.13, 2.4.3): Users should be able to do anything with a keyboard that they can do with a mouse. For data vis, that might include a tooltip that shows on hover, or a filter that is triggered by a click. If a user navigates through your data visualization with a keyboard, they should be able to do so in an order that makes sense. Users should be able to exit this interaction and not get stuck in a loop.
-
Animation (standards 1.2, 2.2, 2.3): Provide alternatives for time-based media. Do not use flashing images. Users should have control over the timing of animations.
Team familiarity with the guidelines, regular internal audits, and automated tools can help you design with accessibility in mind and catch bugs that you are introducing to the code base. But only user research will tell you if what you're building truly works for everyone. There are organizations you can pay for help with user research.
-
The World Institute on Disability does usability research
-
Fable recruits users with disabilities for you and offers accessibility QA