diff --git a/_rules/aria-required-accessible-name-gp8n89.md b/_rules/aria-required-accessible-name-gp8n89.md new file mode 100644 index 0000000000..825116090f --- /dev/null +++ b/_rules/aria-required-accessible-name-gp8n89.md @@ -0,0 +1,268 @@ +--- +id: gp8n89 +name: ARIA required accessible name +rule_type: atomic +description: | + This rule checks that WAI-ARIA accessible name is available when required. +accessibility_requirements: + aria12:accessible_name_required: + title: ARIA 1.2, Accessible Name Required + forConformance: true + failed: not satisfied + passed: satisfied + inapplicable: satisfied + wcag20:1.1.1: # Non-text Content (A) + secondary: This success criterion is **related** to this rule. This is because elements assigned the ARIA role of `img` or `image` necessitate an accessible name according to WCAG standards. Some of the examples that either pass or fail overlap with this success criterion. + wcag20:1.3.1: # Info and Relationships (A) + secondary: This success criterion is **related** to this rule. Unlike WCAG, which might not mandate accessible names for certain elements like table elements, this rule requires them. On the other hand, there are situations where information is not visually presented and is not required by WCAG, but is still required to have an accessible name according to ARIA requirements. + wcag20:2.4.4: # Link Purpose (In Context) (A) + secondary: This success criterion is **related** to this rule. This is because elements assigned the ARIA role of `link` necessitate an accessible name according to WCAG standards. Some of the examples that either pass or fail overlap with this success criterion. + wcag20:2.4.9: # Link Purpose (Link Only) (AAA) + secondary: This success criterion is **related** to this rule. This is because elements assigned the ARIA role of `link` necessitate an accessible name according to WCAG standards. Some of the examples that either pass or fail overlap with this success criterion. + wcag20:4.1.2: # Name, Role, Value (A) + secondary: This success criterion is **related** to this rule. This is because elements assigned an ARIA role corresponding to a user interface component necessitate an accessible name according to WCAG standards. Some of the examples that either pass or fail overlap with this success criterion. +input_aspects: + - Accessibility Tree + - CSS styling + - DOM Tree +acknowledgments: + authors: + - Giacomo Petri +--- + +## Applicability + +This rule applies to any [HTML or SVG element][] that is [included in the accessibility tree][] and has a [semantic role][] that has the "Accessible Name Required: True" [characteristic][], unless the element has a [explicit][explicit semantic role] presentational role. + +[characteristic]: https://www.w3.org/TR/wai-aria-1.2/#Properties + +## Expectation + +Each target element has an [accessible name][] that is not empty (`""`). + +## Assumptions + +There are no assumptions. + +## Accessibility Support + +Elements with a [semantic role][] of `heading` and with no [accessible name][] seem to be consistently ignored by assistive technologies. Nonetheless, in the context of this rule, they fail since [WAI-ARIA 1.2][wai-aria 1.2] mandates the presence of an [accessible name][]. + +The [accessible name and description computation][] suggests that if an `aria-labelledby` attribute refers to an existing but empty element, the computation should stop and return an empty name without defaulting to the next steps. Several user agents and assistive technologies chose to use the next step in the computation in this case (ultimately defaulting to the content). + +## Background + +Although this ARIA rule mandates authors to ensure an [accessible name][] for each [HTML or SVG element][] [included in the accessibility tree][] and possessing a [WAI-ARIA 1.2][wai-aria 1.2] [semantic role][] requiring an [accessible name][], it does not automatically constitute a WCAG accessibility violation. + +For instance, consider a `search` landmark comprising an element with the `form` role, a search label, a search input, and a search submit button. According to ARIA specifications, the `searchbox` role necessitate an [accessible name][]. However, adhering strictly to this rule may lead to repetitive announcements by assistive technologies like screen readers, overwhelming users. Therefore, while this might technically breach ARIA specs, it does not necessarily translate to a violation of WCAG accessibility standards. + +Elements subjected to the [Presentational Roles Conflict Resolution][] are not part of this rule and must be tested separately. + +### Bibliography + +- [WAI-ARIA 1.2][wai-aria 1.2] +- [ARIA in HTML](https://www.w3.org/TR/html-aria/#docconformance) +- [Understanding Success Criterion 1.1.1: Non-text Content](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html) +- [Understanding Success Criterion 1.3.1: Info and Relationships](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value) +- [Understanding Success Criterion 2.4.4 Link Purpose (In Context)]([https://www.w3.org/WAI/WCAG22/Understanding/name-role-value](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html)) +- [Understanding Success Criterion 2.4.9 Link Purpose (Link Only)](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-link-only.html) +- [Understanding Success Criterion 4.1.2: Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value) + +## Test Cases + +### Passed + +#### Passed Example 1 + +This `button` element with an [implicit semantic role] of `button` has an [accessible name][] provided by its content. + +```html + +``` + +#### Passed Example 2 + +The `div` element with role `button` has an [accessible name][] provided by its content. + +```html +
These are our terms.
+These are our terms.
+