Notice: This is a work in progress. Please submit feedback or suggestions.

role attribute (html)

Screen reader support level: partial (19/20)

Voice Control support level: partial (7/8)

On this page

The role attribute is used to convey the purpose of various elements to users of assistive technology. While the role attribute is defined in ARIA, these expectations test the attribute as implemented in HTML.

Expectations

What are expectations?

Screen Reader support by expectation

ExpectationJAWSNarratorNVDAOrcaTalkBackVoiceOver (iOS)VoiceOver (macOS)
MUST convey the presence of the role attributesupportedsupportedsupportedsupportedsupportedsupportedsupported
MUST support fallback rolespartial (2/3)supportedsupportedsupportedsupportedsupportedsupported
SHOULD process changes in role valuessupportedsupportedsupportedsupportedsupportednonesupported
SHOULD NOT lose the location of the browsing caret when a container role is changedsupportedsupportedpartial (1/2)supportedsupportedsupportedsupported

Voice Control support by expectation

ExpectationDragon Naturally SpeakingVoice Access (Android)Voice Control (iOS)Voice Control (MacOS)Windows Speech Recognition
MUST convey the presence of the role attributesupportedsupportednot applicablesupportedsupported
MUST support fallback rolesnonesupportednot applicablesupportedsupported
SHOULD process changes in role valuessupportedsupportednot applicablesupportedsupported
MAY use the role to determine if an element is actionablesupportedsupportednot applicablesupportedsupported

Expectation: convey the presence of the role attribute

Rationale: The user needs to know when a role is defined.

Strength of these expectations for different types of assistive technologies:

  • Screen Readers: MUST
  • Voice Control: MUST

Notes: The expectation is that a valid role value is conveyed to end users. This expectation does not check the correctness of the role conveyed, but only that a role is conveyed. Note that roles can be conveyed in a way that is implied by context and that AT have discretion in how to actually convey the role value. For example, some screen readers may convey the actual value of the role, and others may choose to convey a slightly different value. The correctness of role values is tested on a per-value bases elsewhere in this project.

Screen Reader support for 'MUST convey the presence of the role attribute'
TestJAWSNarratorNVDAOrcaTalkBackVoiceOver (iOS)VoiceOver (macOS)
ChromeIEFirefoxEdgeChromeFirefoxFirefoxChromeSafariSafari
HTML role attribute test suitesupportedsupportedsupportedsupportedsupportedsupportedsupportedsupportedsupportedsupported
Voice Control support for 'MUST convey the presence of the role attribute'
TestDragon Naturally SpeakingVoice Access (Android)Voice Control (iOS)Voice Control (MacOS)Windows Speech Recognition
ChromeChromeSafariSafariChrome
HTML role attribute test suitesupportedsupportednot applicablesupportedsupported

Expectation: support fallback roles

Rationale: If multiple roles are defined, the user needs to be made aware of the first supported role value

Strength of these expectations for different types of assistive technologies:

  • Screen Readers: MUST
  • Voice Control: MUST

Notes: Authors can list multiple role values within a role attribute, and each role is separated by white space. The first recognized role will be used used. This can be helpful when authors want to use a new role that is not widely supported yet, and fall back to an older role with wider support.

Screen Reader support for 'MUST support fallback roles'
TestJAWSNarratorNVDAOrcaTalkBackVoiceOver (iOS)VoiceOver (macOS)
ChromeIEFirefoxEdgeChromeFirefoxFirefoxChromeSafariSafari
HTML role attribute test suitesupportednonesupportedsupportedsupportedsupportedsupportedsupportedsupportedsupported
Voice Control support for 'MUST support fallback roles'
TestDragon Naturally SpeakingVoice Access (Android)Voice Control (iOS)Voice Control (MacOS)Windows Speech Recognition
ChromeChromeSafariSafariChrome
HTML role attribute test suitenonesupportednot applicablesupportedsupported

Expectation: process changes in role values

Rationale: If the role of an element changes, users need to be able to determine the new role

Strength of these expectations for different types of assistive technologies:

  • Screen Readers: SHOULD
  • Voice Control: SHOULD

Notes: Due to the way that accessibility APIs and caching mechanisms work, this may not be supported. ARIA explicitly forbids authors from changing roles in this way.

Screen Reader support for 'SHOULD process changes in role values'
TestJAWSNarratorNVDAOrcaTalkBackVoiceOver (iOS)VoiceOver (macOS)
ChromeIEFirefoxEdgeChromeFirefoxFirefoxChromeSafariSafari
HTML role attribute test suitesupportedsupportedsupportedsupportedsupportedsupportedsupportedsupportednonesupported
Voice Control support for 'SHOULD process changes in role values'
TestDragon Naturally SpeakingVoice Access (Android)Voice Control (iOS)Voice Control (MacOS)Windows Speech Recognition
ChromeChromeSafariSafariChrome
HTML role attribute test suitesupportedsupportednot applicablesupportedsupported

Expectation: lose the location of the browsing caret when a container role is changed

Rationale: If a screen reader user is browsing the contents of a container element and the role of the container changes, the caret should stay in the same location so that the user can continue reading the document in a logical order.

Strength of these expectations for different types of assistive technologies:

  • Screen Readers: SHOULD NOT
  • Voice Control: NA

Notes: When the role of an element changes, some AT and accessibility APIs may remove the element and all children and then replace them with the new container, which may result in the screen reader losing its caret position.

Screen Reader support for 'SHOULD NOT lose the location of the browsing caret when a container role is changed'
TestJAWSNarratorNVDAOrcaTalkBackVoiceOver (iOS)VoiceOver (macOS)
ChromeIEFirefoxEdgeChromeFirefoxFirefoxChromeSafariSafari
HTML role attribute test suitesupportedsupportedsupportedsupportednonesupportedsupportedsupportedsupportedsupported

Expectation: use the role to determine if an element is actionable

Rationale: Voice control users may wish to activate roles that are actionable.

Strength of these expectations for different types of assistive technologies:

  • Screen Readers: NA
  • Voice Control: MAY

Notes: Voice control software may choose to look at an element's role when determining if it is actionable. Some voice control software will allow users to activate elements by specific roles, while others will only flag actionable elements with numbers. Note that Voice Control for iOS will flag all elements on the page with numbers, not just those that are actionable.

Voice Control support for 'MAY use the role to determine if an element is actionable'
TestDragon Naturally SpeakingVoice Access (Android)Voice Control (iOS)Voice Control (MacOS)Windows Speech Recognition
ChromeChromeSafariSafariChrome
HTML role attribute tests for Voice Controlsupportedsupportednot applicablesupportedsupported