Codestin Search App

minorninth · 2017-03-14T22:40:30Z

No description provided.

alice

LGTM with tweaks.

alice · 2017-03-15T04:33:55Z

spec/index.html

+          attribute DOMString? roleDescription;

          // Accessible label and description.
          attribute DOMString? label;


Urgh, I thought we were going to get away from the whole labelledBy/labeledBy controversy here 😞

Urgh. Not sure what to do, there's no way to win.

I recall we discussed labelElement instead.

I didn't like making this the one glaring exception in otherwise very
straightforward translations from the ARIA attribute names. Any time we
deviate it's just adding confusion for users.

I guess labeledBy because it's different from ARIA but close enough that
it will confuse people.

I guess my preference would be to try to come up with a consistent way to
modify all of the relationship attributes, then, rather than making
labeledBy an exception.

Since it's a reference to an AccessibleNode and not a DOM element, maybe labelNode instead of labelElement?

We could add Node or Nodes to all of them to help convey whether they take a single reference or an array.

labelNode
descriptionNode
activeDescendantNode
controlledNodes
detailsNode
errorMessageNode
flowToNode
ownedNodes

alice · 2017-03-15T04:37:26Z

spec/index.html

+          and null otherwise. The validity of a property valid is specified in
+          greater detail below.
        </p>
        <p>


ARIA should win, as per my comment on the explainer.

@alice wrote:

~"ARIA wins"

Alice, which part of the explainer are you referencing? I recall us agreeing any value defined in AOM would override any content attribute (ARIA or otherwise).

alice · 2017-03-15T04:49:06Z

spec/index.html

-          Nearly all accessibility properties on the AccessibleNode interface have an
-          equivalent ARIA attribute. When they do, the mappings are very straightforward.
-          This table shows the mappings and indicates the ones that have different semantics
-          explained below.


This is awkwardly worded: perhaps "there's a 1:1 correspondence between the set of properties on AccessibleNode and the list of valid ARIA attributes from the WAI-ARIA 1.1 spec."?

alice · 2017-03-15T04:49:36Z

spec/index.html

-
      <table>
        <caption>
          <dfn>Accessibility property table</dfn>


Where's the rest of this?

I think the diff is a little confusing in GitHub. The table is complete, if you
expand above this it should make sense.

alice · 2017-03-15T04:53:25Z

spec/index.html

-          <code>label</code> and <code>description</code>
-          attributes directly if you want those to change.
+          Upon setting a property of AccessibleNode, no validation is
+          done. The user-provided value is simply stored. This is to


Is there a reason to do validation at read time rather than write time? Where does the invalid value live? Is it simply hidden from the accessor?

Yes, I think that's better for performance. We can always cache it at read
time, but the purpose is to ensure that if an author sets AccessibleNode
properties and doesn't try to read them back and accessibility is never enabled,
we don't waste any time even trying to validate them.

alice · 2017-03-15T04:56:22Z

spec/phase2.html

+        Phase 2: Accessible Actions
+      </h2>
+        <p>
+          In this phase, we extent AccessibleNode so that it's also an


typo s/extent/extend/

alice · 2017-03-15T05:16:48Z

spec/phase2.html

+        </pre>
+        <p>
+          Accessibility input events are needed for two reasons.
+          First, because it's possible to create AccessibleNodes


<ul> for the two reasons?

alice · 2017-03-15T05:17:20Z

spec/phase2.html

+              <th>event name</th>
+              <th>type</th>
+              <th>valid roles</th>
+              <th>fallback behavior</th>


We haven't discussed what fallback behaviour means before this table. Maybe "(see below)"?

alice · 2017-03-15T05:19:59Z

spec/phase2.html

+                <code>"scrollbar"</code>,
+                <code>"slider"</code>
+              </td>
+              <td>Change value of INPUT or TEXTAREA element</td>


This may need a little more explanation - how would a TEXTAREA be acting as a scrollbar or slider?

alice · 2017-03-15T05:20:19Z

spec/phase2.html

+              <td><code>"accessiblesetvalue"</code></td>
+              <td><code>AccessibleSetValueEvent</code></td>
+              <td>
+                <code>"scrollbar"</code>,


Incomplete/wrong list of roles?

Yes, I haven't updated the other phases much yet, I just moved them to
separate files.

cookiecrook

Did you make any substantive changes to Phases 2-4? If so, it's not obvious since those now show up as entirely new files .

cookiecrook · 2017-03-16T05:02:19Z

spec/index.html

      </section>
      <section id="inclusion">
        <h2>Criteria for Inclusion</h2>
-        <p>The first version of this specification is not intended to be complete. It is currently impossible to make some web features accessible, so the primary goal is to resolve immediate needs quickly for existing, inaccessible web interfaces. The specification editors are purposefully deferring many useful ideas in order to maintain a realistic timeline for highest priority features.</p>


