Accessibility is simply good design

Accessibility is something our team really cares about

The way we think about accessibility in the US is a little, well, weird

We build stairs. Then make a ramp for people with disabilities. We create a dropdown box on a website. Then add keyboard navigation. These additions are afterthoughts and, as John Brownlee put it, usually “framed in terms of charity alone.” If people have extra time and energy, they might get to it. 

But what if we built the ramp first? Why stairs at all? 🤔

A ramp not only grants access to persons with mobility challenges, it helps you pull a heavy moving cart inside, carry boxes more easily, not fall on your face while texting, or hobble along on crutches.  

This ramp-first mindset is a radically different way of thinking about accessibility. Instead of adding specialized items for a perceived minority (a whopping 18.7% of the US population), what if we approached accessibility as creating a more barrier-free world for everyone? 

Turns out, this is a pretty smart way to build an app. 📱

The web was fine before we broke it 😑

If you haven’t thought about it in a while, the premise of the web is friggin’ amazing—anyone with an internet connection can access information on anything from anywhere. 💥

Which is awesome. Or it was, until folks made experiencing information downright uncomfortable. Tiny font sizes, low color contrast, a million items competing for focus, lots of flashing elements. Pages like that aren’t just tricky for someone with vision impairment (1.3 billion people, by the way), they’re tricky for anyone with eyes. 🙈

This nods to a larger trend. Somewhere along the way, a lot of design and development became about looking cool, clever, and cutting-edge, instead of about usability. 

Accessibility is about re-focusing on usability and reclaiming the open playground the internet created. As the Web Accessibility Initiative (WAI) defines it:

“Web accessibility fulfills the basic promise of the web—making information and communication readily available to all people regardless of barriers in geography, language, or disability.” 

It’s in your best interest to focus on accessibility 📈

Our team had a good laugh at this comic via CBInsights last week. 

T_Et_QPCFjtGXCG-G16fWBx1END7u_FgwmSuCVDF

It’s funny, but it also represents a serious profit-draining mistake: not understanding your users’ experience. 😬

Turns out, creating an accessible app is a surprisingly good way to avoid this mistake. Implementing accessibility forces you to consider and empathize with your users. In order to make something easy to use, you have to ask questions like:

  • Who is this for? 

  • What do they need to accomplish?

  • How will they accomplish it? 

  • What barriers might stand in their way?

  • How can I make their journey easier? 

In a day and age where the company closest to the customer wins, this type of thinking is nothing short of a product-building superpower. 💰

Plus, it helps you avoid gnarly lawsuits and PR snafus. The Next Web cautions, “lawsuits against companies with inaccessible sites are increasing…” By how much? 181% between 2017 and 2018. And lawsuits aren’t the only expense, either. The cost of addressing one Americans with Disabilities Act (ADA) complaint can run a company a cool $10,000. 😳

Needless to say, it’s in your business, legal, and audience best interests to care about accessibility. 

What this looks like in practice 🤓

So how do you build an accessible app? One helpful acronym to keep in mind is POUR: Perceivable, Operable, Understandable, Robust. 💁

  • Perceivable: Is it available to the senses—vision, touch, and hearing?

  • Operable: Can users interact with all controls and elements with the mouse, keyboard, and assistive devices? 

  • Understandable: Is it clear, concise, and easy to understand?

  • Robust: Does it consistently work across all platforms and screen sizes? 

For each of these focal points, there are a variety of guidelines, frameworks, and tests designers and developers can apply. App builders who put POUR in practice would make sure their app has:

  • High contrast between text and background

  • Descriptive alternative text for images 

  • Large, legible fonts 

  • Logical keyboard and tab navigation 

  • Clear page structures

  • Correct markup 

  • Pinch-to-zoom

  • Consistent navigation

  • Text alongside icons

  • Descriptive labels for all form fields

  • Explicit error and feedback messages

  • Purposeful animations

Far from restricting your app, POUR parameters enhance it. As our front-end developer, Jess Mitchell, knows from experience, “Accessible apps often have better user experience (UX) because they have more intuitive interactions.” 🎯

And this makes sense, right? 

  • Content that’s easy to read isn’t only better for someone with visual challenges, it’s better for every skimming customer.

  • A quick-loading app doesn’t just benefit someone with a slow internet connection, it benefits every impatient user who hates long loading times (aka literally everyone). 

  • Intuitive interfaces don’t simply make your app easier for anyone with memory impairments, they make your app easier for all of us with a million to-dos rolling around our brains. 

Fun fact: the German word for accessibility is barrierefreiheit. Literally translated, that means “barrier-free.” Done well, this is what accessibility is all about. Better access and fewer barriers for everyone, no matter where they are, who they are, or how they take in information. 🤗

So as you start building your app, consider making accessibility your baseline…rather than an afterthought. All of your users will thank you.

Accessibility is something our team really cares about. In fact, most of this newsletter isn’t from me. One of our Front-End Developers, Austin Carr, pointed out the German tidbit and ramp analogy. And our newest teammate and Front-End Developer, Jess Mitchell, contributed a load of other insights and facts. Not surprising, since she’s written plenty about accessibility herself. 

Other insights on product-building: