no getter part for phase 1

[asurkov]

There are at least three proposals for 'getter' of AccessibleNode interface, which is:

1. return validated value (current proposal)
2. return value that was set
3. return computed value.

Technically speaking all these three may be subsets of their preceding approaches, i.e. 3d includes 2nd, 2nd includes 1st.

#1 is simple and anticipated approach, but probably has no great application.

2nd is sort of funny because validation is often expected on setting, not on getting. Also the validation may done by 3d party tools, what makes it optional for phase 1.

I like 3d the most but it has perf concerns and not yet agreed how to address them.

So I'm not yet certain which approach should be taken. I suggest either to skip the get part from phase 1 at all, or alternatively go with 1st approach with a note that the behavior may be changed later in the phases. It makes sense to do the latter if majority of us thinks that having no get part is rather confusing, and it's better to return something than throwing exceptions.

[minorninth]

I think there are potentially more possibilities when you consider reflection of ARIA.

1a. Return validated value from AccessibleNode, ignoring ARIA 1b. Return validated value from AccessibleNode, but if that's not present, return validated value from corresponding ARIA attribute if set. 2a. Return value that was set, no validation, no ARIA. 2b. Return value that was set, but if that's not present, return value from corresponding ARIA attribute if set, but with no validation. 3a. Return computed value. (Has performance concerns.)

Can you clarify, do you have a preference between 1a and 1b?

[asurkov]

1b is a bridging approach between 1a and 3a, being a partial implementation of computed value. I like that 1b moves us towards to 3a, but definitely ARIA makes things more complicated. It's also not clear whether 1b is covering explicit ARIA only, but 1b can be split into 1ba and 1bc, which are about explicit and in-explicit ARIA correspondingly.

I think I would stick with 2a (no validation, no ARIA) for the start and then figure out where we want to be in the end to move further through other options. Frankly, I'd be also happy with 'throw on get' approach for now since phase 1 is all about setting if I understand it right.

[alice]

By "in-explicit ARIA" (i.e. implicit ARIA, I'm assuming), do you mean the default values for ARIA properties? If so, I don't think we need to worry about those - for the purposes of this API they can be thought of as a null value, which feeds into the computed value via those default values. i.e.

<custom-checkbox id="checkbox1" role="checkbox"></custom-checkbox>

console.log(checkbox1.accessibleNode.checked);  // null even if reflecting ARIA
checkbox1.getComputedAccessibleNode().then(axNode => console.log(axNode.checked));  // false

I agree that the bare minimum would be a write-only API which throws on get, and I think we should keep that in our pockets for if we can't come to a timely agreement on the reflection and validation issues (though we would still need to address precedence with ARIA, meaning explicitly the use of HTML attributes to set ARIA semantics).

I'd like to keep the discussion of reflection and precedence to #60, and the discussion of validation to #70 (I'll copy the relevant parts of #60 over there so we have it all in one place) - it would be good if we could all be up to speed on the arguments in #60 before our meeting tomorrow, as there was a lot of good input from people not in the editors' group.

Finally, I would like to propose that we explicitly state that runtime feature detection or validation are out of scope as use cases for the phase 4 API. However, development time activities like testing and console logging are within scope.

[asurkov]

This comment might be more suitable for issue #60.

I'd say if ARIA is mapped into AOM, then the users may expect that AOM handles implicit ARIA semantcis as well, at least I don't see a good reason why to ignore implicit ARIA on purpose, because if the user wanted original ARIA value, then getAttribute() is a way to go.