In times of crisis like the one we're facing now it's more important than ever to make our applications as accessible as possible. People rely on getting information from the apps and websites we design. Not being able to get a certain information because of poor network connectivity, weak hardware, or (most commonly) some stupid design mistake can be critical.
What most of our workflows right now are optimized for is MVP-and-ship. If your app somehow runs, it's good enough. Testing for accessibility pitfalls can be time consuming and arduous, so it's mostly ignored.
But we can fix that.
By adopting a few habits we can get ourselves into a working mode that incorporates A11y into our daily grind.
#1: Just write HTML
Most developers I know would estimate their HTML skills at 100%. It's just markup, right?
That stands in stark contrast with the HTML that's out there in the wild. There are <div>s that act as <button>s, <button>s that act as links and links that act as nothing really because some Javascript stopped working.
Please, write semantic HTML. Structuring your content in a standardized and meaningful way (no, not <div> everywhere) is really helpful. Screenreaders can navigate your page more easily (they have helpers for semantic tags), your site still looks structured when printed out and your content can easily be serialized for other interfaces ("Alexa, read my latest article").
#2: Use the tools
While relying solely on a checklists is not a good practice, incorporating them into your workflow is. A lot of the most common A11y errors can be checked automatically. I like to use Google's Lighthouse and Microsofts Accessibility Insights browser extension. They'll notify me when I used too weak contrasts, small fonts, unlabeled buttons, etc. The small things.
#3: Look ma, no mouse!
Stop using your mouse when testing. You'll be forced to navigate your site by keyboard. Can you still operate all your links and buttons, your off canvas menus und modals? Can you close overlays with Esc? Can your operate your carousel with the arrow keys?
Even better: you'll notice which functions you use often. Give them a shortcut! Keyboard users will love you for that and it might even boost your own productivity!
#4: Hardware for the masses
Your testing tools might have ways to tell you where memory leaks occur or where your CPU-intensive tasks are, but they still have a hard time to tell you how your app feels on slower hardware. There's no way around it: you need to test manually from time to time. I like having an old Android around for those things (and as a backup for when I break the screen of my phone again). If it still feels as snappy as the rest of the device, it's fine. However intensive tasks can easily freeze the browser or the entire device. That's when I know I still have something to do.
The same goes for network connectivity. However that's way easier to emulate even in your desktop browser.
#5: Up your cross browser testing
When you test your app, you probably test it most thoroughly in the browser that you develop in (that's Chrome for me), and from time to time in one or two other browsers of your choice (Firefox and Safari in my case).
Time to add two more browsers to your occasional list: A screen reader for desktop and one for mobile.
I develop on a Mac, so the desktop screen reader of my choice is VoiceOver with Safari (which doubles as my Safari test anyway, so yay!). I have an Android smartphone, so TalkBack and Chrome it is on there.
Both of them have to be configured only once and can then be accessed by hotkeys.
I found manual testing in an actual screen reader to be the only viable method to know if your app works well with them. By relying on checklists and best practices there are still huge gaps where things could go wrong.
Use your app like your users would!
#6: Get into a real life situation
Contrary to popular opinion, A11y doesn't just help people with disabilities. It helps everyone.
Being able to navigate a mobile interface with only one hand is great for people who actually can use only one arm, but it's also nice for a parent holding their child. It's also nice for you, when you're showing off the cool feature you built, while you balance your tray on the other hand during lunch break.
Do your wear glasses? Take them off and try to use your app like that (Maybe memorize how your screen reader works before, depending on your vision).
#7: Talk to people
This is really important. Get feedback from your users. If someone reports an issue that prevents them from using your app, fix it.
As always with modifying our habits, the effects won't be immediate. We need to learn and give it some time to sink in. So better start sooner than later to think about it.
Top comments (4)
Regarding, number 3, I feel it's more important that your carousel have semantic controls with perceivable text. There is no native HTML carousel, so there's no standard behavior. Unless you provide instructions that your carousel can be operated with the arrow keys, it's not guaranteed that anyone will even try.
When you lack a pointer, you probably would try the arrow keys.
Also, it's just an example. Sure, HTML should be semantic, just as I covered earlier in the post. But you should try everything not to break your sites a11y. Those seven points are just a small fraction.
Jeff Veen interviewed an accessibility advocate Liz Jackson on his Presentable podcast: relay.fm/presentable/83
It gave me a different perspective on what accessibility really means.
I think accessibility should be as intimate a developing process as for general use. For many people it is general use! Thanks for a thoughtful article.