[AAPI] Minutes UAI TF Meeting, Tuesday 26 July 2016

URL: https://www.w3.org/2016/07/26-aapi-minutes.html

Plain text follows:

   [1]W3C

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

   Accessible Rich Internet Applications Working Group Teleconference

26 Jul 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/07/26-aapi-irc

Attendees

   Present
          Joanmarie_Diggs, Joseph_Scheuhammer, Bryan_Garaventa,
          Rich_Schwerdtfeger

   Regrets
          Cynthia_Shelly

   Chair
          Joseph_Scheuhammer

   Scribe
          joanie

Contents

     * [3]Topics
         1. [4]ISSUE-676/ACTION-1739: (Joseph) Identify ATK/AT-SPI
            interfaces in role mappings. done?
         2. [5]ISSUE-676/ACTION-2083: (Joanie) Review and update
            ATK/AT-SPI states. - status?
         3. [6]ISSUE-583: (Rich) Children elements of ancesstor
            with aria-activedescendant should not all be focuable.
            - done?
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <clown> agenda: this

   <scribe> scribe: joanie

ISSUE-676/ACTION-1739: (Joseph) Identify ATK/AT-SPI interfaces in
role mappings. done?

   <clown> issue-676?

   <trackbot> issue-676 -- Is it useful to identify MSAA+IA2 and
   ATK/AT-SPI actions, interfaces, and relations in the mappings?
   -- open

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

      [9] http://www.w3.org/WAI/ARIA/track/issues/676

   JS: I want to see how far we can get with issue-676.

   <clown> action-1739?

   <trackbot> action-1739 -- Joseph Scheuhammer to Provide all the
   missing atk/at-spi2 interfaces for joseph -- due 2016-07-05 --
   PENDINGREVIEW

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

     [10] http://www.w3.org/WAI/ARIA/track/actions/1739

   JS: Jason Kiss suggested we add the appropriate MSAA+IA2 and
   ATK/AT-SPI actions, interfaces, etc. to the mappings
   ... I've done much of this work on action-1739.

   <clown>
   [11]https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#r
   ole-map-cell

     [11]
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-cell

   JS: But for the cell role, there was a question about the
   TableCell interface.
   ... And the request to mark it as [ARIA1.1]
   ... But the role was introduced in ARIA 1.1.

   <clown>
   [12]https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#r
   ole-map-gridcell

     [12]
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-gridcell

   JD: I'm afraid I don't recall now.
   ... To answer the question, no, I don't think any additional
   "ARIA 1.1" notation is needed.

   JS: Can I close this action then?

   JD: I think so.

   JS: Ok, will do.
   ... That closes half of this issue.

ISSUE-676/ACTION-2083: (Joanie) Review and update ATK/AT-SPI states.
- status?

   <clown> action-2083

   <trackbot> action-2083 -- Joanmarie Diggs to Review and update
   ATK/AT-SPI2 states in Core AAM -- due 2016-06-21 -- OPEN

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

     [13] http://www.w3.org/WAI/ARIA/track/actions/2083

   JD: I worked on this today.
   ... I have added notes to the action.

   JS: Looking at the action, that's a lot of work.

   JD: Cynthia had a similar situation didn't she? With
   aria-value* on focusable splitters?

   <clown>
   [14]https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#a
   riaValueNow

     [14]
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaValueNow

   JS: Yes, she said you didn't have to list it for the role; it
   could be listed for the states and properties mappings.

   <clown>
   [15]https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#m
   apping_state-property_table

     [15]
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#mapping_state-property_table

   JD: Aha, yes. It would make sense for my states to be listed in
   the states and properties table.
   ... Which they already are.
   ... Which means I'm an idiot for duplicating things.

   JS: I'll take this and compare what you've provided to what is
   already in the spec.
   ... And if I have question, I'll ask you.

   JD: Thanks!
   ... I still need to review relations, etc.

