Now that rules are stored in the same repository, we should only have to include dependencies once, however the following dependencies are bundled both for core/engine and commons:

[
  'bower_components/simple-clone/lib/index.js',
  'bower_components/element-matches/lib/index.js',
  'bower_components/escape-selector/lib/index.js'
]

This information is not readily available as the CSS selector will not use an ID if it is not unique. We should include the value of the duplicated ID attribute in the failure message.

The passes array can be large and capturing it for large pages can take seconds, we should allow for an option to be added to suppress the capture of the node information in the passes array.

When this option is turned on, the rules that run and passed on the page should still be captured but the nodes array will be empty.

A color contrast violation should not be identified for labels of inputs which are currently disabled, per the "Incidental" exception found at http://www.w3.org/TR/WCAG20/#visual-audio-contrast-contrast.

For example, in the example below, the label containing "Jim" should not fail color contrast.

<style>
  label.disabled {
    color: #ccc;
  }
</style>

<input id="bob" type="radio" name="name" />
<label for="bob">Bob</label>

<input id="jim" type="radio" name="name" disabled="disabled" />
<label for="jim" class="disabled">Jim</label>

1. How to add a Rule
2. How to add a Check
3. How to override a Rule
4. How to override a Check

PhantomJS thinks NodeLists have a typeof function. The following fails to find any issues in PhantomJS < 2.

