@arcaauth/eslint-plugin-jsx-a11y 6.10.2

package/docs/rules/label-has-associated-control.md

@@ -0,0 +1,152 @@
+# jsx-a11y/label-has-associated-control
+
+💼 This rule is enabled in the following configs: ☑️ `recommended`, 🔒 `strict`.
+
+<!-- end auto-generated rule header -->
+
+Enforce that a label tag has a text label and an associated control.
+
+There are two supported ways to associate a label with a control:
+
+- Wrapping a control in a label tag.
+- Adding `htmlFor` to a label and assigning it a DOM ID string that indicates an input on the page.
+
+This rule checks that any `label` tag (or an indicated custom component that will output a `label` tag) either (1) wraps an `input` element (or an indicated custom component that will output an `input` tag) or (2) has an `htmlFor` attribute and that the `label` tag has text content.
+
+## How do I resolve this error?
+
+### Case: I just want a text label associated with an input.
+
+The simplest way to achieve an association between a label and an input is to wrap the input in the label.
+
+```jsx
+<label>
+  Surname
+  <input type="text" />
+</label>
+```
+
+All modern browsers and assistive technology will associate the label with the control.
+
+### Case: The label is a sibling of the control.
+
+In this case, use `htmlFor` and an ID to associate the controls.
+
+```jsx
+<label htmlFor={domId}>Surname</label>
+<input type="text" id={domId} />
+```
+
+### Case: My label and input components are custom components.
+
+You can configure the rule to be aware of your custom components.
+
+```jsx
+<CustomInputLabel label="Surname">
+  <CustomInput type="text" value={value} />
+</CustomInputLabel>
+```
+
+And the configuration:
+
+```json
+{
+  "rules": {
+    "jsx-a11y/label-has-associated-control": [ 2, {
+      "labelComponents": ["CustomInputLabel"],
+      "labelAttributes": ["label"],
+      "controlComponents": ["CustomInput"],
+      "depth": 3,
+    }],
+  }
+}
+```
+
+### Case: I have two labels for the same input
+
+If the second `label` is in a different part of the HTML, then the second one can only contain `htmlFor` but not nesting. You will probably need eslint override comment on the second label.
+
+```jsx
+{/* eslint jsx-a11y/label-has-associated-control: ["error", { assert: "either" } ] */}
+<label htmlFor="a">
+  Username:
+</label>
+...
+<label htmlFor="a">
+  <input id="a" />
+</label>
+```
+
+## How to manage IDs of `input`
+
+A common way to think of `id` with libraries like React is, `id`s should be avoided since it must be unique on the page, and components need to be reusable. Hence it is tempted to generate `id` during render-time if `id` is required. *However:*
+
+IDs shouldn't be generated in the browser, so that server and client rendering are deterministic. Render-time uuids aren't just a hack, they're actually broken and should never be used.
+
+To restate, **every ID needs to be deterministic**, on the server and the client, and guaranteed to be unique on the page. EG: For each input, a required ID prop can be passed down from as far up the tree as possible to guarantee uniqueness.
+
+## Rule options
+
+This rule takes one optional object argument of type object:
+
+```json
+{
+  "rules": {
+    "jsx-a11y/label-has-associated-control": [ 2, {
+      "labelComponents": ["CustomLabel"],
+      "labelAttributes": ["inputLabel"],
+      "controlComponents": ["CustomInput"],
+      "assert": "both",
+      "depth": 3,
+    }],
+  }
+}
+```
+
+`labelComponents` is a list of custom React Component names that should be checked for an associated control.
+
+`labelAttributes` is a list of attributes to check on the label component and its children for a label. Use this if you have a custom component that uses a string passed on a prop to render an HTML `label`, for example.
+
+`controlComponents` is a list of custom React Components names that will output an input element. [Glob format](https://linuxhint.com/bash_globbing_tutorial/) is also supported for specifying names (e.g., `Label*` matches `LabelComponent` but not `CustomLabel`, `????Label` matches `LinkLabel` but not `CustomLabel`).
+
+`assert` asserts that the label has htmlFor, a nested label, both or either. Available options: `'htmlFor', 'nesting', 'both', 'either'`.
+
+`depth` (default 2, max 25) is an integer that determines how deep within a `JSXElement` label the rule should look for text content or an element with a label to determine if the `label` element will have an accessible label.
+
+### Fail
+```jsx
+function Foo(props) {
+  return <label {...props} />
+}
+```
+
+### Succeed
+```jsx
+function Foo(props) {
+    const {
+        htmlFor,
+        ...otherProps
+    } = props;
+
+   return <label htmlFor={htmlFor} {...otherProps} />
+}
+```
+
+### Fail
+```jsx
+<input type="text" />
+<label>Surname</label>
+```
+
+### Succeed
+```jsx
+<label>
+  <input type="text" />
+  Surname
+</label>
+```
+
+## Accessibility guidelines
+- [WCAG 1.3.1](https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships)
+- [WCAG 3.3.2](https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions)
+- [WCAG 4.1.2](https://www.w3.org/WAI/WCAG21/Understanding/name-role-value)

package/docs/rules/label-has-for.md

@@ -0,0 +1,130 @@
+# jsx-a11y/label-has-for
+
+❌ This rule is deprecated. It was replaced by [`jsx-a11y/label-has-associated-control`](label-has-associated-control.md).
+
+🚫 This rule is _disabled_ in the following configs: ☑️ `recommended`, 🔒 `strict`.
+
+<!-- end auto-generated rule header -->
+
+_This rule was deprecated in v6.1.0. It will no longer be maintained._
+
+Enforce label tags have associated control.
+
+There are two supported ways to associate a label with a control:
+
+- nesting: by wrapping a control in a label tag
+- id: by using the prop `htmlFor` (or any configured attribute) as in `htmlFor=[ID of control]`
+
+To fully cover 100% of assistive devices, you're encouraged to validate for both nesting and id.
+
+## Rule options
+
+This rule takes one optional object argument of type object:
+
+```json
+{
+    "rules": {
+        "jsx-a11y/label-has-for": [ 2, {
+            "components": [ "Label" ],
+            "required": {
+                "every": [ "nesting", "id" ]
+            },
+            "allowChildren": false
+        }]
+    }
+}
+```
+
+For the `components` option, these strings determine which JSX elements (**always including** `<label>`) should be checked for having `htmlFor` prop. This is a good use case when you have a wrapper component that simply renders a `label` element (like in React):
+
+```js
+// Label.js
+const Label = props => {
+  const {
+    htmlFor,
+    ...otherProps
+  } = props;
+
+  return (
+    <label htmlFor={htmlFor} {...otherProps} />
+  );
+}
+
+...
+
+// CreateAccount.js (for example)
+...
+return (
+  <form>
+    <input id="firstName" type="text" />
+    <Label htmlFor="firstName">First Name</Label>
+  </form>
+);
+```
+
+The `required` option (defaults to `"required": { "every": ["nesting", "id"] }`) determines which checks are activated. You're allowed to pass in one of the following types:
+
+- string: must be one of the acceptable strings (`"nesting"` or `"id"`)
+- object, must have one of the following properties:
+
+  - some: an array of acceptable strings, will pass if ANY of the requested checks passed
+  - every: an array of acceptable strings, will pass if ALL of the requested checks passed
+
+The `allowChildren` option (defaults to `false`) determines whether `{children}` content is allowed to be passed into a `label` element. For example, the following pattern, by default, is not allowed:
+
+```js
+<label>{children}</label>
+```
+
+However, if `allowChildren` is set to `true`, no error will be raised. If you want to pass in `{children}` content without raising an error, because you cannot be sure what `{children}` will render, then set `allowChildren` to `true`.
+
+Note that passing props as spread attribute without `htmlFor` explicitly defined will cause this rule to fail. Explicitly pass down `htmlFor` prop for rule to pass. The prop must have an actual value to pass. Use `Label` component above as a reference. **It is a good thing to explicitly pass props that you expect to be passed for self-documentation.** For example:
+
+#### Bad
+
+```jsx
+function Foo(props) {
+  return <label {...props} />
+}
+```
+
+#### Good
+
+```jsx
+function Foo({ htmlFor, ...props}) {
+    return <label htmlFor={htmlFor} {...props} />
+}
+
+// OR
+
+function Foo(props) {
+    const {
+        htmlFor,
+        ...otherProps
+    } = props;
+
+   return <label htmlFor={htmlFor} {...otherProps} />
+}
+```
+
+### Succeed
+
+```jsx
+<label htmlFor="firstName">
+  <input type="text" id="firstName" />
+  First Name
+</label>
+```
+
+### Fail
+
+```jsx
+<input type="text" id="firstName" />
+<label>First Name</label>
+```
+
+## Accessibility guidelines
+
+- [WCAG 1.3.1](https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships)
+- [WCAG 3.3.2](https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions)
+- [WCAG 4.1.2](https://www.w3.org/WAI/WCAG21/Understanding/name-role-value)

package/docs/rules/lang.md

@@ -0,0 +1,31 @@
+# jsx-a11y/lang
+
+<!-- end auto-generated rule header -->
+
+The `lang` prop on the `<html>` element must be a valid IETF's BCP 47 language tag.
+
+## Rule details
+
+This rule takes no arguments.
+
+### Succeed
+
+```jsx
+<html lang="en">
+<html lang="en-US">
+```
+
+### Fail
+
+```jsx
+<html>
+<html lang="foo">
+```
+
+## Accessibility guidelines
+- [WCAG 3.1.1](https://www.w3.org/WAI/WCAG21/Understanding/language-of-page)
+
+### Resources
+- [axe-core, valid-lang](https://dequeuniversity.com/rules/axe/3.2/valid-lang)
+- [Language tags in HTML and XML](https://www.w3.org/International/articles/language-tags/)
+- [IANA Language Subtag Registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)

package/docs/rules/media-has-caption.md

@@ -0,0 +1,48 @@
+# jsx-a11y/media-has-caption
+
+💼 This rule is enabled in the following configs: ☑️ `recommended`, 🔒 `strict`.
+
+<!-- end auto-generated rule header -->
+
+Providing captions for media is essential for deaf users to follow along. Captions should be a transcription or translation of the dialogue, sound effects, relevant musical cues, and other relevant audio information. Not only is this important for accessibility, but can also be useful for all users in the case that the media is unavailable (similar to `alt` text on an image when an image is unable to load).
+
+The captions should contain all important and relevant information to understand the corresponding media. This may mean that the captions are not a 1:1 mapping of the dialogue in the media content. However, captions are *not* necessary for video components with the `muted` attribute.
+
+## Rule options
+
+This rule takes one optional object argument of type object:
+
+```json
+{
+    "rules": {
+        "jsx-a11y/media-has-caption": [ 2, {
+            "audio": [ "Audio" ],
+            "video": [ "Video" ],
+            "track": [ "Track" ],
+          }],
+    }
+}
+```
+
+For the `audio`, `video`, and `track` options, these strings determine which JSX elements (**always including** their corresponding DOM element) should be used for this rule. This is a good use case when you have a wrapper component that simply renders an `audio`, `video`, or `track` element (like in React):
+
+### Succeed
+```jsx
+<audio><track kind="captions" {...props} /></audio>
+<video><track kind="captions" {...props} /></video>
+<video muted {...props} ></video>
+```
+
+### Fail
+```jsx
+<audio {...props} />
+<video {...props} />
+```
+
+## Accessibility guidelines
+- [WCAG 1.2.2](https://www.w3.org/WAI/WCAG21/Understanding/captions-prerecorded.html)
+- [WCAG 1.2.3](https://www.w3.org/WAI/WCAG21/Understanding/audio-description-or-media-alternative-prerecorded.html)
+
+### Resources
+- [axe-core, audio-caption](https://dequeuniversity.com/rules/axe/2.1/audio-caption)
+- [axe-core, video-caption](https://dequeuniversity.com/rules/axe/2.1/video-caption)

package/docs/rules/mouse-events-have-key-events.md

@@ -0,0 +1,58 @@
+# jsx-a11y/mouse-events-have-key-events
+
+💼 This rule is enabled in the following configs: ☑️ `recommended`, 🔒 `strict`.
+
+<!-- end auto-generated rule header -->
+
+Enforce onmouseover/onmouseout are accompanied by onfocus/onblur. Coding for the keyboard is important for users with physical disabilities who cannot use a mouse, AT compatibility, and screen reader users.
+
+## Rule options
+
+By default, this rule checks that `onmouseover` is paired with `onfocus` and that `onmouseout` is paired with `onblur`. This rule takes an optional argument to specify other handlers to check for "hover in" and/or "hover out" events:
+
+```json
+{
+  "rules": {
+    "jsx-a11y/mouse-events-have-key-events": [
+      "error",
+      {
+        "hoverInHandlers": [
+          "onMouseOver",
+          "onMouseEnter",
+          "onPointerOver",
+          "onPointerEnter"
+        ],
+        "hoverOutHandlers": [
+          "onMouseOut",
+          "onMouseLeave",
+          "onPointerOut",
+          "onPointerLeave"
+        ]
+      }
+    ]
+  }
+}
+```
+
+Note that while `onmouseover` and `onmouseout` are checked by default if no arguments are passed in, those are *not* included by default if you *do* provide an argument, so remember to explicitly include them if you want to check them.
+
+### Succeed
+```jsx
+<div onMouseOver={ () => void 0 } onFocus={ () => void 0 } />
+<div onMouseOut={ () => void 0 } onBlur={ () => void 0 } />
+<div onMouseOver={ () => void 0 } onFocus={ () => void 0 } {...otherProps} />
+<div onMouseOut={ () => void 0 } onBlur={ () => void 0 } {...otherProps} />
+```
+
+### Fail
+In example 3 and 4 below, even if otherProps contains onBlur and/or onFocus, this rule will still fail. Props should be passed down explicitly for rule to pass.
+
+```jsx
+<div onMouseOver={ () => void 0 } />
+<div onMouseOut={ () => void 0 } />
+<div onMouseOver={ () => void 0 } {...otherProps} />
+<div onMouseOut={ () => void 0 } {...otherProps} />
+```
+
+## Accessibility guidelines
+- [WCAG 2.1.1](https://www.w3.org/WAI/WCAG21/Understanding/keyboard)

package/docs/rules/no-access-key.md

@@ -0,0 +1,30 @@
+# jsx-a11y/no-access-key
+
+💼 This rule is enabled in the following configs: ☑️ `recommended`, 🔒 `strict`.
+
+<!-- end auto-generated rule header -->
+
+Enforce no accessKey prop on element. Access keys are HTML attributes that allow web developers to assign keyboard shortcuts to elements. Inconsistencies between keyboard shortcuts and keyboard commands used by screen readers and keyboard-only users create accessibility complications so to avoid complications, access keys should not be used.
+
+### References
+1. [WebAIM](https://webaim.org/techniques/keyboard/accesskey#spec)
+
+## Rule details
+
+This rule takes no arguments.
+
+### Succeed
+```jsx
+<div />
+```
+
+### Fail
+```jsx
+<div accessKey="h" />
+```
+
+## Accessibility guidelines
+General best practice (reference resources)
+
+### Resources
+- [WebAIM, Keyboard Accessibility: Accesskey](https://webaim.org/techniques/keyboard/accesskey#spec)

package/docs/rules/no-aria-hidden-on-focusable.md

@@ -0,0 +1,37 @@
+# jsx-a11y/no-aria-hidden-on-focusable
+
+<!-- end auto-generated rule header -->
+
+Enforce that `aria-hidden="true"` is not set on focusable elements.
+
+`aria-hidden="true"` can be used to hide purely decorative content from screen reader users. An element with `aria-hidden="true"` that can also be reached by keyboard can lead to confusion or unexpected behavior for screen reader users. Avoid using `aria-hidden="true"` on focusable elements.
+
+## Rule details
+
+### Succeed
+```jsx
+  <div aria-hidden="true" />
+  <img aria-hidden="true" />
+  <a aria-hidden="false" href="#" />
+  <button aria-hidden="true" tabIndex="-1" /> // `tabIndex=-1` removes the element from sequential focus navigation so we don't flag it.
+  <a href="/" />
+  <div aria-hidden="true"><a href="#"></a></div> // This is also bad but will not be handled by this rule.
+```
+
+### Fail
+```jsx
+  <div aria-hidden="true" tabIndex="0" />
+  <input aria-hidden="true" />
+  <a href="/" aria-hidden="true" />
+  <button aria-hidden="true" />
+  <textarea aria-hidden="true" />
+```
+
+## Accessibility guidelines
+General best practice (reference resources)
+
+### Resources
+
+- [aria-hidden elements do not contain focusable elements](https://dequeuniversity.com/rules/axe/html/4.4/aria-hidden-focus)
+- [Element with aria-hidden has no content in sequential focus navigation](https://www.w3.org/WAI/standards-guidelines/act/rules/6cfa84/proposed/)
+- [MDN aria-hidden](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-hidden)

package/docs/rules/no-autofocus.md

@@ -0,0 +1,43 @@
+# jsx-a11y/no-autofocus
+
+💼 This rule is enabled in the following configs: ☑️ `recommended`, 🔒 `strict`.
+
+<!-- end auto-generated rule header -->
+
+Enforce that autoFocus prop is not used on elements. Autofocusing elements can cause usability issues for sighted and non-sighted users, alike.
+
+## Rule options
+
+This rule takes one optional object argument of type object:
+
+```json
+{
+    "rules": {
+        "jsx-a11y/no-autofocus": [ 2, {
+            "ignoreNonDOM": true
+        }],
+    }
+}
+```
+
+For the `ignoreNonDOM` option, this determines if developer created components are checked.
+
+### Succeed
+```jsx
+<div />
+```
+
+### Fail
+```jsx
+<div autoFocus />
+<div autoFocus="true" />
+<div autoFocus="false" />
+<div autoFocus={undefined} />
+```
+
+## Accessibility guidelines
+General best practice (reference resources)
+
+### Resources
+- [WHATWG HTML Standard, The autofocus attribute](https://html.spec.whatwg.org/multipage/interaction.html#attr-fe-autofocus)
+- [The accessibility of HTML 5 autofocus](https://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/)

package/docs/rules/no-distracting-elements.md

@@ -0,0 +1,41 @@
+# jsx-a11y/no-distracting-elements
+
+💼 This rule is enabled in the following configs: ☑️ `recommended`, 🔒 `strict`.
+
+<!-- end auto-generated rule header -->
+
+Enforces that no distracting elements are used. Elements that can be visually distracting can cause accessibility issues with visually impaired users. Such elements are most likely deprecated, and should be avoided. By default, the following elements are visually distracting: `<marquee>` and `<blink>`.
+
+## Rule options
+
+This rule takes one optional object argument of type object:
+
+```json
+{
+    "rules": {
+        "jsx-a11y/no-distracting-elements": [ 2, {
+            "elements": [ "marquee", "blink" ],
+          }],
+    }
+}
+```
+
+For the `elements` option, these strings determine which JSX elements should be checked for usage. This shouldn't need to be configured unless you have a seriously compelling use case for these elements. You cannot add any additional elements than what is offered, as the schema is only valid with the provided enumerated list. If you have another element that you think may cause a11y issues due to visual impairment, please feel free to file an issue or send a PR!
+
+### Succeed
+```jsx
+<div />
+```
+
+### Fail
+```jsx
+<marquee />
+<blink />
+```
+
+## Accessibility guidelines
+- [WCAG 2.2.2](https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide)
+
+### Resources
+- [axe-core, marquee](https://dequeuniversity.com/rules/axe/3.2/marquee)
+- [axe-core, blink](https://dequeuniversity.com/rules/axe/3.2/blink)

package/docs/rules/no-interactive-element-to-noninteractive-role.md

@@ -0,0 +1,73 @@
+# jsx-a11y/no-interactive-element-to-noninteractive-role
+
+💼 This rule is enabled in the following configs: ☑️ `recommended`, 🔒 `strict`.
+
+<!-- end auto-generated rule header -->
+
+Interactive HTML elements indicate _controls_ in the user interface. Interactive elements include `<a href>`, `<button>`, `<input>`, `<select>`, `<textarea>`.
+
+Non-interactive HTML elements and non-interactive ARIA roles indicate _content_ and _containers_ in the user interface. Non-interactive elements include `<main>`, `<area>`, `<h1>` (,`<h2>`, etc), `<img>`, `<li>`, `<ul>` and `<ol>`.
+
+[WAI-ARIA roles](https://www.w3.org/TR/wai-aria-1.1/#usage_intro) should not be used to convert an interactive element to a non-interactive element. Non-interactive ARIA roles include `article`, `banner`, `complementary`, `img`, `listitem`, `main`, `region` and `tooltip`.
+
+## How do I resolve this error?
+
+### Case: The element should be a container, like an article
+
+Wrap your interactive element in a `<div>` with the desired role.
+
+```jsx
+<div role="article">
+  <button>Save</button>
+</div>
+```
+
+### Case: The element should be content, like an image
+
+Put the content inside your interactive element.
+
+```jsx
+<div
+  role="button"
+  onClick={() => {}}
+  onKeyPress={() => {}}
+  tabIndex="0">
+  <div role="img" aria-label="Save" />
+</div>
+```
+
+## Rule options
+
+The recommended options for this rule allow the `tr` element to be given a role of `presentation` (or its semantic equivalent `none`). Under normal circumstances, an element with an interactive role should not be semantically neutralized with `presentation` (or `none`).
+
+Options are provided as an object keyed by HTML element name; the value is an array of interactive roles that are allowed on the specified element.
+
+```js
+{
+  'no-interactive-element-to-noninteractive-role': [
+    'error',
+    {
+      tr: ['none', 'presentation'],
+    },
+  ]
+}
+```
+
+Under the recommended options, the following code is valid. It would be invalid under the strict rules.
+
+```jsx
+<tr role="presentation" />
+```
+
+## Accessibility guidelines
+
+- [WCAG 4.1.2](https://www.w3.org/WAI/WCAG21/Understanding/name-role-value)
+
+### Resources
+
+- [ARIA Spec, States and Properties](https://www.w3.org/TR/wai-aria/#states_and_properties)
+- [Chrome Audit Rules, AX_ARIA_04](https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#ax_aria_04)
+- [WAI-ARIA roles](https://www.w3.org/TR/wai-aria-1.1/#usage_intro)
+- [WAI-ARIA Authoring Practices Guide - Design Patterns and Widgets](https://www.w3.org/TR/wai-aria-practices-1.1/#aria_ex)
+- [Fundamental Keyboard Navigation Conventions](https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_generalnav)
+- [Mozilla Developer Network - ARIA Techniques](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role#Keyboard_and_focus)