ISSUE-583: (Rich) Children elements of ancesstor with
aria-activedescendant should not all be focuable. - done?

   <clown> issue-583

   <trackbot> issue-583 -- Elements that are descendants of an
   element having aria-activedescendant should not all be
   focusable -- open

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

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

   JS: Rich raised the issue.
   ... David, Alex and I resolved it in action-1222.

   action-1222

   <trackbot> action-1222 -- David Bolter to Look into ISSUE-583,
   and think about section 4.3, step 4A to see if that answers the
   question. -- due 2013-05-16 -- CLOSED

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

     [17] http://www.w3.org/WAI/ARIA/track/actions/1222

   RS: What did you change in the steps?

   JS: Absolutely nothing, as far as I recall.
   ... You have a container with aria-activedescendant.
   ... Only the elements with an id are focusable.

   <clown>
   [18]https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#k
   eyboard-focus_aria-activedescendant

     [18]
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#keyboard-focus_aria-activedescendant

   JS: Because elements without an id cannot be referenced.
   ... The URL is above.
   ... In addition to an id, it has to have a role.
   ... So if you think of a listbox, focusable is only applied to
   elements with role="option" and an id.

   RS: So every element with an id and role are focusable?

   JS: Well, if it has a tabindex, it would also be focusable.
   ... That's what tabiindex means.

   RS: Did this resolve the issue with combobox?

   JS: It says "descendant"; not "direct descendant"

   RS: In the case of a combobox, you can have activedescendant on
   the combobox; but the listbox doesn't have to be a descendant.

   JS: Can I see the markup?

   RS: Sure

   <clown>
   [19]https://rawgit.com/w3c/aria/master/aria/aria.html#combobox

     [19] https://rawgit.com/w3c/aria/master/aria/aria.html#combobox

   <Rich> <div role=“combobox”><input type=“text”
   aria-activedescendant=“foo”><div role=“listbox><div
   role=“option” id=“foo”>option 1</div?</div></div>

   JS: If you look at example 5 in the spec, I think that's what
   you're talking about.

   RS: Above is my example.

   JS: So the listbox is a descendant of the combobox, right?

   RS: aria-activedescendant is on the input.
   ... So the listitem that contains "zoom" is not a descendant of
   the input with type "text"

   JS: It can't be because inputs don't have descendants.

   RS: Right.
   ... And it's more than that.
   ... I thought the lisbox would be inside the combobox.

   JS: It is.

   RS: I see an ordered list outside the combobox.

   JS: I'm looking at what you typed.

   RS: I'm looking at the spec.

   JS: In the spec, aria-owns is being used. That makes it a
   descendant.

   <Rich> <div aria-label="Tag" role="combobox"
   aria-expanded="true" aria-owns="owned_listbox"
   aria-haspopup="listbox">

   <Rich> <input type="text" aria-autocomplete="list"
   aria-controls="owned_listbox"
   aria-activedescendant="selected_option">

   <Rich> </div>

   <Rich> <ul role="listbox" id="owned_listbox">

   <Rich> <li role="option">Zebra</li>

   <Rich> <li role="option" id="selected_option">Zoom</li>

   <Rich> </ul>

   JS: There's a div with role combobox which has aria-owns and
   points to the listbox.

   RS: It seems to be acting on behalf of the combobox.

   JS: And there's no ownership relation either.
   ... So the question is: Is there enough information here to
   mark the elements as focusable?
   ... And they don't all have IDs.

   RS: So they are not focusable.

   JS: That's easily corrected; but I don't know about the others.

   RS: It's a descendant of the container.
   ... So it's acting on behalf of the container.
   ... (Reads from spec)
   ... So they made a special case.

   "Authors may set aria-activedescendant on the textbox to a
   value that refers to the active element within the popup while
   focus remains on the textbox element."

   RS + JS: Not sure that will work.

   JS: Oh, focus is on the input.
   ... It's not a problem for focused; I don't know about
   focusable.

   <clown>
   [20]https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#k
   eyboard-focus_aria-activedescendant

     [20]
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#keyboard-focus_aria-activedescendant

   <clown>
   [21]https://rawgit.com/w3c/aria/master/aria/aria.html#aria-acti
   vedescendant

     [21]
