See also: IRC log
<clown> agenda: this
<scribe> scribe: joanie
<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> 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> 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> 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> 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.
<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> 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> 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> 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.
<clown> issue-583
<trackbot> issue-583 -- Elements that are descendants of an element having aria-activedescendant should not all be focusable -- open
<trackbot> 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> 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> 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> 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> https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#keyboard-focus_aria-activedescendant
<clown> 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> https://www.w3.org/WAI/ARIA/track/products/23
<clown> 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> http://www.w3.org/WAI/ARIA/track/issues/1037
<Rich> 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> 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.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Brian/Bryan/ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Found Scribe: joanie Inferring ScribeNick: joanie Default Present: Joanmarie_Diggs, Joseph_Scheuhammer, Bryan_Garaventa, Rich_Schwerdtfeger Present: Joanmarie_Diggs Joseph_Scheuhammer Bryan_Garaventa Rich_Schwerdtfeger Regrets: Cynthia_Shelly Found Date: 26 Jul 2016 Guessing minutes URL: http://www.w3.org/2016/07/26-aapi-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]