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
- Remove mention of react-a11y from the file
- Add recommendation to use jsx-a11y together with @axe-core/react
- Add recommendation to complement automated tools with manual testing
Fixes#829.
Ryan Florence built out this awesome runtime-analysis tool called [react-a11y](https://github.com/reactjs/react-a11y). It is super useful. However, since you're probably already using linting in your project, this plugin comes for free and closer to the actual development process. Pairing this plugin with an editor lint plugin, you can bake accessibility standards into your application in real-time.
37
34
38
-
**Note**: This project does not *replace* react-a11y, but can and should be used in conjunction with it. Static analysis tools cannot determine values of variables that are being placed in props before runtime, so linting will not fail if that value is undefined and/or does not pass the lint rule.
35
+
This plugin does a static evaluation of the JSX to spot accessibility issues in React apps. Because it only catches errors in static code, use it in combination with [@axe-core/react](https://github.com/dequelabs/axe-core-npm/tree/develop/packages/react) to test the accessibility of the rendered DOM. Consider these tools just as one step of a larger a11y testing process and always test your apps with assistive technology.
39
36
40
37
## Installation
41
38
@@ -69,13 +66,10 @@ Add `jsx-a11y` to the plugins section of your `.eslintrc` configuration file. Yo
69
66
70
67
```json
71
68
{
72
-
"plugins": [
73
-
"jsx-a11y"
74
-
]
69
+
"plugins": ["jsx-a11y"]
75
70
}
76
71
```
77
72
78
-
79
73
Then configure the rules you want to use under the rules section.
80
74
81
75
```json
@@ -91,9 +85,7 @@ Add `plugin:jsx-a11y/recommended` or `plugin:jsx-a11y/strict` in `extends`:
91
85
92
86
```json
93
87
{
94
-
"extends": [
95
-
"plugin:jsx-a11y/recommended"
96
-
]
88
+
"extends": ["plugin:jsx-a11y/recommended"]
97
89
}
98
90
```
99
91
@@ -135,45 +127,45 @@ Add `plugin:jsx-a11y/recommended` or `plugin:jsx-a11y/strict` in `extends`:
## Some background on WAI-ARIA, the AX Tree and Browsers
271
267
272
268
### Accessibility API
269
+
273
270
An operating system will provide an accessibility API that maps application state and content onto input/output controllers such as a screen reader, braille device, keyboard, etc.
274
271
275
272
These APIs were developed as computer interfaces shifted from buffers (which are text-based and inherently quite accessible) to graphical user interfaces (GUIs). The first attempts to make GUIs accessible involved raster image parsing to recognize characters, words, etc. This information was stored in a parallel buffer and made accessible to assistive technology (AT) devices.
276
273
277
274
As GUIs became more complex, the raster parsing approach became untenable. Accessibility APIs were developed to replace them. Check out [NSAccessibility (AXAPI)](https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/index.html) for an example. See [Core Accessibility API Mappings 1.1](https://www.w3.org/TR/core-aam-1.1/) for more details.
278
275
279
276
### Browsers
277
+
280
278
Browsers support an Accessibility API on a per operating system basis. For instance, Firefox implements the MSAA accessibility API on Windows, but does not implement the AXAPI on OSX.
281
279
282
280
### The Accessibility (AX) Tree & DOM
281
+
283
282
From the [W3 Core Accessibility API Mappings 1.1](https://www.w3.org/TR/core-aam-1.1/#intro_treetypes)
284
283
285
284
> The accessibility tree and the DOM tree are parallel structures. Roughly speaking the accessibility tree is a subset of the DOM tree. It includes the user interface objects of the user agent and the objects of the document. Accessible objects are created in the accessibility tree for every DOM element that should be exposed to assistive technology, either because it may fire an accessibility event or because it has a property, relationship or feature which needs to be exposed. Generally, if something can be trimmed out it will be, for reasons of performance and simplicity. For example, a `<span>` with just a style change and no semantics may not get its own accessible object, but the style change will be exposed by other means.
@@ -289,13 +288,15 @@ Browser vendors are beginning to expose the AX Tree through inspection tools. Ch
289
288
You can also see a text-based version of the AX Tree in Chrome in the stable release version.
290
289
291
290
#### Viewing the AX Tree in Chrome
292
-
1. Navigate to `chrome://accessibility/` in Chrome.
293
-
1. Toggle the `accessibility off` link for any tab that you want to inspect.
294
-
1. A link labeled `show accessibility tree` will appear; click this link.
295
-
1. Balk at the wall of text that gets displayed, but then regain your conviction.
296
-
1. Use the browser's find command to locate strings and values in the wall of text.
291
+
292
+
1. Navigate to `chrome://accessibility/` in Chrome.
293
+
1. Toggle the `accessibility off` link for any tab that you want to inspect.
294
+
1. A link labeled `show accessibility tree` will appear; click this link.
295
+
1. Balk at the wall of text that gets displayed, but then regain your conviction.
296
+
1. Use the browser's find command to locate strings and values in the wall of text.
297
297
298
298
### Pulling it all together
299
+
299
300
A browser constructs an AX Tree as a subset of the DOM. ARIA heavily informs the properties of this AX Tree. This AX Tree is exposed to the system level Accessibility API which mediates assistive technology agents.
300
301
301
302
We model ARIA in the [aria-query](https://github.com/a11yance/aria-query) project. We model AXObjects (that comprise the AX Tree) in the [axobject-query](https://github.com/A11yance/axobject-query) project. The goal of the WAI-ARIA specification is to be a complete declarative interface to the AXObject model. The [in-draft 1.2 version](https://github.com/w3c/aria/issues?q=is%3Aissue+is%3Aopen+label%3A%22ARIA+1.2%22) is moving towards this goal. But until then, we must consider the semantics constructs afforded by ARIA as well as those afforded by the AXObject model (AXAPI) in order to determine how HTML can be used to express user interface affordances to assistive technology users.
0 commit comments