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

I'm very supportive of what I've seen from [the gist](https://gist.github.com/alice/15ac1f8f147bc0648957ccd52e6de928), specifically, not having special accessibility events, and instead surfacing requests that come through an AT as normal (indistinguishable, and thus not special-cased) keyboard events.

..and the [explainer](https://github.com/WICG/aom/blob/HEAD/explainer.md) is looking good as well; love the helpful code samples and usage descriptions! I just have a few comments at this point.

* In the section on [reflecting ARIA attributes](https://github.com/WICG/aom/blob/HEAD/explainer.md#reflecting-aria-attributes), I wonder if there will be any planned semantic difference between the exposed aria attributes in the DOM on HTML elements vs the ones proposed for ShadowRoot objects? I couldn't quite tell from the explainer, because the examples did not use any common aria attributes :-). E.g., would `ariaChecked` reflect as a string for HTML Elements, but as a Boolean for ShadowRoot objects? This really got interesting when reading the next section on [IDRef reflection](https://github.com/WICG/aom/blob/HEAD/explainer.md#use-case-2-setting-relationship-properties-without-needing-to-use-idrefs), because I wondered what `ariaActiveDescendant` would report on the ShadowRoot after being set to a value using `ariaActiveDescendantElement`. (I suspect certain aria reflecting attributes just wouldn't be present on the ShadowRoot, but it seems like having an `ariaActiveDescendantElement` assignment would be useful in other scenarios as well, so I'm hopeful these can be rationalized together to avoid inconsistencies between the ShadowRoot's set of exposed properties and the HTML Element's set.
* Another thing to consider for assigning default accessibility state to a custom element is [this trend toward providing default styles](https://github.com/w3c/webcomponents/issues/468), which make use of an options dictionary. This is likely only an option if there's no need to subsequently change the default values, which runs contrary to your example... so merely something to think about.
* The [precedence rules suggested here](https://github.com/WICG/aom/blob/HEAD/explainer.md#precedence-between-string-based-and-element-based-relationship-properties) seem overly complicated. Instead, I would rather not expose the primitive "string-reflecting" property (because these can always be obtained through `getAttribute` anyway), and just make the DOM property reflect in only one-direction (downstream from the content attribute). This is how event handler attributes work (e.g., `onclick`). Consider:
   ```js
      // 'aria-labelledby' content attribute reflects down to the IDL attribute... 
      // ... 'ariaLabelledBy', but changes to the IDL attribute are not reflected back.
      // Ex: assume <button aria-labelledby="id1">
      let elem = button.ariaLabelledBy; // Returns the element found by IDRef "id1"
      // (or null if nothing found).
      button.ariaLabelledBy = someOtherElement;
      // The content attribute is unchanged (getAttribute('aria-labelledby') is 
      // still 'id1', but the true value as *reflected* in the IDL attribute has changed.```

There may be a better way to do this, but having both IDL attributes with precedence rules seems undesirable to me.
* Based on the lastest Gist, I'm not sure any of the section on [accessible events](https://github.com/WICG/aom/blob/HEAD/explainer.md#user-action-events-from-assistive-technology) is still relevant. Maybe remove that section from the explainer?
* In the section on [virtual accessibility nodes](https://github.com/WICG/aom/blob/HEAD/explainer.md#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?
* Also in the virtual accessibility nodes, won't virtual text nodes be needed? If so, perhaps the newer 'append', 'prepend', 'before', 'after' DOM APIs would be better for this non-legacy interface? (see [`ChildNode`](https://dom.spec.whatwg.org/#interface-childnode) and [`ParentNode`](https://dom.spec.whatwg.org/#interface-parentnode)
* The example of using the virtual accessibility tree hints at a cool feature: specialized accessibility nodes, e.g., like those for a role=table, which then have IDL for things like `colCount` and `rowcount`. Is there plan to make a hierarchical set of AccessibleNode objects? Are things like colCount and rowcount already provided via aria attributes?
* `ComputedAccessibleNode` still makes me uneasy. 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? I'm also not sure `getComputedStyle` is a great pattern to follow here...

-- 
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-420078157