- From: Joanmarie Diggs <jdiggs@igalia.com>
- Date: Tue, 26 Jul 2016 16:16:22 -0400
- To: ARIA Working Group <public-aria@w3.org>
- Cc: "wai-xtech@w3.org" <wai-xtech@w3.org>
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:24 UTC