See also: IRC log
<trackbot> Date: 08 October 2013
<scribe> scribenick: clown
<davidb> on my way
issue-612?
<trackbot> issue-612 -- Review ia2/atk rule in group position. should this really determine level based on aria-owns chain. see uaig: http://www.w3.org/wai/pf/aria-implementation/#mapping_additional_position and test case 69: https://www.w3.org/wai/pf/testharness/testresults?tes -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/612
http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_position
https://www.w3.org/wai/pf/testharness/testresults?testsuite_id=2&testcase_id=69
https://dvcs.w3.org/hg/pfwg/raw-file/default/ARIA-UAIG/1.0/tests/test-files/test69.html
DB: I'm going to give this one to
Alex.
... he's the one that implemented this.
JS: we a flat list of
<div>'s.
... They are all siblings.
... But, the first aria-owns the 2nd, the 2nd the 3rd, and so
on
... Making an ARIA tree widget.
... James wondered if this was legal.
... In reality, you would nest these.
DB: For aria 1.0 we expose relationships.
JS: you do not change the tree.
DB: right. Expose parent-of
relationship.
... things like level or structural changes — we leave that up
to the AT
JS: But the question is about
IA2's group position.
... Checking FF24 on the test file … it fails.
DB: The statement in the UAIG — is it specifically for treeitem?
JS: Yes.
... It seems to me that if aria-owns is used to make the tree,
and not the DOM, then the aria-level should be "correct" for
the virtual parent/child relationship.
DB: I will follow up with Alex.
action-1219?
<trackbot> action-1219 -- Joseph Scheuhammer to UAIG: passive RFC requirement: two instances of "The state change events MAY be trimmed out for performance" Who is this requirement for? Authors? UA? AT? Be specific. What does "trimmed out" mean? Be specific. -- due 2013-05-14 -- OPEN
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1219
http://www.w3.org/WAI/PF/aria-implementation/#mapping_events_selection
JS: see suggested text in the note dated Sep 23.
<davidb> we call it coalescing
DB: I approve of the text.
JS: I believe Cynthia approved at
a previous meeting (I'll check the minutes).
... and we were waiting fo your approval.
action-1219?
<trackbot> action-1219 -- Joseph Scheuhammer to UAIG: passive RFC requirement: two instances of "The state change events MAY be trimmed out for performance" Who is this requirement for? Authors? UA? AT? Be specific. What does "trimmed out" mean? Be specific. -- due 2013-05-14 -- OPEN
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1219
issue-616?
<trackbot> issue-616 -- ISSUE: Review potentially at-risk statement "When the user triggers an element with a defined activation behavior in a manner other than clicking it, such as by pressing Enter, simulate a click on the element." -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/616
JS: Cynthia agreed with the text
in the UAIG as is, and even if IE failed the test, IE should be
fixed.
... I think this is what it the UAIG is talking about:
<div role="button" tabindex="0" onclick="someScript" ...>
<cyns> my last meeting ran really long. did I miss hte whole thing?
cyns, no, we are in the middle of the meeting.
come join us!
http://www.w3.org/WAI/PF/aria-implementation/#keyboard-focus_tabindex
DB: what document?
... Section 4.2?
JS: yes.
... Step 10.
... I guess step 11 is somewhat involved.
... in the DOM world, there was discussion of a "oncommand" or
"onactivate" event.
... but, that was rejected in favour of "onclick"
... note that onclick is different from onmousedown and
onmouseup.
... It does mean "onactivate".
... I believe "onclick" is activated by a space bar or
enter.
... but I might be wrong.
... James sees the utility of the approach, but feels it is the
province of the DOM group, not the UAIG.
CS: this is something that is
absolutely essential.
... We spent six months putting this in. I don't want it
out.
http://www.w3.org/WAI/PF/aria-implementation/#def_activation_behavior
DB: what is a defined activation behavior.
CS: I think it's fne to have this
at risk.
... But if we don't put something in the spec, it will never be
implemented.
JS: the comeback would be: then
take it to the DOM event group, and have them do it.
... But I have looked at the DOM level 3, and there is nothing
like this in there.
DB: This whole area is to make
the keyboard work.
... It may be that James thinks all of this belongs in the DOM
spec.
... I don't really care where it goes, and I think everyone
should implement it.
... I don't itchy when it's documented in the spec.
JS: <reads what James said from the issue>
CS: That's why it's here — I don't trust authors to do it right.
<davidb> I wish this was all cleaner
JS: BTW, there is no DOM-2
keyboard event standard.
... There is a DOM-1 keyboard event model, where keyevents are
only on form elements and the <body> element.
... note that in DOM-1 there is no bubbling.
... Now all browsers do bubbling of keyevents, even though this
is underspecified by DOM events.
https://www.w3.org/WAI/PF/testharness/testresults?testsuite_id=1&testcase_id=31
https://www.w3.org/WAI/PF/testharness/testresults?testsuite_id=1&testcase_id=32
JS: These are the wrong test cases.
DB: I understand the event systems, but I want to read it again. The text is kind of ambiguous.
http://www.w3.org/TR/2009/WD-wai-aria-implementation-20091215/#keyboard-focus_tabindex
"When the user triggers an element that is only focusable because of its tabindex attribute in a manner other than clicking it, such as by pressing Enter, and the element has no defined activation behavior, the user agent MUST fire a click event."
JS: the wording in the 2009 version of the document.
<davidb> that makes more sense to me
<davidb> i wish i could disambiguate "When the user triggers an element" - triggers how?
<davidb> ok enter… but what about API
CS: the gist of it is that it is always going to fire a click event.
JS: The overall impression I'm getting is that it should be kept even though it's at risk.
CS: It's important. I'm willing
to make it a 1.1 issue.
... I don't think we need to make it a 1.1 issue: The
resolution is to mark it at risk.
DB: I think we could word this better in places.
JS: Do you think that would satisfy James' problem?
DB: No.
CS: I think it's worth taking it to him.
JS: I think we need a joint PF UAIG meeting about this.
DB: Or do it over email.
action-1255?
<trackbot> action-1255 -- Cynthia Shelly to Look into toggle patterns and how that needs to be modified in the uaig. -- due 2013-09-28 -- OPEN
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1255
CS: I will get to it. Move the due date to next week.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/the expert/the one that implemented this/ Succeeded: s/aria-tree/ARIA tree widget/ Succeeded: s/AT>/AT/ Succeeded: s/wolrd/world/ Succeeded: s/default activation behaviour/defined activation behavior/ Succeeded: s/all the text/the event systems/ Found ScribeNick: clown Inferring Scribes: clown Default Present: Joseph_Scheuhammer, Michael_Cooper, David_Bolter, Cooper, cyns Present: Cynthia_Shelly David_Bolter Joseph_Scheuhammer Michael_Cooper Agenda: http://lists.w3.org/Archives/Public/wai-xtech/2013Oct/0001.html Found Date: 08 Oct 2013 Guessing minutes URL: http://www.w3.org/2013/10/08-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]