Excerpted and based on a talk given at PluralsightLIVE 2018 in Salt Lake City, see Part 1 here and Part 2 here.
If you’ve read my previous two posts in this series, you’re sold on the value of inclusive, accessible design, and you have some responses in your arsenal to combat a few common myths about making accessible products. The next question is simple: now what?
How can we get started actually making our software accessible? Where do we even begin? Don’t worry — I have a few tips to help you get off the ground.
Tip #1: Empathy, Empathy, Empathy
Remember what we learned in the last post: that everyone experiences some amount of mismatch with their environment. Use your own different access needs to your advantage.
Try approaching your app in a few different ways: For example, one of the first things I will do is to try navigating my product by tabs alone. With just this small exercise, you’ll discover classic “keyboard traps,” potentially spinning up your tabs in an endless loop that you can’t escape (yikes)! This should help you ensure that keyboard-only users can do everything you would want them to do in your app; and you’ll help out power users, to boot.
You can also turn on the accessibility guides on your phone or your computer (for example, my Mac has VoiceOver), to check that what you hear makes sense and allows you to complete a task. You’ll learn quickly how annoying some bad alt text can be!
I once had a boss who would pull up the website he was building, put his computer in the passenger seat of his car, and then hit the highway to see what he could glean from a distracted glance. I REALLY don’t recommend this method, but there’s a multitude of creative – and less extreme – ways to walk through your product or website with a different point of view.
So don’t stay in your own bubble! Talk to different people about how they might approach your app, and reach out to the disabled community to find out how they do things. As always, empathy is best when it’s born from open listening and meaningful relationships with people.
Tip #2: It’s the Information Age, Google it! And Find Your Guides.
Good news: There are so many great resources out there to get you started on accessibility and inclusion, including guides by industry leaders like Airbnb (they highlight how access is never “just” digital), IBM Design, and Google. I also recommend reading up on blogs, both personal and professional, from the disabled tech community. You can learn how a blind programmer codes on Medium, or watch a deaf gamer play on YouTube and search hashtags like #a11y #fails on Twitter as a valuable resource of what not to do.
As you wade in, you’ll watch your community and conversation around inclusive, accessible design proliferate!
Image of the black and white text accessible color swatches from IBM’s Design Language Color Guide
Similarly, don’t be afraid to lean on the good work of others! I could publish an enormous list of accessibility resources, from newsletters to podcasts, but here are a few: Microsoft gets a special shoutout for doing really fantastic work on Inclusive Design, led by Kat Holmes. IBM built a robust color system using easy math to know if a color combination is accessible. (Full disclosure: I previously worked at IBM with some of the team who built this.) Vox has a checklist focusing on media and content guidance, and 18F’s accessibility guide is chock-full of resource links and plain-language government requirements. There’s a lot out there, and you can put together resources for yourself based on how you learn best. And besides, in the real world, it’s never cheating to look it up! (By the way, I’m only mentioning a few, but if you have a favorite resource, drop it in the comments!)
Tip #3: Get Everyone Involved
You do not have to – nor should you – do this alone! Get everyone involved. At many places, including Pivotal, we take a balanced team approach. This involves the three interwoven disciplines of Design, Product, and Engineering. Each role owns a piece of the responsibility of the work, while together, they're equally accountable for the success of a product. Your team might have other roles as well, and it’s up to each of you to see where it would make sense for you to enable accessibility in your work! As for the balanced team, this is the tactical part. I’ve put together some things you can start looking out for as you work:
Image showing the “Balanced Team” Venn diagram to create a successful product, including Engineering (Feasibility: “Can we build it?”), Design (Usability: “Is it intuitive and valuable to users?”) and Product Management (Viability: “Will it help with the business?”)
Design
In setting up your problem space, ask yourself: What are my best UX patterns? What can I avoid in order to ensure a more accessible solution? As you uncover users and user needs, find your crisis scenario — what problems can you solve that will ensure the least friction across the board, for all users? Map their journey. In research, diversify the people you talk to — ensure you’re doing research with disabled folks, and ask for their pet peeves when working with your software, or a similar software.
Once you’ve started putting together your prototype, test your assumptions! Does the order and hierarchy of actions make sense, and does that align to the tab order? Can someone get stuck? Cover the basics from the beginning: Do your colors have enough contrast? Is anything important hidden away in a hover state? Are you using color alone to communicate meaning? Does your use of motion help with a tangible understanding of the application, or is it distracting and gets in the way? Am I saying things in the simplest, most direct way?
And of course, when you and test your prototypes, test with different ranges of ability as well!
Product
As you set up the team for success, start with inclusion. Help identify user bases that are being excluded from the existing product and work to include them. Build accessibility into your stories and your sprints, and help your designers source diverse users.
When your team starts building, learn to recognize accessibility issues. Include this in the first pass when you test a story for acceptance, and check that a feature can be done with both a mouse and a keyboard. Even better, include accessibility in your acceptance criteria!
As the team’s liaison with the business, you can be their strongest advocate. Bring in your stakeholders early on, and explain why accessibility is not optional. Your product is not viable if it is not accessible, and it’s important that everyone aligns on that notion from the beginning.
Accessibility is also an opportunity for you to diversify your market. Include disabled folks in your assessments, and understand the concepts of temporary and momentary disability, and how accounting for these scenarios can grow the user base for any accessibility feature need.
Finally, model the risk! Many clients now have accessibility included in their product requirements. How much would it cost to build accessibility into your cycles, versus how much it would cost to shoehorn it in later? How about compared to a lawsuit? Thinking about accessibility from the very beginning is not only the right thing to do: it also pays off.
Engineering
In tech, the devil-in-the-details always comes down to good code. When building a product, use semantic HTML wherever possible. Define meaningful page components, and adopt “div-phobia” — this will not only make your code cleaner, but it will make it far more readable for people using screen readers or audio hints. Make use of ARIA attributes as an option B.
Speaking of clean code, when naming things, ask yourself: am I saying this in the simplest, most direct way? Do the error messages make sense and give the users a path forward? If you have a designer, work with them to make sure every error has a way out! You can also collaborate on ensuring your images have meaningful alt-text descriptions for non-sighted users, and that videos have captioning. This not only helps the deaf community access your content, but it also allows people to engage with your stuff even if they’re in a loud coffee shop or in a super-quiet library, for example. Make sure every active element has a focus state that you can see and find easily. People don’t like to get lost.
While there are myriad libraries for all kinds of different things, promising to solve all your problems with one npm-install, beware of pre-packaging: often, out-of-the-box code snippets aren’t accessible. This includes copy and pasting from your own codebase. You'd be surprised how many times you’ll discover small but significant accessibility refactors you can do when you take a fresh look at your code.
Finally, when you’re testing, familiarize yourself with assistive technologies. If you can, get access to screen-readers like VoiceOver, JAWS, and NVDA. Ask about getting an assistive tech lab — or improvise! While it’s not an end-all solution (after all, what is?), consider adding an automated A11Y linter to your continuous integration pipeline. Design your automated tests with a11y in mind, and write tests for accessibility.
Everyone!
But wait, there’s more! Everyone involved can build themselves some reflexive, small things that they always check for: color contrast, tab order, hover styles, semantic HTML, simple language. Find a favorite resource, and use it to check your gut. Build an accessibility posse too: make an #a11y slack channel at your work, and advocate for hiring accessibility-literate people. Hold accessibility critiques with other people who are interested in making more inclusive software.
And, frankly, forget the “golden path” — no one will ever use your software in a perfect bubble. Complicate your scenarios, explore your edge cases, start with the surprisingly common idiosyncrasies, and you’ll find you come out with far more robust solutions than you initially expected.
And remember, this is a full-team effort, and it’ll be better for it. Anything you do to address these issues makes for better design overall. It’ll be more legible, more understandable, and more accessible for anyone who comes to your app — and at the end of the day, that’s your best vision for success.
Inclusive, accessible design is better for all.
