W3C home > Mailing lists > Public > public-aria@w3.org > March 2016

[aapi] Minutes: UAI TF Meeting Tue, 15 March, 2016

From: Joanmarie Diggs <jdiggs@igalia.com>
Date: Tue, 15 Mar 2016 16:14:30 -0400
To: ARIA Working Group <public-aria@w3.org>
Cc: "wai-xtech@w3.org" <wai-xtech@w3.org>
Message-ID: <56E86D26.4010902@igalia.com>
Link: https://www.w3.org/2016/03/15-aapi-minutes.html

Plain text follows:

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

   Accessible Rich Internet Applications Working Group Teleconference

15 Mar 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/03/15-aapi-irc

Attendees

   Present
          Joseph_Scheuhammer, Bryan_Garaventa, Joanmarie_Diggs,
          AmeliaBR, Rich_Schwerdtfeger

   Regrets
   Chair
          Joseph_Scheuhammer

   Scribe
          Rich, joanie

Contents

     * [3]Topics
         1. [4]ACTION-1681 (Joseph, Amelia) Editorial change(s)
            clarifying inclusions rules and/or exclusion rules.
         2. [5]No meeting next week.
     * [6]Summary of Action Items
     * [7]Summary of Resolutions
     __________________________________________________________

   <clown> agenda: this

   <scribe> scribenick: joanie

