Automated Accessibility Checking

[sylus]

I was looking at the work being done at https://github.com/kevee/quail and was wondering if anyone has taken a look at this? The jQuery library aspect looks pretty extensive and would be a crazy boon to assist in the checking for accessibility problems. I believe he has or plans to have over 100 tests. Maybe we could reach out to @kevee as his work might be a valuable addition to WET? There is also a PHP lib but the jquery addition is fairly new and looks promising.

Main jquery file at https://github.com/kevee/quail/blob/master/jquery/quail.js

@pjackson28 @mgifford @LaurentGoderre

[mgifford]

There's also https://drupal.org/project/quail_api to take a look at.

And yes, I've been mostly watching this for a long time. I haven't had the time to go through & fully evaluate it. It's totally a great initiative though.

[nschonni]

I came across this bookmarklet https://github.com/squizlabs/HTML_CodeSniffer and have asked about a CLI version that we could integrate into the build system

[mgifford]

Interesting. Not sure a that a CLI version is required. It's I think more about what tools you're plugging into it. See:
quailjs/quail#11

[LaurentGoderre]

This would be cool if they did a nodejs version as opposed to jQuery

[kevee]

Just opened an issue quailjs/quail#46 to be added in next release, we have a new ui builder and packager project coming out that will require a saner build process. This will also mean I can do a build for cheerio that would get us closer to a node package.

There are a few tests that won't work in nodejs, like color contrasts or tests that write images to <canvas> elements to test image content. We can use the test tags to prevent these from running in that environment.

[mgifford]

I think it's totally amazing what @kevee has been able to produce, starting first from a PHP script to evaluate site accessibility. Moving to jQuery made a huge performance improvement. I'd just like to see a lot more people contributing code and setting up testing tools like http://drupala11y.org/

I know nodejs is cool, but I'd like to see more folks investing in what is already known to work.

[kevee]

Thanks, @mgifford, the big driver for me to get a better packaging system together is launching covey.io next month, which will finally get the community a packager and a better way to contribute.

[LaurentGoderre]

@mgifford the thing is that many libraries are going to vanilla JS with some nodejs integration. This allow the library to be run either on the browser (without any external library) or in a build system (Grunt).

I am undecided if we would use the SauceLabs INtegration or a grunt task but having the option is always better

[mgifford]

@LaurentGoderre I've been in the software industry long enough to see lots of smart folks work on re-creating the wheel just because they prefer a given language or framework. Ultimately most of those projects fail. If government were in the habit of supporting existing open source projects by contributing resources (code, tests, $$) rather than setting up a new tool in their preferred language/framework we'd see a lot more success all around. How many accessibility audit tools have governments built over the years?

@kevee I do love your naming structure https://github.com/kevee/cheney

Looking forward to http://covey.io's launch.

[LaurentGoderre]

Converting from jQuery to vanilla js is not that big a change while opening huge opportunities. By making this change you enable a lot of projects to integrate these checks within their build

[LaurentGoderre]

Take a look at mocha as an example, it can be run on an html page or in nodejs.

[hsrudnicki]

Are we ready to close this issue or otherwise ?

[mgifford]

I don't think it's been included yet has it?

Also worth looking at:
http://tenon.io
http://www.tanaguru.com

[LaurentGoderre]

This can remain open

[hsrudnicki]

into consideration the following: #3862 - v4 - Integrate WebAIM colour checker

[mgifford]

This isn't very good:
http://webaim.org/resources/contrastchecker/

You can evaluate Hex, RGB & HSL with:
http://leaverou.github.io/contrast-ratio/

There are some great firefox/chrome plugins but not sure how you'd incorporate them into WET testing.

[hsrudnicki]

Can be this issue closed if it's referenced or otherwise (pls update this issue status)?

[hsrudnicki]

again, please update this complex issue's status

[hsrudnicki]

Please update this issue's status/milestone for this current year as well, thanks

[grifare]

Here is what the official readme.md file said more than 3 years ago:

Given the realities of the market and the limited time that the Quail team can devote to this project, we are initializing deprecation for this project.

https://github.com/quailjs/quail/blob/master/README.md

@duboisp would you consider the closure of this issue, which recommended a tool in 2012?

[mgifford]

Hi @grifare like many other accessibility engines, the maintainers of QuailJS are deferring to axe https://github.com/dequelabs/axe-core

Same goes for the CKEditor Accessibility Checker that was also based on QuailJS.

Unfortunately, there hasn't been as much effort to make automated testing simple as I would like.

There are new options with Drupal 8:
https://www.previousnext.com.au/blog/automate-your-drupal-accessibility-testing-axe-and-nightwatchjs

There are definitely folks using axe on the command line to integrate with CI systems. I do think that this would be appropriate for WxT.

As I read it, this issue is about automated accessibility checking. Quail was an example. I'm fine with killing it and starting a new one highlighting modern tools command line tools.