https://rawgit.com/w3c/aria/master/aria/aria.html#aria-activedescendant

   JD: (Long explanation about how focus versus selection are
   expected to work on her platform)

   JS: I'm telling you, focus changes are being emitted by
   Firefox; not selection changes.

   JD: Well that strikes me as broken.

   BG: I have some examples that might be helpful.
   ... If you just leave focus on the input, the user can resume
   typing at any time.
   ... And it works smoothly once it's coded.
   ... I know what Joanie is talking about.
   ... I've used aria-selected for this.
   ... And it fires a selection event.

   JD: Bryan is my hero!
   ... Can that go in the APG?
   ... And should someone take an action to address this?

   BG: The value of using aria-selected is that it triggers a
   selection event.
   ... And this causes the AT to present the newly-selected item.
   ... But you still need to be able to use the arrow keys to
   change the selection.

   JS: I understand why aria-selected is useful.
   ... I'm still not seeing why aria-activedescendant is.

   BG: I've seen this with a date picker.
   ... Focus was on the input.
   ... If you used aria-selected, focus would still be on the
   input and that would be confusing to the user.

   JS: So why wouldn't you use real focus in that case?

   BG: In my date pickers you do.
   ... In others, it would involve lots of recoding.

   JS: Can we close issue-583?

   RS: Do I think it's been resolved?
   ... The activedescendant doesn't quite work.

   JS: I'm not sure that's the same issue.

   RS: I think the focusable issue has been addressed.

   JS: I don't think the other issue is a Core AAM issue.
   ... It might be an ARIA spec issue.

   RS: But focusable is a mappings thing; the spec doesn't say
   anything about that.

   JS: (Reads aria-activedescendant from the ARIA spec)
   ... Note that the ARIA spec says "focusable"

   RS: But it doesn't say what defines "focusable"; only that it
   has "focusable" descendants.

   JS: It says "identifies the currently-active element when DOM
   focus is on a widget"
   ... It also refers to alternative focus management.
   ... It also says "active," but I'm not sure what "active" means
   in this case.

   JD: It means what I said before: It might mean "focused"; it
   might mean "selected." It depends on the context.

   JS: Ok, I'm closing this issue. If you want to open another
   one, please do.

   RS: I can do that.
   ... Against Core AAM?

   JS: I guess.

   <clown> [22]https://www.w3.org/WAI/ARIA/track/products/23

     [22] https://www.w3.org/WAI/ARIA/track/products/23

   <clown>
   [23]https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#k
   eyboard-focus_aria-activedescendant

     [23]
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#keyboard-focus_aria-activedescendant

   issue-1037

   <trackbot> issue-1037 -- Focus does not address
   aria-asctivedescendant when the element is not a descendant --
   raised

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

     [24] http://www.w3.org/WAI/ARIA/track/issues/1037

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

     [25] https://www.w3.org/WAI/ARIA/track/issues/1037

   JS: You asked me about blockers?
   ... I think this is going to be one of them.

   RS: How many issues are left?

   JS: There are tons of them.
   ... But I don't think most will be blockers.

   issue-1030

   <trackbot> issue-1030 -- Specify mappings for role="password"
   for all AAPIs -- raised

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

     [26] http://www.w3.org/WAI/ARIA/track/issues/1030

   RS: Move that one to ARIA 2.

   JS: I want to move it to ARIA 2 Core Mappings, but I don't
   think I can.

   RS: I can add a new product.

   <Rich> [27]https://www.w3.org/WAI/ARIA/track/products/53

     [27] https://www.w3.org/WAI/ARIA/track/products/53

Summary of Action Items

Summary of Resolutions

   [End of minutes]

Received on Tuesday, 26 July 2016 20:17:26 UTC