govuk_publishing_components 21.16.3 → 21.17.0

data/node_modules/axe-core/doc/accessibility-supported.md

@@ -4,7 +4,7 @@ In order to adhere to the manifesto and at the same time be useful to developers
 
 ## Accessibility supported
 
-Boiled-down, accessibility supported means that in order for a technique to be valid, it must work on all viable platforms for all assitive technology that are widely used and freely available (paraphrased).
+Boiled-down, accessibility supported means that in order for a technique to be valid, it must work on all viable platforms for all assistive technology that are widely used and freely available (paraphrased).
 
 We currently test the following AT combinations for support
 

data/node_modules/axe-core/doc/aria-supported.md

@@ -6,18 +6,9 @@ This page contains a list of ARIA 1.1 features that axe-core raises as unsupport
 
 For a detailed description about how accessibility support is decided, see [How we make decisions on rules](accessibility-supported.md).
 
-## Roles
-
-| aria-role | axe-core support |
-| --------- | ---------------- |
-| figure    | No               |
-
 ## Attributes
 
-| aria-attribute       | axe-core support |
-| -------------------- | ---------------- |
-| aria-describedat     | No               |
-| aria-details         | No               |
-| aria-roledescription | Mixed[^1]        |
-
-[^1]: Supported on elements: `<button>`, `<input type="button" | "checkbox" | "image" | "radio" | "reset" | "submit">`, `<img>`, `<select>`, `<summary>`
+| aria-attribute   | axe-core support |
+| ---------------- | ---------------- |
+| aria-describedat | No               |
+| aria-details     | No               |

data/node_modules/axe-core/doc/backwards-compatibility-doc.md

