Re: [w3ctag/design-reviews] Review Accessibility Object Model (#134)

Thanks for the thorough review! Responding point by point, as there is a bit of a moving target problem here :smirk: 

> not having special accessibility events, and instead surfacing requests that come through an AT as normal (indistinguishable, and thus not special-cased) keyboard events.

After recent discussions, we also plan to surface InputEvents for the AT actions which would cause keyboard events to fire: https://gist.github.com/alice/570307ab24765de14837be1da49e1f98 ("Option 1" in that write-up.)

> ... assigning default accessibility state to a custom element ...

This is discussed in more detail in https://github.com/WICG/aom/issues/127. 

TL;DR
- We are moving away from having default state set on the Shadow Root, and towards having it be a Custom Element API.
- This should allow setting *both* static default (a la default styles) values shared by all instances of a particular element, *and* non-reflected dynamic states specific to a single instance.
- The shape of the Custom Element API is being discussed in https://github.com/w3c/webcomponents/issues/758 and I think will be discussed more at TPAC.

> ... would  `ariaChecked` reflect as a string for HTML Elements, but as a Boolean for ShadowRoot objects? 

Per above, we are likely dropping the ShadowRoot reflection piece. So, `ariaChecked` will reflect as a string for elements only.

> ... IDRef reflection ...
 
There has been a long discussion at https://github.com/whatwg/html/issues/3515 about IDREF reflection, with the result that I think we'll no longer have both string and element versions for relationship attributes.

> I'm not sure any of the section on accessible events is still relevant. Maybe remove that section from the explainer?

Agreed!

> In the section on virtual accessibility nodes, why are offset* properties included? These seem like a decidedly legacy [visual] styling concept that isn't terribly useful for an accessibility node?

Accessibility tree nodes have position attributes which are useful for multiple reasons:
- drawing outlines for sighted users to keep track of where AT focus is
- supporting "[touch exploration](https://support.google.com/accessibility/android/answer/6006598?hl=en)" modes

I'm not sure what you mean by "legacy" - what would the non-legacy version be?

> Also in the virtual accessibility nodes... perhaps the newer 'append', 'prepend', 'before', 'after' DOM APIs would be better for this non-legacy interface?

I'm not quite sure I follow the logic, sorry (but thanks for the pointers). Is this because append/prepend can take a DOMString? I'm not sure we've thought deeply about what virtual text nodes will be like.

Either way, happy to harmonise with newer APIs.

> Is there plan to make a hierarchical set of AccessibleNode objects? 

Good question. I'm not sure we've reached any kind of agreement on this yet - I think there were some competing options for how to support polymorphism in AccessibleNode objects.

> Are things like colCount and rowcount already provided via aria attributes?

Yup! Have a look at the supported properties on https://www.w3.org/TR/wai-aria-1.1/#table and https://www.w3.org/TR/wai-aria-1.1/#row

> I wonder what unique set of state is missing that would be surfaced via such a node, but isn't already discoverable via planned "reflected" aria properties and their relationships in aria relational properties?

For example:

```html
<button id="banana">Banana</button>
```

```js
console.log(banana.role);            // empty string - no ARIA role is set

let accessibleBanana = await getComputedAccessibleNode(banana);
console.log(accessibleBanana.role);  // "button"
```

Additionally, ARIA has a set of rules about when roles and attributes do and don't apply. 

For example, I can put an `aria-rowcount` attribute on a button element, but it won't be exposed in the accessibility tree, because `aria-rowcount` only applies to tables.

>  I'm also not sure `getComputedStyle` is a great pattern to follow here...

Would you be able to elaborate on this? Obviously we're not directly copying `getComputedStyle`, since it's an asynchronous API, but it was more to provide an analogy for the relationship between the specified semantic properties and the computed node - but definitely interested in pitfalls to avoid.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/134#issuecomment-420102289