Skip to content

Commit

Permalink
Draft sections on role presentation and children presentational
Browse files Browse the repository at this point in the history 
modified:   aria-practices.html.

For issue #79, added a section describing the presentation role, its uses, and the rules that govern its effects.

For issue #177, drafted a section informing readers that some roles automatically cause descendants to have role presentation and illustrating what that means.
  • Loading branch information
@mcking65
mcking65 committed Dec 5, 2016
1 parent a02a64a commit 5b94eb2
Showing 1 changed file with 171 additions and 0 deletions.
171 changes: 171 additions & 0 deletions aria-practices.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3325,6 +3325,177 @@ <h2>Grid and Table Properties</h2>
</p>
</section>

<section id="presentation_role">
<h2>
Intentionally Hiding Semantics with the <code>presentation</code> Role
</h2>
<p>
Please provide feedback on this section in <a href="https://github.com/w3c/aria-practices/issues/176">issue 176</a>.
</p>
<p>
While ARIA is primarily used to express semantics, there are some situations where hiding an
element’s semantics from assistive technologies is helpful. This is done with the
<a href="#presentation" class="role-reference">presentation</a>
role, which declares that an element is being used only for presentation and therefore does
not have any accessibility semantics. The ARIA 1.1 specification also includes role
<a href="#none" class="role-reference">none</a>
, which serves as a synonym for <code>presentation</code>.
</p>
<p>
For example, consider a tablist built using an HTML <code>ul</code> element.
</p>
<pre>
&lt;ul role=&quot;tablist&quot;&gt;
&lt;li role=&quot;presentation&quot;&gt;
&lt;a role=&quot;tab&quot; href=&quot;#&quot;&gt;Tab 1&lt;/a&gt;
&lt;/li&gt;
&lt;li role=&quot;presentation&quot;&gt;
&lt;a role=&quot;tab&quot; href=&quot;#&quot;&gt;Tab 2&lt;/a&gt;
&lt;/li&gt;
&lt;li role=&quot;presentation&quot;&gt;
&lt;a role=&quot;tab&quot; href=&quot;#&quot;&gt;Tab 3&lt;/a&gt;
&lt;/li&gt;
&lt;/ul&gt;
</pre>
<p>
Because the list is declared to be a tablist, the list items are not in a list context. It
could confuse users if an assistive technology were to render those list items. Applying role
<code>presentation</code> to the <code>li</code> elements tells browsers to leave those
elements out of their accessibility tree. Assistive technologies will thus be unaware of the
list item elements and see the tab elements as immediate children of the tablist.
</p>
<p>
Three common uses of role <code>presentation</code> are:
</p>
<ol>
<li>Hiding a presentational image.</li>
<li>Suppressing semantics of a layout table.</li>
<li>Eliminating semantics of intervening orphan elements in the structure of a composite
widget, such as a tablist, menu, or tree as demonstrated in the example above.</li>
</ol>
<section id="presentation_role_rules">
<h3>
Four Rules for Using Role <code>presentation</code>
</h3>
<p>
When reading the following rules, it is important to understand that most host language
elements, such as an HTML <code>h1</code> element, have an implied ARIA role and may also
have implied states or properties. When rendering an <code>h1</code> element, browsers tell
assistive technologies that it has ARIA role <code>heading</code> and property value <code>aria-level=&quot;1&quot;</code>.
</p>
<p>
The following rules describe the result of applying role <code>presentation</code> to an
element.
</p>
<ol>
<li>
Browsers ignore the <code>presentation</code> role and it therefore does not affect how
assistive technology users perceive the element if either:
<ul>
<li>the element is focusable.</li>
<li>
The element has any of the
<a href="#global_states" class="specref">twenty-one global ARIA states and properties</a>
, e.g., <code>aria-label</code>.
</li>
</ul>
</li>
<li>If not ignored, the element’s implied ARIA role and associated ARIA states and
properties are hidden from assistive technologies.</li>
<li>
Text contained by the element and all its descendant elements remains visible to assistive
technologies except, of course, when the text is explicitly hidden, e.g., styled with <code>display:
none</code> or has <code>aria-hidden=&quot;true&quot;</code>.
</li>
<li>
The roles, states, and properties of all descendant elements remain visible to assistive
technologies except when the descendant element is a required part of the presentational
element. For example:
<ul>
<li>If the implied role of an element with role presentation is list, its listitem
children inherit the presentation role.</li>
<li>
If the implied role of an element with role <code>presentation</code> is <code>table</code>,
its <code>rowgroup</code> and <code>row</code> children inherit the <code>presentation</code>
role. And, in turn, the <code>colheader</code>, <code>rowheader</code>, and <code>cell</code>
children will then inherit the presentation role from their <code>row</code> or <code>rowgroup</code>
parents.
</li>
<li>
Note that a table contained in the cell of a table with role <code>presentation</code>
does not inherit the <code>presentation</code> role because the nested table is not a
required part of the presentational table.
</li>
</ul>
</li>
</ol>
<p>
The
<a href="examples/presentation/PresentationRole.html">
<code>presentation</code> role examples page
</a>
illustrates the effects of these rules in a variety of scenarios and provides more detailed
explanations of the rationale behind them.
</p>
</section>
</section>

<section id="children_presentational">
<h2>Roles That Automatically Hide Semantics by Making Their Descendants Presentational</h2>
<p>
Please provide feedback on this section in <a href="https://github.com/w3c/aria-practices/issues/178">issue 178</a>.
</p>
<p>
There are some types of user interface components that, when represented in a platform
accessibility API, can only contain text. For example, accessibility APIs do not have a way of
representing semantic elements contained in a button. To deal with this limitation, WAI-ARIA
requires browsers to automatically apply role <code>presentation</code> to all descendant
elements of any element with a role that cannot support semantic children.
</p>
<p>The roles that require all children to be presentational are:</p>
<ul>
<li>button</li>
<li>checkbox</li>
<li>img</li>
<li>math</li>
<li>menuitemcheckbox</li>
<li>menuitemradio</li>
<li>option</li>
<li>progressbar</li>
<li>radio</li>
<li>scrollbar</li>
<li>separator</li>
<li>slider</li>
<li>switch</li>
<li>tab</li>
</ul>
<p>For instance, consider the following tab element, which contains a heading.</p>
<pre>
&lt;li role=&quot;tab&quot;&gt;&lt;h3&gt;Title of My Tab&lt;/h3&gt;&lt;/li&gt;
</pre>
<p>
Because WAI-ARIA requires descendants of tab to be presentational,
the following code is equivalent.
</p>
<pre>
&lt;li role=&quot;tab&quot;&gt;&lt;h3 role=&quot;presentation&quot;&gt;Title of My Tab&lt;/h3&gt;&lt;/li&gt;
</pre>
<p>
And, from the perspective of anyone using a technology that relies on an accessibility API, such as a screen reader,
the heading does not exist since the previous code is equivalent to the following.
</p>
<pre>
&lt;li role=&quot;tab&quot;&gt;Title of My Tab&lt;/li&gt;
</pre>
<p>
See the
<a href="#presentation_role">
section about role <code>presentation</code>
</a>
for a detailed explanation of what it does.
</p>
</section>

<section id="appendices" class="appendix">
<h2>Appendices</h2>

Expand Down

0 comments on commit 5b94eb2

Please sign in to comment.