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

The WCAG accessibility testing tools today are only looking at the DOM so
we need to ensure that the querySelector resolves to an object. The web
accessibility testing tools check for matching ids in the DOM when there is
an  ID reference. They don't go to determine if there is an accessible
object that can be derived from the reference. So, we need to think about
that.

Glad you can come Monday. I will put it high up in the agenda. We are now
meeting at 10am pacific so it is a little more sane for west coasties.

Rich


Rich Schwerdtfeger



From:	Dominic Mazzoni <dmazzoni@google.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	"W3C WAI Protocols & Formats" <public-pfwg@w3.org>
Date:	03/25/2014 11:44 PM
Subject:	Re: Agenda: March 24, 2014 WAI-PF ARIA Caucus



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.