An Accessibility Scorecard is a way to get a high-level answer to “Where might we want to improve (in terms of accessibility)?” We do this by looking at a few areas, and indicative behaviours in each.
📈 Scores
For each of the “We…” sections below, review the list of behaviours. Pick a score from 1 to 5.
| Score | Meaning |
|---|---|
| 1 | Not confident at all |
| 2 | Not confident |
| 3 | Somewhat confident |
| 4 | Confident |
| 5 | Very confident |
The score follows something like a classic Likert scale.
When picking our current level of confidence, consider things like frequency of the behaviour, how well-documented the processes are, what level of depth they cover, what kind of conversations we tend to have around the topic.
Reviewing the list of behaviours and deciding that we do them appropriately frequently, they’re well-documented, go to a good level of depth, and the topics are raised in team conversations? We’ll probably be Confident.
Reviewing the list of behaviours, realising that we do none of them, haven’t done them before, we won’t have any docs on them, and we never talk about them? We’ll probably be Not confident at all.
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”. Any average of scores should be rounded to the nearest whole number.
🧠 We think accessibly
Behaviours that demonstrate this include being familiar with:
- The accessibility tree;
- The Web Content Accessibility Guidelines and the Quick Reference version of the Success Criteria;
- The Rules of ARIA;
- ARIA attributes and ARIA patterns.
⌨️ We develop accessibly
Behaviours that demonstrate this include:
- Writing semantic HTML;
- Doing Static Analysis (For example axe Accessibility Linter for VS Code or eslint-plugin-jsx-a11y in
eslint-config); - Using the design system accessibly;
- Doing some QACs (Quick Accessibility Checks).
🧪 We test accessibly
Behaviours that demonstrate this include:
- Including accessibility in some unit tests (For example:
jest-axein unit tests); - Including accessibility in some end-to-end tests (For example:
axe-playwrightorcypress-axefor E2E tests); - Testing with assistive technology, in particular testing with screen readers;
- Doing (or asking for) an accessibility audit.
🙋 Getting help
If you’re not sure which “We…” to start with, it’s usually more effective to start with the earlier one(s). These build patterns of thinking and behaviour that lead more easily into later “We…”s.