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: README.md
+29-27
Original file line number
Diff line number
Diff line change
@@ -47,15 +47,16 @@ _Note: This is experimental and subject to change._
47
47
48
48
The `react` config includes rules which target specific HTML elements. You may provide a mapping of custom components to an HTML element in your `eslintrc` configuration to increase linter coverage.
49
49
50
-
For each component, you may specify a `default` and/or `props`. `default` may make sense if there's a 1:1 mapping between a component and an HTML element. However, if the HTML output of a component is dependent on a prop value, you can provide a mapping using the `props` key. To minimize conflicts and complexity, this currently only supports the mapping of a single prop type.
50
+
By default, these eslint rules will check the "as" prop for underlying element changes. If your repo uses a different prop name for polymorphic components provide the prop name in your `eslintrc` configuration under `polymorphicPropName`.
|[a11y-aria-label-is-well-formatted](docs/rules/a11y-aria-label-is-well-formatted.md)|[aria-label] text should be formatted as you would visual text. | ⚛️ |||
88
-
|[a11y-no-generic-link-text](docs/rules/a11y-no-generic-link-text.md)| disallow generic link text ||| ❌ |
|[a11y-aria-label-is-well-formatted](docs/rules/a11y-aria-label-is-well-formatted.md)|[aria-label] text should be formatted as you would visual text. | ⚛️ |||
87
+
|[a11y-no-generic-link-text](docs/rules/a11y-no-generic-link-text.md)| disallow generic link text ||| ❌ |
88
+
|[a11y-no-title-attribute](docs/rules/a11y-no-title-attribute.md)| Guards against developers using the title attribute | ⚛️ |||
89
+
|[a11y-no-visually-hidden-interactive-element](docs/rules/a11y-no-visually-hidden-interactive-element.md)| Ensures that interactive elements are not visually hidden | ⚛️ |||
89
90
|[a11y-role-supports-aria-props](docs/rules/a11y-role-supports-aria-props.md)| Enforce that elements with explicit or implicit roles defined contain only `aria-*` properties supported by that `role`. | ⚛️ |||
90
-
|[array-foreach](docs/rules/array-foreach.md)| enforce `for..of` loops over `Array.forEach`| ✅ |||
# Guards against developers using the title attribute (`github/a11y-no-title-attribute`)
2
+
3
+
💼 This rule is enabled in the ⚛️ `react` config.
4
+
5
+
<!-- end auto-generated rule header -->
6
+
7
+
The title attribute is strongly discouraged. The only exception is on an `<iframe>` element. It is hardly useful and cannot be accessed by multiple groups of users including keyboard-only users and mobile users.
8
+
9
+
The `title` attribute is commonly set on links, matching the link text. This is redundant and unnecessary so it can be simply be removed.
10
+
11
+
If you are considering the `title` attribute to provide supplementary description, consider whether the text in question can be persisted in the design. Alternatively, if it's important to display supplementary text that is hidden by default, consider using an accessible tooltip implementation that uses the aria-labelledby or aria-describedby semantics. Even so, proceed with caution: tooltips should only be used on interactive elements like links or buttons. See [Tooltip alternatives](https://primer.style/design/guides/accessibility/tooltip-alternatives) for more accessible alternatives.
12
+
13
+
### Should I use the title attribute to provide an accessible name for an <svg>?
14
+
15
+
Use a <title> element instead of the title attribute, or an aria-label.
16
+
17
+
## Rule Details
18
+
19
+
👎 Examples of **incorrect** code for this rule:
20
+
21
+
```jsx
22
+
<a src="https://www.github.com" title="A home for all developers">
# Ensures that interactive elements are not visually hidden (`github/a11y-no-visually-hidden-interactive-element`)
2
+
3
+
💼 This rule is enabled in the ⚛️ `react` config.
4
+
5
+
<!-- end auto-generated rule header -->
6
+
7
+
## Rule Details
8
+
9
+
This rule guards against visually hiding interactive elements. If a sighted keyboard user navigates to an interactive element that is visually hidden they might become confused and assume that keyboard focus has been lost.
10
+
11
+
Note: we are not guarding against visually hidden `input` elements at this time. Some visually hidden inputs might cause a false positive (e.g. some file inputs).
12
+
13
+
### Why do we visually hide content?
14
+
15
+
Visually hiding content can be useful when you want to provide information specifically to screen reader users or other assitive technology users while keeping content hidden from sighted users.
16
+
17
+
Applying the following css will visually hide content while still making it accessible to screen reader users.
0 commit comments