Build vs. buy is even harder when you care about accessibility

By Karl Groves |

This week, we signed up for Intercom.io and installed their code on our site. Intercom.io is incredibly inaccessible. Why would we do such a thing?

Nobody likes to reinvent the wheel, especially in cases where the system you need isn’t core to your business. Build vs. buy is a decision that every company has to make at some time, even software companies. In many cases, the choices are clear. For instance, you’d be crazy to decide to build a Slack/ FlowDock/ Skype/ Lync/ HipChat clone to handle chat among employees. In some cases it isn’t so clear. Perhaps the existing market doesn’t have a product that fits your business needs. Or, like us there might not be a product that fits other important platform requirements. In our case the important platform requirement is often accessibility.

Along the way as we’ve gotten off the ground as a real business, we’ve had needs around certain business functions like user support. Early on, we decided to look into SaaS Help Desk products like ZenDesk, Fresh Desk, Desk.com and so on. Every single one of them had some accessibility issues, which is sadly pretty common, but found Desk.com to be better than most. It fulfilled our business needs and we could provide alternative ways for customers to contact us, like regular email and telephone. Eventually, we decided that a support desk was altogether unnecessary for us at the moment, as we can handle everything through email right now.

Replacing the support desk software with an email address and a form-to-email was ridiculously easy. In fact, it took less time to do that than it did to register, pay for, and configure Desk.com. But other things aren’t so black-and-white. Another area where this has been clear is in payment processing. As a developer, I’ve worked with a lot of payment APIs, including Authorize.net, Network Merchants, and PayPal, so when we started working on the accounts side of things for Tenon, we looked at the major players for SaaS payments like Recurly, Braintree, and Stripe. As was the case with help desk software, all front-end code (including code snippets, examples, etc.) was inaccessible.

Ultimately, we went with Stripe mostly because their API is so excellent. We use absolutely zero of their JS code and have coded everything ourselves. This comes with a bit of a price, however, because philosophically we want to avoid spending time writing code that doesn’t contribute to our core product. In this particular case, it means we haven’t fully implemented all of Stripe’s features. For example, we use EmailHooks.co to handle how we react to some of Stripe’s webhooks, like notifying people their card has expired, etc. That brings us to our next situation: Keeping in contact with our users.

When creating a SaaS product, there are tons of reasons to communicate with users:

  • User registration & confirmation
  • Forgotten password
  • Password reset confirmation
  • Subscription confirmation
  • Expired credit card
  • Subscription payment declined
  • Subscription cancellation

And that’s just the beginning. For instance, we send newly registered users an email asking them if we can help them get started in using the product. This is important not just for customer retention, but because we truly care about our users feeling successful with the product. As you go along, the reasons you can find for communicating with users can truly pile up. For instance, what about users who signed up but never confirmed? Was there a problem with the process? Did they not get the email? What about users who sign up, confirm, but never actually use the product? What is it about the product that made them decide not to use it after all? Getting feedback from customers is vital in knowing whether or not you need to fix something. Then again, keeping in close touch with thousands of users is pretty tough. Initially, we hand-coded these emails. I wrote a PHP class to handle queueing up emails based on certain activities. But, as the list grew it became obvious that this approach was unsustainable – especially when you want to segment users. I even thought about writing a front-end interface to create what would become pretty complex SQL statements to define user segmenting and that’s when I had enough.