var context = document.querySelectorAll('#header, #footer);
axe.a11yCheck(context, function (r) {
   console.log(r);
});

Reporter should include rules that were not applicable because no nodes matched.

The dependency on the node-uuid module is leaking things into the window namespace in a browser and into the module.exports when required in Node.js

We should not leak anything into any namespaces unintentionally

ARIA specifies that some roles require an accessible name. We should have a rule that verifies.

a11yCheck({}, {
  runOnly: {
    type: "tag",
    values: ["my-made-up-tag"]
  }
})

I would expect this to throw an error for my-made-up-tag not being a known ruleset tag. However, it successfully returns 0 violations. (Presumably because the tag doesn't exist, so the rule-set that was checked is empty, thus finding 0 violations.)

Additionally:

a11yCheck({}, {
  runOnly: {
    type: "rule",
    values: ["fakeRule"]
  }
})

also successfully returns 0 violations, rather than an error even though fakeRule doesn't exist.

I would expect both of these scenarios (as well as with {rules: {fakeRule: {enabled:true}}}) to return errors stating that the rule ID or tag doesn't exist.

Similar to what is in accessibility-developer-tools https://github.com/GoogleChrome/accessibility-developer-tools/blob/master/src/js/AuditRule.js#L129

Needs confirmation that aria-disabled=true satisifies the WCAG 1.4.3 requirement

For better or for worse, nodejs conventions are taking over JavaScript as a whole, even in browser js.

One convention that applies to a11yCheck is the callback parameters. It currently accepts a single successful result parameter. NodeJS convention, by contrast, is well established that callbacks are defined as cb(error, result).

I strongly recommend that the a11yCheck callback conform to this pattern, as it would make it possible to use all the nodejs async utilities (like async itself, and any promise library with denodify-like support).

Some ready on node's error-first callbacks: http://thenodeway.io/posts/understanding-error-first-callbacks/

Google's Accessibility developer tools extension has this check which I find useful. I guess this is a very rarely found a11y problem but could be related to checking for only one role=main or was the role=main put on a logical element.

nav role="main"

Scrollable areas (overflow: auto / scroll) need a method for keyboard-only users to scroll the area. This can be fixed if:

1. The scrollable area has focusable elements within it.
2. The scrollable area is added to tab order.

If you have a naturally tab-focusable element (that is not display:none or visibility:hidden) such as a button with aria-hidden="true", screen reader users will hear "blank" when they land on the element. We need a rule to test for these conditions

http://www.w3.org/TR/aria-in-html/#fourth-rule-of-aria-use

This is clearly up to the maintainers (as the behavior is rather subjective), but in the process of working on the matcher gem, I found it odd that invoking a11yCheck({include: "#nonExistant"}) doesn't throw an error when #nonExistant doesn't exist.

Perhaps it's not worth throwing an error, as the 'error state' can be derived by checking if both violations and passes are empty in the results? I'm not familiar enough with the underlying functionality to know if there are other instances where violations and passes would both be empty that doesn't indicate a no-match scenario.

Thoughts?

We currently support all ARIA 1.1 roles; but we may have missed some of the new states and properties.

The list currently only supports Spanish, English and Japanese

https://github.com/dequelabs/axe-core/blob/master/lib/checks/language/valid-lang.json#L3

The documentation around selecting which rules should be run (https://github.com/dequelabs/axe-core/blob/master/doc/API.md#b-options-parameter) lists essentially three modes of operation:

1. only rules included in (presumably the union?) set of rules matching given tags
2. run all rules except x, y, z
3. run only rules x, y, z

syntax for 1. is runOnly: type: "tag", values:[]
syntax for 2. is rules: rule1: enabled: false
syntax for 3. is documented as runOnly: type: "rule", values:[]

However, example 3 shows rules: rule1: enabled: true. With the documented behavior being that only the rules listed as enabled are run. This seemingly contradicts the documentation which states that:

The default operation for a11yCheck is to run all rules.

Is example 3 a typo? Should it have been runOnly: type: "rule", values: [x, y, z]? Or is the syntax truly rules: rule1: enabled: true/false. Or are both forms acceptable? If so, it sounds as if

The default operation for a11yCheck is to run all rules.

should be clarified to state that once any rules/runOnly is specified, then a11yCheck no longer defaults to "all rules". (For if that were true, then specifying a list of rules with enabled:true would be meaningless.)

In order to (sanely) extend or override Checks, the engine will need to store Checks in a single collection and then look up function bodies & default options once rather than for every rule that references it.

Currently it expects:

dqre._load({
  rules: [{
    id: 'bob',
    any: [{
       id: 'bob-check',
       options: 'specific-options-for-rule-implementation'
       evaluate: function () {
         // function body
       }
    }, {
       id: 'bob-check2',
       evaluate: function () {
         // function body
       }
    }]
  }]
});

Change this to:

dqre._load({
  checks: [{
    id: 'bob-check',
    options: 'default-options',
    evaluate: function () {
      // function body
    }
  }, {
     id: 'bob-check2',
     evaluate: function () {
       // function body
     }
  }],
  rules: [{
    id: 'bob',
    any: [{
       id: 'bob-check',
       options: 'specific-options-for-rule-implementation'
    }, 'bob-check2']
  }]
});

<img role="presentation" src="myimage.jpg" />

Is a valid decorational image but is currently being flagged

I recreated your chrome plugin with some extensions (like setup which rules should be checked). If you are interested in code it is available on github: https://github.com/ptrstpp950/a11yChromePlugin

See https://gist.github.com/dsturley/4ce0bcaf8a83e931121e

We could probably ignore any element that is overlaid on top of the element tested.

The following should default include to the document:

axe.a11yCheck({}, function (r) { console.log(r); });

axe.a11yCheck({ exclude: ['.bob'] }, function (r) { console.log(r); });

axe.a11yCheck({ exclude: [] }, function (r) { console.log(r); });

Expose a "getSelector" or DqElement API to allow Chrome to more efficiently generate an ID

empty-heading rule throws on a violation on:

<h3 role="presentation">Not empty</h3>

If a radio or checkbox set does not have a containing fieldset or ARIA group, the check's message is empty and is thus ignored.

We should just show the important bits, e.g. <html lang="en class="blah blah blah">

http://www.w3.org/TR/html5/grouping-content.html#the-ul-element

Need to allow for these within lists

Reporters assume that relatedNodes should always be an Array, not a NodeList. Engine should cast all relatedNodes to Arrays.

Add help, helpUrl and tags to the output of axe.getRules.

1. n/a
2. no-passes
3. v1

API documentation does not document how to specify options for Checks. We should probably also document what Checks take options, the format they expect and default values.

We do not handle SVG images correctly at the moment, need to be able to calculate the accessible name correctly for inline SVG and report when not present.

commons is not exposed, so if custom rules need to access them, they will not be available.

Tabindex values > 0, while to be avoided in most cases, do not necessarily impact accessibility, and could in some cases improve it. Should just be a warning to ensure that tabindex values do not negatively impact meaning or focus order.

For example, the positive tabindex values in the YouTube iframe at http://www.deque.com/products/fireeyes/fireeyes-resource-center/fireeyes-installation-video/ (tested using aXe plugin for Chrome).

https://github.com/dequelabs/axe-core/blob/master/doc/rule-descriptions.md

Would be good to document the easiest way to get going on a given html page.

I would think that doing an audit of the whole page would be the easiest. How would I do that?

I'd rather not have Qunit or Selenium enabled to do this too.

Elements may only be owned by one other element. With aria-owns, it is possible to

1. Have two elements trying to own the same element explicitly
2. Have an element try to own something that is already implicitly owned by some other element

We should have rules that detect both of these scenarios