Everyone Should Be Able To Use Your Software: Part 2, Three Myths About Digital Accessibility

October 31, 2018 Raquel Breternitz

(Excerpted and based on a talk given at PluralsightLIVE 2018 in Salt Lake City)

By now, you might have heard about digital accessibility, #a11y, or if you’re in Washington, D.C. like me, Section 508 compliance. If you read Part 1 of this series (Everyone Should be Able to Use Your Software), you’re sold on the notion that compliance is hard enough, and you have some idea of why our spaces are so inaccessible in the first place.

But there are still a lot of myths out there about digital accessibility, and its importance in product design — and any service at all. Perhaps in your quest to make better software, you’ve encountered some resistance based on these myths.

Today, I’ll go over a few of them with you in the hope that you will have a better idea of what to do when someone tells you something that is simply not true.

Myth #1: Accessibility is a “fringe” need for a small subset of disabled people

Have you ever been driving along in a car and needed to look up directions, fumbling awkwardly with your phone in one hand, and trying not to bump the BMW in front of you? Or have you laid in bed and scrolled through your twitter app at night, one-handed? Do you have a cat that really needs scratching while you try to answer emails from home? Have you ever walked outside and had your glasses immediately fog up? Have you ever tried to work with a migraine, or in a really loud area? Have you ever been traveling and had to try and figure out how to work some software in a foreign country? Do you happen to be aging?

All of these are situations in which you have a different level of access need from the world and your software, and all of these are situations that nearly every single person will experience. And that’s a much larger group than you might have expected!

The truth is, everyone has different access needs at different times. When you define disability not as a personal impairment, but as a mismatch between your world and your environment, you’ll find that every one of us finds ourselves momentarily, temporarily, or permanently disabled across different spans of our lives. We will all need different levels of access, whether now or later.

And in reality, solving for the right “subset” of people can be the right thing to do. When you solve for the extremes of a use case, you end up getting a smoother experience for a much larger group of people, for free. Sara Wachter-Boettcher and Eric A. Meyer write about this in their book, Design for Real Life

“Edge case” is a really easy way to write something off—to say, “this is not important enough to care about.” Calling something or someone an edge case pushes them to the margins, quite literally. Instead of treating people who don’t quite fit whatever you thought of as “average” as fringe, though, we think it’s a lot more helpful to think of these as “stress cases”: the challenges that test the strength of your design. Because if your work can hold up against people at their worst, then you can be more confident it will hold up for everyone else, too.”

They use the example of Oxo, an ergonomic brand of kitchenware and gardening products, originally designed by a woman whose hands were becoming arthritic, alongside her industrial-designer husband, to enable her to continue doing the gardening and cooking that she loved. These designs grew into a Fortune 500 company — turns out everyone likes more ergonomic, easy-to-use products.

Myth #2: Accessibility makes design uglier and harder

“What if none of the high-contrast color combinations look good?” “This relegates us to just three shades of blue!” Accessibility concerns can grate on a young designer, eager to show their graphics chops, who may chafe at outside constraints. As a former Visual Design lead, I most often found myself mentoring junior designers through a frustrating tension: follow the best, latest, flashy trends, or make something a little more “boring” that actually works? The challenge to make something beautiful, desirable, delightful — AND accessible — is not impossible! It’s just another challenge.

When designers fail to take on that challenge, people notice. Kevin Marks wrote for HuffPo's Backchannel of the “low contrast/gray on gray” trend: “I thought my eyesight was beginning to go. It turns out, I’m suffering from design.” Suffering from design! That’s the last thing we want as human-centered product designers. Rather than take this constraint as a burden, young designers should consider how it helps them do better work. Someone who is reading an article, or using developer tools, or trying to order online won’t care if the app follows the latest trends; they care that they can accomplish what they set out to do.

I’m certainly not advocating for ugly design, but rather for stronger design, or using our chops in typography, hierarchy, and composition, instead of relying too heavily on trends like pastels or layers of gray as hierarchical training wheels.

