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:
<script>
window.tenonSiteMonitor = {
siteKey: [put your site key here]
}
</script>
<script src='https://tenon.io/api/monitor.js'></script>
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.
Keep in mind, this hashes the content in that location. If that content changes, the Site Monitor will think it is new. So things like A/B testing, session tokens, or JavaScript content in the hashed container can make it look new to the monitor.
<script>
window.tenonSiteMonitor = {
siteKey: [put your site key here],
hashFrom: '#container'
}
</script>
<script src='https://tenon.io/api/monitor.js'></script>
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.
<script>
window.tenonSiteMonitor = {
siteKey: [put your site key here],
interval: 2592000
}
</script>
<script src='https://tenon.io/api/monitor.js'></script>
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.
<script>
window.tenonSiteMonitor = {
siteKey: [put your site key here],
onlyNew: true
}
</script>
<script src='https://tenon.io/api/monitor.js'></script>
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.
One of the most powerful features of Tenon’s API is that it is fully DOM-aware. In simplest terms, it means that we can access all features of the page. If we can have all of your HTML, CSS, JavaScript, and images, we will be able to more accurately test the page. This is made possible by adding inline: true to your Site Monitor snippet. With this option, the Site Monitor will fully inline all page assets as a package for testing.
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.
<script>
window.tenonSiteMonitor = {
siteKey: [put your site key here],
inline: true
}
</script>
<script src='https://tenon.io/api/monitor.js'></script>
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 talktous@tenon.io