/eslint-plugin-jsx-a11y

Static AST checker for a11y rules on JSX elements.

Primary LanguageJavaScriptMIT LicenseMIT

build status npm version license Coverage Status Total npm downloads

Get professional support for eslint-plugin-jsx-a11y on Tidelift

eslint-plugin-jsx-a11y

Static AST checker for accessibility rules on JSX elements.

Read this in other languages.

Mexican Spanish🇲🇽

Why?

Ryan Florence built out this awesome runtime-analysis tool called 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.

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.

Installation

If you are installing this plugin via eslint-config-airbnb, please follow these instructions.

You'll first need to install ESLint:

# npm
npm install eslint --save-dev

# yarn
yarn add eslint --dev

Next, install eslint-plugin-jsx-a11y:

# npm
npm install eslint-plugin-jsx-a11y --save-dev

# yarn
yarn add eslint-plugin-jsx-a11y --dev

Note: If you installed ESLint globally (using the -g flag in npm, or the global prefix in yarn) then you must also install eslint-plugin-jsx-a11y globally.

Usage

Add jsx-a11y to the plugins section of your .eslintrc configuration file. You can omit the eslint-plugin- prefix:

{
  "plugins": [
    "jsx-a11y"
  ]
}

Then configure the rules you want to use under the rules section.

{
  "rules": {
    "jsx-a11y/rule-name": 2
  }
}

You can also enable all the recommended or strict rules at once. Add plugin:jsx-a11y/recommended or plugin:jsx-a11y/strict in extends:

{
  "extends": [
    "plugin:jsx-a11y/recommended"
  ]
}

Supported Rules

Rule strictness in different modes

Rule Recommended Strict
alt-text error error
anchor-has-content error error
anchor-is-valid error error
aria-activedescendant-has-tabindex error error
aria-props error error
aria-proptypes error error
aria-role error error
aria-unsupported-elements error error
autocomplete-valid error error
click-events-have-key-events error error
heading-has-content error error
html-has-lang error error
iframe-has-title error error
img-redundant-alt error error
interactive-supports-focus error error
label-has-associated-control error error
media-has-caption error error
mouse-events-have-key-events error error
no-access-key error error
no-autofocus error error
no-distracting-elements error error
no-interactive-element-to-noninteractive-role error, with options error
no-noninteractive-element-interactions error, with options error
no-noninteractive-element-to-interactive-role error, with options error
no-noninteractive-tabindex error, with options error
no-onchange error error
no-redundant-roles error error
no-static-element-interactions error, with options error
role-has-required-aria-props error error
role-supports-aria-props error error
scope error, with options error
tabindex-no-positive error error

The following rules have extra options when in recommended mode:

no-interactive-element-to-noninteractive-role

'jsx-a11y/no-interactive-element-to-noninteractive-role': [
  'error',
  {
    tr: ['none', 'presentation'],
  },
]

no-noninteractive-element-interactions

'jsx-a11y/no-noninteractive-element-interactions': [
  'error',
  {
    handlers: [
      'onClick',
      'onMouseDown',
      'onMouseUp',
      'onKeyPress',
      'onKeyDown',
      'onKeyUp',
    ],
  },
]

no-noninteractive-element-to-interactive-role

'jsx-a11y/no-noninteractive-element-to-interactive-role': [
  'error',
  {
    ul: [
      'listbox',
      'menu',
      'menubar',
      'radiogroup',
      'tablist',
      'tree',
      'treegrid',
    ],
    ol: [
      'listbox',
      'menu',
      'menubar',
      'radiogroup',
      'tablist',
      'tree',
      'treegrid',
    ],
    li: ['menuitem', 'option', 'row', 'tab', 'treeitem'],
    table: ['grid'],
    td: ['gridcell'],
  },
]

no-noninteractive-tabindex

'jsx-a11y/no-noninteractive-tabindex': [
  'error',
  {
    tags: [],
    roles: ['tabpanel'],
  },
]

no-static-element-interactions

'jsx-a11y/no-noninteractive-element-interactions': [
  'error',
  {
    handlers: [
      'onClick',
      'onMouseDown',
      'onMouseUp',
      'onKeyPress',
      'onKeyDown',
      'onKeyUp',
    ],
  },
]

Creating a new rule

If you are developing new rules for this project, you can use the create-rule script to scaffold the new files.

$ ./scripts/create-rule.js my-new-rule

Some background on WAI-ARIA, the AX Tree and Browsers

Accessibility API

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.

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.

As GUIs became more complex, the raster parsing approach became untenable. Accessibility APIs were developed to replace them. Check out NSAccessibility (AXAPI) for an example. See Core Accessibility API Mappings 1.1 for more details.

Browsers

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.

The Accessibility (AX) Tree & DOM

From the W3 Core Accessibility API Mappings 1.1

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.

Browser vendors are beginning to expose the AX Tree through inspection tools. Chrome has an experiment available to enable their inspection tool.

You can also see a text-based version of the AX Tree in Chrome in the stable release version.

Viewing the AX Tree in Chrome

  1. Navigate to chrome://accessibility/ in Chrome.
  2. Toggle the accessibility off link for any tab that you want to inspect.
  3. A link labeled show accessibility tree will appear; click this link.
  4. Balk at the wall of text that gets displayed, but then regain your conviction.
  5. Use the browser's find command to locate strings and values in the wall of text.

Pulling it all together

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.

We model ARIA in the aria-query project. We model AXObjects (that comprise the AX Tree) in the 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 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.

License

eslint-plugin-jsx-a11y is licensed under the MIT License.