mdn · ericwbailey · Mar 1, 2022 · Feb 21, 2022 · Feb 21, 2022 · Feb 21, 2022
@@ -36,6 +36,28 @@ A toggle button is a two-state button that can be either off (not pressed) or on
 
 A menu button is a button that controls a menu and has an [`aria-haspopup`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-haspopup) property attribute set to either `menu` or `true`.
 
+### All descendants are presentational
+
+There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in a `button`. To deal with this limitation, browsers, automatically apply role [`presentation`](/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role) to all descendant elements of any `button` element as it is a role that does not support semantic children.
+
+For example, consider the following ```` element, which contains a heading.
+
+```html
+<div role="button"><h3>Title of my button</h3></div>
+```
+
+Because descendants of `button` are presentational, the following code is equivalent:
+
+```html
+<div role="button"><h3 role="presentation">Title of my button</h3></div>
+````
+
+From the assitive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the [accessibility tree](/en-US/docs/Glossary/Accessibility_tree):
+
+```html
+<div role="button">Title of my button</div>
+```
+
 ### Associated ARIA roles, states, and properties
 
 - [`aria-pressed`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-pressed)

@@ -31,6 +31,28 @@ Since a checkbox is an interactive control, it must be focusable and keyboard ac
 
 The developer is required to change the value of the `aria-checked` attribute dynamically when the checkbox is activated.
 
+### All descendants are presentational
+
+There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in a `checkbox`. To deal with this limitation, browsers, automatically apply role [`presentation`](/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role) to all descendant elements of any `checkbox` element as it is a role that does not support semantic children.
+
+For example, consider the following ```` element, which contains a heading.
+
+```html
+<div role="checkbox"><h6>Name of my checkbox</h6></li>
+```
+
+Because descendants of `checkbox` are presentational, the following code is equivalent:
+
+```html
+<div role="checkbox"><h6 role="presentation">Name of my checkbox</h6></li>
+````
+
+From the assitive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the [accessibility tree](/en-US/docs/Glossary/Accessibility_tree):
+
+```html
+<div role="checkbox">Name of my checkbox</div>
+```
+
 ### Associated WAI-ARIA Roles, States, and Properties
 
 - [`aria-checked`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-checked)

@@ -89,6 +89,28 @@ Another example where this might be suitable is when using ASCII emoji combinati
 
 If `aria-labelledby` were used, the screen reader would read it. In this case, only the contents of the `aria-label` are announced to screen reader users, hiding the gibberish of the characters without the need for descendant ARIA to hide things, but also hiding potential content that may be part of the image.
 
+### All descendants are presentational
+
+There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in an `img`. To deal with this limitation, browsers, automatically apply role [`presentation`](/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role) to all descendant elements of any `img` element as it is a role that does not support semantic children.
+
+For example, consider the following ```` element, which contains a heading.
+
+```html
+<div role="img"><h3>Title of my image</h3></div>
+```
+
+Because descendants of `img` are presentational, the following code is equivalent:
+
+```html
+<div role="img"><h3 role="presentation">Title of my image</h3></div>
+````
+
+From the assitive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the [accessibility tree](/en-US/docs/Glossary/Accessibility_tree).:
+
+```html
+<div role="img">Title of my image</div>
+```
+
 ### Associated WAI-ARIA Roles, States, and Properties
 
 - `aria-label` or `aria-labelledby`

@@ -20,6 +20,28 @@ Each element with `role="meter"` must also have one of the following:
 - An [`aria-label`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-label) attribute.
 - An [`aria-labelledby`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-labelledby) attribute pointing to an element with text that describes the meter.
 
+### All descendants are presentational
+
+There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in a `meter`. To deal with this limitation, browsers, automatically apply role [`presentation`](/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role) to all descendant elements of any `meter` element as it is a role that does not support semantic children.
+
+For example, consider the following ```` element, which contains a heading.
+
+```html
+<div role="meter"><h3>Title of my meter</h3></div>
+```
+
+Because descendants of `meter` are presentational, the following code is equivalent:
+
+```html
+<div role="meter"><h3 role="presentation">Title of my meter</h3></div>
+````
+
+From the assitive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the [accessibility tree](/en-US/docs/Glossary/Accessibility_tree).:
+
+```html
+<div role="meter">Title of my meter</div>
+```
+
 ### Associated ARIA roles, states, and properties
 
 - [`aria-valuenow`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-valuenow)