ACTION-1681 (Joseph, Amelia) Editorial change(s) clarifying
inclusions rules and/or exclusion rules.

   JS: Amelia is here for this action.

   action-1681

   <trackbot> action-1681 -- Joseph Scheuhammer to Propose new
   wording, as an editorial change only to clarify the inclusion
   rules in section 5.1.2 -- due 2015-09-15 -- OPEN

   <trackbot> [8]http://www.w3.org/WAI/ARIA/track/actions/1681

      [8] http://www.w3.org/WAI/ARIA/track/actions/1681

   <clown>
   [9]http://w3c.github.io/aria/core-aam/core-aam.html#exclude_ele
   ments2

      [9] http://w3c.github.io/aria/core-aam/core-aam.html#exclude_elements2

   JS: This action is only a small slice of the issue.
   ... At the above spec URL, there is the excluding elements
   content.

   <clown> Elements with none or presentation as the first
   mappable role in the role attribute string, according to the
   rules for the none and the presentation role defined in
   Accessible Rich Internet Applications (WAI-ARIA) 1.1
   [WAI-ARIA].

   <AmeliaBR> Also related discussion here:
   [10]https://github.com/w3c/aria/issues/136

     [10] https://github.com/w3c/aria/issues/136

   JS: I noticed just recently that the first bullet point
   (above), has this catch-all that I missed.
   ... So what the Core AAM is doing is saying none/presentation
   is excluded.
   ... But this is modified by the rules in the spec.
   ... The advantage is that the statement in the Core AAM is
   always correct. :)
   ... The disadvantage is that one needs to consult with the spec
   to see what the state is.

   RS: (Asks about role-specific attributes)

   JS: Here is the spec text about global attributes.

   <clown> "the user agent MUST always expose global WAI-ARIA
   states and properties to accessibility APIs, even if an element
   has an explicit or inherited role of presentation."

   JS: (reads text above)
   ... So you want to add something for role-specific states and
   properties?

   RS: Yes.

   JS: Where?

   RS: If you have a layout table and wanted to give one of the
   rows the role of region, that's doable.
   ... And that would cause them to be included.
   ... And that's covered in the spec.
   ... We need to cover both roles and their states and
   properties.
   ... We need to say if you have any role attribute, whether
   inherited or not, it is included in the tree.

   ABR: This gets into the issue they had with the HTML mapping.
   ... A div/span without a role, but an aria-label needs a role
   change to be included in the tree.

   JS: Firefox always includes divs even without a label.

   CS: IE did as well; I don't think Edge does.

   JS: So non-interoperability.

   ABR: I'm not sure we want to recommend every div in a document
   gets exposed.
   ... That would be painful in some documents.

   JS: Let's say all divs are not, but if you add a label it must
   be included.
   ... In the case of ATK, the role would have ROLE_SECTION and a
   label.

   CS: It's group in UIA and IA2, I think.

   <AmeliaBR> [11]http://w3c.github.io/aria/html-aam/html-aam.html

     [11] http://w3c.github.io/aria/html-aam/html-aam.html

   <cyns_>
   [12]http://rawgit.com/w3c/aria/master/html-aam/html-aam.html

     [12] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html

   <clown>
   [13]http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el
   -div

     [13] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-div

   JS: They do have, for IA2 and ATK, may not have accessible
   object if there is no semantic meaning; otherwise it's a
   section.
   ... But if it's included due to the presence of a label, and
   there's not another role, it's ROLE_SECTION.

   ABR: There's the general issue of which element should be
   included or excluded.
   ... Another issue is if you're forcing something to be included
   and it lacks a role, what role should it be given?

   RS: You typically fall back on the host language.

   JS: You also look at the relevant AAM to figure out the role
   for the host language element.

   (Brief discussion that you can display script, which is not
   normally exposed, via CSS)

   RS: If you have an ARIA attribute....

   JS: A non-global one?

   RS: Are global already addressed?

   JS: Yes.

   CS: It would be nice to have it all in one place.

   JS: I could summarize what the role="presentation" spec text
   says.
   ... For instance, you can override presentation with a new
   role. That's covered by the spec.
   ... (Reads example regardring aria-level)

   CS: Does anyone else think this is way too complicated?

   Group: Yes.

   <clown> "aria-level is not a global attribute and would
   therefore only apply if the element was not in a presentational
   state."

   ABR: Basically, global attributes apply regardless of roles.
   ... Role-specific attributes do not apply if role="none".

   JS: That's covered by the spec text I quoted.
   ... The very next sentence is

   <clown> "If an element with a role of presentation is
   focusable, user agents MUST ignore the normal effect of the
   role and expose the element with implicit native semantics"

   RS: Do we need anything in the mapping spec?

   CS: I think it's good to copy it there, because it's not clear
   from how it's currently written that stuff with
   role="presentation" might wind up in the tree.

   JS: That's why I raised the issue last year.

   ABR: Editorial suggestion: It's not obvious that there is all
   this information under role="presentation" that is not pointed
   out by role="none".
   ... There might need to be some top-level section that
   everything can point to.

   CS: That's a good idea.
   ... Is there anything we can do in ReSpec (or elsewhere) to
   include shared text?

   JS: We do that with the glossary.

   CS: Maybe it would be good to do this for the
   what's-in/what's-out content.

   ABR: In the SVG AAM, there are some areas where I need to
   manually include text that is in Core AAM.

   CS: It would be nice to have this in HTML AAM as well.

   RS: Why don't we raise an issue against ARIA to separate out
   the common text?

   ABR: So we resolved what role should be exposed if overriding
   role of none (goes back to host language)
   ... Confirmed focusable elements as one role="none" is ignored.
   ... On the mailing list we discussed when aria-hidden should be
   ignored.

   JD: Link to the thread?

   <AmeliaBR>
   [14]https://lists.w3.org/Archives/Public/public-aria/2016Mar/00
   43.html

     [14] https://lists.w3.org/Archives/Public/public-aria/2016Mar/0043.html

   ABR: That email (above) links to the other threads.

   RS: Here is the issue

   <Rich> [15]https://www.w3.org/WAI/ARIA/track/issues/1017

     [15] https://www.w3.org/WAI/ARIA/track/issues/1017

   issue-1017

   <trackbot> issue-1017 -- Separate out text from role="none" and
   "presentation" so that a single location may be referenced in
   Core-AAM -- raised

   <trackbot> [16]http://www.w3.org/WAI/ARIA/track/issues/1017

     [16] http://www.w3.org/WAI/ARIA/track/issues/1017

   RS: I personally won't be looking at that for a while because
   I'm working on key shortcuts.

   JS: Where is this text going to go?

   RS + ABR: Somewhere in the ARIA spec.

   JS: One other thing: I've not yet looked at the spec to see if
   it's covered, but....
   ... In Core AAM, it says that if it causes an accessibility
   event it has to be in the tree.

   CS: That's not possible.
   ... For instance, if you put a click handler on the page, all
   children could have an event.

   ABR: Events bubble. There are also text mutations.

   CS: There are a couple of tricky things. UIA has no concept of
   bubbling.
   ... The other thing is that if you have a click handler on the
   body, you don't want to expose every single element in the DOM.
   ... So the text that is currently in the spec doesn't reflect
   reality.
   ... It does express a problem which needs to be solved, namely
   how to figure out the elements which should be clickable and
   expose them.

   JS: I'm thinking aria-selected.
   ... If aria-selected changes, you get an accessible
   state-changed event.

   <clown>
   [17]http://w3c.github.io/aria/core-aam/core-aam.html#mapping_ev
   ents_state-change

     [17]
