What makes Tenon different?

Several weeks ago, Steve Lee asked me a question: “What makes Tenon different?”. My answer was, basically, the 140 characters allowed by Twitter was not enough, so go check out this video we have on the homepage. In it I talk a lot about the philosophy behind Tenon. I also have the slides from that presentation available. But let’s face it: watching an hour-long video is a bit much to expect. So here’s my attempt at discussing the differences.


I lay out Tenon’s philosophy in very long form on my personal site, starting with Everything you know about accessibility testing is wrong (part 1). There’s also a Part 2, Part 3, and Part 4. The two main drivers, however, are: put testing in the hands of developers and work with existing systems and workflows.

  • Put testing in the hands of developers – Avoiding bugs before they’re created is hands-down the least expensive, least time-consuming, and the best way to mitigate risk.
  • Work with existing tools and workflow – Deploying an accessibility tool that is wholly separate from other tools has the effect of allowing accessibility to be treated as something “extra” and outside of existing development workflows. This allows it to become marginalized and, eventually, ignored altogether.

Put together both of those main drivers are the basis of our API-first approach.

API First

We frequently say Tenon is “API first”. This is important to us. Vendors for competing products often say they have an API but we’re actually suspicious of those claims. Tenon is the API. The Tenon.io website is actually a client application built around the API. Our entire architecture is based on it. New features will be based on it. This allows Tenon to be – unquestionably – the single most flexible accessibility testing product on the market.


Tenon’s API allows you to customize your testing using 13 parameters that include things like WCAG Level, test certainty, and viewport parameters. By customizing the values for these parameters, you can fine-tune Tenon’s testing to give you the results based on your own priorities. In return, Tenon’s response includes a wealth of details, useful in processing the response for your specific needs, including 14 fields in each issue result.. The flexibility of the API allows you to very easily integrate Tenon into existing developer, QA, and content workflows.


Each of Tenon’s 86 accessibility tests are unit tested before deployment. None of our accessibility tests are allowed to be included without at least one “positive” test (on other words where it actually finds an accessibility error) and one “negative” test (one where it avoided a false positive). In reality some tests have as many as 94 different combinations they test for. Tenon isn’t perfect. We sometimes find bugs in our tests. This practice of unit testing each test allows us to fix those bugs very fast.


We have an incredible community and actively support people wishing to develop stuff that uses Tenon. Our community developers have already created:


The only way our prices could be better is if the product was free. Other than that, we challenge you to find a product that does what Tenon does for a better price, and we invite you to do the research.

As I mentioned earlier in this post, we want to put testing in the hands of developers. That meant putting a price tag on the product that’s within reach of the individual developer and small teams of developers. The “big guys” don’t even want that business – they’re too busy hunting whales on the Fortune 500 list. We care about making the Web more accessible and that means affordable pricing for the common developer.

Want to know what the “big guys” cost? Go to GSA Advantage and type in their products by name.

Continuous Improvement

If you’re at all excited about what Tenon offers right now, just wait until you see what else we have coming up. As I write this we are finishing a handful of new features including new web services, API improvements, and more.

Start your free trial of Tenon today!