Recently, there was a Twitter thread going around asking what accessibility fact you’ve learned recently. I responded with a few, but thought I’d take it a bit further here. I’ve been practicing accessible design for almost ten years now, and there are a lot of gotchas of accessibility I’ve picked up.

1. Design crime – Designing without accessibility in mind, and selling that design in certain countries, is illegal. WCAG 2.1 AA is the law in some places. If it’s flagged ahead of time, that product can’t be sold. Whoa.
2. WCAG 2.1 AA is the international accessibility standard – So is PDF U/A. Learn them both. Learn semantic HTML. Learn ARIA. (Also, some governments have additional requirements on top of these.)
3. Not all [disability group] users are the same – Obviously, right? It’s unfortunately too easy to fall into this trap. Everyone is unique and approaches things differently. Some people are more skilled than others at a certain technology, others are more forgiving about ableist ignorance, and not all people with a similar disability experience it the same way.
4. Not all disabilities are permanent ones, or lifelong ones – Some are situational or sporadic as well. This is why the term ‘curb cuts’ helps more than just wheelchair users.
5. Assistive technologies and the browsers they are used with provide wildly inconsistent results – This means you need to test them all, which is why I have a Mac, Windows, iOS and Android device. If you need to prioritize, use the WebAim survey as a guideline. They read back differently, the work differently, and it’s all very confusing. Sad but true.
6. Consider your language, but don’t overthink it – I’ve been in many tests with users that are both blind and say “I can see how it might be…”. While I try to be considerate of my language, this is usually a good cue that it’s less important for me to worry about that with the current tester.
7. Design for fingers, keyboards – A nice smooth touch and grab interface is great, but it’s easy to forget everyone else. By all means, make those slick sliding UIs, but add a secondary way to make the features work for others.
8. Design for voice – And on that note, icon-only buttons suck for voice navigation, as people won’t know what to say to take action on that button. At bare minimum, provide a non-native tooltip on focus, so the button label is learnable.
9. Go beyond compliance – I’ve had tests where compliant solutions fail. I’ve had tests where semantic solutions that worked perfectly didn’t meet the common standards expected. And I’ve designed assets where adding a ‘bullet’ character helped define the context of a list better. All had semantic code & contrast. All didn’t meet the expectation.
10. Automate and delegate – Add accessibility linting and checking into the dev process. Use a third party to validate your compliance level. Use actual people to provide feedback on the quality of a solution. Don’t do everything yourself. (I need this reminder often)
11. Responsivity is an accessibility thing – It’s part of WCAG 2.1. Down to 320px. And also for landscape mode. This is hard to design for. But I believe in you.
12. All caps is bad news – Screen readers reads them back as an acronym. Some regular text set to all caps with CSS also will occasionally do this in some readers. Even worse, some letters are read out as the common abbreviation meaning, whether you want them to or not. (NVDA reads back “Mia” with CSS text-transform uppercase on it as “Missing in Action”. A potential serious UX issue if it happens in the wrong app or context)
13. Aria-label and Aria-describedby override everything – This is good. And sometimes frustrating. But it can solve the issue I just mentioned!
14. You may need to educate your organization – Just because your company has a legal team, an inclusion team, etc. doesn’t mean they get the impact of accessibility.
15. It’s fascinating and super rewarding – And most importantly, seeing the real change you can make in people’s lives is incredibly cool. It’s hard not to think about it any new design now.