http://w3c.github.io/aria/core-aam/core-aam.html#mapping_events_state-change

   CS: If you're talking about ARIA attributes changing, yes, that
   is true.
   ... But if you're talking about DOM events....

   JS: I'm talking about accessibility events.

   CS: For things like focus, there are. But for input events like
   click and keypress, they can bubble.

   JS: The link above is about accessibility events for state and
   property changes.

   ABR: For most events which are about the accessibility API will
   be handled as a result of the role and other ARIA properties.
   ... As far as general DOM events or text mutation events, it
   needs to become a requirement on the user agent to bubble them
   up to the nearest element which is exposed in the accessibility
   tree and fire the event on that element.

   CS: That's close to what we've been thinking about.
   ... But it gets tricky when the element with the input event is
   not in the tree.
   ... In other words, that the div that got clicked on is not in
   the tree.
   ... We can express the x,y coordinates, but I'm not sure how
   the ATs will find it.

   ABR: The author should give the element some semantic
   relevance, or a tabindex, etc.
   ... What's the consequence if something says you clicked on
   this paragraph instead of this em element in a span in a
   paragraph?
   ... Is there a usability issue?

   CS: That's a good question.
   ... The accessibility APIs were not designed for this scenario.
   ... If you have a thing that looks programmatically like a
   range of text, but is supposed to act like a button, it's an
   authoring error if it doesn't have (say) a tabindex of -1.

   ABR: A more practical example: A diagram like a chart where you
   can hover over data points and have information about that
   element show up.
   ... Chances are that the author will put just one event handler
   that looks at the target and gets the data.
   ... This is a realistic case where the exact element might
   matter and need to be communicated.

   CS: In that case, if the reference points have tabindex of -1,
   or are links or buttons or something else interactive, they'd
   be in the tree.
   ... That is the advice I'd give the author.

   ABR: That sounds like a natural approach that anything with
   semantic meeting has a property that causes it to be included.

   CS: I think that's the right approach.
   ... Bubbling/pass-through mechanisms will not be done in time
   for 1.1.

   ABR: On the Accessibility API side, or the DOM side?

   CS: Either one.
   ... Are there implications there with respect to CR?

   ABR: Where it's currently defined is
   ... (Reads from the text in Core AAM)
   ... There is no direct link to what it means to fire an
   accessibility event.

   JS: I always thought it meant the content in the section
   related to accessibility events.

   CS: And I thought it included things like click handlers.

   <AmeliaBR>
   [18]http://w3c.github.io/aria/core-aam/core-aam.html#mapping_ev
   ents

     [18] http://w3c.github.io/aria/core-aam/core-aam.html#mapping_events

   ABR: The above link has the section in Core to what events are
   being mapped.

   JS: There's a table there.

   ABR: Those are about specific ARIA properties and how they are
   mapped.
   ... And that shouldn't be a problem because they'll be in the
   tree.
   ... 5.8.2 and 5.8.3 regarding visibility and text mutations,
   there might not be a one-to-one correspondence between DOM node
   and event to be triggered.

   <Rich> scribe: Rich

   Cynthia: The scenario is sort of a reverse bubbly scenario
   ... some children are not in accessibility tree

   <scribe> scribe: Rich

   joanie: some of the things I scribed that Joseph said was my
   understanding. However, if we are talking about the paragram
   example, we don’t care so much about the EM. We are interested
   in the coordinates at what was clicked.
   ... what is they waypoint example?
   ... if I don’t have to synthesize the input event and something
   pops up I will get an event and an appropriate role

   amelia: we wan the assistive technology to know that the event
   happened on a meaningful object and it may need to bubble up in
   the DOM tree
   ... we don’t want non-important elements to suddenly announced
   as you clicked on this span. But the reverse issue it is hard
   to determine what is important in these scenarios

   cynthia: an image button in the middle of a paragraph is a
   great example'

   <clown> <p onclick="handleClickOnImage()"> …. <img
   tabindex="0"> …</p>

   cynthia: so it is just an image and there is a click handler
   elsewhere up the tree that does something on behalf of the
   image and it is all over the web. we need to find a way to have
   authors repair it

   <joanie> scribenick: joanie

   <clown> <p onclick="handleClickOnImage()"> …. <span>click
   me</span>   …</p>

   CS: Joseph, your example has a tabindex; remove that. And make
   it a span.

   <clown> <p onclick="handleClickOnSpan()"> …. <span>click
   me</span>   …</p>

   JS: Like the above?

   Group: Yes.

   JS: So you click on the span and it bubbles up to the
   paragraph.

   CS: Exactly, and this sort of thing is really common.
   ... Though it's more often on the body.
   ... And it's an authoring error. But it's very common.
   ... There's enough content out there in the world that it would
   be great if the user agent could repair this.

   JS: But how, as this cannot be found via the DOM?

   CS: There's certain magic one can do for DOM-based solutions.
   ... But for ATs based on accessibility APIs, there's no way to
   deal with this currently.

   <AmeliaBR> <body onclick="handleClickonPar()"><p tabindex="0">
   something something <span>click me</span> …</p>

   <cyns_> <body onclick><div tabindex=0><span>click
   me!</span></div></body>

   ABR: Above is the opposite case. You still have a span called
   "click me!", but the paragraph is the important thing.

   JD: On my platform, the span wouldn't be exposed. I would only
   see the paragraph.

   CS: That could be handled I think.
   ... The tricky one is in my example (above)
   ... The click handler is looking for the ID of the span.
   ... It will get a click on the div, but not on the span.
   ... If we use the approach I'm thinking of.

   ABR: No way sort of reading authors' minds can you handle all
   of these cases correctly.
   ... Unless you parse the JavaScript, or....

   Group: That way madness lies.

   CS: I think we can solve Amelia's scenario.

   RS: I'm trying to figure out what they're doing when putting
   the click handler above (in the DOM tree) the object.

   CS + JS: They're reducing code.

   RS: Example, a click handler was put on the body tag so if you
   click anywhere outside a dialog box, it would close.

   ABR: The event handler itself has the element associated with
   the event.

   RS: This is Firefox telling you that there's an onclick handler
   on all the descendants.
   ... And then ATs were trying to infer why all of those elements
   had an onclick handler.

   CS: We added invoke only if there was an explicit onclick
   handler; not all descendants.
   ... I'd be curious how Firefox is doing it.

   RS: I think they were using the Action interface.

   JD: If so, that might be a real problem.

   JS: It's the end of the hour!
   ... I guess the discussion with events are ongoing since we
   didn't solve everything.

   ABR: We didn't even get to aria-hidden.

   RS: I'll send a note to Alex Surkov regarding the action issue.

No meeting next week.

   Group: CSUN is next week, so we won't be meeting.

   <scribe> scribe: joanie

Summary of Action Items

Summary of Resolutions

   [End of minutes]
Received on Tuesday, 15 March 2016 20:15:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 15 March 2016 20:15:11 UTC