feat(a11yPlugin): plugin for integrating with Chrome Accessibility Developer Tools

[marcysutton]

The first pass on an accessibility plugin for Protractor, integrating with the Chrome Accessibility Developer Tools.

We talked about adding a plugin hook for running after every test, as a way to increase test coverage.

I'll see how far I can get on the Tenon integration this week!

[marcysutton]

Woot! Plugin hook: #1842

[sjelin]

Maybe it would be best if we re-used the copy of angular that the testapp already has instead of your importing your own?

[marcysutton]

I thought the accessibility testing app should include ngAria, which was introduced in 1.3 and iterated on in releases since (1.4 would be best when it comes out, but 1.3.5 was a bug-free one). Can we upgrade the 1.3-rc1 version in the testapp folder to something newer? That's why I included a new version. Alternatively, we could try using newer ngAria with the 1.3-rc1 release of Angular.

[juliemr]

Yes, let's upgrade the all of the testapp version to something newer - it's just on 1.3-rc1 because we never had the motivation to update it. I will do this in a separate PR.

[juliemr]

Update this to the array format and include path:

plugins: [{
  path: 'node_modules/protractor.plugins/accessiblity',
  // etc
}]

[juliemr]

Awesome, just a couple of nits and comments about tests, as you mentioned.

[juliemr]

I've pushed a commit to use angular v1.3.13 and include aria: 64704e0

[marcysutton]

@juliemr I added a failure test (and I'm glad I did! it caught holes in the implementation), but I'm running into an issue where it's difficult to match the exact error message when the results will vary depending on the markup and audit results.

At the bottom of scripts/test.js, I have a placeholder error message of "warning -- Inaccessible markup". I didn't think we would print this to the console since we already have output, but I'm wondering the best way to assert there was a failure without hard-coding the errorMessage from the failing test (which includes HTML strings, urls, and other text). I looked into test_util.js and figured you'd have a good idea of how to handle it. Tenon will present a similar situation.

[juliemr]

Git seems to have lost the accessibility/failureConfig file.

expectErrors can take a regexp - can we use that to verify that the output message are sane? That should take care of not needing to hard code URLs - although I don't mind hard coding some error messages int his situation, it'll easily tell us when something unexpected happens and should be quick to update when we need to change our tests.

[marcysutton]

Yep, you were right–Git ate some files when I updated from the previous commit. They are back in there now and I have failing tests working appropriately.

[juliemr]

Ok, looks good to me! Merging in as a first version.

[juliemr]

Merged as 54163dc

I made a small edit - the testapp webserver takes care of adding the version prefix to the angular directory, so I removed the explicit version in the script srcs.

[marcysutton]

Thanks @juliemr!