Skip to content

Commit 0a5f5f3

Browse files
cookiecrookpkra
andauthored
clarifying existing live region announcement behavior on creation/rendering of new live regions (#2116)
Closes #1216 Codifies existing UA behavior for live regions, especially in the context of creation and initial rendering, where only `alert` live regions are announced. Co-authored-by: pkra <pkra@users.noreply.github.com> Co-authored-by: Peter Krautzberger <p.krautzberger@gmail.com>
1 parent 638e8c5 commit 0a5f5f3

1 file changed

Lines changed: 46 additions & 26 deletions

File tree

index.html

Lines changed: 46 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -1454,6 +1454,13 @@ <h3>Landmark Roles</h3>
14541454
<section id="live_region_roles">
14551455
<h3>Live Region Roles</h3>
14561456
<p>The following <a>roles</a> are <a>live regions</a> and can be modified by <a href="#attrs_liveregions">live region attributes</a>.</p>
1457+
<p>
1458+
Typically, assistive technology will only convey <em>changes</em> to a live region, not the initial contents of a live region. To ensure content in a live region is announced, authors
1459+
SHOULD create a rendered but empty live region as early as possible (such as on page load), and then modify the content of the live region when the author expects changes to be spoken or
1460+
brailled. The exception to this live region convention is <code>alert</code>, due to system accessibility notifications events required for the role. While an <rref>alert</rref> is a live
1461+
region, its content is announced by assistive technology when the alert is rendered on the page and when the content changes.
1462+
<!-- Duplicate paragraph in #aria-live. Synchronize any changes to these paragraphs. -->
1463+
</p>
14571464
<ul>
14581465
<li><rref>alert</rref></li>
14591466
<li><rref>log</rref></li>
@@ -1481,13 +1488,13 @@ <h2>Definition of Roles</h2>
14811488
<div class="role-description">
14821489
<p>A type of <a>live region</a> with important, and usually time-sensitive, information. See related <rref>alertdialog</rref> and <rref>status</rref>.</p>
14831490
<p>
1484-
Alerts are used to convey messages that might be immediately important to users. In the case of audio warnings, alerts provide an accessible alternative for hearing-impaired users. The
1485-
<code>alert</code> <a>role</a> is applied to the element containing the alert message. An <code>alert</code> is a specialized form of the <rref>status</rref> role, which is processed as
1486-
an atomic <a>live region</a>.
1491+
Alerts are used to convey messages that will be immediately important to users. In the case of audio warnings, visibly displayed alerts provide an accessible alternative to audible
1492+
alerts for Deaf or hard-of-hearing users. Likewise, alerts can provide an accessible alternative to the visible alerts for blind, deaf-blind, or low-vision users, and others with certain
1493+
developmental disabilities. The <code>alert</code> <a>role</a> is applied to the element containing the alert message.
14871494
</p>
14881495
<p>
1489-
Alerts are assertive live regions, which means they cause immediate notification for assistive technology users. If the operating system allows, the <a>user agent</a> SHOULD fire a
1490-
system alert <a>event</a> through the accessibility API when the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> alert is created.
1496+
Alert is a special type of assertive live region that is intended to cause immediate notification for assistive technology users. If the operating system allows, the
1497+
<a>user agent</a> SHOULD fire a system alert <a>event</a> through the accessibility API when the alert is rendered.
14911498
</p>
14921499
<p>
14931500
Neither authors nor user agents are required to set or manage focus to an alert in order for it to be processed. Since alerts are not required to receive focus, authors SHOULD NOT
@@ -1587,6 +1594,10 @@ <h2>Definition of Roles</h2>
15871594
dialog. Authors SHOULD make alert dialogs modal by ensuring that, while the <code>alertdialog</code> is shown, keyboard and mouse interactions only operate within the dialog. See
15881595
<pref>aria-modal</pref>.
15891596
</p>
1597+
<p>
1598+
Alertdialog is a special type of dialog that is intended to cause an immediate, alert-level notification for assistive technology users. If the operating system allows, the
1599+
<a>user agent</a> SHOULD fire a system alert <a>event</a> through the accessibility API when the alert dialog is rendered.
1600+
</p>
15901601
<p>
15911602
Unlike <rref>alert</rref>, <code>alertdialog</code> can receive a response from the user. For example, to confirm that the user understands the alert being generated. When the alert
15921603
dialog is displayed, authors SHOULD set focus to an active element within the alert dialog, such as a form control or confirmation button. The <a>user agent</a> SHOULD fire a system
@@ -13645,9 +13656,9 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
1364513656
</p>
1364613657
<p>User agents MUST NOT expose <code>aria-errormessage</code> for an object with an <sref>aria-invalid</sref> value of <code>false</code>.</p>
1364713658
<p>
13648-
Authors MAY call attention to a newly rendered error message with a live region by either applying an <pref>aria-live</pref> property or using one of the
13649-
<a href="#live_region_roles">live region roles</a>, such as <rref>alert</rref>. A live region is appropriate when an error message is displayed to users after they have provided an
13650-
invalid value.
13659+
Authors MAY call attention to a new error message with a live region by modifying inserting the error message into the contents of a existing, rendered element with a
13660+
<a href="#live_region_roles">live region role</a>, such as <rref>alert</rref>. A live region notification is appropriate when an error message is displayed to users after they have
13661+
provided an invalid value.
1365113662
</p>
1365213663
<p>
1365313664
A typical message describes what is wrong and informs users what is required. For example, an error message might be,
@@ -13658,19 +13669,20 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
1365813669
&lt;!-- Initial valid state --&gt;
1365913670
&lt;label for="startTime"&gt; Please enter a start time for the meeting: &lt;/label&gt;
1366013671
&lt;input id="startTime" type="text" aria-errormessage="msgID" value="" aria-invalid="false"&gt;
13661-
&lt;span id="msgID" aria-live="assertive"&gt;&lt;span style="visibility:hidden"&gt;Invalid time: the time must be between 9:00 AM and 5:00 PM&lt;/span&gt;&lt;/span&gt;
13672+
&lt;span id="msgID" role="alert"&gt;&lt;/span&gt;
1366213673

1366313674
&lt;!-- User has input an invalid value --&gt;
1366413675
&lt;label for="startTime"&gt; Please enter a start time for the meeting: &lt;/label&gt;
1366513676
&lt;input id="startTime" type="text" aria-errormessage="msgID" aria-invalid="true" value="11:30 PM" &gt;
13666-
&lt;span id="msgID" aria-live="assertive"&gt;&lt;span style="visibility:visible"&gt;Invalid time: the time must be between 9:00 AM and 5:00 PM&lt;/span&gt;&lt;/span&gt;
13677+
&lt;span id="msgID" role="alert"&gt;Invalid time: the time must be between 9:00 AM and 5:00 PM&lt;/span&gt;
1366713678
</pre
1366813679
>
1366913680
<p class="note">
13670-
This example uses <code>aria-live="assertive"</code> to indicate that assistive technologies should immediately announce the error message rather than completing other queued
13671-
announcements first. This increases the likelihood that users are aware of the error message before they move focus out of the input.
13681+
This example uses <code>role="alert"</code> (which includes an implicit value of <code>aria-live="assertive"</code>) to indicate that assistive technologies will immediately announce
13682+
the error message rather than completing other queued announcements first. This increases the likelihood that users are aware of the error message before they move focus out of the
13683+
input.
1367213684
</p>
13673-
<p class="note">This state is being deprecated as a global state in ARIA 1.2. In future versions it will only be allowed on roles where it is specifically supported.</p>
13685+
<p class="note">This state has been deprecated as a global state in ARIA 1.2. It is only supported on <a href="#live_region_roles">live region roles</a>.</p>
1367413686
</div>
1367513687
<table class="def">
1367613688
<caption>
@@ -14459,37 +14471,45 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
1445914471
<pdef>aria-live</pdef>
1446014472
<div class="property-description">
1446114473
<p>
14462-
<a>Indicates</a> that an <a>element</a> will be updated, and describes the types of updates the [=user agents=], <a>assistive technologies</a>, and user can expect from the
14474+
<a>Indicates</a> that an <a>element</a> will be updated or modified, and defines the priority of updates the [=user agents=], <a>assistive technologies</a>, and user can expect from the
1446314475
<a>live region</a>.
1446414476
</p>
1446514477
<p>
1446614478
The <span>values</span> of this <a>attribute</a> are expressed in degrees of importance. When regions are specified as <code>polite</code>, assistive technologies will notify users of
1446714479
updates but generally do not interrupt the current task, and updates take low priority. When regions are specified as <code>assertive</code>, assistive technologies will immediately
14468-
notify the user, and could potentially clear the speech queue of previous updates.
14480+
notify the user of relevant modifications to the live region, and could potentially clear the speech queue of previous updates.
1446914481
</p>
1447014482
<p>
14471-
Politeness levels are essentially an ordering mechanism for updates and serve as a strong suggestion to user agents or assistive technologies. The value can be overridden by user agents,
14472-
assistive technologies, or the user. For example, if assistive technologies can determine that a change occurred in response to a key press or a mouse click, the assistive technologies
14473-
might present that change immediately even if the value of the <pref>aria-live</pref> attribute states otherwise.
14483+
Priority levels (<code>none</code>, <code>polite</code>, <code>assertive</code>) act as an ordering mechanism for updates and serve as a recommendation to user agents or assistive
14484+
technologies. The value can be overridden by user agents, assistive technologies, or the user. For example, if assistive technologies can determine that a change occurred in response to
14485+
a key press or a mouse click, the assistive technologies might present that change immediately even if the value of the <pref>aria-live</pref> attribute states otherwise.
1447414486
</p>
1447514487
<p>
14476-
Since different users have different needs, it is up to the user to tweak his or her assistive technologies' response to a live region with a certain politeness level from the commonly
14477-
defined baseline. Assistive technologies might choose to implement increasing and decreasing levels of granularity so that the user can exercise control over queues and interruptions.
14488+
Since different users have different needs, it is up to the user to tweak their assistive technologies' response to a live region. Assistive technologies might choose to implement
14489+
increasing and decreasing levels of granularity so that the user can exercise control over queues and interruptions.
1447814490
</p>
1447914491
<p>
14480-
When the [=ARIA/property=] is not set on an <a>object</a> that needs to send updates, the politeness level is the value of the nearest ancestor that sets the
14492+
When the [=ARIA/property=] is not set on an <a>object</a> that needs to send updates, the priority level is the value of the nearest ancestor that sets the
1448114493
<pref>aria-live</pref> attribute.
1448214494
</p>
1448314495
<p>
1448414496
The <pref>aria-live</pref> attribute is the primary determination for the order of presentation of changes to live regions. Implementations will also consider the default level of
14485-
politeness in a <a>role</a> when the <pref>aria-live</pref> attribute is not set in the ancestor chain (e.g., <rref>log</rref> changes are <code>polite</code> by default). Items which
14486-
are <code>assertive</code> will be presented immediately, followed by <code>polite</code> items. User agents or assistive technologies can choose to clear queued changes when an
14487-
assertive change occurs. (e.g., changes in an assertive region can remove all currently queued changes)
14497+
priority in a <a>role</a> when the <pref>aria-live</pref> attribute is not set in the ancestor chain (e.g., <rref>log</rref> changes are <code>polite</code> by default). Modifications to
14498+
live regions which are <code>assertive</code> will be presented immediately, followed by <code>polite</code> items. User agents or assistive technologies can choose to clear queued
14499+
changes when an assertive change occurs. (e.g., changes in an assertive region can remove all currently queued changes)
1448814500
</p>
1448914501
<p>
1449014502
When live regions are marked as <code>polite</code>, assistive technologies SHOULD announce updates at the next graceful opportunity, such as at the end of speaking the current sentence
14491-
or when the user pauses typing. When live regions are marked as <code>assertive</code>, assistive technologies SHOULD notify the user immediately. Because an interruption might disorient
14492-
users or cause them to not complete their current task, authors SHOULD NOT use the assertive value unless the interruption is imperative.
14503+
or when the user pauses typing. When live regions are marked as <code>assertive</code>, assistive technologies SHOULD immediately notify the user of modifications to the live region.
14504+
Because an interruption might disorient users or cause them to not complete their current task, authors SHOULD NOT use the <code>assertive</code> value unless the interruption is
14505+
imperative.
14506+
</p>
14507+
<p>
14508+
Typically, assistive technology will only convey <em>changes</em> to a live region, not the initial contents of a live region. To ensure content in a live region is announced, authors
14509+
SHOULD create a rendered but empty live region as early as possible (such as on page load), and then modify the content of the live region when the author expects changes to be spoken or
14510+
brailled. The exception to this live region convention is <code>alert</code>, due to system accessibility notifications events required for the role. While an <rref>alert</rref> is a
14511+
live region, its content is announced by assistive technology when the alert is rendered on the page and when the content changes.
14512+
<!-- Duplicate paragraph in #live_region_roles. Synchronize any changes to these paragraphs. -->
1449314513
</p>
1449414514
</div>
1449514515
<table class="def">

0 commit comments

Comments
 (0)