Re: Agenda: March 24, 2014 WAI-PF ARIA Caucus

On Mon, Mar 24, 2014 at 12:04 AM, James Craig <jcraig@apple.com> wrote:

> Just a reminder to Dominic and others to please send requests like this
> into the main email list, formal comments email, W3C Tracker (you’re a WG
> member), or even the Bugzilla tracker.
>

Sure, no problem.

> Wants to form an effort to deal with ID references from DOM to
> WebComponent (http://www.w3.org/TR/components-intro/) subdom. How to
> handle (process-wise).   e.g.: You can't do use aria-activedescendant to
> reference an id in a descendant of a web component.
>

I don't necessarily want to form a new effort, but my question was what
would be the best home for this. I can see this as something that could be
solved in this group, with a bit of help from components, or it be solved
by that group. My worry was about timeline - web components is already
shipping, and I'm worried that without a fix we won't have a good way to
solve a bunch of real accessibility problems we're encountering.


> I’ve been thinking about the (long-term) possibility of leveraging
> document.querySelector for this and other attributes that are currently
> IDREF-based. It would make a lot of things easier, but it would be more
> difficult to have a reflected content attribute, or to connect this in
> declarative markup.
>
> You could still use IDREFs.
>
>     tree.ariaActiveDescendant = tree.querySelector('#foo');
>
> But it’d be possible to point to elements that did not have a defined ID.
>
>     tree.ariaActiveDescendant =
> tree.querySelector('[aria-selected="true"]');
>

I hadn't thought about it this way. I was assuming that we'd have to solve
this with declarative markup, so I was assuming we'd do something like
<input aria-activedescendant="querySelector('[aria-selected="true"]')">,
but we certainly don't have to. Considering that most of the cases where
we'd need this are in dynamic content and not static, it's less important
to expose ARIA in an attribute.

I’m not sure we should open up a property on Element for every ARIA
> attribute though.


Why not? I've heard this idea discussed before, and I'm not sure I
understand the objections. For cleanliness of design, perhaps Element could
inherit from a new AccessibleElement interface with ARIA attributes defined
there - that way the Element idl can remain small.

Maybe something more general like a setReference method:
>
>     // Dialog is labelled by the first heading inside it plus the value of
> the global element with class username.
>     dialog.setReference("aria-labelledby", [
>         dialog.querySelector('*:role(heading)’),
>         document.querySelector('.username’)
>     ]);
>

How about setAccessibleRelation?

How did you want to handle multiple relations, like if an element is
labeled by two or more elements?


> The main drawback I see is that there’d be no way to have a reflected DOM
> attribute, so it’d be a little harder for authors to see and debug. Dev
> tools could help with that, though.
>
>         <dialog aria-labelledby="???”>…</dialog>
>

This would certainly work. I think I could live with not having the
reflected DOM attribute if we reach consensus on this.

However, let's consider the alternative. Suppose we redefine the spec such
that anywhere we have an IDREF in an attribute, you're allowed to specify
some selector syntax. I'm proposing something like "querySelector(#foo)" or
something shorter like "select(#foo)". In theory this could break backwards
compatibility, but I think the odds that someone was using an id with the
name "select(#foo)" are pretty slim.

The advantage of this approach is that the selector would update
automatically, with no JavaScript required. For example, I could implement
a listbox like this:

<div role="listbox" aria-activedescendant="select([tabindex="0"])">
  <div role="option" tabindex=0>Apple</div>
  <div role="option" tabindex=-1>Orange</div>
  <div role="option" tabindex=-1>Banana</div>
</div>

Now when the selected item changes, all I need to do is update the
tabindex, and the activedescendant changes automatically. The browser would
implement this using its existing style recalculation logic, which already
knows when a document might have changed in such a way that a selector has
changed.

We may have to add separate syntax for a query selector relative to the
current element, vs relative to the document.

I forgot to connect the dots to Web Components, but this could use the
> cat/hat selectors or author-exposed pseudos to interact with the shadow DOM.


Yes, that's exactly the problem we were facing and what I had in mind.

To bring everyone else into the loop, the problem we're facing is when you
need to express an ARIA relationship between something in the embedding
document and something inside the shadow dom of a web component. You can't
use ids, because the shadow dom is scoped - but there is special
querySelector syntax (cat/hat) that lets you "jump inside" shadow dom and
reference elements that way.

I can present some specific examples of composite controls where we're
hitting this problem.

- Dominic