You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+13Lines changed: 13 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,19 @@
2
2
3
3
All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.
-**aria-allowed-role:** Add math to allowed roles for img element ([#4658](https://github.com/dequelabs/axe-core/issues/4658)) ([f6dddd9](https://github.com/dequelabs/axe-core/commit/f6dddd905bb86d2073d760d4c1ff39996e59a4f4)), closes [#4657](https://github.com/dequelabs/axe-core/issues/4657)
10
+
-**captions:** fix grammar in captions check incomplete message ([#4661](https://github.com/dequelabs/axe-core/issues/4661)) ([3ef7058](https://github.com/dequelabs/axe-core/commit/3ef7058d3a16a6898eaed718e39b34b45f9ed74f))
11
+
- consistently parse tabindex, following HTML 5 spec ([#4637](https://github.com/dequelabs/axe-core/issues/4637)) ([3b0a361](https://github.com/dequelabs/axe-core/commit/3b0a3619d5e6147d8885725cce196868dac89f7f)), closes [#4632](https://github.com/dequelabs/axe-core/issues/4632)
12
+
-**core:** measure perf for async checks ([#4609](https://github.com/dequelabs/axe-core/issues/4609)) ([e7dc26e](https://github.com/dequelabs/axe-core/commit/e7dc26e6cbaf9089611853805e05216b6529e1f9))
13
+
-**locale:** fixed typos in german (DE) locale ([#4631](https://github.com/dequelabs/axe-core/issues/4631)) ([0740980](https://github.com/dequelabs/axe-core/commit/07409802115c199a68f58dcaf7467e35b4867140))
14
+
-**locale:** proofread and updated de.json ([#4643](https://github.com/dequelabs/axe-core/issues/4643)) ([910cdb2](https://github.com/dequelabs/axe-core/commit/910cdb20702ce116c781d58f021adc05095ffcbb))
15
+
-**no-autoplay-audio:** don't timeout for preload=none media elements ([#4684](https://github.com/dequelabs/axe-core/issues/4684)) ([b7f1ad1](https://github.com/dequelabs/axe-core/commit/b7f1ad1ccf719b7149a5ef1805b405707a474e31))
16
+
-**target-size:** do not treat focusable tabpanels as targets ([#4702](https://github.com/dequelabs/axe-core/issues/4702)) ([67d4e4f](https://github.com/dequelabs/axe-core/commit/67d4e4f7d0d0b803b66f216ff86f401649ed024f)), closes [#4421](https://github.com/dequelabs/axe-core/issues/4421)[#4701](https://github.com/dequelabs/axe-core/issues/4701)
Copy file name to clipboardExpand all lines: README.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ Axe is an accessibility testing engine for websites and other HTML-based user in
14
14
15
15
## The Accessibility Rules
16
16
17
-
Axe-core has different types of rules, for WCAG 2.0, 2.1, 2.2 on level A, AA and AAA as well as a number of best practices that help you identify common accessibility practices like ensuring every page has an `h1` heading, and to help you avoid "gotchas" in ARIA like where an ARIA attribute you used will get ignored. The complete list of rules, grouped WCAG level and best practice, can found in [doc/rule-descriptions.md](./doc/rule-descriptions.md).
17
+
Axe-core has different types of rules, for WCAG 2.0, 2.1, 2.2 on level A, AA and AAA as well as a number of best practices that help you identify common accessibility practices like ensuring every page has an `h1` heading, and to help you avoid "gotchas" in ARIA like where an ARIA attribute you used will get ignored. The complete list of rules, grouped WCAG level and best practice, can be found in [doc/rule-descriptions.md](./doc/rule-descriptions.md).
18
18
19
19
With axe-core, you can find **on average 57% of WCAG issues automatically**. Additionally, axe-core will return elements as "incomplete" where axe-core could not be certain, and manual review is needed.
20
20
@@ -65,7 +65,7 @@ Axe was built to reflect how web development actually works. It works with all m
65
65
- It's actively supported by [Deque Systems](https://www.deque.com), a major accessibility vendor.
66
66
- It integrates with your existing functional/acceptance automated tests.
67
67
- It automatically determines which rules to run based on the evaluation context.
68
-
- Axe supports in-memory fixtures, static fixtures, integration tests and iframes of infinite depth.
68
+
- Axe supports in-memory fixtures, static fixtures, integration tests, and iframes of infinite depth.
@@ -49,16 +49,16 @@ This section gives a quick description of how to use the axe APIs to analyze web
49
49
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:
50
50
51
51
1. Load page in testing system
52
-
2. Optionally, set configuration options for the javascript API (`axe.configure`)
53
-
3. Call analyze javascript API (`axe.run`)
52
+
2. Optionally, set configuration options for the JavaScript API (`axe.configure`)
53
+
3. Call analyze JavaScript API (`axe.run`)
54
54
4. Either assert against results or save them for later processing
55
55
5. Repeat for any inactive or non-rendered content after making it visible
56
56
57
57
## Section 2: API Reference
58
58
59
59
### Overview
60
60
61
-
The axe APIs are provided in the javascript file axe.js. It must be included in the web page under test, as well as each `iframe` under test. Parameters are sent as javascript function parameters. Results are returned in JSON format.
61
+
The axe APIs are provided in the JavaScript file axe.js. It must be included in the web page under test, as well as each `iframe` under test. Parameters are sent as JavaScript function parameters. Results are returned in JSON format.
62
62
63
63
### Full API Reference for Developers
64
64
@@ -72,7 +72,7 @@ For a full listing of API offered by axe, clone the repository and run `npm run
72
72
73
73
### Axe-core Tags
74
74
75
-
Each rule in axe-core has a number of tags. These provide metadata about the rule. Each rule has one tag that indicates which WCAG version / level it belongs to, or if it doesn't it have the `best-practice` tag. If the rule is required by WCAG, there is a tag that references the success criterion number. For example, the `wcag111` tag means a rule is required for WCAG 2 success criterion 1.1.1.
75
+
Each rule in axe-core has a number of tags. These provide metadata about the rule. Each rule has one tag that indicates which WCAG version / level it belongs to, or if it doesn't, it has the `best-practice` tag. If the rule is required by WCAG, there is a tag that references the success criterion number. For example, the `wcag111` tag means a rule is required for WCAG 2 success criterion 1.1.1.
76
76
77
77
The `experimental`, `ACT`, `TT`, and `section508` tags are only added to some rules. Each rule with a `section508` tag also has a tag to indicate what requirement in old Section 508 the rule is required by. For example `section508.22.a`.
78
78
@@ -182,7 +182,7 @@ In this example, we pass in the WCAG 2 A and AA tags into `axe.getRules` to retr
182
182
183
183
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.
184
184
185
-
**important**: `axe.configure()` does not communicate configuration calls into iframes. Instead `axe.configure()` must be called with the same argument in each `frame` / `iframe` individually.
185
+
**Important**: `axe.configure()` does not communicate configuration calls into iframes. Instead `axe.configure()` must be called with the same argument in each `frame` / `iframe` individually.
186
186
187
187
#### Description
188
188
@@ -213,7 +213,7 @@ axe.configure({
213
213
-`reporter` - Used to set the output format that the axe.run function will pass to the callback function. Can pass a reporter name or a custom reporter function. Valid names are:
214
214
-`v1` to use the previous version's format: `axe.configure({ reporter: "v1" });`
215
215
-`v2` to use the current version's format: `axe.configure({ reporter: "v2" });`
216
-
-`raw` to return the raw result data without formating: `axe.configure({ reporter: "raw" });`
216
+
-`raw` to return the raw result data without formatting: `axe.configure({ reporter: "raw" });`
217
217
-`raw-env` to return the raw result data with environment data: `axe.configure({ reporter: "raw-env" });`
218
218
-`no-passes` to return only violation results: `axe.configure({ reporter: "no-passes" });`
219
219
-`checks` - Used to add checks to the list of checks used by rules, or to override the properties of existing checks
@@ -567,7 +567,7 @@ The `resultTypes` option can be used to limit the number of nodes for a rule to
567
567
568
568
After axe has processed all rules normally, it generates a unique selector for all nodes in all rules. This process can be time consuming, especially for pages with lots of nodes. By limiting the nodes to a maximum of one for result types you are not interested in, you can greatly speed up the tail end performance of axe.
569
569
570
-
Types listed in this option will cause rules that fall under those types to show all nodes. Types _not_ listed will causes rules that fall under one of the missing types to show a maximum of one node. This allows you to still see those results and inform the user of them if appropriate.
570
+
Types listed in this option will cause rules that fall under those types to show all nodes. Types _not_ listed will cause rules that fall under one of the missing types to show a maximum of one node. This allows you to still see those results and inform the user of them if appropriate.
571
571
572
572
```js
573
573
axe.run(
@@ -670,7 +670,7 @@ The results of axe are grouped according to their outcome into the following arr
670
670
-`passes`: These results indicate what elements passed the rules
671
671
-`violations`: These results indicate what elements failed the rules
672
672
-`inapplicable`: These results indicate which rules did not run because no matching content was found on the page. For example, with no video, those rules won't run.
673
-
-`incomplete`: Also known as "needs review," these results were aborted and require further testing. This can happen either because of technical restrictions to what the rule can test, or because a javascript error occurred.
673
+
-`incomplete`: Also known as "needs review," these results were aborted and require further testing. This can happen either because of technical restrictions to what the rule can test, or because a JavaScript error occurred.
674
674
675
675
Each object returned in these arrays have the following properties:
676
676
@@ -834,7 +834,7 @@ axe.teardown();
834
834
835
835
### API Name: axe.frameMessenger
836
836
837
-
Set up a alternative communication channel between parent and child frames. By default, axe-core uses `window.postMessage()`. See [frame-messenger.md](frame-messenger.md) for details.
837
+
Set up an alternative communication channel between parent and child frames. By default, axe-core uses `window.postMessage()`. See [frame-messenger.md](frame-messenger.md) for details.
838
838
839
839
### API name: axe.runPartial / axe.finishRun
840
840
@@ -931,7 +931,7 @@ The top-level document or shadow DOM document fragment
931
931
932
932
This package contains examples for [jasmine](examples/jasmine), [mocha](examples/mocha), [qunit](examples/qunit), and [generating HTML from the violations array](examples/html-handlebars.md). Each of these examples is in the [doc/examples](examples) folder. In each folder, there is a README.md file which contains specific information about each example.
933
933
934
-
See [axe-webdriverjs](https://github.com/dequelabs/axe-webdriverjs#axe-webdriverjs) for selenium webdriver javascript examples.
934
+
See [axe-webdriverjs](https://github.com/dequelabs/axe-webdriverjs#axe-webdriverjs) for selenium webdriver JavaScript examples.
Copy file name to clipboardExpand all lines: doc/accessibility-supported.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ In order to adhere to the manifesto and at the same time be useful to developers
6
6
7
7
Accessibility supported means that in order for a technique to pass, it must work in some predefined set of browsers and assistive technologies. For axe-core this means that for a screen reader, browser, or environment to be added to the list of supported combinations, the following two criteria must be met:
8
8
9
-
1. Be used by more than 1% of users (currently extrapolated from the [WebAims Screen Reader User Survey](https://webaim.org/projects/screenreadersurvey8/#browsercombos))
9
+
1. Be used by more than 1% of users (currently extrapolated from the [WebAim Screen Reader User Survey](https://webaim.org/projects/screenreadersurvey10/#browsercombos))
10
10
1. Introduce new coverage for a screen reader, browser, or environment not currently accessibility supported
11
11
12
12
We currently test the following AT combinations for support
@@ -32,6 +32,6 @@ In addition, we disallow invalid attributes starting with `aria-` and invalid at
32
32
33
33
## Best practices
34
34
35
-
We recognize that there are best practices that significantly improve the usability of application, even though they are not strictly required in order to conform with WCAG 2. We develop the best practice rules to help content developers to identify these and adhere to them.
35
+
We recognize that there are best practices that significantly improve the usability of an application, even though they are not strictly required in order to conform with WCAG 2. We develop the best practice rules to help content developers to identify these and adhere to them.
36
36
37
37
We recognize that this topic is somewhat controversial and the rules we have represent Deque's opinion on what constitutes a best practice.
Copy file name to clipboardExpand all lines: doc/act-rules-format.md
+5-5Lines changed: 5 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# W3C Standardized Rules
2
2
3
-
Deque Systems is one of leading organizations in the development of standardized accessibility conformance testing rules. The [axe-core rules proposal format](./rule-proposal.md) is an adaptation of the [Accessibility Conformance Testing Rules Format](https://www.w3.org/TR/act-rules-format/).
3
+
Deque Systems is one of the leading organizations in the development of standardized accessibility conformance testing rules. The [axe-core rules proposal format](./rule-proposal.md) is an adaptation of the [Accessibility Conformance Testing Rules Format](https://www.w3.org/TR/act-rules-format/).
4
4
5
5
There are two ways a rule written in the axe-core rule format can be transformed into the ACT Rules format:
6
6
@@ -9,17 +9,17 @@ There are two ways a rule written in the axe-core rule format can be transformed
9
9
This method is useful for rules with a small number of checks.
10
10
11
11
1. Add the test input type to it: `rendered page`
12
-
2. Add an `assumptions` section, add possible assumptions to it
12
+
2. Add an `assumptions` section, including possible assumptions to it
13
13
3. Add an `outcomes` section, describing the different possible outcomes of the rule
14
-
4. Add a `Validation Tests` section, that links to the integration tests
14
+
4. Add a `Validation Tests` section that links to the integration tests
15
15
5. Update the check to return pass/fail/cantTell instead of true/false/undefined
16
16
6. Add control flow to the checks:
17
17
18
18
-`any` checks should only return `fail` in the last step. All steps leading up to it either return `pass` or say `continue to the next step`.
19
19
-`all` and `none` checks should only return `pass` in the last step. All steps leading up to it either return `fail` or say `continue to the next step`.
20
20
21
21
7. Rename `checks` to `steps` and add a `step X` (where X is the step number) to the heading with the check name.
22
-
8. Replace the `tags` section with a`Accessibility Requirements`. The requirements can be determined based on the `wcag###` tags.
22
+
8. Replace the `tags` section with an`Accessibility Requirements`. The requirements can be determined based on the `wcag###` tags.
23
23
24
24
## Method 2: Create a rule group
25
25
@@ -34,4 +34,4 @@ This method is useful for larger rules with `any` checks. This effectively turns
34
34
7. Update the check to return pass/fail/cantTell instead of true/false/undefined
35
35
8. Add a `Validation Tests` section, that links to only those integration tests relevant for this check (now a new rule).
36
36
9. Indicate that the new rule is part of a group, using the original axe-core rule ID as the group name.
37
-
10. Replace the `tags` section with a`Accessibility Requirements`. The requirements can be determined based on the `wcag###` tags.
37
+
10. Replace the `tags` section with an`Accessibility Requirements`. The requirements can be determined based on the `wcag###` tags.
0 commit comments