Core-AAM: Add Computed Accessibility Properties section - #2800
Core-AAM: Add Computed Accessibility Properties section#2800spectranaut wants to merge 22 commits into
Conversation
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
🚀 Deployed on https://deploy-preview-2800--wai-aria.netlify.app |
|
Hi @jcsteh, @cookiecrook, @rahimabdi, @lucasradaelli -- this is ready for review based on the feedback from yesterday's meeting. Here is a link to the added section I only included "Computed Accessibility Properties" for the following rows:
Let me know what you think of this list, we can remove or add things! |
| </ol> | ||
| </aside> | ||
| <p> | ||
| When the state or property does not have a default value other than undefined, is not required on a given role, and is missing, undefined, or set to a invalid token, user agents MUST NOT include it the computed accessibility properties. When a state or property has a default value other than undefined and is supported but not required on a given role, user agents MAY include it in the computed accessibility properties. |
There was a problem hiding this comment.
An alternative (or addition) to the "MAY" case here is something like:
"When a state or property has a default value other than undefined, is supported but not required on a given role and is not mapped on all platforms, user agents MUST NOT include it in the computed accessibility properties."
This would mean that we have a clear rule for aria-required="false", for example: we do not include it in the property bag.
That said, I see you already have "Do not expose required" for aria-required="false". Does that already fit one of the rules here and I'm just missing it?
There was a problem hiding this comment.
Hmm.. right. So below, in the tables, when something is not mapped, it seems to make sense to write "Do not expose". I guess, without thinking about it too clearly, it seemed like I didn't have to put the case you suggested into the prose because it would always be covered below.
But I suppose it's fine to be overly pedantic, this is a technical specification, I'm going to include your sentence (and the "may") for now.
|
I've converted this to draft because I'm working on moving the definition of accessibilityID, parent and child here per webdriver reviewer's request: w3c/webdriver#1960 (comment) |
969a173 to
939cdb2
Compare
|
Ok, @cookiecrook @janewman @rahimabdi @cyns - I'd really appreciate another look at this section: https://deploy-preview-2800--wai-aria.netlify.app/core-aam/index.html#computed_accessibility_properties As mentioned above, the webdriver reviewer requested that the definition of these concepts be owned outside of webdriver, so that they can be referred to by webdriverBiDi as well. So here is my first attempt at doing that. I had to add a definition of "accessibility node" and "accessibility node ID" which I'm particularly unsure about, so review of those specifically would be appreciated. |
lolaodelola
left a comment
lolaodelola
left a comment
There was a problem hiding this comment.
LGTM bar one editorial comment I have about readability below.
| <section id="computed_accessibility_properties"> | ||
| <h2>Computed Accessibility Properties</h2> | ||
| <p> | ||
| The computed accessibility properties are a set of platform-independent key/value pairs of strings that represent the states and properties of any <a href="#dfn-accessible-object" class="specref">accessible object</a> in the <a>accessibility tree</a>. The computed accessibility properties are exposed primarily for the purposes of developer tools, specification conformance, and interoperability testing. Because the term <a href="#dfn-accessible-object" class="specref">accessible object</a> is used to refer to a node in a specific platform accessibility API, and the computed accessibility properties are properties of an intermediate platform-independent, implementation-defined abstraction used to back the various platform APIs, the term <dfn>accessibility node</dfn> will be used to refer to a node with the computed accessibility properties defined here. The tree of <a>accessibility nodes</a> follows the same rules as the <a>accessibility tree</a> and it is an exactly parallel structure to the platform accessibility API trees except where the Core-AAM specifies a difference for a specific accessibility API. |
There was a problem hiding this comment.
The third sentence is long and a little confusing, and ends up burying the lede a little. You've also already defined what the computed accessibility properties are in the first sentence. What about:
| The computed accessibility properties are a set of platform-independent key/value pairs of strings that represent the states and properties of any <a href="#dfn-accessible-object" class="specref">accessible object</a> in the <a>accessibility tree</a>. The computed accessibility properties are exposed primarily for the purposes of developer tools, specification conformance, and interoperability testing. Because the term <a href="#dfn-accessible-object" class="specref">accessible object</a> is used to refer to a node in a specific platform accessibility API, and the computed accessibility properties are properties of an intermediate platform-independent, implementation-defined abstraction used to back the various platform APIs, the term <dfn>accessibility node</dfn> will be used to refer to a node with the computed accessibility properties defined here. The tree of <a>accessibility nodes</a> follows the same rules as the <a>accessibility tree</a> and it is an exactly parallel structure to the platform accessibility API trees except where the Core-AAM specifies a difference for a specific accessibility API. | |
| The computed accessibility properties are a set of platform-independent key/value pairs of strings that represent the states and properties of any <a href="#dfn-accessible-object" class="specref">accessible object</a> in the <a>accessibility tree</a>. The computed accessibility properties are exposed primarily for the purposes of developer tools, specification conformance, and interoperability testing. | |
| The term <dfn>accessibility node</dfn> will be used to refer to a node with the computed accessibility properties defined here, as the term <a href="#dfn-accessible-object" class="specref">accessible object</a> is currently used to refer to a node in a specific platform accessibility API. | |
| The tree of <a>accessibility nodes</a> follows the same rules as the <a>accessibility tree</a> and it is an exactly parallel structure to the platform accessibility API trees except where the Core-AAM specifies a difference for a specific accessibility API. |
There was a problem hiding this comment.
Thanks Lola! I incorporated your suggestion and modified it, if you want to take a look.
spectranaut
changed the title
| <tr> | ||
| <th>Computed Accessibility Property</th> | ||
| <td> | ||
| Do not expose <code>checked</code>. |
There was a problem hiding this comment.
@rahimabdi @spectranaut Substantive: would this conflict with the IDL structure? Should we treat this as exposing the default value rather than not exposing?
Ditto for several listed in this PR as "Do not expose [x]."
There was a problem hiding this comment.
I think the idea is that if there is a default value, like "false", then that should be exposed, and that is covered by the table for aria-checked="false". So this is only the scenario where it is explicitly not set, or missing on something that doesn't have a default value of a specific token.
Co-authored-by: James Craig <cookiecrook@users.noreply.github.com>
6 participants
🚀 Netlify Preview:
🔄 this PR updates the following sspecs: