Over the past year and a bit, I’ve written quite a lot of help documentation about accessibility-related things. I’ve covered: Process, Design reviews, Auditing, Testing, and User Interfaces and Patterns.
I would watch for patterns in questions and audit results, and write up docs to address these things.
Process
Getting a feel for how teams are working, questions they seem to have are:
- how do we “do” accessibility?
- how do we know if we’re doing a good job?
What to do when
Some teams look for clarity on “what to do when”: what activities should we be doing, and at what point in the process should we be doing them?
Measuring and metrics
Product people often want metrics, or measurements. Thinking about Measuring accessibility and how “100% accessible” is impossible I focused on leading (rather than lagging) measurements.
Design reviews
I’m a strong believer in the power of shifting left. Catching potential issues at the Design stage is better than catching after things have been built.
Auditing
I have a confession to make: I enjoy auditing. I think this makes me a little unusual (but I’m okay with that). I like doing detailed analysis of a UI. I really like being able to suggest fixes, and showing the impact of the fix on our customer’s experience.
The process
Over the months, I’ve refined, revised, and standardised our audit process. The mobile one is still a bit in flux.
The results
Presenting the results of an audit can be tricky. It’s not helpful to make it a blame game or just a big list of problems. Some ways to make it a bit better are to be clear on the severity of issues (to help teams prioritise) and being clear and consistent.
- Accessibility Audit Severity examples
- Accessibility Audit Guide: writing good words
- Delivering the results of an accessibility audit
- Classifying and prioritising accessibility bugs
Compliance and standards
I am in the accessibility business for the people, for making human-centered things. I prefer the carrot to the stick. But, sometimes we need to talk about compliance, and WCAG.
Quick checks
Audits can be a big deal. They feel heavy for the team receiving the results, and they can be time-consuming for the team doing the audit. To soften both of those, I thought about “mini-audits”.
Testing
For now at least, automated testing can only find some issues. We need manual, human, testing to find the rest.
Automated accessibility testing
Keyboard
Testing with the keyboard is by far the best “value for money” when doing accessibility testing. A good keyboard-friendly interface helps power users, keyboard-only users, screen reader users, and more.
Screen readers
Screen readers can seem intimidating at first. But they are a really powerful way to test our UI.
- Sounds like a good idea: how to get started testing with a screen reader
- The two modes of Screen Readers
- Testing with a screen reader (QE / AC edition)
User Interfaces and Patterns
I’ve written a few things about working with a design system, and about specific UI patterns that crop up. Sometimes I throw together a reduced test cases and add it to my list of a11y demos and tests.
- How to get the most (accessibility) out of a design system
- Accessibility and usability considerations for disabling buttons and inputs
- Tables and links and things
- Opening in a new tab
- More accessible headings
Images
Writing alternative text for images can feel tricky. I wrote up a guide with some worked examples.
A quick guide to text alternatives for images