W3C home > Mailing lists > Public > public-pfwg@w3.org > March 2014

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

From: Dominic Mazzoni <dmazzoni@google.com>
Date: Tue, 25 Mar 2014 21:43:58 -0700
Message-ID: <CAFz-FYwenkD-C+nJvHK-FSCLL+x9=HtMk-KYHeknKqTefsF=Rw@mail.gmail.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
Cc: "W3C WAI Protocols & Formats" <public-pfwg@w3.org>
On Tue, Mar 25, 2014 at 5:08 PM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote:

> 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.
Glad you like the idea!

> 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.
I'm not sure this will be a problem, because it's the browser's job to
translate the selector to an element. On Windows, for example, a compliant
browser would expose aria-labelledby using IA2_RELATION_LABELLED_BY, with a
reference to the IAccessible2 object for the other element. On Mac it'd be
AXTitleUIElement. The testing tool can just verify the correct object is
linked to in the platform API - they don't need to actually evaluate the
query selector.

> 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?
Agreed, we'd have to support this - perhaps we'd have to allow a mix like
aria-labelledby="id1 id2 select(q3) select(q4) id5".

> 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.
Yes, this was why I was naively wondering if it might make sense to not tie
this to ARIA 1.1 or 2.0 at all, but write a separate spec in a community
group with the support of PF/APA and Web Components, with the intention of
integrating it into ARIA some time in the future. (The Web Speech API is an
example of a community group spec that got implemented relatively quickly,
without a formal working group.)

> I think we can coordinate a review with web components.
> Would you be able to come to Monday's ARIA call?
Sure, I'll be there.
Received on Wednesday, 26 March 2014 04:44:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:01 UTC