<commit_before># ember-a11y-testing

[![Build Status](https://travis-ci.org/ember-a11y/ember-a11y-testing.svg)](https://travis-ci.org/ember-a11y/ember-a11y-testing)
[![NPM Version](https://badge.fury.io/js/ember-a11y-testing.svg)](http://badge.fury.io/js/ember-a11y-testing)
[![Ember Observer Score](https://emberobserver.com/badges/ember-a11y-testing.svg)](https://emberobserver.com/addons/ember-a11y-testing)

Ember A11y Testing is a wrapper around [Deque Labs'](https://github.com/dequelabs)
[axe-core](https://github.com/dequelabs/axe-core) accessibility testing engine.
It integrates into your testing environment with a simple `a11yAudit()` helper.

If you're using Ember 1.13.0 or above, it also integrates into your development
workflow by running during a component's `didRender` phase in non-production
environments. This gives you instant feedback on if your component's are
accessible in any given state.

## Installation

```bash
ember install ember-a11y-testing
```

## Usage

Ember A11y Testing injects the `axe` global during development and tests so that
you can run accessibility audits while developing your application. It also
provides some Ember-specific tools so that you can integrate accessibility
checks into your workflow easily.

### Testing Usage

Ember A11y Testing also provides a simple helper to run accessibility audits
on-demand within your test suite.

For Acceptance tests, the helper is an async test helper so you can use it like
this:

```javascript
import a11yAudit from 'ember-a11y-testing/test-support/audit';

// ...elided for brevity

test('Some test case', function(assert) {
  visit('/');
  a11yAudit();
  andThen(() => assert.ok(true, 'no a11y errors found!'));
});
```

The helper can optionally accept a "context" on which to focus the audit as
either a selector string or an HTML element. You can also provide a secondary
parameter to specify axe-core options.

The helper is also able to be used Integration/Unit tests like so:

```javascript
import a11yAudit from 'ember-a11y-testing/test-support/audit';

// ...elided for brevity

test('Some test case', function(assert) {
  this.render(hbs`{{some-component}}`);

  let axeOptions = {
    rules: {
      'button-name': {
        enabled: false
      }
    }
  };
  return a11yAudit(this.$(), axeOptions).then(() => {
    assert.ok(true, 'no a11y errors found!');
  });
});
```

As you can see, the usage for all types of tests is pretty much the same. The
only real difference is Acceptance tests get automatic async handling.

_Note:_ any tests run with Ember A11y Testing will adjust the testing container
to occupy the entire screen. This is to simulate the actual application
environment, as browsers adjust styles at small sizes for accessibility reasons.
It will reset itself at the conclusion of testing though.

### Development Usage

Usage in development is restricted to applications using Ember 1.13 and up, as it
relies on the `didRender` hook of a component's life-cycle (a feature only<commit_msg>Update readme with new features/info<commit_after># ember-a11y-testing

[![Build Status](https://travis-ci.org/ember-a11y/ember-a11y-testing.svg)](https://travis-ci.org/ember-a11y/ember-a11y-testing)
[![NPM Version](https://badge.fury.io/js/ember-a11y-testing.svg)](http://badge.fury.io/js/ember-a11y-testing)
[![Ember Observer Score](https://emberobserver.com/badges/ember-a11y-testing.svg)](https://emberobserver.com/addons/ember-a11y-testing)

Ember A11y Testing is a wrapper around [Deque Labs'](https://github.com/dequelabs)
[axe-core](https://github.com/dequelabs/axe-core) accessibility testing engine.
It integrates into your testing environment with a simple `a11yAudit()` helper.

If you're using Ember 1.13.0 or above, it also integrates into your development
workflow by running during a component's `didRender` phase in non-production
environments. This gives you instant feedback on if your component's are
accessible in any given state.

## Installation

```bash
ember install ember-a11y-testing
```

## Usage

Ember A11y Testing injects the `axe` global during development and tests so that
you can run accessibility audits while developing your application. It also
provides some Ember-specific tools so that you can integrate accessibility
checks into your workflow easily.

### Testing Usage

Ember A11y Testing also provides a simple helper to run accessibility audits
on-demand within your test suite.

For Acceptance tests, the helper is an async test helper so you can use it like
this:

```javascript
import a11yAudit from 'ember-a11y-testing/test-support/audit';

// ...elided for brevity

test('Some test case', function(assert) {
  visit('/');
  a11yAudit();
  andThen(() => assert.ok(true, 'no a11y errors found!'));
});
```

The helper can optionally accept a "context" on which to focus the audit as
either a selector string or an HTML element. You can also provide a secondary
parameter to specify axe-core options, or specify options as a single argument:

```js
test('Some test case', function(assert) {
  let axeOptions = {
    rules: {
      'button-name': {
        enabled: false
      }
    }
  };

  visit('/');
  a11yAudit(axeOptions);
  andThen(() => assert.ok(true, 'no a11y errors found!'));
});
```

The helper is also able to be used Integration/Unit tests like so:

```javascript
import a11yAudit from 'ember-a11y-testing/test-support/audit';

// ...elided for brevity

test('Some test case', function(assert) {
  this.render(hbs`{{some-component}}`);

  let axeOptions = {
    rules: {
      'button-name': {
        enabled: false
      }
    }
  };
  return a11yAudit(this.$(), axeOptions).then(() => {
    assert.ok(true, 'no a11y errors found!');
  });
});
```

As you can see, the usage for all types of tests is pretty much the same. The
only real difference is Acceptance tests get automatic async handling.

_Note:_ any tests run with Ember A11y Testing will adjust the testing container
to occupy the entire screen. This is to simulate the actual application
environment, as browsers adjust styles at small sizes for accessibility reasons.
It will reset itself at the conclusion of testing though.

#### Optionally Running a11yAudit

Ember A11y Testing also provides an `a11yAuditIf` helper which will only run
audits if `enableA11yAudit=true` is set as a query param on the test page. This
is useful if you want to conditionally run accessibility audits, such as during
nightly build jobs.

```javascript
import a11yAuditIf from 'ember-a11y-testing/test-support/audit-if';

test('Some test case', function(assert) {
  visit('/');
  a11yAuditIf(); // Only runs when enableA11yAudit=true is in the URL
  andThen(() => assert.ok(true, 'no a11y errors found!'));
});
```

### Development Usage

Usage in development is restricted to applications using Ember 1.13 and up, as it
relies on the `didRender` hook of a component's life-cycle (a feature only
{'fraction_non_alphanumeric': 0.10637375343257696, 'fraction_numerical': 0.01849978320566556, 'mean_word_length': 4.335389360061681, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 9, 'https://': 14, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5637313', 'n_tokens_mistral': 2208, 'n_tokens_neox': 2038, 'n_words': 791}