@@ -0,0 +1,93 @@
+# Backwards Compatibility in axe-core
+
+## What is part of the public axe-core API?
+
+The axe-core API includes:
+
+- Any APIs documented here: [https://github.com/dequelabs/axe-core/blob/develop/doc/API.md](https://github.com/dequelabs/axe-core/blob/develop/doc/API.md)
+- The selectors generated and included in the node information in the results arrays for any given HTML page
+- The JSON structures passed into and out of any API functions
+- Any functions in the `axe.utils` and `axe.commons` collections that are used by one of our standard rules (this document refers to these as the “Public Utils”). This includes use in any of the “matches”, “eval” and “after” functions.
+- The implicit function signature of the matches, eval and after functions (the names of the parameters that are passed-to the functions and the values returned by them)
+
+## What is not included in the public axe-core API?
+
+Any other function or attribute on the axe object is not considered part of the public API and is therefore not covered by the guarantee in this document.
+
+## What do we guarantee for the public axe-core API?
+
+We guarantee that the API signatures and the return values of functions will not break in patch or minor release versions except that we may add items to JSON structures in minor releases or override parameters. We will not remove items from JSON structures.
+
+In a minor release, we may change the implementation of Public Utils to fix bugs or improve performance. This means that a call to a Public Util may return a different value across patch versions.
+
+We will not add or remove rules in a patch release. We will not add support for new technologies in a patch release. We will endeavour to return the exact same results across patch releases with the exception of changes that are due to bug fixes. This means that the likelihood of a patch release finding issues on a page that was clean in a previous release is very close to zero but not zero.
+
+In a minor release, we may add support for new technologies in the Public Utils or in existing rules and we may add or disable rules. We may also change an experimental rule to become a standard rule (essentially equivalent to adding rule). This means that pages that did not return violations in a particular minor release may return violations in a subsequent release.
+
+If the HTML page is unchanged, calls to the analysis function(s) when compared across minor or patch releases will return the same exact selector for the nodes in any of the result arrays. If the HTML page has changed, it is possible for the selector to be different but it is not guaranteed that the selector will be different.
+
+APIs may be deprecated in a major or minor release. APIs that have been deprecated for 6 months or more will be removed in the next major release.
+
+A major or a minor release may introduce new Public Utils.
+
+Major releases may remove rules.
+
+### Table: Summary of What Deque Guarantees with Public axe-core API
+
+|                                               | Major                                                   | Minor                 | Patch                      |
+| :-------------------------------------------- | :------------------------------------------------------ | :-------------------- | :------------------------- |
+| **New Technologies**                          |                                                         |                       |                            |
+| Support for new technologies\*                | May add support                                         | May add support       | Will not add support       |
+| **APIS**                                      |                                                         |                       |                            |
+| API signatures and return values of functions | May break                                               | Will not break        | Will not break             |
+| APIs deprecated                               | May be deprecated                                       | May be deprecated     | Will not be deprecated     |
+| APIs removed                                  | May be removed (will remove previously deprecated APIs) | Will not be removed   | Will not be removed        |
+| **Public Utils**                              |                                                         |                       |                            |
+| Implementation of Public Utils                | May change                                              | May change            | Will not change            |
+| New public Utils                              | May add                                                 | May add               | Will not add               |
+| **Rules**                                     |                                                         |                       |                            |
+| Add rules                                     | May add                                                 | May add               | Will not add               |
+| Disable or remove rules                       | May remove (will remove previously deprecated rules)    | May disable or remove | Will not disable or remove |
+| Deprecate rules                               | May deprecate                                           | May deprecate         | Will not deprecate         |
+
+\*_New OSes, Browsers, ATs, new standards (e.g. introduction of ARIA), new versions of standards (e.g. WCAG 2.1)_
+
+## Implications
+
+### Breaking Builds
+
+Patch release upgrades can be applied in CI environments with a high degree of certainty that breakages will not be due to changes in the release. The chance is, however, not zero.
+
+### Custom Rules
+
+A custom rule configuration (with-or-without custom rules) is guaranteed to run on any newer version that shares the same major version number as the version for which it was created. A custom rule configuration (with-or-without custom rules) is not guaranteed to work with an older version of axe-core than the version for which it was created.
+
+You can write custom rules that utilize the Public Utils and the parameters that are passed to a check function, secure in the knowledge that the API will not change unless a major version is released.
+
+However, because we can introduce new rules, it is possible that a custom rule configuration will return additional results when run against a new minor release and may return different results when run against a newer patch release.
+
+A custom rule configuration may return different results (more or fewer) when run on a newer patch release due to bug fixes.
+
+A major release may completely break a custom rule or even all custom rules because of a change to any of the APIs.
+
+### Table: Implication of axe-core Updates on Custom Rule Function
+
+| Axe-core Release Semantic Version              | Example | Simple Custom Rules    | Complex Custom Rules   |
+| :--------------------------------------------- | :------ | :--------------------- | :--------------------- |
+| Prior release (different major release number) | 1.3.4   | Not guaranteed to work | Not guaranteed to work |
+| Release used to create custom rules            | 2.0.0   | Guaranteed to work     | Guaranteed to work     |
+| Next release (minor release)                   | 2.1.0   | Guaranteed to work\*   | Guaranteed to work\*   |
+| Next +1 release (patch release)                | 2.1.1   | Guaranteed to work\*   | Guaranteed to work\*   |
+| Next +2 release (major release)                | 3.0.0   | Not guaranteed to work | Not guaranteed to work |
+
+\*_Minor and patch releases will not break custom rules, but testing results may vary from those tests performed with previous minor and patch releases of axe-core. There may be inconsistencies between what Attest reports and what Comply reports._
+
+Please note that with even small changes in versions for simple custom rules, there may be inconsistencies between what Attest reports and what Comply reports. For best results, in both cases, versions should match exactly.
+
+### Tracking Issues Over Time
+
+Many systems attempt to identify unique issues using a combination of the page and state, the rule-id and the selector to track an issue across time and across calls to the analysis functions. This will work reliably across patch releases. This could break if a rule is removed or split up across minor releases. In a major release, this could break for the additional reason of a possible change in the selector generation (this did happen in the changes between 2.6.x and 3.x).
+
+### Comply
+
+Comply has the ability to add labels and comments to issues and to mark issues as ignored. Comply will lose this information when it is not able to track issues across time. This means that historical issue information may be lost when upgrading to a newer major version of axe-core.

data/node_modules/axe-core/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#).
 
@@ -35,9 +35,9 @@ that includes a type, a scope and a subject. Here's a sample of the format:
 ```sh
 perf(rule): improve speed of color contrast rules
 
-  Use async process to compare elements without UI lockup
+Use async process to compare elements without UI lockup
 
-    Closes #1
+Closes #1
 ```
 
 > Commit messages should be 100 characters or less to make them easy to read on Github and
@@ -139,7 +139,7 @@ changes in the pull request, so the git log stays lean. We particularly want to
 You can use git's interactive rebase to manipulate, merge, and rename commits in your local
 history. If these steps are followed, a force push shouldn't be necessary.
 
-**Do not force push to develop or master under any circulstances.**
+**Do not force push to develop or master under any circumstances.**
 
 To interactively rebase all of your commits on top of the latest in develop, run:
 

data/node_modules/axe-core/doc/developer-guide.md

@@ -1,10 +1,15 @@
-# 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. [Environment Pre-requisites](#environment-pre-requisites)
+   1. [Building axe.js](#building-axejs)
+   1. [Running Tests](#running-tests)
+   1. [API Reference](#api-reference)
+   1. [Supported CSS Selectors](#supported-css-selectors)
 1. [Architecture Overview](#architecture-overview)
    1. [Rules](#rules)
    1. [Checks](#checks)
@@ -31,7 +36,7 @@ aXe 3.0 supports open Shadow DOM: see our virtual DOM APIs and test utilities fo
 
 ### Building axe.js
 
-To build axe.js, simply run `grunt build` in the root folder of the axe-core repository. axe.js and axe.min.js are placed into the `dist` folder.
+To build axe.js, simply run `grunt build` in the root folder of the axe-core repository. axe.js and axe.min.js are placed into the root folder.
 
 ### Running Tests
 
@@ -47,11 +52,20 @@ 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)
+
+### Supported CSS Selectors
+
+Axe supports the following CSS selectors:
+
+- Type, Class, ID, and Universal selectors. E.g `div.main, #main`
+- Pseudo selector `not`. E.g `th:not([scope])`
+- Descendant and Child combinators. E.g. `table td`, `ul > li`
+- Attribute selectors `=`, `^=`, `$=`, `*=`. E.g `a[href^="#"]`
 
 ## 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 +76,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](#supported-css-selectors) 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 +176,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 +192,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 +225,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 +244,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
 
@@ -285,7 +299,7 @@ will make it easier to work with the virtual DOM.
 
 #### Description
 
-Recursvely return an array containing the virtual DOM tree for the node specified, excluding comment nodes
+Recursively return an array containing the virtual DOM tree for the node specified, excluding comment nodes
 and shadow DOM nodes `<content>` and `<slot>`. This method will return a flattened tree containing both
 light and shadow DOM, if applicable.
 
@@ -378,7 +392,7 @@ None
 
 #### Returns
 
-An object containg the data, relatedNodes, and a way to reset them.
+An object containing the data, relatedNodes, and a way to reset them.
 
 ```js
 {

data/node_modules/axe-core/doc/examples/chrome-debugging-protocol/package.json

@@ -1,8 +1,11 @@
 {
 	"name": "axe-cdp",
 	"private": true,
+	"scripts": {
+		"test": "echo 'No test specified.'"
+	},
 	"dependencies": {
-		"axe-core": "^3.1.1",
-		"chrome-remote-interface": "^0.26.0"
+		"axe-core": "^3.3.1",
+		"chrome-remote-interface": "^0.27.1"
 	}
 }

data/node_modules/axe-core/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
@@ -10,15 +10,13 @@ result from HTML with a single error.
 
 - Node must be installed; please follow the directions at http://www.nodejs.org
   to install it.
-- `npm install -g grunt-cli` to install the Grunt task runner (may need to be
-  run with `sudo` on Unix or as Administrator on Windows)
 - Move to the `doc/examples/jasmine` directory
 - `npm install` to install dependencies
 
 ## To run the example
 
 - Move to the `doc/examples/jasmine` directory
-- `grunt jasmine` to run Jasmine
+- `npm test` to run Jasmine
 
 You should see output indicating that the tests ran successfully, with zero
 failures.
@@ -32,6 +30,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`.

data/node_modules/axe-core/doc/examples/jasmine/karma.conf.js

@@ -0,0 +1,29 @@
+module.exports = function(config) {
+	config.set({
+		basePath: '',
+
+		frameworks: ['jasmine'],
+
+		files: ['spec/**/*.js', 'node_modules/axe-core/axe.js'],
+
+		exclude: [],
+
+		preprocessors: {},
+
+		reporters: ['progress'],
+
+		port: 9876,
+
+		colors: true,
+
+		logLevel: config.LOG_INFO,
+
+		autoWatch: true,
+
+		browsers: ['ChromeHeadless'],
+
+		singleRun: true,
+
+		concurrency: Infinity
+	});
+};

data/node_modules/axe-core/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": {
@@ -10,11 +10,12 @@
 	},
 	"dependencies": {},
 	"scripts": {
-		"test": "grunt jasmine"
+		"test": "karma start karma.conf.js"
 	},
 	"devDependencies": {
-		"axe-core": "^3.1.1",
-		"grunt": "~1.0.2",
-		"grunt-contrib-jasmine": "~2.0.0"
+		"axe-core": "^3.3.1",
+		"karma": "^4.2.0",
+		"karma-chrome-launcher": "^3.0.0",
+		"karma-jasmine": "^2.0.1"
 	}
 }

data/node_modules/axe-core/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

data/node_modules/axe-core/doc/examples/jest_react/link.test.js

@@ -2,11 +2,11 @@ import React from 'react';
 import axe from 'axe-core';
 import { mountToDoc } from './test-helpers';
 
-import Link from './Link';
+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();
 

data/node_modules/axe-core/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": {
@@ -13,14 +13,14 @@
 		"test": "jest"
 	},
 	"devDependencies": {
-		"axe-core": "^3.1.1",
-		"babel-jest": "^23.0.0",
-		"babel-preset-es2015": "^6.24.1",
-		"babel-preset-react": "^6.24.1",
-		"enzyme": "^3.5.0",
-		"enzyme-adapter-react-16": "^1.3.0",
-		"jest": "^22.4.0",
-		"jest-cli": "^23.0.1",
+		"@babel/preset-env": "^7.5.5",
+		"@babel/preset-react": "^7.0.0",
+		"axe-core": "^3.3.1",
+		"babel-jest": "^24.8.0",
+		"enzyme": "^3.10.0",
+		"enzyme-adapter-react-16": "^1.14.0",
+		"jest": "^24.8.0",
+		"jest-cli": "^24.8.0",
 		"react": "^16.4.0",
 		"react-dom": "^16.4.0",
 		"react-test-renderer": "^16.2.0"

data/node_modules/axe-core/doc/examples/jsdom/package.json

@@ -0,0 +1,15 @@
+{
+	"name": "axe-jsdom-example",
+	"description": "Axe JSDOM Example",
+	"version": "0.0.1",
+	"private": true,
+	"dependencies": {},
+	"scripts": {
+		"test": "mocha"
+	},
+	"devDependencies": {
+		"axe-core": "^3.3.1",
+		"jsdom": "^15.1.1",
+		"mocha": "^6.2.0"
+	}
+}

data/node_modules/axe-core/doc/examples/mocha/README.md

@@ -1,6 +1,6 @@
 # Mocha README
 
-This example demonstrates how to use aXe with the Mocha unit testing framework.
+This example demonstrates how to use axe with the Mocha unit testing framework.
 
 The unit test is in `test/a11y.js`, and has two test cases: One that shows the
 expected results from HTML with no errors, and one that shows the expected
@@ -10,15 +10,13 @@ result from HTML with a single error.
 
 - Node must be installed; please follow the directions at http://www.nodejs.org
   to install it.
-- `npm install -g grunt-cli` to install the Grunt task runner (may need to be
-  run with `sudo` on Unix or as Administrator on Windows)
 - Move to the `doc/examples/mocha` directory
 - `npm install` to install dependencies
 
 ## To run the example
 
 - Move to the `doc/examples/mocha` directory
-- `grunt mocha` to run Mocha
+- `npm test` to run Mocha
 
 You should see output indicating that the tests ran successfully, with zero
 failures.
@@ -32,6 +30,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
-should be consulted for more details on customizing and
-analyzing calls to `axe.run`.
+more detailed information is available if desired. The axe documentation
+should be consulted for more details on customizing and analyzing calls to
+`axe.run`.