Accessibility Thinking
Accessibility in tech has, for as long as I can remember, been associated with disability inclusion. For most people, the word accessible is associated with blind or hard-of-hearing people. But there’s so much more to it! Accessibility has a broad range of meanings that impact everyone.
I have two hypotheses on how we became so narrow on our view of accessibility. First, the regulatory environment demanded buildings, cities, and products to have certain design aspects to it. This led to most companies just doing what’s necessary to check the box and not understanding the full value of accessibility. Second, UI/UX designers took the term, and led the narrative of what accessibility is. Inevitably, if you are a hammer, everything looks like a nail, and the conversation and content on the web about accessibility is nearly all about UI.
Now, don’t take it the wrong way. It’s very important to be compliant with regulation. And, UI accessibility is one of the critical components necessary to build usable products. It’s also admirable how much focus and attention designers gather to this aspect of building products. But, it’s not sufficient to tell the full story.
I’ve attended hundreds of talks on product, technology, and design. With a single exception in 2007, I’ve never seen accessibility being mentioned outside of the context of disability inclusion, permanent or temporary. I hope I can open your mind and see outside of the box we’ve drawn for accessibility, and use Accessible Thinking to go farther for our customers.
What is Accessibility Thinking?
I define Accessibility Thinking as the act of minimizing access friction to the audience you are targeting for them to use the product as it was intended.
Access friction also requires some clarification. Access is the ability of your target customers to be able to discover, register for, and use the product. Please, read that sentence again. And, again. And, again. Nearly all discourse around accessibility only talks about use, and within the “use”, the narrower “UI” view.
As part of Accessibility Thinking, I grouped access into seven categories. I see these categories through the lenses of high-tech software products, and might differ from other types of products and industries. These categories overlap, so they are not perfect. They are good enough for you to create a checklist when you are thinking about business, product, marketing, and other types of strategies and tactics that should incorporate Accessibility Thinking.
Interface Accessibility
Interface accessibility is about users being able to navigate and interact with the product. This is where professionals in UI design, UX design, UX research, front-end development, and mobile development will devote a lot of their time to. When you search “Web accessibility” or “Mobile accessibility,” you’ll find hundreds of thousands of articles, books, and videos on this topic.
As I stated above, there’s an overemphasis on disability inclusion, although more people understand that many of the best practices for disability inclusion are also good for everyone. However, it’s just not enough to have excellent inclusive design and call the job done.
I won’t expand the details, but in this category, I include everything related to typography, iconography, layout, interactivity, positioning & layering, flow, gestures & input, audio, motion, color, contrast, imagery, etc.
Usability studies can be a blessing and a curse to improve Interface Accessibility. It’s out of the scope of this article, but there are many traps in Usability testing that can lead to the wrong data being collected. I’ll let you do your own online research on this topic.
Since there is so much goodness on the web, I recommend: W3C Accessibility Guidelines, iOS Accessibility for Developers, Microsoft Inclusive Design, and Google Accessibility for Developers.
Cognition Accessibility
Cognition Accessibility is about the mental effort to understand and interact with the product. There is an overlap between Cognition and Interface accessibility. A poor interface will lead to higher cognitive load, thus lowering accessibility. However, I want you to think of all the products where the Interface itself is good, yet people find the product hard to use. When you hear someone saying “I don’t get it” and you have to explain it again.
The biggest culprit of Cognition Accessibility is that products are built by smart people, who create mental models and content they find easy to comprehend, but it doesn’t work for many people. Information Architecture plays a big role in cognition accessibility. Grouping, sorting, or creating hierarchies that are not trivial to digest will lead to more cognitive load, and if it’s just high enough, it makes the product unusable.
If you’ve built products, you’ll notice I left one critical element out of the Interface Accessibility list: text! Copy is one of the most important and often overlooked aspects of accessibility. It’s worse than that. Subject matter experts write with a vocabulary and sentence structure that it’s either a barrier for some people to comprehend (a.k.a., the curse of knowledge), or–that’s why I saved it to this category–it creates enormous cognitive load. Even if you are smart, knowledgeable, and overall capable of reading and understanding the text, if it’s simpler, and shorter, it’ll lead to a faster comprehension and less mental energy being spent. That translates into people being able to complete the task faster and feeling less burden.
There are other things that impact Cognition Accessibility, like the speed in which things appear and disappear from the screen (e.g. scrolling Chiron/marquee) or UIs that don’t create cognitive dissonance (e.g., when the word “red” appears in green color).
Financial Accessibility
Financial Accessibility is about the ability for someone to afford the product, directly or indirectly. Direct affordability means the cost of the product itself. Indirect affordability refers to other products or services you must buy before you can access the product. An app on iPhone that costs $3.99 a month actually requires you to have an iPhone (hundreds of dollars), have a data plan, be able to charge your phone, etc.
We (the tech industry) rarely use cost and accessibility in the same sentence. In the US, the median salary of a Product Designer is $160,000 and for a Software Engineer Manager it’s $300,000. Now, pick the everyday American, age 30. 25% of them make less than $21,000 a year(!!!) and 50% of them make less than $35,000 a year! Imagine your product is Tinder, Netflix, Figma, Strava, Spotify, or Amazon Prime. No matter how you slice it, these products are very expensive to the point of becoming inaccessible to much of the population. Wait! It’s worse! The US is one of the most prosperous countries in the world. A $9.99 a month for Spotify Premium is outside of reach for billions of people.
Let’s be fair. Products need to make money, and many products use price as a differentiator and a way to create exclusivity. As long as that is intentional, and not accidental, that’s perfectly fine.
The more nuanced situation is when there are unexpected financial barriers. For the longest time, Microsoft kept enhancing the Windows Operating System in ways that consumed more memory, more CPU, and more powerful hardware. People who wanted to run the latest version of some software that would only run on the latest version of Windows would have to upgrade their computer. This exists today with mobile phones! There are billions of people out there with phones that are 5+ years old, and hundreds of million with phones that are 10+ years old! Does your app even run (reasonably well) on an iPhone 6? Or, on a 2012 Samsung Galaxy Series A running Android 6.0?
Digital Infrastructure Accessibility
Digital Infrastructure accessibility is about having access to data, voice, and power networks that are required to use the product. From a stack perspective, this is the first layer. If you can’t charge or power your device, the tech is dead. Most times, data is also required.
Until recently, you couldn’t use Google Maps without data connectivity. How useful is a mapping app if it doesn’t work when there is no data connection? And that’s a reality when you are traveling in an isolated area, or when you don’t have data roaming. It might not come as a surprise, but I still have dozens of apps that are about *travel* and they don’t support offline mode.
Still, on data, it might not be about having or not having access to data networks. It might be about how much “data” you have on your phone or on your plan. I’m sure you don’t remember the last time you checked how much you downloaded on your unlimited data plan, but in many parts of the world, having just a few hundred megabytes of network data is still common. If your app keeps downloading 10MB a day of data, your app is not usable by many people.
Latency is also an issue. Most of us who build mobile apps live in urban areas with pretty good latency. “Chatty” websites or mobile apps that make a lot of serial network calls become nearly unusable when you are in a slow or spotty network.
Localization Accessibility
Localization accessibility is about the product having the content that’s localized for the current market. The first thing that comes to mind when people think of localization is translation. Translation is part of it. Localization is also about currency, date/time/number conventions, support for different character sets, imagery & color localization (yes, that’s a thing!), and, as importantly, cultural localization.
Here’s an example: If you launch your app in English in Brazil, you are creating more access friction than if you launch it in Portuguese. That’s obvious. What’s less obvious is that there are large numbers of people in any country who don’t speak any of the national languages of said country. The latest estimate is that nearly 4% of the global population live in a different country from where they came from. That’s nearly 300M people. How many of those don’t speak the local language?!
And it’s not just an immigrant issue, it’s also about travelers. Globally, 1.4B people travel internationally. France gets 90M tourists a year, Spain 83M, the US 80M, China 63M. If you only speak Arabic (275M people worldwide), and you are visiting Milan, Italy, and the only way to get into a bus is to install a mobile app that’s only available in Italian, that’s an accessibility barrier.
Here’s a way to not make your app accessible: It’s not unusual for app developers to only launch their app in the App Store or Play Store of their country, so expats and tourists can only install the app if they switch to the country’s Store. Most customers don’t even know that, and, even if they do, it’s an enormous hassle. To make matters worse, there are websites that geo-locate your IP address, and block and/or limit access. Recently, I was in another country and I couldn’t access the website to pay for a speeding ticket.
Availability Accessibility
Availability Accessibility is about users being available at the time they have to use the product or for the duration required to access the product. This applies to time of day, day of week, time period, season, and more.
Depending on the type of work or school an individual is in, or other personal factors, being available is a limiting factor. For example, if a person works in an environment they are not allowed to bring a mobile device with them. Or, if they don’t have access to the data network during those times, but they get a notification they have two hours to confirm a transaction, that creates an accessibility issue. This is not only factory and blue-collar workers that will find themselves in these situations. Pilots, flight crews, research labs workers, and other professionals might go hours or days without being able to access a device.
Another example of availability is vacation, sick days, or leave of absence. Imagine if we gave new parents twenty-four hours after the birth of their child to click on a link they’ll receive via email to confirm they want to add the baby to their health plan. This similar problem is prevalent in the corporate world, where managers or employees are told on Monday they must take an action “by Friday” without accounting for people’s vacation or being on leave.
Which brings me to another type of availability. Being emotionally and mentally available to use the product. Our digital life is intrinsically connected to all aspects of our “real” life. Leaving a hospital after a surgery is probably not the best time to receive critical information in verbal form.
Inclusion Accessibility
Inclusion Accessibility is about users not being limited to register or use the product based on who they are or what they have. Many aspects of diversity apply here. But there is more.
I went to visit an island in Brazil. It’s a national park and the government tourism agency requires all visitors to register and pay a fee upon arrival. No big deal, one would think. They have kiosks to pay the fees right at the exit of the peer. Here’s the kick: the kiosks don’t accept any phone number that’s not a Brazilian phone number (+55). There are other similar stories based on phone numbers, addresses, government IDs, and more. All barriers!
It also happens when people don’t fully understand what they are building. When a two-letter last name is invalid, or when you must enter the mother’s maiden name (not everyone has a known mother), or a credit card as proof of age. These are just some of the ways that a poorly thought out product can limit access.
I’ll give you another one, which is a favorite of expats everywhere. You can’t open a bank account in a new country until you have proof of address. You can’t get a lease on an apartment or house without having a local bank account. Good luck, and good day!
To wrap up
If you are not applying “accessibility thinking” into how you strategize, design, build, and sell your product, you are missing out on market opportunity, revenue, and product engagement. Be deliberate about building products that minimize access friction!
