Get Accessibility Properties#1960
Conversation
| <tr> | ||
| <td><dfn>stale accessible reference</dfn> | ||
| <td>404 | ||
| <td><code>stale accessible reference</code> |
There was a problem hiding this comment.
Do we have confidence that the implementations will retain the difference between “was here but is now stale” and “not found for some other reason”? If not, the first 404 may suffice.
|
|
||
| <p> An <dfn>accessibility ID</dfn> is a string value representing a handle to an <a>accessible object</a> in a specific WebDriver session. | ||
|
|
||
| <p> <dfn>Accessibility properties</dfn> is a JSON <a>Object</a> that contains the relevant <a>WAI-ARIA states and properties</a> of an <a>accessible object</a>, as well as the following properties: |
There was a problem hiding this comment.
Not to downgrade ARIA, but it’s a subset here:
| <p> <dfn>Accessibility properties</dfn> is a JSON <a>Object</a> that contains the relevant <a>WAI-ARIA states and properties</a> of an <a>accessible object</a>, as well as the following properties: | |
| <p> <dfn>Accessibility properties</dfn> is a JSON <a>Object</a> that contains the relevant <a>accessibility properties</a> of an <a>accessible object</a>, as well as the following properties: |
There was a problem hiding this comment.
This suggestion is a bit tautological :)
I wonder if we should defined "computed accessibility properties" like we defined "computed role" in core-aam, and reference that...?
There was a problem hiding this comment.
From he API meeting yesterday, this will likely land in either Core-AAM as a formalized property list... Most will reference ARIA attribute concepts, but some, like size/bounds, ignored (maybe), clickable, etc. may be specified in Core-AAM or another relevant AAM.
| <dd>The <a>accessibility ID</a> of the parent of this <a>accessible object</a> in the <a>accessibility tree</a>, including <a>ignored accessible objects</a>. | ||
|
|
||
| <dt>"<code>children</code>" | ||
| <dd>A list of <a>accessibility IDs</a> representing the children of this <a>accessible object</a> in the <a>accessibility tree</a>, including <a>ignored accessible objects</a>. |
There was a problem hiding this comment.
| <dd>A list of <a>accessibility IDs</a> representing the children of this <a>accessible object</a> in the <a>accessibility tree</a>, including <a>ignored accessible objects</a>. | |
| <dd>A list of <a>accessibility IDs</a> representing the child nodes of this <a>accessible node</a> in the implementation’s <a>accessibility tree</a>. |
There was a problem hiding this comment.
I think we need a term for the implementation's accessibility tree that is not "accessibility tree", maybe "internal accessibility tree" or "computed accessibility tree", because "accessibility tree" alone is defined in ARIA and it basically means the platform API's tree.
| <dd>A list of <a>accessibility IDs</a> representing the children of this <a>accessible object</a> in the <a>accessibility tree</a>, including <a>ignored accessible objects</a>. | ||
| </dl> | ||
|
|
||
| <p> <dfn>Ignored accessible objects</dfn> are accessible objects that represent <a>elements which are excluded from the accessibility tree</a>. The <a>accessibility properties</a> of these <a>accessible objects</a> must only have the keys <va>accessibilityID</var>, <va>parent</var>, <va>children</var> and <va>role</var> set to <code>"none"</code>. |
There was a problem hiding this comment.
Ignored accessible children may not be implementable as written. The “ignored” state is usually on the non-accessibility rendered object which can—modulo implementation details—result in no backing accessibility node to return in the child list.
There was a problem hiding this comment.
good point, I think we don't need this definition using your definition above.
| <p>To <dfn>get a known accessible object</dfn> given <var>session</var> and <var>reference</var>: | ||
|
|
||
| <ol class="algorithm"> | ||
| <li><p>TO DO: Should we create a parallel to the specification of <a>get a known element</a>? Do we need to make a parallel structure to <a>browsing context group node map</a> and <a>node id map</a>? |
There was a problem hiding this comment.
I don’t think we need it, unless the element ID can’t be returned in the property bag.
| <p>The following terms are defined | ||
| in the Accessible Rich Internet Applications (WAI-ARIA) 1.2 specification: [[wai-aria-1.2]] | ||
| <ul> | ||
| <li><dfn><a href="https://w3c.github.io/aria/#dfn-accessible-object"></a>accessible object</dfn> |
There was a problem hiding this comment.
Maybe we should sync an ARIA edit with this PR?
There was a problem hiding this comment.
Right so I originally used "accessible object" everywhere because that is defined in aria and "accessibility node" is not defined anywhere. But given your other comments... I'm realizing we can't define things in terms of ARIA's "accessibility tree" because that (and "accessibility object") is defined in terms of the platform accessibility API. And we are talking about something else, here.
There was a problem hiding this comment.
To discuss in next week's API sync with @jcsteh et al.
| <li><dfn><a href="https://w3c.github.io/aria/#accessibility_tree">accessibility tree</a></dfn> | ||
| <li><dfn><a href="https://w3c.github.io/aria/#tree_exclusion">elements which are excluded from the accessibility tree</a></dfn> | ||
| <li><dfn><a href="https://w3c.github.io/aria/#introroles">WAI-ARIA role</a></dfn> | ||
| <li><dfn><a href="https://w3c.github.io/aria/#introstates">WAI-ARIA states and properties</a></dfn> |
There was a problem hiding this comment.
We’ll need a landing spot for the new “accessibility properties” ref above because this ARIA list is a subset.
spectranaut
left a comment
There was a problem hiding this comment.
First pass at fixes to your comments, @cookiecrook, but I still need to work on definitions and where they belong!
|
|
||
| <p> An <dfn>accessibility ID</dfn> is a string value representing a handle to an <a>accessible object</a> in a specific WebDriver session. | ||
|
|
||
| <p> <dfn>Accessibility properties</dfn> is a JSON <a>Object</a> that contains the relevant <a>WAI-ARIA states and properties</a> of an <a>accessible object</a>, as well as the following properties: |
There was a problem hiding this comment.
This suggestion is a bit tautological :)
I wonder if we should defined "computed accessibility properties" like we defined "computed role" in core-aam, and reference that...?
| <dd>A list of <a>accessibility IDs</a> representing the children of this <a>accessible object</a> in the <a>accessibility tree</a>, including <a>ignored accessible objects</a>. | ||
| </dl> | ||
|
|
||
| <p> <dfn>Ignored accessible objects</dfn> are accessible objects that represent <a>elements which are excluded from the accessibility tree</a>. The <a>accessibility properties</a> of these <a>accessible objects</a> must only have the keys <va>accessibilityID</var>, <va>parent</var>, <va>children</var> and <va>role</var> set to <code>"none"</code>. |
There was a problem hiding this comment.
good point, I think we don't need this definition using your definition above.
| <dd>The <a>accessibility ID</a> of the parent of this <a>accessible object</a> in the <a>accessibility tree</a>, including <a>ignored accessible objects</a>. | ||
|
|
||
| <dt>"<code>children</code>" | ||
| <dd>A list of <a>accessibility IDs</a> representing the children of this <a>accessible object</a> in the <a>accessibility tree</a>, including <a>ignored accessible objects</a>. |
There was a problem hiding this comment.
I think we need a term for the implementation's accessibility tree that is not "accessibility tree", maybe "internal accessibility tree" or "computed accessibility tree", because "accessibility tree" alone is defined in ARIA and it basically means the platform API's tree.
| <p>The following terms are defined | ||
| in the Accessible Rich Internet Applications (WAI-ARIA) 1.2 specification: [[wai-aria-1.2]] | ||
| <ul> | ||
| <li><dfn><a href="https://w3c.github.io/aria/#dfn-accessible-object"></a>accessible object</dfn> |
There was a problem hiding this comment.
Right so I originally used "accessible object" everywhere because that is defined in aria and "accessibility node" is not defined anywhere. But given your other comments... I'm realizing we can't define things in terms of ARIA's "accessibility tree" because that (and "accessibility object") is defined in terms of the platform accessibility API. And we are talking about something else, here.
See WICG/aom#203
Added/update sections:
To dos:
accessibility idThis change is
Preview | Diff