Minor nit: "web" as an adjective should remain lower case like this: "web page", etc. However, as the proper noun ("the Web" or "the World Wide Web") should always be capitalized. It's pretty common for people to mis-interpret this as meaning all instances of the word "web" should be capitalized. Most uses are adjectives and should not be capitalized. 😉

Sorry, I should have clarified, but I deliberately did not make any changes
to phases 2 - 4 in this patch. I just moved them.

Fixed "Web".

cookiecrook · 2017-03-16T05:10:35Z

spec/index.html

+          <code>Element</code>.
        </p>
        <pre class="idl">
-          partial interface Node {


Didn't we have a long-term plan to use this on text nodes, too?

Yes, but not for phase 1

cookiecrook · 2017-03-16T05:11:29Z

spec/index.html

+          "grid",
+          "gridcell",
+          "group",
+          "heading",


Let's correct this errata from ARIA... "image"

Hmmm, I'm not so sure we want to use a different lexicon than ARIA here.
Is it worth it to confuse authors and force authors who try to make glue
code to translate things?

cookiecrook · 2017-03-16T05:16:36Z

spec/index.html

-          attribute double? rangeMax;
-          attribute double? rangeStep;
+          attribute double? valueNow;
+          attribute double? valueMin;


At the F2F, we changed these to rangeValue, etc because they were more clear. Is the goal just to reduce author adoption complexity despite the odd names of some ARIA properties?

Yeah, that's exactly the idea.

I guess some minor renaming could be okay, but not having a 1:1
correspondence significantly complicates this phase.

cookiecrook · 2017-03-16T05:21:03Z

spec/index.html

+          attribute boolean? pressed;

          // Control values.
-          attribute DOMString? value;


At the F2F, we normalized all variants of value (besides rangeValue) to a single "value" property. What's the need for a valueText property if we already have value. Also, I don't think we can remove value because it would be required for different field types (date, tel, etc). valueText appears to be future-limiting for the sole purpose of matching ARIA.

That was when we were hoping to expose the computed tree.
Maybe in the computed tree we can just expose one value.

Now that we've separated out the ideas of modifying accessibility
attributes in the DOM and getting their computed values, it makes
far more sense for Phase 1 to have parity with ARIA.

Parity with ARIA frees us up to not have to clearly define the semantics
for all of these attributes. Sure, it'd be nice to have a single "value", but
then what do you do if someone specifies both "value" and valueNow?
What about "value" and valueText?

My thinking now is that AccessibleNode in Phase 1 - 3 will be a strict superset of
ARIA, but then the computed accessible properties in Phase 4 can resemble the
native tree much more - i.e. "name", "description", etc.

cookiecrook · 2017-03-16T05:33:07Z

spec/index.html

@@ -308,11 +392,21 @@ <h3>
            <td><code>AccessibleNode</code></td>
            <td><code>aria-activedescendant</code></td>


cookiecrook · 2017-03-16T05:33:20Z

spec/index.html

          <tr>
            <td><code>autocomplete</code></td>
            <td><code>enum { "both", "inline", "list", "none" }?</code></td>
            <td><code><nobr>aria-autocomplete</nobr></code></td>


cookiecrook · 2017-03-16T05:34:39Z

spec/index.html

@@ -384,20 +497,40 @@ <h3>
            <td><code><nobr>aria-invalid</nobr></code></td>
          </tr>
          <tr>


labelElement

cookiecrook · 2017-03-16T05:35:16Z

spec/index.html

            <td><code><nobr>aria-readonly</nobr></code></td>
          </tr>
+          <tr>
+            <td><code>relevant</code></td>


liveRelevant

cookiecrook · 2017-03-16T05:36:22Z

spec/index.html

+          </tr>
+          <tr>
+            <td><code>valueText</code></td>
            <td><code>DOMString?</code></td>


IMO, this should be value for greater forward compatibility.

Split into 4 docs for 4 phases, give parity with ARIA

12f3afc

alice approved these changes Mar 15, 2017

View reviewed changes

Address some more straightforward feedback

efdb9ba

cookiecrook requested changes Mar 16, 2017

View reviewed changes

Address more feedback

42b4210

minorninth merged commit 467b0d2 into WICG:gh-pages Mar 17, 2017

		@@ -308,11 +392,21 @@ <h3>
		<td><code>AccessibleNode</code></td>
		<td><code>aria-activedescendant</code></td>

Conversation

minorninth commented Mar 14, 2017

Uh oh!

alice left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cookiecrook Mar 16, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cookiecrook left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

cookiecrook Mar 16, 2017 •

edited

Loading