ARIA required context role

  • Rule Typeatomic
  • Rule ID: ff89c9
  • Last modified: -
  • Accessibility Requirements Mapping
    • 1.3.1 Info and Relationships (Level: A)
      • Learn More about 1.3.1 (Info and Relationships)
      • Required for conformance to WCAG 2.0 and above on level A and above.
      • Outcome mapping:
        • Any failed outcomes: not satisfied.
        • All passed outcomes: further testing needed.
        • An inapplicable outcome: further testing needed.
  • Input Aspects

Description

This rule checks that an element with an explicit semantic role exists inside its required context.

Applicability

The rule applies to any HTML or SVG element that is included in the accessibility tree and has a WAI-ARIA 1.1 explicit semantic role with a WAI-ARIA required context role, except if the element has an implicit semantic role that is identical to its explicit semantic role.

Note: An example of an element that has a WAI-ARIA required context role is tab that has tablist as a required context role.

Note: An example of an element that has an implicit semantic role that is identical to its explicit semantic role is an li element that has role="listitem". These elements are not applicable.

Note: The applicability of this rule is limited to only the WAI-ARIA 1.1 Recommendation roles, since there are unresolved issues with how Digital Publishing WAI-ARIA Module (DPUB ARIA) 1.0 uses role inheritance to define the required context roles, which makes it deviate from the model defined in WAI-ARIA 1.1. The WAI-ARIA Graphics Module does not include any required context roles.

Expectation

Each test target is owned by an element that has a semantic role that is one of the WAI-ARIA required context roles of the target element.

Note: The definition of owned by used in this rule is different than the definition of "owned element" in WAI-ARIA. See more in the owned by definition.

Note: Subclass roles of WAI-ARIA required context roles are not automatically included as possible required context roles. E.g. the feed role is not a possible required context role for listitem, even though feed is a subclass role of the list role.

Assumptions

If the explicit semantic role on the target element is incorrectly used, and any relationships between elements are already programmatically determinable, failing this rule may not result in accessibility issues for users of assistive technologies, and it should then not be considered a failure under WCAG success criterion 1.3.1 Info and Relationships.

Accessibility Support

  • User agents do not all have the same accessibility tree. Particularly the method of deriving which element owns which other elements varies between browsers. This can lead to different results for this rule, depending on which accessibility tree is used as input.
  • aria-owns has limited support in some user agents.

Background

Test Cases

Passed

Passed Example 1

Element with explicit semantic role listitem is contained within its required context role list, expressed as an explicit semantic role.

<div role="list">
	<div role="listitem">List item 1</div>
</div>

Passed Example 2

Element with explicit semantic role listitem is contained within its required context role list, through the implicit semantic role of ul.

<ul>
	<div role="listitem">List item 1</div>
</ul>

Passed Example 3

Element contained within its required context role even though it is not a direct child of the context role.

<div role="list">
	<div role="presentation">
		<div role="listitem">List item 1</div>
	</div>
</div>

Passed Example 4

aria-owns used to give the target element the right context role.

<div role="list" aria-owns="item"></div>
<div id="item" role="listitem">List item 1</div>

Passed Example 5

The aria-owns attribute override normal DOM tree relationship. Thus, the innermost div element (item) is not owned by the intermediate one (with a role="navigation") and has the correct context role.

<div role="list" aria-owns="item">
	<div role="navigation">
		<div id="item" role="listitem">List item 1</div>
	</div>
</div>

Passed Example 6

Since implicit ownership can cross shadow boundaries, the element with the explicit semantic role of listitem is contained within its required context role of list.

<div id="host" role="list"></div>

<script>
	const host = document.querySelector('#host')
	const root = host.attachShadow({ mode: 'open' })
	root.innerHTML = '<div role="listitem">List item 1</div>'
</script>

Failed

Failed Example 1

The listitem has no context role.

<div role="listitem">List item 1</div>

Failed Example 2

The listitem is owned by the tabpanel, because it is the closest ancestor, but tabpanel is not the correct context for listitem.

<div role="list">
	<div role="tabpanel">
		<div role="listitem">List item 1</div>
	</div>
</div>

Failed Example 3

The listitem is owned by the aria-label="menu" div, rather than the list.

<div role="list">
	<div aria-label="menu">
		<div role="listitem">List item 1</div>
	</div>
</div>

Failed Example 4

Since explicit ownership cannot cross shadow boundaries, the element with the explicit semantic role of listitem does not have a context role.

<div role="list" aria-owns="item"></div>

<div id="host"></div>

<script>
	const host = document.querySelector('#host')
	const root = host.attachShadow({ mode: 'open' })
	root.innerHTML = '<div id="item" role="listitem">List item 1</div>'
</script>

Inapplicable

Inapplicable Example 1

There is no element with an explicit semantic role.

<ul>
	<li>List item 1</li>
</ul>

Inapplicable Example 2

The listitem is not included in the accessibility tree.

<div role="listitem" style="display:none;">List item 1</div>

Inapplicable Example 3

The header role does not have a required context role.

<div role="header" aria-level="1">Hello!</div>
<p>Welcome to my homepage!</p>

Inapplicable Example 4

The listitem has an explicit semantic role, but it is identical to the implicit semantic role, making the element inapplicable.

