Draft Minutes: May 19, 2016 WAI-ARIA Working Group


Accessible Rich Internet Applications Working Group Teleconference
19 May 2016
See also: IRC log<http://www.w3.org/2016/05/19-aria-irc>
Janina, Joanmarie_Diggs, LJWatson, jongund, MichielBijl, fesch, JamesNurthen, matt_king, JaeunJemmaKu

  *   Topics<https://www.w3.org/2016/05/19-aria-minutes.html#agenda>
     *   CFC for last weeks actions<https://www.w3.org/2016/05/19-aria-minutes.html#item01>
     *   Initiate a review of the spec for feature freeze in June<https://www.w3.org/2016/05/19-aria-minutes.html#item02>
     *   Separator role and autocomplete<https://www.w3.org/2016/05/19-aria-minutes.html#item03>
     *   Any progress on keyshortcuts?<https://www.w3.org/2016/05/19-aria-minutes.html#item04>
     *   Issue 2067 aria-owns<https://www.w3.org/2016/05/19-aria-minutes.html#item05>
     *   Action 2068<https://www.w3.org/2016/05/19-aria-minutes.html#item06>
  *   Summary of Action Items<https://www.w3.org/2016/05/19-aria-minutes.html#ActionSummary>
  *   Summary of Resolutions<https://www.w3.org/2016/05/19-aria-minutes.html#ResolutionSummary>

scribe jongund
<janina> http://lists.w3.org/Archives/Public/public-aria/2016May/0135.html

TOPICS: jongund
CS: Discussing contact John Jensen
MK: That is a nice development
JS: Nice
... The goal is to get ARIA out in June
CFC for last weeks actions
Actions 1743 2059 1524
<joanie> action-1743
<trackbot> action-1743 -- Matthew King to Put aria-activedescendant on application and request wg review -- due 2016-03-31 -- PENDINGREVIEW
<trackbot> http://www.w3.org/WAI/ARIA/track/actions/1743

JS: There have been no comments, so by default they will be approved
Initiate a review of the spec for feature freeze in June
JS: Goal CR June 16th
MK: I thought it was a psuedo last call
... Feature freeze June 9th
... Before June 9th, everyone do a sweep of the document
... In the editors call we want a top to bottom review
... There is not any time between June 9th and 16th to make changes
JS: It depends on how severe the issue is
MK: June 16th is when all of the issues must be resoloved for pub on June 16th
JS: Please look at the spec top to bottom
... Hopefully there are no major issue
... Any other questions, the usual proceedure to have a final review
Separator role and autocomplete
MK: I'll put a URL in for a branch
<mck> http://rawgit.com/w3c/aria/action2069-separator/aria/aria.html

MK: I will describe the issue
... Issue 1028
... Currently the separator within a menu or content, to divide content
<jemma> http://rawgit.com/w3c/aria/action2069-separator/aria/aria.html#separator

MK: It is the same as HR element in accessibility apis
... It is a scrutural element, but then it also can be used as an interactive sepearator for like movable windows
... You can make it focusable, but AT does not support any keyboard interaction, so keys are not passed through to the application, since it is a structural role
... We just take the interactive language away from the separator role, let separator be separators
... Look at the branch
<Zakim> fesch, you wanted to ask is Matt talking about separator or splitter
MK: I added a splitter role, it might not have time to make ARIA 1.1
... It supports aria-expanded, so I took that off
... I think we need to remove the text either way
<Zakim> joanie, you wanted to ask why ATs cannot look at role + state to conclude that a separator is a splitter
Joanie: My think is about splitters
... I want to stay on que
FE: I took my self off que, my comment is on splitter
MK: Splitter is what we could do to close the gap between separator and the feature need

MK: Discussion?
CS: Sounds like at great 2.0 proposal
MK: You want to push it off
CS: It is a good idea, but not enough time to implement
FE: same
Joanie: I have a followup on my e-mail and the implementation issue
JD: The ARIA stack, that is not exposed to AT, all I know is that I can hack around it
... Plateforms already has splitter roles, at least mine does
... User agendt could see it is a separator and tabindex, then map to splitter role, otherwise separator role
... ATs can already deal with this
... This is so easy to implement
MK: I am glad to hear your perspective
... If it is as simple as separators as whether they are focusable, ....
... We do give ATs specific instructions to pass keys through for widgets
... Checkboxes and buttons have default actions
CS: All great ideasare good, but we need to lock down to get implementation
<fesch> +1 to feature lockdown
<Zakim> cyns, you wanted to say that the spec lockdown is separte from implementation. It's fine for Orca to implement even if this isn't in 1.1
<joanie> +1 to lockdown
MK: Is it reasonably implementable
... We only need two implementations
FE: It maybe great, but we have not had a time to review
CS: Joanie can still implement
MK: If we don't make a change in the spec
CS: Browsers and ATs can do exploratory implementation
LW: In HTML 5.1
JS: Can you hear me
MK: Yes
lw: With HTML5.1 we have decided against rushing through substantive new features so close to CR and suggest doing the same with ARIA 1.1
JD: This would go into the core AMMs, a possible solution, not change anything in the spec, change in the AMM
... I don't think we should change the spec
... We will probably not get splitter role in 1.1
... Just change the AMM
MK: The ARIA 1.0 spec that separators can be static and dynamic, but there is not implementation
... We don't make normative requirements in the ARIA spec
<Zakim> joanie, you wanted to respond (but after others can take their turns)
MK: All the spec changes are editorial
... If is focuable you do it this way, if not do it this way
... I will withdraw this proposal, and I will make editorial changes based on JD suggestions
JN: I maybe in correct, but there are plateforms allow separators to get focus in menus
MK: We consider it a mistake when that happens
JN: Thats OK, just wanted to check
... This is not a new requirement, if we can do it in the AAM that is great
<Zakim> fesch, you wanted to say would adding a splitter affect posinset and setsize
FE: Does adding a splitter role will effect posinset, and setsize, if they are interactive then there would need to be a change in the calc
MK: This is only in a window splitter
... I will revise my proposal based on today's discussion, action 2069
... The group has proposed an alternative to 1028, I will run with it
... I will bring it back next week
JS: Sounds good
Any progress on keyshortcuts?
MK: We will discuss in the APG call on monday
... I am on track
JS: That was easy
Issue 2067 aria-owns
JN: I have not had time to get to it
JS: ok
MK: What Bryan sent to the list, there are implementation problems due to the spec language, so it maybe more editorial to clarify
... This is pretty important stuff
JN: When I accepted, I was not sure I had time to work on it
Action 2068
BG: These are not true of other widget roles, children need to have presentational roles
MK: In the action itself
<fesch> action-2068
<trackbot> action-2068 -- Bryan Garaventa to Address issue 1006 -- due 2016-05-19 -- OPEN
<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2068

