Winter 2018 Improvements: More Power Behind Site Monitors
By far, the biggest differentiator between Tenon and all other accessibility tools is that our API-first approach allows us unrivaled flexibility. This is demonstrated quite easily by the number of integrations and related tools that make use of Tenon. Our API gives us the ability to quickly make new things that make accessibility testing easier. We want Tenon to work for you, not make you work for Tenon. One way we’ve accomplished this is with Site Monitors.
Adding a Site Monitor to your site is as easy as adding Google Analytics to your site. They’re also, without a doubt, the most powerful way to test a site once you’ve configured it properly. The first step, of course, is to set up your site monitor. Assuming you’ve already done that, let’s go through some use cases:
Test Every Page
By far the simplest thing to do is just insert the Site Monitor snippet right before your page’s closing body tag:
This is the bare minimum configuration of your Site Monitor. Installing this on your page will cause Tenon to test that page every time it is accessed. Using it this way is actually not a good idea. It will eat up all of your API calls very quickly, especially if you have a high-traffic website. This would be very useful in a QA environment, but not on a live site. Let’s look at some better ways.
Test only when the page has changed
It doesn’t really make sense to test the same exact page over and over if it has not changed. Conversely, it is a good idea to test a page when it changes – for instance, when it is edited from within a CMS. That’s where hashFrom comes in. hashFrom takes any string value that you can use within querySelectorAll(). When you add this to your configuration, the Site Monitor script will hash the content and determine if the hash value has changed. If it has, the page is tested. If it hasn’t changed, the page is ignored.
Test at a Specified Interval
What if you wanted to test your site on a regular schedule? interval allows you to set the total number of seconds between testing of the same page. So if you want to test your page once a month: (30 days 24 hours 60 minutes * 60 seconds) = 2592000.
Test Only New Pages
This is probably my favorite configuration option. onlyNew tells the Site Monitor to only test pages that it has never seen before. Using this option will immediately test your entire site as soon as the Site Monitor script is added to your site and then only new pages when they get added.
Test Behind a Login/ VPN/ other private environment
One of the hardest things for any automated testing tool to do – be it an accessibility tool, security tool, broken link checker, etc. – is testing things that require user interaction, things requiring the user to be logged in, or non-public environments like a QA or staging server. There are a couple of ways to do this. You can use Ngrok or, for even more power, use Selenium. Both of these options are excellent – and our preferred approach is using Selenium. However, these approaches might require more setup work than is feasible in some circumstances.
Using any of the above approaches, Tenon’s Site Monitors will work just fine, because if Tenon can’t access the URL, the Site Monitor script will send over the page source to the API. Unfortunately, this doesn’t give you the full power of Tenon.
Note: this is not a good option for testing a production website, because the inlining process uses your visitors’ CPU to compile the assets. Doing so will seriously diminish site performance for your users. However, it is an extremely powerful way to test within a QA environment.
Fast, Easy, and Powerful
Tenon Site Monitors allow you to test all pages of your site, regardless of whether they’re new or whether they require a login to view merely by adding a small snippet of code to your page. If there’s an easier way to do accessibility testing across an entire website, we’d love to hear it.
If you have any questions feel free to email us firstname.lastname@example.org