<ul>
	<li role="listitem">List item 1</li>
</ul>

Inapplicable Example 5

The doc-biblioentry has a role from the Digital Publishing WAI-ARIA Module (DPUB ARIA) 1.0, not the WAI-ARIA 1.1 Recommendation, and it is therefore inapplicable.

<section role="doc-bibliography">
	<h1>Cited Works</h1>
	<div role="list">
		<p role="doc-biblioentry" id="b8cab5dd-bc24-459c-9858-7afa9da69b64">
			John Steinbeck, The Grapes of Wrath (New York: The Viking Press, 1939)
		</p>
	</div>
</section>

Glossary

Explicit Semantic Role

key: explicit-role

The explicit semantic role is the semantic role of an element set by its role attribute.

The role attribute takes a list of tokens. The explicit semantic role is the first valid role in this list. If none of the tokens are valid, the implicit semantic role will be used instead. The valid roles are all non-abstract roles from WAI-ARIA Specifications.

Other roles may be added as they become available. Not all roles will be supported in all assistive technologies. Testers are encouraged to adjust which roles are allowed according to the accessibility support base line. For the purposes of executing test cases in all rules, it should be assumed that all roles are supported by assistive technologies so that none of the roles fail due to lack of accessibility support.

Accessibility Support

Some browsers and assistive technologies treat the tokens of the role attribute as case-sensitive. Unless lowercase letters are used for the value of the role attribute, not all user agents will be able to interpret the tokens correctly. ARIA in HTML (working draft) also specifies that authors must use lowercase letters for the role and aria-* attributes.

Included in the accessibility tree

key: included-in-the-accessibility-tree

Elements included in the accessibility tree of platform specific accessibility APIs. Elements in the accessibility tree are exposed to assistive technologies, allowing users to interact with the elements in a way that meet the requirements of the individual user.

The general rules for when elements are included in the accessibility tree are defined in the core accessibility API mappings. For native markup languages, such as HTML and SVG, additional rules for when elements are included in the accessibility tree can be found in the HTML accessibility API mappings (working draft) and the SVG accessibility API mappings (working draft).

Note: Users of assistive technologies might still be able to interact with elements that are not included in the accessibility tree. An example of this is a focusable element with an aria-hidden attribute with a value of true. Such an element could still be interacted with using sequential keyboard navigation regardless of the assistive technologies used, even though the element would not be included in the accessibility tree.

Examples

Note: The examples presented here are non-normative and not testable. They serve to illustrate some common pitfalls about the definition and to help implementers of ACT rules understand it.

This span element is included in the accessibility tree (by default, elements are included in the accessibility tree).

<span>ACT rules</span>

This span element is not included in the accessibility tree because it is hidden to everybody by the CSS property.

<span style="display:none">ACT rules</span>

This span element is not included in the accessibility tree because it is explicitly removed by the aria-hidden attribute.

<span aria-hidden="true">ACT rules</span>

This span element is positioned off screen, hence is not visible, but is nonetheless included in the accessibility tree.

<span style="position: absolute; top:-9999em">ACT rules</span>

Although the span element with an id of "label" is not itself included in the accessibility tree, it still provides an accessible name to the other span, via the aria-labelledby attribute. Thus, it is still indirectly exposed to users of assistive technologies. Removing an element from the accessibility tree is not enough to remove all accessibility concerns from it since it can still be indirectly exposed.

<span id="label" style="display:none">ACT rules</span>
<span aria-labelledby="label">Accessibility Conformance Testing rules</span>

Although this input element is not included in the accessibility tree, it is still focusable, hence users of assistive technologies can still interact with it by sequential keyboard navigation. This may result in confusing situations for such users (and is in direct violation of the fourth rule of ARIA (working draft)).

<input type="text" aria-hidden="true" name="fname" />

Outcome

key: outcome

A conclusion that comes from evaluating an ACT Rule on a test subject or one of its constituent test target. An outcome can be one of the three following types:

  • Inapplicable: No part of the test subject matches the applicability
  • Passed: A test target meets all expectations
  • Failed: A test target does not meet all expectations

Note: A rule has one passed or failed outcome for every test target. When there are no test targets the rule has one inapplicable outcome. This means that each test subject will have one or more outcomes.

Note: Implementations using the EARL10-Schema can express the outcome with the outcome property. In addition to passed, failed and inapplicable, EARL 1.0 also defined an incomplete outcome. While this cannot be the outcome of an ACT Rule when applied in its entirety, it often happens that rules are only partially evaluated. For example, when applicability was automated, but the expectations have to be evaluated manually. Such "interim" results can be expressed with the incomplete outcome.

Owned by

key: owned-by

An element A is owned by element B if element A is a child of element B in the accessibility tree.

Note: This definition is different from the definition of "owned element" in WAI-ARIA. Because browsers have different accessibility trees, which element owns which other elements can vary between browsers. Until there is a standard accessibility tree, testing with multiple accessibility trees may be necessary.

Semantic Role

key: semantic-role

A semantic role is a semantic association that indicates an object's type. This allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.

The semantic role of an element is its explicit semantic role if it has any, otherwise, the implicit semantic role is used.


Useful Links


Implementations

OrganisationTool NameReport
Axe CoreDeque SystemsView Report

Acknowledgements

previous_authros

Table of Contents