How to Get Started on Accessibility Before You Have a Product
Welcome! I’m Derek Featherstone, accessibility guru. You’ve heard about accessibility. You know what it means. Why it’s important. But you don’t know where to start, especially because you don’t have a product yet.
You’re pre-product. You’re a startup. Maybe you’re pre-startup.
- What can you do to make your non-product more accessible?
- How can you build accessibility in from the start?
- How can you shift accessibility left?
- How can you start sooner?
You may not have a product, but…
- You have a great idea.
- You have a sketch.
- You may even have a prototype.
Congratulations! You can get started with accessibility!
Why now? Why not later?
After all, you could start thinking about accessibility once you start building. Or you could “get to it in phase 2,” which we all know is code for “never gonna happen.”
The longer you wait to incorporate accessibility, the greater the chance that your product will be inaccessible (or at least expensive and time-consuming to retrofit). When you start immediately, you can iterate, test, learn, and end up with a stronger—and more accessible—product.
This page is all about finding ways to ensure that accessibility isn’t forgotten or pushed off to the end. I’ll share some ways to start thinking about and implementing accessibility in your product—while it’s still a twinkle in your eye.
Test Your Competitors’ Products
Discover their accessibility strengths and weaknesses
Take accessibility into account as part of your research and competitive analysis. We often talk about accessibility as a competitive advantage in the marketplace — people with disabilities are often very loyal customers when they find a solution that works well for them.
Five things to consider when testing your competitor’s product
- Can you use your competitor’s product using only a keyboard? If you can, they’re thinking about accessibility in a reasonably mature way.
- When you’re using your competitors’ products with a keyboard, can you see a visual focus indicator? You should always be able to see the focus outline in an interface as you’re moving through with the keyboard. If you can see it, they’ve done a decent job of making things accessible. If you can’t see it, then there’s opportunity for you to outshine them when it comes to designing for keyboard usage.
- Do all of the form fields have visible labels that are programmatically tied to their field? If you click on the label, you should see the focus go into the label’s field. If the product has good form labels, there’s a good chance other parts of the interface are also accessible.
- What does automated testing tell you about the product? Automated testing is only part of the solution, but it often serves as a good proxy for the entire picture. A team that has taken good care of accessibility in their product won’t have many issues detectable by automated tools. On the flip side, if their product has a lot of issues detected with automation, there’s a good chance they also have many other accessibility issues.
- Does their product use semantic markup well? Do they use
<h1>to<h6>for headings? Do they use actual<button>elements and real links for things that are clickable or is all just a mess of<div>and<span>elements with click handlers attached?
How did they do?
This isn’t an exhaustive list, but if you take a look at how well your competitors are performing in each of the above categories, you’ll get a sense of where they’ve valued accessibility. Then you can note opportunities to be more accessible and give your product the competitive advantage.
I know — you’re probably saying, “But we don’t have time for accessibility. We have to get to market faster!”
I get that. I do. But remember this: the reason most people think accessibility takes longer is that they’ve always done it retroactively. That’s what eats up all the time. Doing things right from the start will save time in the long run.
Talk To People with Disabilities
Find out what they want from your product
People with disabilities are the original life hackers. When a product or solution doesn’t meet their needs, they find a way to fill that need themselves.
Here’s a great example. Many gamers with disabilities use modified video game controllers, installing bigger buttons, sip/puff devices, mounts to enable one-handed play, etc.
It took a while, but eventually Microsoft turned that idea into the Xbox Adaptive Controller (XAC). The XAC takes into account the needs of people with disabilities and accessibility features are built into the product. Microsoft has won awards for this brilliant piece of design.
And that’s because Microsoft did the research to figure out what needs aren’t being met by existing controllers.
You can do the same. Go and talk with people with disabilities that use products like yours. See what they’re doing to solve the accessibility problems that they’re facing. Those mods and hacks express a specific need that exists that isn’t being met. Your product can be the one that meets those needs.
Have people with disabilities test your UI & UX
This final piece is all about how you can get feedback from people with disabilities before your product is launched. What do you need to get feedback from people with disabilities? How might you test prototypes at various stages?
Have a sketch or wireframe?
Take that sketch and talk through it with people with different disabilities. Explore how they solve problems. Understand their motivations and the way they think. Work with people that use voice recognition software to talk aloud about how they’d approach the interface and what voice commands they might give to accomplish tasks.
Have a Figma, Sketch, InDesign, or Adobe XD prototype?
Get people with low vision to review it. Even though it isn’t coded, you can still get feedback on colors, layout, interaction flows, and more.
Have a coded HTML prototype?
Get people that use a screen reader to run through the prototype and give you feedback.