<mck> action-2068?
<trackbot> action-2068 -- Bryan Garaventa to Address issue 1006 -- due 2016-05-19 -- OPEN
<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2068

MK: I agrre with ever single one, ATs are already doing this
... Authors and user agents have to be on the same page
BG: The actual link role, exception
<jemma> more info can be found here. https://www.w3.org/WAI/ARIA/track/issues/1006

MK: How would AT know when it present a link know that the link contains semantics, it would have to say complicated link, ...
... We could use our imagination on what ATs could do, it could be mapped differently, you can look inside of the link to see if there are semantics, then some way for people to explore the semantics
... We would need to write some "should" language for ATs
BG: I find it a problem
... I am just talking about structural elements
MK: Does HTML allow that though?
... It can contain block elements, but not interactive elements, have not read for a few years
<Zakim> jamesn, you wanted to ask about combobox
JN: I agree with most, what about combobox>
BG: That was before 1.1, we can take that one out
JN: ok
<jamesn> https://www.w3.org/WAI/ARIA/track/issues/1006

JS: FE is on que
GE: The ones I am worried about menu item and treeitem
BG: It doesn't limit us to additional controls, difference between an interactive widget and container
FE: If you put a custom widget, like a datepicker
MK: You can't do that
... You have a menu item that says datepicker and pressing the menu it opens a date picker dialog
FE: What open the menu button?
MK: The menuitem opens the dialog, sometimes ... is used to indicate a dialog
FE: Even in treeview
MK: It is not common, but it could be done
BG: We are talking about non-composite widgets
... Menubar is a composite widget
... It can be rendered adjacent to the ....
JS: WHere are we with this proposal? Is it acceptable?
MK: I think yes, I am working on proposed text, removed combobox
<mck> proposed resolution: Add children presentationaal true to checkbox, menuitem, menuitemcheckbox, menuitemradio, option, radio, searchbox, spinbutton, switch, tab, textbox, and treeitem,
JS: Any objections?
<mck> proposed resolution: Add children presentationaal true to checkbox, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, searchbox, spinbutton, switch, tab, textbox, and treeitem.
JD: I have seen both native and web, that there is an "X" to clear current results, or caps lock indicators, textboxes and ...
CS: All of the edit controls in Windows support these features
MK: When you are making a rich text editor, has to expose the structural information
JS: I have a comment
MK: We don't say anything about host language semantics
JS: Regarding spin button, those web apps and naitve controls, input type equal number, they have incrementer/dec buttons
... They show up in accessibility apis as objects, on purpose
CS: They are needed for touch support
... For some controls they are actually inside
MK: SR users use swip up and down
BG: The right and left is the inc/dec buttons, this works on touch screen devices, button would need to be a compsite widget
MK: Right it is not written as composite, and you need a text box
CS: Sounds like a ARIA 2.0
MK: I think we should leave it in
<mck> proposed resolution: Add children presentationaal true to checkbox, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, spinbutton, switch, tab, and treeitem.
FE: It seems we are changing the issue, because we have not talked about it
CS: Accessibility APIs have changed since ARIA 1.0
MK: I repoposed
FE: I object, we have not thought about it enough
MK: I disagree, this is a long standing issue, and we have been working on it for 6 months
Summary of Action Items
Summary of Resolutions
[End of minutes]
Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> version 1.144 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/05/19 17:34:26 $
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
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/<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/>

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/LW: With HTML5.1 we are not putting in new feature, we will branch to 5.2, not advisable for 1.1/lw: With HTML5.1 we have decided against rushing through substantive new features so close to CR and suggest doing the same with ARIA 1.1/
No ScribeNick specified.  Guessing ScribeNick: jongund
Inferring Scribes: jongund
Present: Janina Joanmarie_Diggs LJWatson jongund MichielBijl fesch JamesNurthen matt_king JaeunJemmaKu
Found Date: 19 May 2016
Guessing minutes URL: http://www.w3.org/2016/05/19-aria-minutes.html

People with action items:

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> diagnostic output]

Received on Thursday, 19 May 2016 18:04:22 UTC