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

Hi Dominic,

I don't see there being a backward compatibility issue with id either. I
actually like this a LOT. I like it as I am also looking to use ARIA to
drive CSS using attribute selectors in IBM. ... In other words to use ARIA
semantics as a base and to use attribute selection to drive style. We need
to make greater use of CSS selectors and reduce javascript usage to get the
necessary functionality. We also need to use a lot more CSS3. The net -
this saves code as, in your case, you only have to change tabindex and
activedescendant updates. ... that is slick.

The challenge is accessibility test tools. We would need to get
accessibility test tools to verify that the selector resolves to a valid
DOM Object. We also have to deal with mulitple IDREF <aria-labelledby =
"foo1" "foo2"> and where we cap testing of all the permutations. Perhaps
the WebComponents people have addressed this?

If you feel web components are going to be used a great deal we cannot wait
until ARIA 2.0 but understand that we have to hit the 2016 date. We, for
1.1, would need to cap the number of properties supported as we are on a
tight runway and push the bulk off to ARIA 2.0. IOW we need to make sure we
can deliver the minimum necessary to fix webcomponents this go around.
Also, we could use your help in developing the test suite.

I think we can coordinate a review with web components.

Would you be able to come to Monday's ARIA call?

Rich

Rich Schwerdtfeger



From: Dominic Mazzoni <dmazzoni@google.com>
To: James Craig <jcraig@apple.com>
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, "W3C WAI Protocols &
            Formats" <public-pfwg@w3.org>
Date: 03/25/2014 06:40 PM
Subject: 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