Illustrate how attributes and properties could be distinct concepts #1896
Conversation
This could be a potential solution to w3c#1895. The idea here would be to define all the ARIA attributes in terms of DOM/HTML types. This example shows what aria-orientation would look like defined as an enumerated attribute. And then separately define how identically-named ARIA properties end up using those attributes to compute their own state for use by AT. I think applying this throughout would resolve a lot of ambiguity and would help end up solving the reflect problem as well.
There was a problem hiding this comment.
Thanks for the start on this @annevk. I'd like to hear @spectranaut and @jnurthen's comments before progressing much further.
| <p>The <pref>aria-orientation</pref> attribute's <a>invalid value default</a> and <a>missing value default</a> are the undefined state. | ||
|
|
||
| <p class="note">In ARIA 1.1, the default value for <pref>aria-orientation</pref> changed from <code>horizontal</code> to <code>undefined</code>.</p> |
There was a problem hiding this comment.
These statements are seemingly in conflict unless we clarify the two different value concepts like "IDL value" and "accessibility internal value" (not particular to this name) ....
There was a problem hiding this comment.
Right, I was thinking we'd have a general distinction between "attribute" and "property" where the property is what AT computes the value of based on the "attribute". And I guess this note was about the "property" so should be moved a bit and clarified.
There was a problem hiding this comment.
I'm having trouble wrapping my head around this a bit, even though I do understand the problem you are trying to solve, IDL value/defaults vs "accessibility internal value"/defaults.
maybe we should use "implicit value" for the "Accessibility internal values"/defaults, as that is already what is in the role tables?
Maybe we should introduce some terms definitions in the PR so that it will be easier to understand where we are moving?
There was a problem hiding this comment.
oh one more thing, because I was just looking at #1894, and noticed here and there @annevk uses the phrase "AT value" or what the "AT computes" -- what we are really talking about here is what the BROWSER computes. The browser provides this "accessibility internal value" to the AT via the accessibility API for the platform: https://w3c.github.io/core-aam/#ariaOrientationHorizontal
Just wanted to make sure you understood that, @annevk :) There is nothing in the ARIA specs that specify what an AT does, only what information the browser passes on to the AT.
Also, I'm realizing, in this new language, the AAMs translate the "accessibility internal value" to the accessibility APIs, which we will also have to make clear, somehow.
There was a problem hiding this comment.
I was using that to encompass things that the browser specifically does for AT when AT is enabled, which is somewhat separate implementation-wise and also in terms of what we're comfortable exposing. Whereas reflecting is more general and will also function if AT isn't enabled.
There was a problem hiding this comment.
Yes, what we'd be talking about is not the default value of the DOM property, where el.ariaOrientation would always return undefined, but something like a new webdriver getter like computedAriaOrientation, or computedAccessibleNode.orientation where the default value on a range could be horizontal
| <p>The <pref>aria-orientation</pref> attribute's <a>invalid value default</a> and <a>missing value default</a> are the undefined state. | ||
|
|
||
| <p class="note">In ARIA 1.1, the default value for <pref>aria-orientation</pref> changed from <code>horizontal</code> to <code>undefined</code>.</p> |
There was a problem hiding this comment.
I'm having trouble wrapping my head around this a bit, even though I do understand the problem you are trying to solve, IDL value/defaults vs "accessibility internal value"/defaults.
maybe we should use "implicit value" for the "Accessibility internal values"/defaults, as that is already what is in the role tables?
Maybe we should introduce some terms definitions in the PR so that it will be easier to understand where we are moving?
|
|
||
| <p class="note">In ARIA 1.1, the default value for <pref>aria-orientation</pref> changed from <code>horizontal</code> to <code>undefined</code>.</p> | ||
|
|
||
| <p>The state of the <pref>aria-orientation</pref> property of an element <var>element</var> is computed as follows: |
There was a problem hiding this comment.
Now that you added the algorithm the "explicit value" for aria-orientation is in two places, the algorithm and the characteristic/value table for the relevant roles (see https://w3c.github.io/aria/#listbox). Maybe it doesn't need to be in two places? Or maybe for spec understandablity, it should be?
There was a problem hiding this comment.
You mean "Implicit Value for Role"? Yeah, I think we could remove that if we go down this path.
|
As per editors' call today, asking @spectranaut to make a suggestion on moving this forward. |
This could be a potential solution to #1895. The idea here would be to define all the ARIA attributes in terms of DOM/HTML types. This example shows what aria-orientation would look like defined as an enumerated attribute.
And then separately define how identically-named ARIA properties end up using those attributes to compute their own state for use by AT.
I think applying this throughout would resolve a lot of ambiguity and would help end up solving the reflect problem as well.
Closes #????
Describe Change Here!
PR tracking
Check these when the relevant issue or PR has been made, OR after you have confirmed the
related change is not necessary (add N/A). Leave unchecked if you are unsure. Read the
Process Document or
Test Overview for more information.
Implementation tracking
Preview | Diff