Use a trend because it works for your user or the task at hand, not as an end of itself. Junior designers can easily “level up” by doing more sophisticated typographic and compositional work that accounts for the contrast needs of low-vision users.

It can also make you a better designer to co-create with someone who literally sees differently than you. Such is the case of Piotr Kaczmarek and Julie Rodriguez, authors of a book called Visualizing Financial Data. Financial data is notoriously complicated and dense, but Kaczmarek and Rodriguez make it super understandable, using clear, simple concepts and compelling combinations. Their use of color is minimalist and smart, and when that was pointed out to Rodriguez, she noted that Kaczmarek is color-blind! His way of seeing the worlded helped the pair create clearer, better graphs together.

Contrary to popular opinion, the reality is that the best design is the one that works best, not the one that looks the nicest. As two patron-saints of Design, Charles and Ray Eames, told us, “Design depends largely on constraints.”

Myth #3: Accessibility takes too long, so it’s not MVP-friendly or a business priority

According to the 2010 Census, and using a broad definition, just under 20% of the population in the US reported having a disability. That’s nearly one in five people! And more than half of those groups reported their disability as being severe. Meanwhile, in 2016 one survey showed that about 16% of internet users preferred Firefox. But which of the two groups of potential users do Product Managers tend to prioritize? You probably guessed it: The browser folks.

The reality is that we are not modular people — there is no such thing as a true “average” or “default” person;  everyone has a spectrum of capabilities. When designers do not acknowledge that, they end up saying that not a single one of these people deserve to have equal access to their work or services. But I can’t imagine anyone would truly look at any of these people in the eye and tell them such a thing. The truth is that when we think of a “user” as a default, able-bodied man of “average” height and dimension, we’ve divorced ourselves from the many shapes and sizes that humanity comes in. And if that’s the case, our product is doomed from the start. The majority of workers and users will not conform to your “default.”

Oh, it's also, the law, ignoring the parameters of which could lead to legal trouble. Talk about bearing down risk!

Fear might not be the best impetus to expand how we think about design though. It's ultimately more cost-efficient to build your product to be inclusive and accessible from the very beginning. As Frank Lloyd Wright said, "You can use an eraser on the drafting table,

or a sledgehammer on the construction site.” Which one do you think is less costly? It pays to do the hard thinking in the design and development phase rather than to insert it at the last minute— and you’ll have a much broader user base to boot.

So remember, the next time you face resistance to building accessible software, you might answer it by saying that everyone has different access needs at different times, and all of us will need a broader spectrum of access at some point in our lives. The best workers and users may not conform to your expectations, so consider adjusting your expectations, and what’s more, going and meeting them where they are.

It’s not only cheaper, in the long run, to do it right the first time, but the best design is also the design that works best, bar none, and designing accessibly will actually help you make better work in the first place.

The more inclusive your software and design is, the better it will be, and the more people will use it. 💯

About the Author

Raquel Breternitz

Raquel Breternitz is designer, speaker, and writer with experience across diverse mediums, problem spaces, and domains. At Pivotal, she works to help government organizations better serve the citizens that need them, and serves as a co-lead of the DC grassroots Diversity & Inclusion team. An advocate for diversity & inclusion, accessibility, and human rights, Raquel draws from her personal experience as a queer, first-generation Brazilian-American, woman of color in technology. An inveterate “word person,” she believes design should be approached content-first, with a sharp eye on ethical considerations and human-centered outcomes. She’s also just a <i>little bit</i> obsessed with typography. She loves journalism, creative non-fiction, semi-colons, and the oxford comma. (Could you tell? She also loves parenthetical statements.) Finally, as a teen-at-heart, she loves memes, social media, and comics, and as a Texan, loves tacos, cacti, and a good whiskey.

Previous
This Month in Spring - November 1, 2018
This Month in Spring - November 1, 2018

Next
How to Measure Software’s Ability to Deliver Value
How to Measure Software’s Ability to Deliver Value

A dive into why an organization should take Pivotal’s Benchmark survey, which measures how well an organiza...

×

Subscribe to our Newsletter

!
Thank you!
Error - something went wrong!