Important: This website does not attempt to establish a standard for how assistive technologies must behave. Read the FAQ for more information. Additionally, this is a work in progress. Please submit feedback or suggestions.

aria-controls attribute (aria)

Screen Reader support level: partial (10/42)

On this page

About this feature

Identifies the element (or elements) whose contents or presence are controlled by the current element. See related aria-owns.

Age of results

Results across all tests for this feature range from 8 months ago to 5 years ago. Detailed dates and version information can be found in associated tests.

Failing and partial results are between 8 months ago and 5 years ago.

Expectations

What are expectations?

Important: The aria-controls attribute has expectations that are not directly testable by end users. Continue to use it if it is required by the specification, even if user-facing expectation support is poor. For more information, see FAQ: What about expectations that are not directly testable by users?.

Screen Reader support by expectation

ExpectationJAWSNarratorNVDAOrcaTalkBackVoiceOver (iOS)VoiceOver (macOS)
ChromeEdgeFirefoxEdgeChromeEdgeFirefoxFirefoxChromeSafariSafari
SHOULD convey the presence of the aria-controls attributenonenonenonenonenonenonenonenonenonenonenone
MUST allow the user to jump to the controlled elementsupportedsupportedsupportednonenonenonenonenonenonenonenone

Expectation: convey the presence of the aria-controls attribute

Rationale:

Users need to be aware that an element has aria-controls functionality. If the presence of the attribute is not explicitly conveyed, then users may not be aware of the functionality. However, some screen readers may choose to not convey the presence by default since the controlled element is usually directly after the controlling element in the reading order and easily findable. In these situations, explicitly conveying the presence could be unnecessarily verbose.

Strength of this expectation for different types of assistive technologies:

  • Screen Readers: SHOULD
  • Voice Control: NA

Notes:

This is not a MUST requirement, because the functionality could still be discoverable via the screen reader's command to jump to the controlled element. If the command fails, the attribute is not present.

Examples:

  • When supported, screen readers will often hint that an element controls another element, and may even announce the keyboard shortcut to jump to the controlled element
  • Most screen readers either do not support this attribute or the setting to convey the presence is turned off by default. This is because in the vast majority of cases, the controlled element is adjacent to the element with aria-controls, and thus announcing the presence is redundant and add extra verbosity.

Expectation: allow the user to jump to the controlled element

Rationale:

The controlled element might not be close to the element with aria-controls and the user might find it convenient to jump directly to the controlled element.

Strength of this expectation for different types of assistive technologies:

  • Screen Readers: MUST
  • Voice Control: NA