At the same time, I saw someone mention Intercom.io in a startup forum. Specifically, they were asking about engaging with users in real-time. I thought that idea was really cool. Chatting with user might be helpful in helping them get started. Given that most web-based chat is inaccessible, my first concern is whether Intercom.io or any of its competitors are accessible. I took a poke at a few live customer chat products and my concerns were justified. None of them were accessible. But I wanted to get a real user’s perspective, so I grabbed my good friend Léonie Watson on Skype and asked her to try some out. Here’s our conversation as we spoke as she chatted on one of the products, Olark:

  • [8/14/15, 12:45:46 PM] Karl Groves: Hi. I do have a question though. Would you mind poking at the chat thing on www.olark.com
  • [8/14/15, 12:46:52 PM] leonie.watson: Yup
  • [8/14/15, 12:49:05 PM] leonie.watson: Is there a demo, or do I need to get a free trial?
  • [8/14/15, 12:49:44 PM] Karl Groves: Well that’s actually perfect feedback!
  • [8/14/15, 12:50:00 PM] leonie.watson: You know this company?
  • [8/14/15, 12:50:33 PM] Karl Groves: I’m trying to find a live chat product to add to Tenon.
  • [8/14/15, 12:51:13 PM] leonie.watson: Ok, so I’ve asked them a question – which presumably uses their own live-chat thing. The edit field seems to be labelled – at least Jaws announced it had appeared (focus moved to it when it opened).
  • [8/14/15, 12:51:43 PM] leonie.watson: Was able to type into the field and submit my question, which then appeared visually above the edit field. The fact this happened wasn’t announced by Jaws though.
  • [8/14/15, 12:51:58 PM] Karl Groves: dammit
  • [8/14/15, 12:52:36 PM] Karl Groves: Have you ever used live person?
  • [8/14/15, 12:52:42 PM] leonie.watson: No.
  • [8/14/15, 12:52:51 PM] leonie.watson: I’m just chatting with their sales person about a11y.
  • [8/14/15, 12:54:13 PM] Karl Groves: Live Person is pretty popular in that industry, but I’m almost positive they’re not accessible either
  • [8/14/15, 12:54:20 PM] leonie.watson: he question “how well does it work with a screen reader” seems to have them stumped sadly.
  • [8/14/15, 12:54:34 PM] Karl Groves: ugh
  • [8/14/15, 12:54:38 PM] leonie.watson: TBH I doubt that any of these are without some mucking about with.
  • [8/14/15, 12:54:52 PM] Karl Groves: So disappointing
  • [8/14/15, 12:54:54 PM] leonie.watson: This one could be with some live-regions/alert roles or somesuch.
  • [8/14/15, 12:54:58 PM] leonie.watson: Yeah.
  • [8/14/15, 12:55:35 PM] Karl Groves: I’m gonna write a blog post about this.
  • [8/14/15, 12:56:09 PM] leonie.watson: Good idea. Response “Will have to get back to you about this. Which screen reader do you use, or do you mean accessibility in general?”.
  • [8/14/15, 12:56:19 PM] leonie.watson: leonie.watson sighs.
  • [8/14/15, 12:56:38 PM] Karl Groves: There have been so many similar situations where I’ve decided not to buy because stuff wasn’t accessible
  • [8/14/15, 12:56:53 PM] leonie.watson: Yup. That’s the point I’m basically making to these guys now.
  • [8/14/15, 12:58:07 PM] leonie.watson: “We are not ADA compliant at this time, but it does work with certain programs”.
  • [8/14/15, 12:58:27 PM] Karl Groves: they don’t know what they don’t know
  • [8/14/15, 12:58:40 PM] leonie.watson: That’s often most of the problem.
  • [8/14/15, 12:59:42 PM] leonie.watson: “I am not sure which programs as it is not something we have worked on yet, it is just speculation that some programs may work with Olark. At this point I cannot say that there are firm plans in place.”
  • [8/14/15, 1:01:38 PM] leonie.watson: I’m guessing all these things are using Web RTC?
  • [8/14/15, 1:02:03 PM] Karl Groves: That’s a good question. Not sure but it makes sense
  • [8/14/15, 1:02:28 PM] leonie.watson: Yup. I’ve been meaning to read through the WRTC spec to give them some a11y feedback. Perhaps I’ll find time over the weekend.
  • [8/14/15, 1:02:59 PM] leonie.watson: Wonder how difficult it would be to create an accessible one of these things? The UI is fairly simple, but I have no idea about the underlying mechanics.
  • [8/14/15, 1:03:34 PM] Karl Groves: The UI is ridiculously simple. Its gotta be easy to make accessible
  • [8/14/15, 1:03:41 PM] leonie.watson: You’d think.
  • [8/14/15, 1:03:48 PM] Karl Groves: BBIAB
  • [8/14/15, 1:03:51 PM] leonie.watson: Later.
  • [8/14/15, 1:26:21 PM] Karl Groves: Dammit
  • [8/14/15, 1:26:42 PM] Karl Groves: Now you got me wanting to build one
  • [8/14/15, 1:27:40 PM] leonie.watson:
  • [8/14/15, 1:27:49 PM] leonie.watson: I was thinking the same thing.
  • [8/14/15, 1:28:56 PM] Karl Groves: Web sockets and Node would work for this. Basically you Create a socket tied to the user’s session.
  • [8/14/15, 1:29:44 PM] leonie.watson: Don’t know anything much about Node, but that seems reasonable.
  • [8/14/15, 1:38:12 PM] Karl Groves: OK. I’m mad enough about this chat stuff.
  • [8/14/15, 2:26:41 PM] leonie.watson: (highfive)
  • [8/14/15, 2:27:03 PM] Karl Groves: I’m writing out a specification to build one
  • [8/14/15, 2:27:39 PM] leonie.watson: If you want a second pair of eyes on it, give me a shout.

At that point, that’s exactly what I did. I began to spec out my own live chat product. It is even on Github if you’re interested. Upon writing out the high level specification, my next task was going to be writing up feature specs for each individual part of the product. As I began writing the features, it became more and more obvious that actually building the chat would be silly unless I also planned on selling the product to others. Who knows? Maybe I will eventually do that, but for now my focus is on Tenon and spending money on things that are not Tenon is money wasted. I continued my search across the array of live chat providers, but ultimately arrived back at Intercom.io and earlier this week we purchased a subscription.

Although the chat I had above with Léonie was regarding Olark, it is important to remember that none of the competing products, like LivePerson, Intercom.io, Customer.io, MixPanel, etc. are accessible, and each of them have enough accessibility flaws that choosing based on accessibility alone is sort of a fruitless exercise. We made our choice to go with Intercom.io based on features and price.

Hopefully this post added useful information for others who may be wondering whether or not to build or buy software they need. The decision isn’t always easy. In some cases, the decision has to take into consideration factors that go beyond budgets, resources, and time. In any case, when you do decide to buy you should at least make your voice heard, as a customer, to ensure your provider understands how to meet your needs. In our case, we plan to lean on Intercom.io pretty hard to fix the accessibility of their generated emails and of their chat interface. Both of those should take very little effort to fix, but right now the accessibility is rather poor. And who knows, if they decide not to fix it, I might go out to try to raise funding to build my own. After all, I’ve already got most of the spec written!

Start your free trial of Tenon today!

Sign up now