Guest Post: Tenon.io: The Ultimate Accessibility Linter, by Joe Watkins

As a front-end developer, I sure have enjoyed adding Tenon into my workflow. I know that when I ship code that has passed through Tenon’s tests, it’s on its way to being as accessible as possible. Many professional web developers lint their JavaScript, CSS, and HTML – you can now add automated accessibility linting to the list.

I’ve particularly enjoyed using the Grunt Tenon Client for accessing the powers of the Tenon.io’s API. It is super easy to set up and fun to work with. It has earned a regular spot in my Grunt tooling system. I’ve even written a how-to on how to setup the Grunt Tenon Client task.

Test Early: Retrofitting good code into poor code is not fun

I’ve found it is best to integrate Tenon’s testing into your project as early as possible. If you have a basic understanding of Grunt or Gulp, building it into your workflow should be pretty easy. There is helpful documentation for both of these tools.

Here is a snapshot of one of my Grunt setups:

Grunt Tenon Client Configuration

A basic front-end workflow

Let’s say you’ve been handed a few designs and you are starting to setup your project locally. You’ve set up Git, whatever frameworks you swear by, your folder structures are good to go, you’ve set up your task runner of choice, and you’ve even began basic CMS setup. Before you’ve coded one line of html – start thinking about accessibility testing. Test!

Setup the Grunt/Gulp task to run as part of your HTML build task. If you are “watching” particular file formats e.g., .html, have the Tenon task check those files. If you are using a CMS locally have it check a url e.g., localhost.tenon.io:3000 or localhost.tenon.io:3000/page-name-here.

You will be amazed about how much you can learn from these tests. I’ve learned about accessibility features I didn’t know existed and I make it a personal challenge to pass tests with no errors. When used wisely, you can also set up errors to ignore for certain situations.

While everyone’s workflow is different, I generally start out coding a few static pages or components and get things to a point where I will then need to migrate these templates/patterns into a CMS. Along the way I’m either testing a style guide or the static pages I’ve created. Once I’ve moved completely into the CMS, testing can happen less because the code being used has been qualified as accessible from previous tests.

Tenon is famous for finding those tiny accessibility issues you will be amazed that you overlooked.

Clients, Stakeholders and the CMS

An important part of keeping a project accessible is making sure that the CMS you have chosen plays nicely with web accessibility.

It is a good practice to create accessibility features into the CMS and educate your clients about the importance of them. Make these features required fields. For example, if you create an image field in the CMS, follow it up with a required image alt field. Choose a CMS that allows for this. A good CMS will let you put notes with fields to remind clients of what the field is for.

Expression Engine, Drupal, and WordPress are a few that spring to mind.

With good CMS architecture, your accessibility testing is set up for success!

An auditor’s best friend

I also use Tenon.io’s website testing tool as part of my website auditing workflow. Entering a url into the field gives me massive amounts of useful information for auditing a website’s accessibility situation.

With these test results clients can have a very clear picture of what’s going on with their website’s accessibility issues. After an audit, and accessibility work has been completed, the test can be re-run and clients can see the improvements you’ve made!

Armed with a full accessibility testing stack

It is great that we have tools like Tenon.io, but nothing beats manual testing and roping in other tools to add to your accessibility testing stack.

Manually testing websites for navigability issues using only the keyboard, testing with real screen readers on both desktop and mobile devices, as well as leveraging built-in accessibility browser extensions and plugins will make for a full accessibility testing stack. Try not to put all your eggs in one basket and you’ll have better results. Here is an excellent resource for trusted tools and resources you can add to your stack.

Have fun, and sleep better creating things that make the web a better place 🙂

Joe Watkins

Front-end Web Developer & Web Accessibility Advocate

Web: http://joe-watkins.io

Twitter: @_josephwatkins

Github: https://github.com/joe-watkins

Post a Comment