Show human-readable names for accessibility properties

Source/devtools/front_end/accessibility/AccessibilityStrings.js

+// Copyright (c) 2015 The Chromium Authors. All rights reserved.

[pfeldman, 2015/05/29 12:35:31]

TIL: no (c) as per http://dev.chromium.org/developers/coding-style.

[aboxhall, 2015/05/29 15:33:42]

Done.

+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+WebInspector.AXAttributes = {

[pfeldman, 2015/05/29 12:35:31]

Pleasr add a prefix matching the file name

[aboxhall, 2015/05/29 15:33:42]

Done.

+    "disabled" : {
+        name : "Disabled",
+        description : "If true, this element currently cannot be interacted with.",

[paulirish, 2015/05/27 05:33:32]

"Currently" always applies to these. 

The spec text has a slight advantage here:

[aboxhall, 2015/05/27 18:22:33]

I added "currently" to convey that it's a state rather than a property - i.e. it
might become operable in the future. Happy to take it out if you are convinced
it doesn't add anything.

[paulirish, 2015/05/27 23:25:32]

Yeah not a big deal. let's keep 'currently'

+        group : "AXGlobalStates"
+    },
+    "invalid" : {
+        name : "Invalid user entry",
+        description : "If true, this element's user-entered value does not conform to validation requirement.",
+        group : "AXGlobalStates"
+    },
+    "live" : {
+        name : "Live",

[paulirish, 2015/05/27 05:33:32]

"Live region"  since the rest are grouped under that full name?

[aboxhall, 2015/05/27 18:22:33]

Done.

+        description : "Whether and what type of live updates may be expected for this element.",

[paulirish, 2015/05/27 05:33:32]

s/type/priority   ?
Whereas atomic is the flavor of update, this is the priority of delivery, yeah?

[aboxhall, 2015/05/27 18:22:33]

Oh, good point. Done.

+        group : "AXLiveRegionAttributes"
+    },
+    "atomic" : {
+        name : "Atomic (Live Regions)",
+        description : "If this element may receive live updates, whether the entire live region should be presented to the user on changes.",

[paulirish, 2015/05/27 05:33:32]

add to the end? "… or just the changed nodes."

[aboxhall, 2015/05/27 18:22:33]

Done.

+        group : "AXLiveRegionAttributes"
+    },
+    "relevant" : {
+        name : "Relevant (Live Regions)",
+        description : "If this element may receive live updates, what type of updates should trigger a notification.",

[paulirish, 2015/05/27 05:33:32]

Let's add the sort of updates? 
"…what type of updates (additions, removals, text, all)…"

[aboxhall, 2015/05/27 18:22:33]

Not sure about this. It will look something like:
Relevant (live regions): `additions`
   ^
  [If this element may receive live updates, what type of updates should trigger
a notification.]

Since one of the four options will be presented to the right of the label, I'm
worried it might look a little redundant to have them in the tool tip as well.
What do you think?

[paulirish, 2015/05/27 23:25:32]

Maybe, but as I'm personally quite new to this stuff, having the extra context
really helps. Gives me something to google for like `live regions relevant
removals`

[aboxhall, 2015/05/27 23:45:34]

I really don't think this is the place to surface that type of information.
Googling `live regions relevant` will get you the list of potential values; once
we have in-place editing we can do autocompletions like in the CSS pane. Could
also do a follow-up CL to add descriptions to token values.

[paulirish, 2015/05/27 23:51:55]

ok

+        group : "AXLiveRegionAttributes"
+    },
+    "busy" : {
+        name : "Busy (Live Regions)",
+        description : "Whether this element or its subtree are currently being updated (and thus may be in an inconsistent state).",
+        group : "AXLiveRegionAttributes"
+    },
+    "root" : {
+        name : "Live region root",
+        description : "If this element may receive live updates, the root element of the containing live region.",
+        group : "AXLiveRegionAttributes"
+    },
+    "autocomplete" : {
+        name : "Has autocomplete",
+        description : "Whether and what type of autocomplete suggestions are currently provided by this element.",
+        group : "AXWidgetAttributes"
+    },
+    "haspopup" : {
+        name : "Has popup",
+        description : "Whether this element has caused some kind of pop-up (such as a menu) to appear.",
+        group : "AXWidgetAttributes"
+    },
+    "level" : {
+        name : "Level",
+        description : "The hierarchical level of this element.",
+        group : "AXWidgetAttributes"
+    },
+    "multiselectable" : {
+        name : "Multi-selectable",
+        description : "Whether a user may select more than one option from this widget.",
+        group : "AXWidgetAttributes"
+    },
+    "orientation" : {
+        name : "Orientation",
+        description : "Whether this linear element's orientation is horizontal or vertical.",
+        group : "AXWidgetAttributes"
+    },
+    "multiline" : {
+        name : "Multi-line",
+        description : "Whether this textbox may have more than one line.",
+        group : "AXWidgetAttributes"
+    },
+    "readonly" : {
+        name : "Read-only",
+        description : "If true, this element may be interacted with, but its value cannot be changed.",
+        group : "AXWidgetAttributes"
+    },
+    "required" : {
+        name : "Required",
+        description : "Whether this element is a required field in a form.",

[paulirish, 2015/05/27 05:33:32]

"Whether an input value is required for this element before its parent form may
be submitted."

[aboxhall, 2015/05/27 18:22:33]

I had something like that, and then I figured people know what a required field
is - the critical information is that it refers to that concept rather than some
other concept of "required".

[paulirish, 2015/05/27 23:25:32]

I added this because I think developers are still pretty unfamiliar with how a
browser prevents submit if a required field is empty.  (Since nearly everyone
does clientside validation). 

Here we implicitly say "you're going to prevent the user from going forward
unless this field is filled in. be SURE about that, b!"

[aboxhall, 2015/05/27 23:45:34]

They're not, though. This is just the semantic equivalent of putting a little
star next to the field. Using the HTML5 `required` attribute will do that, but
that's not necessary to trigger this property.

[paulirish, 2015/05/27 23:51:55]

You're telling me that we can end up with a computed a11y required value of
`true` and the form is still submittable? If that's the case, then the current
text is great.

[aboxhall, 2015/05/27 23:55:43]

Afraid so! Welcome to the wonderful world of semantics.

+        group : "AXWidgetAttributes"
+    },
+    "valuemin" : {
+        name : "Minimum value",
+        description : "For a range widget, the minimum possible value.",

[paulirish, 2015/05/27 05:33:32]

for this and the next, s/possible/allowed/

[aboxhall, 2015/05/27 18:22:33]

Done.

+        group : "AXWidgetAttributes"
+    },
+    "valuemax" : {
+        name : "Maximum value",
+        description : "For a range widget, the maximum possible value.",
+        group : "AXWidgetAttributes"
+    },
+    "valuetext" : {
+        name : "Value description",
+        description : "A human-readable version of the value of a range widget (where necessary).",
+        group : "AXWidgetAttributes"
+    },
+    "checked" : {
+        name : "Checked",
+        description : "Whether this checkbox, radio button or tree item is checked, unchecked, or mixed (e.g. has both checked and un-checked children).",
+        group : "AXWidgetStates"
+    },
+    "expanded" : {
+        name : "Expanded",
+        description : "Whether this element, or another grouping element it controls, is expanded.",
+        group : "AXWidgetStates"
+    },
+    "pressed" : {
+        name : "Pressed",
+        description : "Whether this toggle button is currently in a pressed state.",
+        group : "AXWidgetStates"
+    },
+    "selected" : {
+        name : "Selected",
+        description : "Whether the option represented by this element is currently selected.",
+        group : "AXWidgetStates"
+    },
+    "activedescendant" : {
+        name : "Active descendant",
+        description : "The descendant of this element which is active; i.e. the element to which focus should be delegated.",
+        group : "AXRelationshipAttributes"
+    },
+    "flowto" : {
+        name : "Flows to",
+        description : "Element to which the user may choose to navigate after this one, instead of the next element in the DOM order.",
+        group : "AXRelationshipAttributes"
+    },
+    "controls" : {
+        name : "Controls",
+        description : "Element or elements whose content or presence is/are controlled by this widget.",
+        group : "AXRelationshipAttributes"
+    },
+    "describedby" : {
+        name : "Described by",
+        description : "Element or elements which form the description of this element.",
+        group : "AXRelationshipAttributes"
+    },
+    "labelledby" : {
+        name : "Labeled by",
+        description : "Element or elements which may form the name of this element.",
+        group : "AXRelationshipAttributes"
+    },
+    "owns" : {
+        name : "Owns",
+        description : "Element or elements which should be considered descendants of this element, despite not being descendants in the DOM.",
+        group : "AXRelationshipAttributes"
+    },
+    "name": {
+        name : "Name",
+        description : "The computed name of this element.",
+        group : "Computed"
+    },
+    "role": {
+        name: "Role",
+        description: "The role of this element.",

[paulirish, 2015/05/27 05:33:32]

Can we offer a tad more than this? My attempt:

"The computed role of this element, indicating for assistive technology the
presentation and interaction processing model"

[aboxhall, 2015/05/27 18:22:33]

Yeah, I wrote these three in a hurry :)
My attempt: "Indicates the purpose of this element, such as a user interface
idiom for a widget, or structural role within a document."

[paulirish, 2015/05/27 23:25:32]

Perfekt.

+        group: "Computed"
+    },
+    "value": {
+        name: "Value",
+        description: "The value of this element.",

[paulirish, 2015/05/27 05:33:32]

"The value of this element, which may be a boolean, number, string, defined
token, etc."

[aboxhall, 2015/05/27 18:22:33]

Again, when its actual value is right next to the label, I think enumerating the
types it may take will be redundant. How about:
"The value of this element; this may be user-provided or author-provided,
depending on the element."

[paulirish, 2015/05/27 23:25:31]

Would rather see "developer" instead of "author". That said, I don't think that
we're going to provide much value (hah) trying to define "value" for people. 
I'm OK with whatever string for this. 

[aboxhall, 2015/05/27 23:45:35]

Totally agreed re: defining value (hence why I kinda phoned it in). Will change
to 'developer'.

+        group: "Computed"
+    }
+}