Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move practices from aria-practices.html to new content tree #2479

Merged
merged 12 commits into from
Sep 25, 2022
Merged

Move practices from aria-practices.html to new content tree #2479

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
224529a
Create practices directories and files
mcking65 Sep 6, 2022
a408e50
Add landmark regions practice content
mcking65 Sep 6, 2022
53269b7
Add names and descriptions practice content
mcking65 Sep 6, 2022
ff9e178
Move keyboard interface practice content
mcking65 Sep 24, 2022
0350f55
Remove keyboard interface practice content from aria-practices.html
mcking65 Sep 24, 2022
c969d4f
Move grid and table properties practice
mcking65 Sep 24, 2022
b6f37ef
Remove grid and table properties practice from aria-practices.html
mcking65 Sep 24, 2022
d9b30cb
Add introduction heading and section tags
mcking65 Sep 24, 2022
b7f229e
Move range properties practice
mcking65 Sep 25, 2022
56e03e1
Move hiding semantics practice
mcking65 Sep 25, 2022
deba639
move structural roles practice
mcking65 Sep 25, 2022
7e0a9d2
Revise to use unique file names
mcking65 Sep 25, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3,637 changes: 0 additions & 3,637 deletions aria-practices.html
View file
Open in desktop

Large diffs are not rendered by default.

492 changes: 492 additions & 0 deletions content/practices/grid-and-table-properties/grid-and-table-properties-practice.html
View file
Open in desktop

Large diffs are not rendered by default.

168 changes: 168 additions & 0 deletions content/practices/hiding-semantics/hiding-semantics-practice.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,168 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta content="width=device-width, initial-scale=1.0" name="viewport">
<title>Hiding Semantics with the Presentation Role</title>
</head>
<body>
<h1>Hiding Semantics with the <code>presentation</code> Role</h1>
<section>
<h2>Introduction</h2>
<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 tabs widget built using an HTML <code>ul</code> element.
</p>
<pre><code>
&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;
</code></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>
</section>

<section id="presentation_role_uses">
<h2>Common Uses of Role <code>presentation</code></h2>
<p>
Three common uses of role <code>presentation</code> are:
</p>
<ol>
<li>Hiding a decorative image; it is equivalent to giving the image null alt text. </li>
<li>Suppressing table semantics of tables used for layout in circumstances where the table semantics do not convey meaningful relationships.</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>

<section id="presentation_role_effects">
<h2>Effects of Role <code>presentation</code></h2>
<p>
When <code>role="presentation"</code> is specified on an element, if a
<a href="#presentation_role_ignored">condition that requires a browser to ignore the <code>presentation</code> role</a>
does not exist, it has the following three effects.
</p>
<ol>
<li>
The element’s implied ARIA role and any ARIA states and properties associated with that role are hidden from assistive technologies.
</li>
<li>
Text contained by the element, i.e., inner text, as well as inner text of all its descendant elements remains visible to assistive technologies.
Of course, text is explicitly hidden, e.g., styled with <code>display: none</code> or has <code>aria-hidden="true"</code> is not visible to assistive technologies.
</li>
<li>
The roles, states, and properties of each descendant element remain visible to assistive technologies unless the descendant requires the context of the presentational element.
For example:
<ul>
<li>
If <code>presentation</code> is applied to a <code>ul</code> or <code>ol</code> element, each child <code>li</code> element inherits the <code>presentation</code> role because ARIA requires the <code>listitem</code> elements to have the parent <code>list</code> element.
So, the <code>li</code> elements are not exposed to assistive technologies, but elements contained inside of those <code>li</code> elements, including nested lists, are visible to assistive technologies.
</li>
<li>
Similarly, if <code>presentation</code> is applied to a <code>table</code> element,
the descendant <code>caption</code>, <code>thead</code>, <code>tbody</code>, <code>tfoot</code>,
<code>tr</code>, <code>th</code>, and <code>td</code>
elements inherit role <code>presentation</code> and are thus not exposed to assistive technologies.
But, elements inside of the <code>th</code> and <code>td</code> elements, including nested tables, are exposed to assistive technologies.
</li>
</ul>
</li>
</ol>
</section>

<section id="presentation_role_ignored">
<h2>Conditions That Cause Role <code>presentation</code> to be Ignored</h2>
<p>Browsers ignore <code>role="presentation"</code>, and it therefore has no effect, if either of the following are true about the element to which it is applied:</p>
<ul>
<li>The element is focusable, e.g. it is natively focusable like an HTML link or input, or it has a <code>tabindex</code> attribute.</li>
<li>
The element has any
<a href="#global_states" class="specref">global ARIA states and properties</a>,
e.g., <code>aria-label</code>.
</li>
</ul>
</section>

<section id="presentation_role_examples">
<h2>Example Demonstrating Effects of the <code>presentation</code> Role</h2>
<p>In the following code, role <code>presentation</code> suppresses the list and list item semantics.</p>
<pre><code>
&lt;ul role=&quot;presentation&quot;&gt;
&lt;li&gt;Date of birth:&lt;/li&gt;
&lt;li&gt;January 1, 3456&lt;/li&gt;
&lt;/ul&gt;
</code></pre>
<p>When the above code is parsed by a browser, it is semantically equivalent to the following code:</p>
<pre><code>
&lt;div&gt;Date of birth:&lt;/div&gt;
&lt;div&gt;January 1, 3456&lt;/div&gt;
</code></pre>
</section>

<section id="children_presentational">
<h2>Roles That Automatically Hide Semantics by Making Their Descendants Presentational</h2>
<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>meter</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><code>
&lt;li role=&quot;tab&quot;&gt;&lt;h2&gt;Title of My Tab&lt;/h2&gt;&lt;/li&gt;
</code></pre>
<p>
Because WAI-ARIA requires descendants of tab to be presentational, the heading semantic is not exposed to assistive technology users.
Thus, the following code is equivalent.
</p>
<pre><code>
&lt;li role=&quot;tab&quot;&gt;&lt;h2 role=&quot;presentation&quot;&gt;Title of My Tab&lt;/h2&gt;&lt;/li&gt;
</code></pre>
<p>
So, from the perspective of anyone using a technology that relies on an accessibility API, such as a screen reader, the heading does not exist.
As described above in the section on
<a href="#presentation_role_effects">Effects of Role <code>presentation</code></a>,
the previous code is equivalent to the following.
</p>
<pre><code>
&lt;li role=&quot;tab&quot;&gt;Title of My Tab&lt;/li&gt;
</code></pre>
</section>

</body>
</html>
Loading