chore(marketing): Stop capitalizing the "x" in "axe"

CHANGELOG.md

@@ -707,7 +707,7 @@ All notable changes to this project will be documented in this file. See [standa
 - Security improvements
 - Build includes Babel/ES6
 - Improvements to table rules
-- aXe can be loaded in Node
+- axe can be loaded in Node
 
 <a name="2.0.0"></a>
 

CONTRIBUTING.md

@@ -110,13 +110,13 @@ To build the package:
 grunt build
 ```
 
-## Using aXe with TypeScript
+## Using axe with TypeScript
 
-### aXe Development
+### Axe Development
 
 The TypeScript definition file for axe-core is distributed with this module and can be found in [axe.d.ts](./axe.d.ts). It currently supports TypeScript 2.0+.
 
-To maintain aXe support for TypeScript you must first install it (globally recommended):
+To maintain axe support for TypeScript you must first install it (globally recommended):
 
 ```console
 sudo npm -g install typescript
@@ -128,9 +128,9 @@ Once that's installed, you can run TypeScript definition tests (with the optiona
 tsc --noImplicitAny typings/axe-core/axe-core-tests.ts
 ```
 
-## Including aXe's type definition in tests
+## Including axe's type definition in tests
 
-Installing aXe to run accessibility tests in your TypeScript project should be as simple as importing the module:
+Installing axe to run accessibility tests in your TypeScript project should be as simple as importing the module:
 
 ```js
 import * as axe from 'axe-core';

Gruntfile.js

@@ -207,7 +207,7 @@ module.exports = function(grunt) {
 						quote_style: 1
 					},
 					output: {
-						comments: /^\/*! aXe/
+						comments: /^\/*! axe/
 					}
 				}
 			},
@@ -220,7 +220,7 @@ module.exports = function(grunt) {
 				}),
 				options: {
 					output: {
-						comments: /^\/*! aXe/
+						comments: /^\/*! axe/
 					},
 					mangle: {
 						reserved: ['commons', 'utils', 'axe', 'window', 'document']
@@ -264,7 +264,7 @@ module.exports = function(grunt) {
 					fixture: 'test/runner.tmpl',
 					testCwd: 'test/core',
 					data: {
-						title: 'aXe Core Tests'
+						title: 'axe Core Tests'
 					}
 				}
 			},
@@ -279,7 +279,7 @@ module.exports = function(grunt) {
 					fixture: 'test/runner.tmpl',
 					testCwd: 'test/checks',
 					data: {
-						title: 'aXe Check Tests'
+						title: 'axe Check Tests'
 					}
 				}
 			},
@@ -294,7 +294,7 @@ module.exports = function(grunt) {
 					fixture: 'test/runner.tmpl',
 					testCwd: 'test/commons',
 					data: {
-						title: 'aXe Commons Tests'
+						title: 'axe Commons Tests'
 					}
 				}
 			},
@@ -309,7 +309,7 @@ module.exports = function(grunt) {
 					fixture: 'test/runner.tmpl',
 					testCwd: 'test/rule-matches',
 					data: {
-						title: 'aXe Rule Matches Tests'
+						title: 'axe Rule Matches Tests'
 					}
 				}
 			},
@@ -321,7 +321,7 @@ module.exports = function(grunt) {
 					testCwd: 'test/integration/rules',
 					tests: ['../../../tmp/integration-tests.js', 'runner.js'],
 					data: {
-						title: 'aXe Integration Tests'
+						title: 'axe Integration Tests'
 					}
 				}
 			}

axe.d.ts

@@ -155,7 +155,7 @@ declare namespace axe {
 	let source: string;
 
 	/**
-	 * Object for aXe Results
+	 * Object for axe Results
 	 */
 	var AxeResults: AxeResults;
 
@@ -165,7 +165,7 @@ declare namespace axe {
 	 * @param   {ElementContext} context  Optional The `Context` specification object @see Context
 	 * @param   {RunOptions}     options  Optional Options passed into rules or checks, temporarily modifying them.
 	 * @param   {RunCallback}    callback Optional The function to invoke when analysis is complete.
-	 * @returns {Promise<AxeResults>|void} If the callback was not defined, aXe will return a Promise.
+	 * @returns {Promise<AxeResults>|void} If the callback was not defined, axe will return a Promise.
 	 */
 	function run(context?: ElementContext): Promise<AxeResults>;
 	function run(options: RunOptions): Promise<AxeResults>;
@@ -183,7 +183,7 @@ declare namespace axe {
 	): void;
 
 	/**
-	 * Method for configuring the data format used by aXe. Helpful for adding new
+	 * Method for configuring the data format used by axe. Helpful for adding new
 	 * rules, which must be registered with the library to execute.
 	 * @param  {Spec}       Spec Object with valid `branding`, `reporter`, `checks` and `rules` data
 	 */

doc/API.md

@@ -1,4 +1,4 @@
-# aXe Javascript Accessibility API
+# Axe Javascript Accessibility API
 
 ## Table of Contents
 
@@ -28,7 +28,7 @@
 
 ## Section 1: Introduction
 
-The aXe API is designed to be an improvement over the previous generation of accessibility APIs. It provides the following benefits:
+The axe API is designed to be an improvement over the previous generation of accessibility APIs. It provides the following benefits:
 
 - Runs in any modern browser
 - Designed to work with existing testing infrastructure
@@ -39,9 +39,9 @@ The aXe API is designed to be an improvement over the previous generation of acc
 
 ### Getting Started
 
-This section gives a quick description of how to use the aXe APIs to analyze web page content and return a JSON object that lists any accessibility violations found.
+This section gives a quick description of how to use the axe APIs to analyze web page content and return a JSON object that lists any accessibility violations found.
 
-The aXe API can be used as part of a broader process that is performed on many, if not all, pages of a website. The API is used to analyze web page content and return a JSON object that lists any accessibility violations found. Here is how to get started:
+The axe API can be used as part of a broader process that is performed on many, if not all, pages of a website. The API is used to analyze web page content and return a JSON object that lists any accessibility violations found. Here is how to get started:
 
 1. Load page in testing system
 2. Optionally, set configuration options for the javascript API (`axe.configure`)
@@ -53,17 +53,17 @@ The aXe API can be used as part of a broader process that is performed on many,
 
 ### Overview
 
-The aXe APIs are provided in the javascript file axe.js. It must be included in the web page under test. Parameters are sent as javascript function parameters. Results are returned in JSON format.
+The axe APIs are provided in the javascript file axe.js. It must be included in the web page under test. Parameters are sent as javascript function parameters. Results are returned in JSON format.
 
 ### Full API Reference for Developers
 
-For a full listing of API offered by aXe, clone the repository and run `npm run api-docs`. This generates `jsdoc` documentation under `doc/api` which can be viewed using the browser.
+For a full listing of API offered by axe, clone the repository and run `npm run api-docs`. This generates `jsdoc` documentation under `doc/api` which can be viewed using the browser.
 
 ### API Notes
 
 - A Rule test is made up of sub-tests. Each sub-test is returned in an array of 'checks'
 - The `"helpUrl"` in the results object is a link to a broader description of the accessibility issue and suggested remediation. These links point to Deque University help pages, which do not require a login.
-- aXe does not test hidden regions, such as inactive menus or modal windows. To test those for accessibility, write tests that activate or render the regions visible and run the analysis again.
+- Axe does not test hidden regions, such as inactive menus or modal windows. To test those for accessibility, write tests that activate or render the regions visible and run the analysis again.
 
 ### API Name: axe.getRules
 
@@ -134,7 +134,7 @@ In this example, we pass in the WCAG 2 A and AA tags into `axe.getRules` to retr
 
 #### Purpose
 
-To configure the format of the data used by aXe. This can be used to add new rules, which must be registered with the library to execute.
+To configure the format of the data used by axe. This can be used to add new rules, which must be registered with the library to execute.
 
 #### Description
 
@@ -465,7 +465,7 @@ This example first includes all `wcag2a` and `wcag2aa` rules. All rules that are
 
 6. Only process certain types of results
 
-The `resultTypes` option can be used to limit the result types that aXe will process, aggregate, and send to the reporter. This can be useful for improving performance on very large or complicated pages when you are only interested in certain types of results.
+The `resultTypes` option can be used to limit the result types that axe will process, aggregate, and send to the reporter. This can be useful for improving performance on very large or complicated pages when you are only interested in certain types of results.
 
 Types listed in this option are processed normally and report all of their results. Types _not_ listed process a maximum of one result. The caller can use this information to inform the user of the existence of that type of result if appropriate.
 
@@ -503,11 +503,11 @@ The `timeout` attribute in the object configuration is `optional` and has a fall
 
 ##### Callback Parameter
 
-The callback parameter is a function that will be called when the asynchronous `axe.run` function completes. The callback function is passed two parameters. The first parameter will be an error thrown inside of aXe if axe.run could not complete. If axe completed correctly the first parameter will be null, and the second parameter will be the results object.
+The callback parameter is a function that will be called when the asynchronous `axe.run` function completes. The callback function is passed two parameters. The first parameter will be an error thrown inside of axe if axe.run could not complete. If axe completed correctly the first parameter will be null, and the second parameter will be the results object.
 
 #### Return Promise
 
-If the callback was not defined, aXe will return a Promise instead. Axe does not polyfill a Promise library however. So on systems without support for Promises this feature is not available. If you are unsure if the systems you will need aXe on has Promise support we suggest you use the callback provided by axe.run instead.
+If the callback was not defined, axe will return a Promise instead. Axe does not polyfill a Promise library however. So on systems without support for Promises this feature is not available. If you are unsure if the systems you will need axe on has Promise support we suggest you use the callback provided by axe.run instead.
 
 #### Error Result
 
@@ -664,7 +664,7 @@ As you can see the `target` array contains one item that is an array. This array
 
 ### API Name: axe.registerPlugin
 
-Register a plugin with the aXe plugin system. See [implementing a plugin](plugins.md) for more information on the plugin system
+Register a plugin with the axe plugin system. See [implementing a plugin](plugins.md) for more information on the plugin system
 
 ### API Name: axe.cleanup
 

doc/code-submission-guidelines.md

@@ -13,7 +13,7 @@ will kindly ask you to resubmit it in the correct format.
 
 We follow Angular's code contribution style with precise rules for formatting git commit messages.
 This leads to more readable messages that are easy to follow when looking through the project
-history. We will also use commit messages to generate the aXe Changelog document.
+history. We will also use commit messages to generate the axe Changelog document.
 
 A detailed explanation of Angular's guidelines and conventions can be found [on Google Docs](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#).
 

doc/developer-guide.md

@@ -1,8 +1,8 @@
-# aXe Developer Guide
+# Axe Developer Guide
 
-aXe runs a series of tests to check for accessibility of content and functionality on a website. A test is made up of a series of Rules which are, themselves, made up of Checks. aXe executes these Rules asynchronously and, when the Rules are finished running, runs a callback function which is passed a Result structure. Since some Rules run on the page level while others do not, tests will also run in one of two ways. If a document is specified, the page level rules will run, otherwise they will not.
+Axe runs a series of tests to check for accessibility of content and functionality on a website. A test is made up of a series of Rules which are, themselves, made up of Checks. Axe executes these Rules asynchronously and, when the Rules are finished running, runs a callback function which is passed a Result structure. Since some Rules run on the page level while others do not, tests will also run in one of two ways. If a document is specified, the page level rules will run, otherwise they will not.
 
-aXe 3.0 supports open Shadow DOM: see our virtual DOM APIs and test utilities for developing axe-core moving forward. Note: we do not and cannot support closed Shadow DOM.
+Axe 3.0 supports open Shadow DOM: see our virtual DOM APIs and test utilities for developing axe-core moving forward. Note: we do not and cannot support closed Shadow DOM.
 
 1. [Getting Started](#getting-started)
 1. [Architecture Overview](#architecture-overview)
@@ -47,11 +47,11 @@ You can also load tests in any supported browser, which is helpful for debugging
 
 ### API Reference
 
-[See API exposed on aXe](./API.md#section-2-api-reference)
+[See API exposed on axe](./API.md#section-2-api-reference)
 
 ## Architecture Overview
 
-aXe tests for accessibility using objects called Rules. Each Rule tests for a high-level aspect of accessibility, such as color contrast, button labels, and alternate text for images. Each rule is made up of a series of Checks. Depending on the rule; all, some, or none of these checks must pass in order for the rule to pass.
+Axe tests for accessibility using objects called Rules. Each Rule tests for a high-level aspect of accessibility, such as color contrast, button labels, and alternate text for images. Each rule is made up of a series of Checks. Depending on the rule; all, some, or none of these checks must pass in order for the rule to pass.
 
 Upon execution, a Rule runs each of its Checks against all relevant nodes. Which nodes are relevant is determined by the Rule's `selector` property and `matches` function. If a Rule has no Checks that apply to a given node, the Rule will result in an inapplicable result.
 
@@ -62,7 +62,7 @@ After execution, a Check will return `true` or `false` depending on whether or n
 Rules are defined by JSON files in the [lib/rules directory](../lib/rules). The JSON object is used to seed the [Rule object](../lib/core/base/rule.js#L30). A valid Rule JSON consists of the following:
 
 - `id` - `String` A unique name of the Rule.
-- `selector` - **optional** `String` which is a CSS selector that specifies the elements of the page on which the Rule runs. aXe-core will look inside of the light DOM and _open_ [Shadow DOM](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Shadow_DOM) trees for elements matching the provided selector. If omitted, the rule will run against every node.
+- `selector` - **optional** `String` which is a CSS selector that specifies the elements of the page on which the Rule runs. axe-core will look inside of the light DOM and _open_ [Shadow DOM](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Shadow_DOM) trees for elements matching the provided selector. If omitted, the rule will run against every node.
 - `excludeHidden` - **optional** `Boolean` Whether the rule should exclude hidden elements. Defaults to `true`.
 - `enabled` - **optional** `Boolean` Whether the rule is enabled by default. Defaults to `true`.
 - `pageLevel` - **optional** `Boolean` Whether the rule is page level. Page level rules will only run if given an entire `document` as context.
@@ -162,7 +162,7 @@ on writing rules and checks, including incomplete results.
 
 #### CheckResult
 
-When a Check is executed, its result is then added to a [CheckResult object](../lib/core/base/check-result.js). Much like the RuleResult object, the CheckResult object only contains information that is required to determine whether a Check, and its parent Rule passed or failed. `metadata` from the originating Check is combined later and will not be available until aXe reaches the reporting stage.
+When a Check is executed, its result is then added to a [CheckResult object](../lib/core/base/check-result.js). Much like the RuleResult object, the CheckResult object only contains information that is required to determine whether a Check, and its parent Rule passed or failed. `metadata` from the originating Check is combined later and will not be available until axe reaches the reporting stage.
 
 A CheckResult has the following properties:
 
@@ -178,7 +178,7 @@ Common functions are an internal library used by the rules and checks. If you ha
 #### Commons and Shadow DOM
 
 To support open Shadow DOM while maintaining backwards compatibility, commons functions that
-query DOM nodes must operate on an in-memory representation of the DOM using aXe-core’s
+query DOM nodes must operate on an in-memory representation of the DOM using axe-core’s
 built-in [API methods and utility functions](./API.md#virtual-dom-utilities).
 
 Commons functions should do the virtual tree lookup and call a `virtual` function
@@ -211,7 +211,7 @@ which passes on a virtual DOM node with both the light DOM and Shadow DOM (if ap
 
 ### Virtual Nodes
 
-To support open Shadow DOM, aXe-core has the ability to handle virtual nodes in [rule matches](#matches-function)
+To support open Shadow DOM, axe-core has the ability to handle virtual nodes in [rule matches](#matches-function)
 and [check evaluate](#check-evaluate) functions. The full set of API methods for Shadow DOM can be
 found in the [API documentation](./API.md#virtual-dom-utilities), but the general
 structure for a virtualNode is as follows:
@@ -230,7 +230,7 @@ structure for a virtualNode is as follows:
 
 ### Core Utilities
 
-Core Utilities are an internal library that provides aXe with functionality used throughout its core processes. Most notably among these are the queue function and the DqElement constructor.
+Core Utilities are an internal library that provides axe with functionality used throughout its core processes. Most notably among these are the queue function and the DqElement constructor.
 
 #### ARIA Lookup Tables
 

doc/examples/jasmine/README.md

@@ -1,6 +1,6 @@
 # Jasmine README
 
-This example demonstrates how to use aXe with the Jasmine unit testing framework.
+This example demonstrates how to use axe with the Jasmine unit testing framework.
 
 The unit test is in `spec/a11y.js`, and has two test cases: One that shows the
 expected results from HTML with no errors, and one that shows the expected
@@ -32,6 +32,6 @@ to `axe.run`.
 
 The third argument to the `axe.run` call should be the function to test
 the results. The example is simply looking at the count of violations, but much
-more detailed information is available if desired. The aXe documentation
+more detailed information is available if desired. The axe documentation
 should be consulted for more details on customizing and analyzing calls to
 `axe.run`.

doc/examples/jasmine/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "axe-jasmine-example",
-	"description": "aXe Jasmine Example",
+	"description": "Axe Jasmine Example",
 	"version": "0.0.1",
 	"private": true,
 	"author": {

doc/examples/jest_react/README.md

@@ -1,6 +1,6 @@
 # Jest + React README
 
-This example demonstrates how to use aXe to test React components using the
+This example demonstrates how to use axe to test React components using the
 Jest unit testing framework.
 
 The unit test is in `link.test.js`, and has one test cases, showing how to run

doc/examples/jest_react/link.test.js

@@ -4,9 +4,9 @@ import { mountToDoc } from './test-helpers';
 
 import Link from './link';
 
-test('Link has no aXe violations', done => {
+test('Link has no axe violations', done => {
 	const linkComponent = mountToDoc(
-		<Link page="http://www.axe-core.org">aXe website</Link>
+		<Link page="http://www.axe-core.org">axe website</Link>
 	);
 	const linkNode = linkComponent.getDOMNode();
 

doc/examples/jest_react/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "axe-jest-react-example",
-	"description": "aXe Jest + React Example",
+	"description": "Axe Jest + React Example",
 	"version": "0.0.1",
 	"private": true,
 	"author": {