WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Tenon.io

for

From: _mallory
Date: Jun 23, 2016 2:43PM

One possible workflow for an individual developer is to have it
integrated in whatever taskrunner is the hippest these days (task
runners are popular among front-end devs, which do things like
minify and concatinate HTML, CSS, and Javascript files, compile
CSS if a preprocessor like LESS or SASS is used, linting, etc) and
each change, or manually, the dev can send what's been built to
Tenon and get feedback (either directly in the terminal as JSON
or on the website for pretty graphs).

This is something we've got in the planning for our dev team at
work, however I feel developers running things like Tenon or aXe
are still best served by having someone on hand who can still
explain the results of the tool. What I think is nice about that
is that, while the developers are developing and getting feedback
from the tools, accessibility experts can help those developers
get more familiar with, and more facility reading accessibility
rules and things like the WCAG docs.

AXe is another that runs within a developer's dev cycle. Unlike
the browser-based testers, this is meant as automation to do what
automation is good at, just like the task runners mentioned above
that developers run. It's not necessarily meant as a replacement
for the browser-based tools, and no tools are a replacement for
dedicated QA/tester/specialists on the accessibility front.

Both aXe and Tenon can be integrated into Selenium tests as well
if you want these tests to be able to break the build when they
find warnings/errors. However for Tenon I'd say make sure you've
tweaked/set your levels (to lower false positives depending on
the kinds of code you have) before letting such a tool actually
break a build. You can adjust the sensitivity and importance of
individual tests (based on WCAG rules) and you can also set
tests by number to be skipped if necessary. I figure aXe has
similar ways of setting sensitivity but I haven't looked further
at it than someone internally giving a quick demo (using Selenium
and Java).

So I see something like Tenon as being useful in two ways: either
to give individual developers feedback as they interate through
write/read/fix code, or something sitting in the QA stack more
near the end, when a dev does a push or a pull request and
a bunch of other testing is happening too.

cheers,
_mallory
On Tue, Jun 21, 2016 at 01:09:57PM +0000, Weissenberger, Todd M wrote:
> One of our groups has expressed an interest in adopting Tenon.io to help their developers keep tabs on accessibility during the development cycle. My knowledge of Tenon is limited to a few perfunctory tests on the public site, and minimal use of the Chrome plug-in.
>
> Does anyone have a good example of a Tenon.io workflow that can help make this a good fit for developers who may not have a solid grasp of accessibility principles, standards, and practices? Feel free to share off-list if you prefer.
>
> Best,
> Todd
>
> T.M. Weissenberger
> Web Accessibility Coordinator
> Information Technology Services
> University of Iowa
>
> 319-384-3323
>
> > > >