An Accessibility Scorecard is a way to get a high-level answer to “How well is our team doing (in terms of accessibility)?”
Note: this is an older version. The latest version is Accessibility scorecard (updated).
This pulls together a few different ideas from What to do when – Accessible Design Edition, What to do when – Accessible Engineering Edition, and more.
📈 Score
For each of the four big “We…” statements below, pick a score from 1 to 5. The score follows something like a classic Likert scale:
Score | Meaning |
---|---|
1 | Strongly disagree |
2 | Disagree |
3 | Neither agree nor disagree |
4 | Agree |
5 | Strongly agree |
We choose a score for each of the four sections below. The list of activities is to help us decide what our score is. If we do most of the activities on the list, we’ll probably be Agree. If we do none of them, we’ll probably be Strongly disagree.
Note: scores are always whole numbers. These measures are subjective and approximate. That means it’s a better fit to say our score is “about 4” instead of ”exactly 4.25”.
Scores
We can choose how much detail we want for the score.
- Four scores, one for each section below.
- Two scores, one for Accessible Design and one for Accessible Engineering.
- The Accessible Design score is the average of the two Design sections (We understand our customers and We create accessible experiences).
- The Accessible Engineering score is the average of the two Engineering sections (We develop accessibly and We test accessibly).
- One score, for Overall Accessibility.
- This is the average of the four individual scores (We understand our customers, We create accessible experiences, We develop accessibly, and We test accessibly).
Note: averages are rounded to the nearest whole number.
🤔 We understand our customers
- Checking our biases.
- Recruiting diverse participants, including people with disabilities.
- Using usability testing to understand more about assistive technologies.
- Checking the accessibility of our research tools.
🖥️ We create accessible experiences
- Following the accessibility design checklist.
- Doing accessibility-focused design reviews.
- Prototype reviewing with people with disabilities.
- Annotating designs.
⌨️ We develop accessibly
- Writing semantic HTML.
- Being familiar with WCAG and ARIA attributes and ARAI patterns.
- Being familiar with the accessibility tree.
- Using the design system accessibly.
🧪 We test accessibly
- Including accessibility in some unit tests and in some end-to-end tests. (For example:
jest-axe
for units tests andaxe-playwright
orcypress-axe
for E2E tests). - Doing some QACs (Quick Accessibility Checks) 🦆.
- Testing with assistive technology, in particular testing with screen readers.
- Doing (or asking for) an accessibility audit.