Review Accessibility Object Model

[travisleithead]

See: https://a11y-api.github.io/a11y-api/spec/

[marcoscaceres]

I would hold a little bit on this. We are still working through quite a few issues and I feel it's still premature to do a TAG review.

[triblondon]

Picked up at F2F Tokyo, agreed to defer until next F2F unless you want to bump it.

[triblondon]

@marcoscaceres Are we still holding on this?

[marcoscaceres]

Yes. But expect a big announcement in the next few days.

[slightlyoff]

Suggesting we close and re-open when there's an update. Thoughts, @marcoscaceres?

[dbaron]

Also, is there a URL to the current spec? Original URL is 404.

[LJWatson]

@dbaron the Phase 1 spec, and the repo

[marcoscaceres]

Deferring to @alice, as Alice will know best when the spec will be ready for review.

[triblondon]

@marcoscaceres @alice are you ready for this review yet?

[alice]

Phase 1 is definitely ready for a look, and is available to experiment with in Chrome Beta per these instructions: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-accessibility/UCfWokyvoj0

Your thoughts on the later phases (Phase 2 has a WIP draft; later phases are sketched out in concept only in the explainer) would also be welcome.

[travisleithead]

Super. We'll take a look at Phase 2 in one of our upcoming teleconferences. Thanks for getting back to us!

[torgo]

Taken up at Nice f2f.

[travisleithead]

OK, coming back to this review! TPAC was a great chance to sync up, so thanks for your time there! Some point-by-point follow-ups on your last comments:

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.)

I participated in the discussion. Outcomes to surface as input events' inputType sounds great.

The shape of the Custom Element API is being discussed in WICG/webcomponents#758 and I think will be discussed more at TPAC.

Yep, that was a spirited discussion. I'm hopeful that the ElementInternals will end-up with the right usage pattern, but that does sound like the right home for this stuff.

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" modes

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

I had this question answered when we chatted in-person. My understanding: if there will be a virtual a11y node, it must act as proxy for all the relevant state that would otherwise be on a regular Element. "Legacy" was just my way of grouping all pre-existing CSS-OM APIs. I hope we can help with the use-cases, but wondering if many of them can be addressed by the so-called "searchable invisible DOM" (which needs a better name BTW). Seems as if the virtual a11y node and related standarization of the a11y tree is still a way off, so not going to worry too much about it right now.

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

Ah, this is not what I expected. I thought the role IDL attribute might work more like input's type content attribute and IDL attribute (e.g., how the IDL attribute always returns the "computed" value). For custom-elements much of this might be made more sensical with the ElementInternals, but for other elements, I'd like to have the IDL attributes reflect/compute as much as possible--however I understand that might be much more complicated for certain types and there's an argument for consistency. But for role, I would really like to see that return a computed value!

[alice]

I thought the role IDL attribute might work more like input's type content attribute and IDL attribute (e.g., how the IDL attribute always returns the "computed" value).

I'm not sure I follow. The type IDL attribute returns the value of the type content attribute, except where that value is missing or invalid, in which case it returns the default value.

Computing the role can be complex; for example the ARIA 1.1 spec states:

When an explicit or inherited role of presentation is applied to an element with the implicit semantic of a WAI-ARIA role that has required owned elements, in addition to the element with the explicit role of presentation, the user agent MUST apply an inherited role of presentation to any owned elements that do not have an explicit role defined.

In terms of a code example, this means:

<table role="presentation">
  <tr>
    <td>All</td>
    <td>these</td>
  </tr>
  <tr>
    <td>elements</td>
    <td>are</td>
  </tr>
  <tr>
    <td colspan="2">presentational</td>
  </tr>
</table>

Because a table (grid) must own rows, and rows must own cells, the <table> element having a role of presentation means that every <tr> and <td> also has a role of presentation, instead of row or cell. So computing the role can involve a tree walk.

[travisleithead]

At Paris F2F: Discussed this further (the computed accessibility node concept). There is a strong parallel to the problems we've seen in Style computation and read-back problems that have long been a sore spot for performance. In this respect, my idea to read the role value and have it imply a computation is probably not a good idea. We're assuming that the computation of a single a11y node in the tree involves potentially global (document-wide) searches to resolve things like element ids to element instances (for certain ARIA properties), etc., so this model of having an operation that returns a promise seems right. So, cudos on your approach. We do have some feedback on the approach to do the read-back, especially around locality, e.g., the requested a11y node should be more directly requested from the node of interest:

banana.getA11yNode().then((n) => { console.log(n.role); });

[alice]

Thanks for the extra feedback!

I appreciate the suggestion about localising the getComputedAccessibleNode() call to the Node instance, but I was curious if you could provide some more context for that advice. We essentially intended to follow the model of getComputedStyle() more or less for consistency, so I'm interested in why we'd want to diverge, especially since AFAIK it'd be the first method on Node which returns a promise.

[domenic]

The getComputedStyle() design is very strange. My best guess for why it exists that way was that separate working groups produced the CSS APIs from the Node APIs, and they didn't want to collaborate and/or didn't have partial interface technology, so the CSS folks went with getX(someY) instead of someY.getX().

I don't think there's anything special about promise return types that makes using them a cause for caution.

So I tend to agree that putting it as a method on Node makes more sense. It's a classic consistency vs. goodness tradeoff, in some sense. But in this case it's not a big pattern we're contemplating consistency consistent with---just a single weird old API from the early days of the web.

[annevk]

I suspect getComputedStyle() was there because there was this idea of having different views for the same document. So each view would have its own method.

[alice]

Thanks for the explanations! We'll definitely take that advice on board - keeping it promise based and moving it to Node.

[travisleithead]

Hey Alice,

Thanks so much for sticking with us through the [long] review! We appreciate all the time you've spent (and continue to sped) revising the various AOM docs and adjusting and reacting to everyone's feedback. We are looking forward to continuing the discussion.

Regarding this particular issue, we think we've reached the end of our general feedback--that the design is trending in a good direction, and that it might be more productive to work on a review for a specific aspect of AOM once the spec reaches a good milestone for review. So, what we'd like to ask of you is to file a new TAG design-review issue for each "level" of AOM that is ready for more specific review.

We look forward to continued involvement in the AOM project. Thanks so much and thanks for "flying TAG"!