W3C home > Mailing lists > Public > public-pfwg@w3.org > October 2015

Fw: TPAC Face to Face (ARIA 2.0) From Dominic

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Wed, 21 Oct 2015 14:08:30 -0500
To: "W3C WAI Protocols & Formats" <public-pfwg@w3.org>
Message-ID: <OF8A8D4685.8D5D43D7-ON86257EE5.006916A3-86257EE5.006925CC@us.ibm.com>





Rich Schwerdtfeger
----- Forwarded by Richard Schwerdtfeger/Austin/IBM on 10/21/2015 02:07 PM
-----

From:	Dominic Mazzoni <dmazzoni@google.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS,
            surkov.alexander@gmail.com
Date:	10/21/2015 11:44 AM
Subject:	Re: TPAC Face to Face



Hi Rich,

Here's the doc on features I'd love to see in ARIA 2. This is several years
old now, note that some of these already made it into ARIA 1.1.

http://www.w3.org/WAI/PF/wiki/ARIA_2_Requirements

I think the ones that are still the most relevant are:

1. aria-focusproxy
4. Disjoint grids
6. Custom text editor (not based on contenteditable)
7. Use queryselector in addition to IDREF
8. aria-interactive (NOT the same as the one proposed to the group last
year that was only for tables/grids)

As for web components, the HUGE issue with them right now is that there's
no way to use any ARIA attributes that require an IDREF to reference an
element inside a component.

As an example, suppose that someone has created their own listbox component
using custom elements. They've defined new <my-listbox> and <my-option>
tags that can be used in HTML, for example:

  <my-listbox>
    <my-option>U.S. Dollar</my-option>
    <my-option>Mexican Peso</my-option>
    <my-option>Euro</my-option>
  </my-listbox>

Inside the shadow DOM of each of these custom elements is several HTML
elements that are used to implement it. Those inner elements need to use
ARIA features like aria-activedescendant in order to be accessible.

The problem is that you can't use aria-activedescendant to link an element
inside my-listbox to an element inside my-option because they're not in the
same tree scope. They're in the same document, but they don't share the
same global element ID namespace, by design - so that IDs inside components
don't conflict with IDs from the host document.

The easiest way to fix this would be to create a way ARIA properties could
be set via JavaScript, for example:

  element.ariaActiveDescendant = otherElement;

We don't have to solve the problem that way, that's just one possible
solution.

This is not theoretical - Firefox and Chrome are both shipping web
components, IE has committed to it, and multiple UI frameworks have started
using them.

Thanks!
- Dominic

On Wed, Oct 21, 2015 at 9:19 AM Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
        Hi Alex, Dominique,

        The new ARIA WG is meeting at TPAC in Japan next week. Please
        notice that we are looking at producing a common accessibility API
        for the Web and ARIA 2.0. In fact, we will be meeting with Web
        Components working group people in Japan. I know you have both
        expressed interest in APIs and also ARIA 2.0. If you are able to
        participate at the appropriate times there will be a call-in.

        https://www.w3.org/WAI/PF/wiki/Meetings/TPAC2015/ARIA


        I know Dominique has been patiently waiting on ARIA 2.0. I am
        trying to find the issues you wanted addressed on the ARIA wiki.
        Can you point me to the URL? Also, I have not looked at web
        components yet. What features to support web components do you
        think we need in ARIA 2.0?

        Best,
        Rich




  Rich Schwerdtfeger
Received on Wednesday, 21 October 2015 19:09:06 UTC

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