Re: [Custom] Custom elements and ARIA

Have you considered allowing ARIA attributes to be set on a shadow root.

The semantics would be that the browser uses the value of an ARIA attribute
on the (most recent) shadow root for an element, and only if it's not set
there will it fall back to the value of the attribute on the shadow host.

This seems to allow for the scenarios you outlined. (In the case of an
element restricting the possible values of an ARIA attribute, you would
incur a microtask-length delay in updating the (shadow) ARIA attribute in
response to an attributeChangedCallback, but this doesn't seem problematic?
At least the (shadow) ARIA attribute would never have an invalid/unexpected
value, merely its old value for slightly longer, and of course that delay
wouldn't be visible to the page - it would just see the unmodified value it
set on the shadow host, as for native elements.)

Nick




On 28 August 2014 00:42, Domenic Denicola <domenic@domenicdenicola.com>
wrote:

> TL;DR: we (Google) are trying to explain the platform with custom elements
> [1], and noticed they can't do ARIA as well as native elements. We would
> like to prototype a solution, ideally as a standardized API that we can let
> authors use too. (If that doesn't work, then we can instead add a
> non-web-exposed API that we can use inside Chrome, but that would be a
> shame.) A succinct statement of the problem is that we need some way to
> explain [3]. The rest of this mail explains the problem in great depth in
> the hopes other people are interested in designing a solution with me.
>
> Also, in the course of figuring all this out, I put together an intro to
> the relevant aspects of ARIA, which you might find useful, at [2].
>
> ## The problem
>
> Right now, custom elements can manually add ARIA roles and stoperties (=
> states or properties) to themselves, by setting attributes on themselves.
> In practice, this kind of allows them to have default ARIA roles and
> stoperties, but they are fragile and exposed in a way that is incongruous
> with the capabilities of native elements in this regard.
>
> For example, if we were to implement `<hr>` as a custom element, we would
> attempt to give it the separator role by doing `this.setAttribute("role",
> "separator")` in the `createdCallback`. However, if the author then did
> `document.querySelector("custom-hr").setAttribute("role", "menuitem")`,
> assistive technology would reflect our `<custom-hr>` as a menu item, and
> not as a separator. So **unlike native elements, custom elements cannot
> have non-overridable semantics**.
>
> Furthermore, even if the author wasn't overriding the role attribute,
> there would still be a difference between `<hr>` and `<custom-hr>`. Namely,
> `document.querySelector("hr").getAttribute("role") === null`, whereas
> `document.querySelector("custom-hr").getAttribute("role") === "separator"`.
> So **unlike native elements, custom elements cannot have default ARIA roles
> or stoperties without them being reflected in the DOM**.
>
> As another example, imagine trying to implement `<button>` as a custom
> element. To enforce the restriction to a role of either `button` or
> `menuitem`, the custom element implementation would need to use its
> `attributeChangedCallback` to revert changes that go outside those
> possibilities. And that of course only occurs at the end of the microtask,
> so in the meantime screen-readers are giving their users bad information.
> And even then, the experience of the attribute value being reverted for the
> custom element is not the same as that for a native element, where the
> attribute value stays the same but the true ARIA role as reflected to
> screenreaders remains `button`. So: **unlike native elements, custom
> elements cannot robustly restrict their ARIA roles to certain values**.
>
> Finally, consider how `<details>` synchronizes `aria-expanded` with the
> `open` attribute. To implement this with custom elements, you would use the
> `attributeChangedCallback` to set an `aria-expanded` attribute. But again,
> the author could change it via `setAttribute`, causing it to be
> out-of-sync. The takeaway here is that **unlike native elements, custom
> elements cannot reserve the management of certain stoperties for
> themselves**.
>
> In the end, trying to manage one's ARIA state HTML attributes is fragile,
> and lacks the conceptual stratification and the resultant power of the
> internal state/mutable HTML attribute approach used by native elements. [3]
> illustrates more drastically the differences between the internal state and
> the HTML elements in many representative cases.
>
> ## Discussion
>
> In my own musings, I came up with a few solutions [4], but they are pretty
> icky to program against. There are a few tough issues that emerge, e.g.
>
> - Do we allow programmatic changing of *all* elements roles/stoperties,
> e.g. via a new API `element.aria.role = "whatever"`, or do we want some
> kind of model that reserves that power for the author of the element code?
> The former allows bad things like a <hr> with role menuitem, but the latter
> makes for tricky programming.
>
> - If an element wants to manage some aspect of its ARIA state itself, e.g.
> restrict its role, how does that impact the rest of its ARIA stuff? E.g.,
> how can I signal that I want to manage aria-expanded, ignoring any
> attribute-setting that goes on, while at the same time allowing the author
> to mess with aria-hidden at will? Or even more complex, how can I signal
> that I want to have a default way of calculating aria-level, but if the
> author sets it, their value overrides it (until they removeAttribute)?
>
> - Trying for a declarative solution, e.g. `"aria-expanded": function () {
> return this.hasAttribute("open"); }` gets you 90% of the way there, but you
> need some way of triggering an "ARIA recalc." E.g. <details> would trigger
> an ARIA recalc when its open="" attribute changes, and h1 would trigger an
> ARIA recalc whenever its position within the document changes (because that
> potentially affects outline level), and input would trigger an ARIA recalc
> under any situation where a <datalist> could become associated with it. If
> you accept this premise, then who has the power to trigger an ARIA recalc?
> Who has the responsibility?
>
> I would welcome anyone else's ideas on solutions. The cases that need to
> be addressed are summed up, somewhat representatively, in [3]. If nobody is
> interested I'll probably just evolve my existing kinda-icky solutions, and
> code one of them into Chrome as a non-web-exposed API (or maybe expose it
> behind a flag).
>
> [1]: https://github.com/dglazkov/html-as-custom-elements
> [2]: https://gist.github.com/domenic/ae2331ee72b3847ce7f5
> [3]: https://gist.github.com/domenic/bc8a36d9608d65bd7fa9
> [4]: https://gist.github.com/domenic/4ddde9bdcb673c48f237
>