@@ -23,6 +23,28 @@ Authors can also explicitly provide an accessible name by specifying [`aria-labe
 
 It is highly recommended to use a {{HTMLElement('select')}} element or an  {{HTMLElement('input')}} element with the `checkbox` or `radio` type instead, when possible. These native HTML elements provide keyboard interactivity to manage focus for all the descendants for you automatically.
 
+### All descendants are presentational
+
+There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in a `option`. To deal with this limitation, browsers, automatically apply role [`presentation`](/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role) to all descendant elements of any `option` element as it is a role that does not support semantic children.
+
+For example, consider the following ```` element, which contains a heading.
+
+```html
+<div role="option"><h3>Title of my option</h3></div>
+```
+
+Because descendants of `option` are presentational, the following code is equivalent:
+
+```html
+<div role="option"><h3 role="presentation">Title of my option</h3></div>
+````
+
+From the assitive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the [accessibility tree](/en-US/docs/Glossary/Accessibility_tree):
+
+```html
+<div role="option">Title of my option</div>
+```
+
 ### Associated ARIA roles, states, and properties
 
 #### Associated Roles

@@ -27,6 +27,28 @@ Authors **may** set aria-valuemin and aria-valuemax to indicate the minimum and
 
 If the `progressbar` role is applied to an HTML {{HTMLElement('progress')}} element, the accessible name can come from the associated {{HTMLElement('label')}}. Otherwise use [`aria-labelledby`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-labelledby) if a visible label is present or  [`aria-label`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-label) if a visible label is not present.
 
+### All descendants are presentational
+
+There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in a `progressbar`. To deal with this limitation, browsers, automatically apply role [`presentation`](/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role) to all descendant elements of any `progressbar` element as it is a role that does not support semantic children.
+
+For example, consider the following ```` element, which contains a heading.
+
+```html
+<div role="progressbar"><h3>Title of my progressbar</h3></div>
+```
+
+Because descendants of `progressbar` are presentational, the following code is equivalent:
+
+```html
+<div role="progressbar"><h3 role="presentation">Title of my progressbar</h3></div>
+````
+
+From the assitive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the [accessibility tree](/en-US/docs/Glossary/Accessibility_tree):
+
+```html
+<div role="progressbar">Title of my progressbar</div>
+```
+
 ### Associated WAI-ARIA roles, states, and properties
 
 - [`aria-valuenow`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-valuenow)

@@ -72,6 +72,28 @@ As `radio` is an interactive control; it must be focusable and keyboard accessib
 
 If any of the radio roles in a group has `aria-required="true"` set, it is as if all of the radios in the group had the attribute making the selection of one of the radios in the radiogroup being required to be valid;  though not necessarily the one that has the [`aria-required`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-required) attribute set.
 
+### All descendants are presentational
+
+There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in a `radio`. To deal with this limitation, browsers, automatically apply role [`presentation`](/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role) to all descendant elements of any `radio` element as it is a role that does not support semantic children.
+
+For example, consider the following ```` element, which contains a heading.
+
+```html
+<div role="radio"><h6>name of my radio</h6></li>
+```
+
+Because descendants of `radio` are presentational, the following code is equivalent:
+
+```html
+<div role="radio"><h6 role="presentation">name of my radio</h6></li>
+````
+
+From the assitive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the [accessibility tree](/en-US/docs/Glossary/Accessibility_tree):
+
+```html
+<div role="radio">name of my radio</div>
+```
+
 ## Associated WAI-ARIA Roles, States, and Properties
 
 - ['radiogroup`](/en-US/docs/Web/Accessibility/ARIA/Roles/radiogroup_role) role

@@ -63,6 +63,28 @@ If the separator is focusable, providing a visible boundary between two sections
 
 An accessible name, with [`aria-label`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-label) should be included if there is more than one focusable separator.
 
+### All descendants are presentational
+
+There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in a `separator`. To deal with this limitation, browsers, automatically apply role [`presentation`](/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role) to all descendant elements of any `separator` element as it is a role that does not support semantic children.
+
+For example, consider the following ```` element, which contains a heading.
+
+```html
+<div role="separator"><h3>Title of my separator</h3></div>
+```
+
+Because descendants of `separator` are presentational, the following code is equivalent:
+
+```html
+<div role="separator"><h3 role="presentation">Title of my separator</h3></div>
+````
+
+From the assitive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the [accessibility tree](/en-US/docs/Glossary/Accessibility_tree):
+
+```html
+<div role="separator">Title of my separator</div>
+```
+
 ### Associated WAI-ARIA roles, states, and properties
 
 - [`aria-orientation`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-orientation) (default is horizontal for separator)

@@ -70,6 +70,28 @@ In many two-thumb sliders, the thumbs are not allowed to pass one another, such
 
 It is not a requirement that the thumbs in multi-thumb sliders be dependent on the other thumb values, but intuitive user experience is a requirement, so it is recommended to avoid this anti-pattern.
 
+### All descendants are presentational
+
+There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in a `slider`. To deal with this limitation, browsers, automatically apply role [`presentation`](/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role) to all descendant elements of any `slider` element as it is a role that does not support semantic children.
+
+For example, consider the following ```` element, which contains a heading.
+
+```html
+<div role="slider"><h3>Temperature in Celcius</h3></div>
+```
+
+Because descendants of `slider` are presentational, the following code is equivalent:
+
+```html
+<div role="slider"><h3 role="presentation">Temperature in Celcius</h3></div>
+````
+
+From the assitive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the [accessibility tree](/en-US/docs/Glossary/Accessibility_tree):
+
+```html
+<div role="slider">Temperature in Celcius</div>
+```
+
 ## Associated roles, states, and properties
 
 - [`aria-valuenow`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-valuenow) (required)

@@ -32,6 +32,28 @@ Assistive technologies may choose to represent `switch` widgets with a specializ
 
 Since a switch is an interactive control, it must be focusable and keyboard accessible. If the role is applied to a non-focusable element, use the `tabindex` attribute to change this. The expected keyboard shortcut for toggling the value of a switch is the <kbd>Space</kbd> key. The developer is required to change the value of the `aria-checked` attribute dynamically when the switch is toggled.
 
+### All descendants are presentational
+
+There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in a `switch`. To deal with this limitation, browsers, automatically apply role [`presentation`](/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role) to all descendant elements of any `switch` element as it is a role that does not support semantic children.
+
+For example, consider the following ```` element, which contains a heading.
+
+```html
+<div role="switch"><h3>Title of my switch</h3></div>
+```
+
+Because descendants of `switch` are presentational, the following code is equivalent:
+
+```html
+<div role="switch"><h3 role="presentation">Title of my switch</h3></div>
+````
+
+From the assitive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the [accessibility tree](/en-US/docs/Glossary/Accessibility_tree):
+
+```html
+<div role="switch">Title of my switch</div>
+```
+
 ### Associated ARIA roles, states, and properties
 
 - [`aria-checked`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-checked) attribute

@@ -22,6 +22,28 @@ Elements with the role `tab` *must* either be a child of an element with the `ta
 
 When elements with the `tab` role are selected or active they should have their [`aria-selected`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-selected) attribute set to `true`. Otherwise, their `aria-selected` attribute should be set to `false`. When a `tab` is selected or active, its corresponding controlled `tabpanel` should have its [`aria-expanded`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-expanded) attribute set to `true` and its `hidden` attribute set to `false`, otherwise the reverse.
 
+### All descendants are presentational
+
+There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in a `tab`. To deal with this limitation, browsers, automatically apply role [`presentation`](/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role) to all descendant elements of any `tab` element as it is a role that does not support semantic children.
+
+For example, consider the following ```` element, which contains a heading.
+
+```html
+<div role="tab"><h3>Title of my tab</h3></div>
+```
+
+Because descendants of `tab` are presentational, the following code is equivalent:
+
+```html
+<div role="tab"><h3 role="presentation">Title of my tab</h3></div>
+````
+
+From the assitive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the [accessibility tree](/en-US/docs/Glossary/Accessibility_tree):
+
+```html
+<div role="tab">Title of my tab</div>
+```
+
 ### Associated roles and attributes
 
 - [`aria-selected`](/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-selected)