Understanding Tenon API Request Parameters
This document discusses all of the various request parameters available to Tenon API users. The number and kinds of request parameters we provide allows Tenon to work for you in a way that matches your specific goals and needs.
You can access a Postman Collection of samples showing how to use the Test API.
There are only two required parameters:
'key' and either
|url or src||
Notes on testing Source
src, ensure that the path to all document assets is set to a fully qualified path, otherwise
those assets (and their impact on the UI) will not be accurately tested. For instance, if you're testing a document
- include the fully qualified path of the relevant assets in the relevant
<link>tags of the source string
Remember: the important part of testing is to test that which will be experienced by the user which means, if testing document source, you should send over a "rendered" version of the source
Note: If you plan to send over document source, you may want to explore utilizing a Grunt plugin like Grunt HTML Smoosher to help prepare the source.
All of the below parameters are optional for all users. Some of these parameters may not be available to you depending upon your plan. For specific details on what your plan allows, review your plan details.
Providing any value outside of the accepted list of values will result in failure.
Sometimes accessibility tools will return results that the tool isn't completely sure is a real issue.
Note: You probably don't want to only choose '100' as this will, in practice, probably be too conservative. We try to create tests that return real results and so very low certainty scores should be few and far between. As a general guide, if integrating Tenon into an automated build or pre-commit hook, use 80 and above. For a QA scenario, choose the lowest value you can tolerate as an organization.
Note: it is your responsibility to ensure accuracy and validity of the supplied string. We will accept any (safe) arbitrary string for this parameter. If no value is supplied, the report will go into your default project
Each Best Practice in the system has a number of factors that allow us to determine their relative priority. In your result set, each issue reported will be given a calculated priority score which you can then use to filter or order your results.
Note: in practice, it is unlikely that an issue returned will have 100% priority. Like
The level parameter indicates the "lowest" WCAG level to test against.
Note: Keep in mind that WCAG Level does not actually correlate to Priority when determining what to test for. For more information on our philosophy regarding prioritization, see blog post by Karl Groves: Understanding WCAG Level
In practice, very few of the Level AAA Success Criteria are testable using automated means and therefore
few tests against these anyway. Despite this, we recommend selecting "AAA" for the
|delay (formerly waitFor)||
The delay parameter tells the API to wait a specified amount of time, in milliseconds, before beginning execution of tests.
This is a very important parameter for web pages that get content from Ajax or 3rd party CDNs. If you have performance issues,
you should strongly consider using it.
Note: The length of time we will store the results depends upon your plan.
Note: it is your responsibility to ensure accuracy and validity of the supplied string. We will accept any (safe) arbitrary string for this parameter. If no value is supplied, Tenon identifies itself with a Google Chrome user-agent string.
Note: If this parameter it is not supplied at time of request it will be set to '768'. If you set one viewport parameter you must set both
Note: If this parameter it is not supplied at time of request it will be set to '1024'. If you set one viewport parameter you must set both