-
Notifications
You must be signed in to change notification settings - Fork 363
Add warning that AX_FOCUS_02 is not available from axs.Audit.run() #85
Comments
Good point: it might make sense log a warning during axs.Audit.run(), although I worry that it might be confusing/noisy. Another option might be to make it a compile flag in grunt; it would probably be necessary to split the audit rules up into two directories to do this. That would at least make it clear which audit rules will be included and which won't. What do you think? |
I definitely agree that logging another warning in axs.Audit.run() may be noisy, especially because it makes a lot of sense once you know why this is the case. The grunt idea is great, but it won't let someone know that the axs.Audit.run() (or the Command Line Runner) does not include all possible tests. Unless they dive into the code or compare with the Chrome plugin. Not sure how common my use case is -- building a test framework in PhantomJS and want to include a flag to log accessibility warnings/errors for our dev team to review. I believe the code below can at least list the rules that aren't supported by axs.Audit.run() Object.keys(axs.AuditRules.rules).forEach(function(k) { var r = axs.AuditRules.getRule(k); if(r.requiresConsoleAPI) { console.log("Rule " + r.code + " is not available in automated testing."); } } ); |
When would the information about what rules are/aren't included be useful? That code snippet would indeed find rules which aren't included; how/when would you use that? |
I've been struggling with this, I see two different approaches:
I'm new to this plugin so I don't know if this is something obvious I should have figured out, or how much this would actually affect other people. For my use case I plan on just putting a comment in my PhantomJS code. |
I think it's hard to know when you're running an audit for the first time, so it would probably end up running every time you ran the audit, which wouldn't be good. Throwing some things out there:
|
I really prefer the first option. Actually what I'm thinking is
My reason for going against having separate code branches and stuff is that my intent to use the CLI is to automate the testing that a person would have to use the Chrome plugin for. I expected the CLI to support the exact same thing as the plugin and was quite surprised when it didn't. Doing a fix with different behaviour would make it even harder to understand why the logic is different. Suggested message: "Some rules cannot be checked using the axs.Audit.run() method call. Use the Chrome plugin to check these rules: [LIST THE RULES] If there is a way to get it to work without the Chrome plugin, I wasn't able to find it -- I tried in the Developer Console to call axs.Audit.run() allowing the console API, and I got a ReferenceError. Should I edit Audit.js and send you a pull request? |
That sounds great! Looking forward to the pull request :) |
There you go. I had some difficulty with grunt as this tool is new to me. Let me know if you need any further fixing. BTW, saw your talk with Cameron at Fluent Conf 2014. Thanks for presenting this tool there, our team was not familiar with it and I brought it back home |
I compared the Chrome plugin with my results from running axs.Audit.run() and kept noticing that the warning AX_FOCUS_02 was being included in the plugin but not from axs.Audit.run().
After digging in the source I realized it is because this rule requires the "console API" as it uses getEventListeners(), which is not available in the DOM (i.e. outside of Firebug, Chrome DevTools, etc.). http://stackoverflow.com/questions/9046741/get-event-listeners-attached-to-node-using-addeventlistener
Would it make sense to add a warning about this in the documentation under "The axs.Audit.run() method"? Are there others who might get tripped up by this?
The text was updated successfully, but these errors were encountered: