Startups Are Hard

You’re a startup. And let’s say you’re a real startup. Not a well-funded, solidly venture-backed behemoth that is pretending to be a startup. I mean strapped for cash, desperately trying to build something that people want, wondering if you and your employees will be able to feed your family 3 months from now: startup.

That’s hard. Really hard.

You’re making choices about which features to build, which customer needs to meet, and which beachheads to tackle first. Your choices may change monthly, weekly, or even daily.

This requires sacrifices. Sometimes painful sacrifices. Because if you don’t make those hard choices today, your company may not exist to solve anyone’s problems tomorrow.

There Are Consequences

Unfortunately, we wish that as an industry we were at a point where great accessibility in software didn’t cost meaningful (to a startup at least) amounts of money to implement, but we just aren’t there yet. It would be disingenuous to pretend otherwise. We know this because we work with them every day.

That being said, there are times when accessibility needs to be a part of the immediate roadmap for a startup, and there are things you can do today to set the stage for successfully implementing accessible software. Let’s examine when accessibility is necessary for a startup, and when you’ll have to make tough choices.

When You Need Great Accessibility

You’re Well Funded

Just do it because you can afford it now, and it will be cheaper to do earlier than later. If you’re still not sold on it, check out The Case for Software Accessibility. The biggest key to success is making accessibility natural to your design/development process.

You’re Selling to the Government

The government is going to require you to pass their accessibility requirements, so have great accessibility from the beginning and avoid the sales/regulatory headaches.

Your Users/Customers Have Accessibility Requirements

Medical software frequently must meet accessibility requirements, as there will be a higher % of users with disabilities. Note that some of these requirements will include accessibility needs beyond audio (the ability to rotate mobile devices, for example), and some may be unexpected (temporary loss of voice).

Again, save yourself the sales and marketing headaches and meet the requirements your users have (don’t forget to confirm these with your customers first!).

When You Need to Make Hard Choices

You’re Bootstrapping

When faced with the choice of focusing on great accessibility or giving your family and your team’s families more runway, choose the runway. Without it, there is no product.

A mediocre product today followed by a great product tomorrow is better than no product ever. Don’t kill your product and business in the pursuit of perfection too soon. Nail your product/market fit first.

Your Platform is Challenging

The platforms can make accessible design challenging, but possible, in certain circumstances. Take video games for example.

Not all video game formats provide an experience that would allow visually impaired users to have a first-class experience. Some blind players do still enjoy first-person shooters despite the extreme level of difficulty (ultra hard mode, anyone?). However, fighting games have a structure and sound design that blind players can successfully learn. The videos of BlindWarriorSven are particularly impressive.

For players with physical disabilities, Microsoft has the impressive Xbox Adaptive Controller, and for those with colorblindness, color blind modes are frequently available.

Challenging doesn’t mean impossible, but you’ll need to account for all these variables when planning your designs and budgets.

What You Can Do Now

So you had to make the hard choice, but it doesn’t mean you should completely disregard accessibility in your software today. Let’s consider what you can do now (no matter who you are) to set yourself up for success.

Web/Mobile

Designs should at least:

  • Implement minimum clickable areas
  • Avoid the usage of pop-ups or modals

Development should at least:

‍

This is the second post in our accessibility series. Check out our other articles:

The case for software accessibility

‍