--- a/src/include/ack.html Thu May 01 09:24:30 2014 -0700
+++ b/src/include/ack.html Thu May 01 09:50:51 2014 -0700
@@ -19,7 +19,7 @@
<section id="Contributors">
<h3>Contributors</h3>
<p>The following individual(s) were previously active members of the working group or otherwise significant contributors.</p>
- <p>Tab Atkins, Jesse Bunch, Chris Fleizach, Lachlan Hunt, Sangwhan Moon, Ryosuke Niwa, Rich Simpson.</p>
+ <p>Tab Atkins, Jesse Bunch, Chris Fleizach, Lachlan Hunt, Bradley Meck, Sangwhan Moon, Ryosuke Niwa, Rich Simpson.</p>
</section>
<!-- todo: Add link to original proposal by James/Chris at http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html -->
<section id="ack-funders">
--- a/src/indie-ui-context.html Thu May 01 09:24:30 2014 -0700
+++ b/src/indie-ui-context.html Thu May 01 09:50:51 2014 -0700
@@ -247,9 +247,9 @@
/*
When the author first attempts to check the setting, the user agent will
- determine that this is a restricted setting, and immediately return false, so
- the first call to this method on the initial page load will never result in
- audio descriptions being enabled.
+ determine that this is a restricted setting, and immediately return the default
+ value or null, so the first call to this method on the initial page load will
+ never result in audio descriptions being enabled.
Note: The immediate return is critical to prevent blocking threads, as well as
eliminating potential abuse by fingerprinting scripts attempting to determine
@@ -999,7 +999,7 @@
<dd>Yes</dd>
<dt>Returns</dt>
- <dd>Boolean indicating whether or not a screen reader is currently active or in use (<code>true</code>), or <code>false</code> otherwise.</dd>
+ <dd>Boolean value indicating whether or not a screen reader is currently active or in use (<code>true</code>), or <code>false</code> otherwise.</dd>
<dt>Restriction Category (IDL)</dt>
<dd data-transform="linkRestrictionCategory">userScreenReaderSettings</dd>
--- a/src/indie-ui-events.html Thu May 01 09:24:30 2014 -0700
+++ b/src/indie-ui-events.html Thu May 01 09:50:51 2014 -0700
@@ -443,8 +443,6 @@
<section id="UIFocusRequestEvent" class="normative">
<h3>Interface UIFocusRequestEvent</h3>
- <p class="ednote">Will probably need an ARIA 1.1 or 2.0 role for palette.</p>
-
<dl title="[Constructor(DOMString typeArg, optional UIFocusRequestEventInit dictUIFocusRequestEventInit)] interface UIFocusRequestEvent : UIRequestEvent" class="idl">
<dt>readonly attribute FocusRequestFocusType focusType</dt><dd></dd>
</dl>
@@ -504,21 +502,24 @@
<li>Cancelable: Yes</li>
<li>Context Info: <code>focusType</code> (one of directional focusType string)</li>
</ul>
+ <p class="note">On most desktop platforms, directional focus may be triggered by keyboard arrow keys. For example, in a spread sheet or other grid-based application, arrow keys allow the user to navigate vertically within a column, or horizontally within a row.</p>
</dd>
<dt id="linearfocusrequest">Linear Focus Request (<code class="event">linearfocusrequest</code>)</dt>
<dd>
- <p>Initiated when the user agent sends a "linear focus" request to the web application. Web authors SHOULD NOT use or register for <code>linearfocusrequest</code> events when standard browser focus and blur events are sufficient. This event type is only necessary on specialized control types such as data grids where the logical next element may not be focusable or even in the DOM until requested. Using these events unnecessarily could result is reduced performance or an other negative user experience.</p>
+ <p>Initiated when the user agent sends a "linear focus" request to the web application. Web authors SHOULD NOT use or register for <code>linearfocusrequest</code> events when standard browser focus and blur events are sufficient. This event type is only necessary on specialized control types such as data grids where the logical "next" or "previous" element may not be focusable or even in the DOM until requested. Using these events unnecessarily could result is reduced performance or an other negative user experience.</p>
<ul>
<li>Bubbles: Yes</li>
<li>Cancelable: Yes</li>
<li>Context Info: <code>focusType</code> (one of linear focusType strings)</li>
</ul>
+ <p class="note">On most desktop platforms, linear focus may be triggered by <kbd>Tab</kbd> (focus next in linear order) and <kbd>Shift+Tab</kbd> (focus previous in linear order). </p>
</dd>
<dt id="palettefocusrequest">Palette Focus Request (<code class="event">palettefocusrequest</code>)</dt>
+ <p class="ednote">Will possibly need an ARIA 1.1 or 2.0 role for palette. Note: palettes are sometimes referred to as non-modal dialogs or inspector windows, but not always, and the definition should not include "sometimes." If we can't come up with a less vague definition and common interaction that doesn't trample a native one (ex. Cmd+tilde on Mac), we may have to drop this event.</p>
<dd>
- <p>Initiated when the user agent sends a "palette focus" request to the web application. Web app authors receiving this event SHOULD move focus to the first palette in the web application, or cycle focus between all available palettes. Note: palettes are sometimes referred to as non-modal dialogs or inspector windows.</p>
+ <p>Initiated when the user agent sends a "palette focus" request to the web application. Web app authors receiving this event SHOULD move focus to the first palette in the web application, or cycle focus between all available palettes.</p>
<ul>
<li>Bubbles: Yes</li>
<li>Cancelable: Yes</li>