6 Ways Startups Can Design for Accessibility
Accessibility is a huge problem in the tech world that we don’t talk enough about.
Google’s social good arm, Google.org, has just announced an initiative they’re calling Google Impact Challenge. Their announced focus is on accessibility.
We don’t consider what our designs and products are like for the deaf, blind and physically disabled individuals. Although, I’m confident, as a community, technologists surely agree that we shouldn’t be designing people out of our systems — it’s easy to see the argument that it’s just not a priority early on.
As companies grow, they can’t avoid it. Recently, Uber hit a PR land mine when the story of wheelchair bound riders escalated to the press and into the courtroom. The public began to debate whether Uber should be required to abide by the Americans with Disabilities act.
Editor’s note: this was originally shared with Kapuno’s Tech Startup community.
Why Does Accessibility Matter to a Start-up?
It’s understandable to say, “it’s not a priority for us, yet but we’ll get there,” when you are a startup without product-market fit. You have a lot on your plate.
My goal isn’t to convince you to solve for all the accessibility problems but be aware of the problems so you don’t make stupid design decisions. A general rule to live by is making your product accessible, likely, makes it more usable to end users and modular to your team. Also, many accessibility features for web, like “alt” tags improves your rank with Google.
If you build for an accessible future, like preparing for internationalization, it lays the foundational flexibility so you can easily implement it when you’re ready.
Acting like it doesn’t matter until you’re successful is a recipe for disaster and, more importantly, is pretty heartless.
How Many People Are Impacted?
Accessibility has many facets in visual disabilities, hearing, and physical. Each impacts how a person may or may not be able to interact with the app. If you want to think in business terms the market size that’s impacted is non-trivial.
- 6.7 million people from 16–75, in the US alone are reported to have a visual disability.
- 1/12 men and 1/200 women have some type of color-blindness. Red-Green being the most prevalent.
- According to WHO, over 5% of the world’s population is profoundly deaf.
- 12.0 million people above the age of 14 in the US alone required the assistance of others in order to perform one or more activities of daily living or instrumental activities of daily living. This includes bathing, dressing, doing housework, and/or preparing meals.
Basics of Accessibility
There are some basic steps that you can take to be prepared to be accessible.
Don’t assume color vision — test your templates and designs in grayscale to ensure that all your elements are distinct without color. Don’t use calls to action like “click the red box to…” UXMag goes a bit deeper on some strategies to handle color deficiencies.
Contrast and sizing is important — zoom out 25% on your design to verify that all the major calls-to-action, core messaging, and interactions are visible and readable when you’re zoomed out. Don’t put key text on top of busy images without a mask. Use the squint test to verify that your key elements don’t fade away. Make sure to abide by Fitts Law in designing buttons and menus.
Use alt tags and watch out for micro-formats — alt and title attributes in HTML are used to describe images. They’re used by Google and by screen readers. Make sure that, if you’re describing an image, use well-known colors rather than an obscure proprietary name that means nothing to the average person. Also, micro-formats can be dangerous for screen readers as they have been known to misuse tags that are read aloud and cause confusion by reading machine instructions to the listener.
Sound shouldn’t be required — sometimes error feedback is only given as a sound. Don’t use sound as the only feedback mechanism even in the case where something good happens. A popup dialog, growl, or inline feedback could help accompany a the error or success ding.
Separate static templates from UI code — Although this is generally a best practice, you’ll be grateful you do this as you build out multiple front-ends for different form factors. Consider how your web interface reads in a screen readeron the web. For bonus, separate all your static text in language files so they can be internationalized as well.
Separate event handler from initiator — there is a movement to the Indie UIstandard so we separate how the “scroll,” “zoom” or any UI action was fired from what’s the app handler’s reaction to it.
For example, if a user wants to scroll down a page, they might use their finger on a touch screen, or click a scroll bar with a mouse, or use a scroll wheel, or press Page Down on a keyboard, or say “scroll down” with a voice command. All those different user actions can be translated into a simple IndieUI scroll event.
IndieUI will allow web application developers to get these events from different devices without having to recognize how the user performed the action. With IndieUI, AT will have a simple set of events to control web applications, and web application developers will have a uniform way to design applications that work for multiple devices and contexts.
