16:29:03 <RRSAgent> RRSAgent has joined #aria
16:29:03 <RRSAgent> logging to http://www.w3.org/2016/06/23-aria-irc
16:29:05 <trackbot> RRSAgent, make logs world
16:29:05 <Zakim> Zakim has joined #aria
16:29:07 <trackbot> Zakim, this will be
16:29:08 <trackbot> Meeting: Accessible Rich Internet Applications Working Group Teleconference
16:29:08 <trackbot> Date: 23 June 2016
16:29:09 <richardschwerdtfeger> chair: Rich
16:29:09 <Zakim> I don't understand 'this will be', trackbot
16:29:18 <richardschwerdtfeger> chair: Rich
16:29:27 <richardschwerdtfeger> RRSAgent, make log public
16:29:33 <joanie> present+ Joanmarie_Diggs
16:30:03 <fesch> fesch has joined #aria
16:30:11 <richardschwerdtfeger> present+ Rich_Schwerdtfeger
16:31:03 <richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria/2016Jun/0156.html
16:31:17 <cyns> cyns has joined #aria
16:32:24 <MichaelC> present+ MichaelC
16:34:16 <clown> clown has joined #aria
16:34:32 <mck> mck has joined #aria
16:34:35 <JaEunJemmaKu> JaEunJemmaKu has joined #aria
16:36:04 <janina_> present+ Janina
16:36:26 <JaEunJemmaKu> present+JaEunJemmaKu
16:36:29 <MichielBijl> present+ Michiel_Bijl
16:36:59 <mck> present+ matt_king
16:37:29 <mck> scribe: matt_king
16:37:43 <fesch> present+ fesch
16:37:47 <mck> TOPIC: aria-owns
16:37:53 <mck> action-2067?
16:37:53 <trackbot> action-2067 -- James Nurthen to Write text to state the order of aria-owns ids wrt. the dom child order and sequential aria-owns ids -- due 2016-05-19 -- PENDINGREVIEW
16:37:53 <trackbot> http://www.w3.org/WAI/ARIA/track/actions/2067
16:38:02 <richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0043.html
16:38:15 <richardschwerdtfeger> ttps://www.w3.org/WAI/ARIA/track/actions/2067
16:38:15 <mck> RS: I didn't see any objections to the cfc.
16:38:25 <JF> JF has joined #aria
16:38:31 <JF> Present+ JF
16:38:40 <mck> rs: action 2067 reached consensus.
16:38:43 <richardschwerdtfeger> https://www.w3.org/WAI/ARIA/track/actions/2067
16:38:46 <bgaraventa1979> bgaraventa1979 has joined #aria
16:38:58 <mck> TOPIC_ password role restriction cfc
16:39:06 <bgaraventa1979> present+ Bryan_Garaventa
16:39:17 <mck> rs: didn't see objections to the proposed note
16:39:26 <clown> present+ Joseph_Scheuhammer
16:39:44 <mck> rs: in the future, this role could change, but I am not objecting to it at this time.
16:39:52 <mck> action-2080?
16:39:52 <trackbot> action-2080 -- Joanmarie Diggs to Draft aria spec text limiting the use of role password on editable objects -- due 2016-06-09 -- PENDINGREVIEW
16:39:52 <trackbot> http://www.w3.org/WAI/ARIA/track/actions/2080
16:40:04 <richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0029.html
16:40:11 <mck> Joseph: Yes, I commented but am fine with it.
16:40:34 <mck> TOPIC: action 2-084 - presentational children cfc
16:40:46 <richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0028.html
16:40:47 <mck> RS: we didn't reach consensus
16:40:58 <mck> lot of discussion on this one.
16:41:31 <mck> James N gave example with menus including menuitems that have menus as children.
16:41:59 <mck> JN: menuitemradio and menuitemcheckbox are a bit weird that way, but spec does allow it.
16:42:23 <mck> rs: not sure what we do with it at this point.
16:42:24 <mck> what is impact if we do not make children presentational?
16:42:38 <mck> BG: Right now every thing is exposed.
16:42:55 <Stefan> Stefan has joined #aria
16:43:28 <mck> What I recommend for this particular issue is to remove those 4 attribs from the proposal (treeitem, menuitem, menuitemradio, menuitemcheckbox)
16:43:42 <mck> And do something separate with them.
16:44:02 <mck> RS: need an aria 1.1 compromise so we we can get 1.1 done.
16:44:31 <mck> We can make a separate issue for treeitem and menuitem, and we can address this with authroing practices.
16:45:33 <mck> Suggestion is to have children presentational  on radio, checkbox, option, menuitemradio and menuitemcheckbox
16:46:13 <mck> BG: I am not sure about tree tiem, menuitem, and menuitemcheckbox
16:47:28 <jongund> present+ jongund
16:47:42 <mck> MK: We should not allow menuitemradio to have semantic children
16:49:16 <mck> JN: Table of owned elments for menuitemradio right now allows for mchild menus
16:49:52 <clown> https://rawgit.com/w3c/aria/master/aria/aria.html#menuitemradio
16:50:20 <richardschwerdtfeger> http://rawgit.com/w3c/aria/master/aria/aria.html#menuitemradio
16:50:22 <jcraig> jcraig has joined #aria
16:50:24 <clown> https://rawgit.com/w3c/aria/master/aria/aria.html#menuitemcheckbox
16:50:39 <mck> Joanie: we had a cfc and it was approved so menuitemradio right now has children presentational true.
16:51:12 <joanie> confirmed
16:51:21 <joanie> action-2071
16:51:21 <trackbot> action-2071 -- Joanmarie Diggs to Implement the presentational children resolution from action-2006 see cfc: https://lists.w3.org/archives/public/public-aria-admin/2016may/0016.html -- due 2016-06-02 -- CLOSED
16:51:21 <trackbot> http://www.w3.org/WAI/ARIA/track/actions/2071
16:54:32 <mck> Joanie: I completed action 2071 that added children presentational to multiple roles.
16:54:40 <mck> rs: We need to partially undo
16:55:06 <mck> rs: remove from menuitem and treeitem
16:55:52 <mck> Joanie: and remove from spinbutton. And there is a separate action to make spinbutton composite.
16:56:04 <jongund> jongund has joined #aria
16:57:01 <mck> rs: I'd like to have one branch that deals with presentational children as we want it.
16:57:10 <mck> and then put that out for cfc.
16:58:07 <mck> Joanie: I agree about spin button can not have children presentational true.
16:59:05 <mck> RS: summarize proposal: remove children presentational true from menuitem, treeitem, and spinbutton.
16:59:16 <clown> +1
16:59:21 <joanie> +1
16:59:23 <richardschwerdtfeger> +1
16:59:28 <JaEunJemmaKu> +1
16:59:32 <mck> +1
17:00:31 <jamesn> jamesn has joined #aria
17:00:41 <mck> RESOLUTION: Modify current master, partially reversing action 2071, to remove children presentation true from menuitem, treeitem, and spinbutton.
17:01:38 <joanie> action Joanie to create a branch removing children presentational from menuitem, treeitem, and spinbutton
17:01:38 <trackbot> Created ACTION-2087 - Create a branch removing children presentational from menuitem, treeitem, and spinbutton [on Joanmarie Diggs - due 2016-06-30].
17:02:17 <mck> action-2084?
17:02:17 <trackbot> action-2084 -- Bryan Garaventa to Propose content for composite role to describe the constraints that have been behind the children-presentational normalization effort -- due 2016-06-23 -- OPEN
17:02:17 <trackbot> http://www.w3.org/WAI/ARIA/track/actions/2084
17:02:17 <clown> action-2084
17:02:18 <trackbot> action-2084 -- Bryan Garaventa to Propose content for composite role to describe the constraints that have been behind the children-presentational normalization effort -- due 2016-06-23 -- OPEN
17:02:18 <trackbot> http://www.w3.org/WAI/ARIA/track/actions/2084
17:02:50 <jcraig> +1 to removing children presentational on spinbutton
17:02:57 <mck> MK: push action 2084 to aria 2.0
17:04:33 <joanie> close what?
17:04:53 <mck> rs: Do we close issue 1006?
17:05:03 <joanie> s/close what?//
17:05:09 <mck> I think we can close the issue.
17:05:23 <mck> I will not bind action 2084 to issue 1006.
17:05:48 <mck> rs: Updating the issue and action.
17:06:33 <mck> TOPIC: SPINBUTTON AS A COMPOSITE
17:07:00 <mck> rs: to me, it is a composite. any objections?
17:07:24 <mck> bg: We need to clarify the spec text for spinbutton to spec how properties are set.
17:07:32 <Stefan> +q
17:07:44 <mck> rs: we may have diff implementations on mobile.
17:08:09 <joanie> q+ To say I don't think this is touch-specific and to offer to draft some spec text
17:08:47 <mck> MK: So far, none of our patterns in apg have mobile specific implementations.
17:09:11 <mck> bg: Our clients want the same implementation on both mobile and desktop.
17:10:09 <richardschwerdtfeger> q?
17:10:26 <mck> MK: I don't think the spec should be ambiguous about where states and props should be applied for composite roles.
17:10:51 <mck> Stefan: spinbutton is a simple composite, but when you have kb implementation, you can leave focus in one position.
17:11:21 <mck> but in mobile, you do need the buttons to be accessible.
17:11:29 <mck> q?
17:11:33 <mck> q+
17:11:39 <Stefan> -q
17:12:04 <mck> Joanie: I agree there are touch related issues.
17:12:23 <mck> I think there is advantage to adding a little text to address bryan's concerns.
17:12:29 <mck> I will volunteer to do that.
17:12:43 <mck> I don't think it is limited to the apg nor is it touch specific.
17:12:53 <mck> rs: you want to change the spec?
17:13:00 <mck> Joanie: a sentence or 2.
17:13:12 <richardschwerdtfeger> q?
17:13:16 <joanie> ack me
17:13:16 <Zakim> joanie, you wanted to say I don't think this is touch-specific and to offer to draft some spec text
17:13:16 <richardschwerdtfeger> ack joanie
17:13:33 <bgaraventa1979> +q
17:14:20 <joanie> action: Joanie to draft some language to clarify spin button children
17:14:21 <trackbot> Created ACTION-2088 - Draft some language to clarify spin button children [on Joanmarie Diggs - due 2016-06-30].
17:15:44 <mck> MK: MK: I see this as a lack of mobile browser support for aria roles.
17:16:11 <mck> rs: divs and spanc in ios safari can not process kb events
17:18:03 <mck> bg: one of the features of spinbutton is aria-valuetext.
17:18:30 <mck> If you make it composite and set focus on something else inside the control, it is not clear what will happen.
17:19:20 <mck> If you set focus inside the spinbutton, you are not interacting with the spinbutton, you are interacting with the element inside the spinbutton.
17:21:01 <Stefan> +q
17:21:14 <mck> Joanie: if the focus is on the input, and input is inside of the spinbutton, then role conveyed should be spinbutton and the value changes for the spinbutoon should be conveyed.
17:21:40 <mck> bg: so the spec needsx to say that.
17:21:41 <clown> action-2088?
17:21:41 <trackbot> action-2088 -- Joanmarie Diggs to Draft some language to clarify spin button children -- due 2016-06-30 -- OPEN
17:21:41 <trackbot> http://www.w3.org/WAI/ARIA/track/actions/2088
17:23:01 <mck> TOPIC: action 2069 separator role
17:23:04 <clown> action-2069
17:23:04 <trackbot> action-2069 -- Matthew King to Write proposal to resolve issue 1028 for the separator role -- due 2016-05-19 -- PENDINGREVIEW
17:23:04 <trackbot> http://www.w3.org/WAI/ARIA/track/actions/2069
17:23:14 <mck> rs: I didn't have any issues with what Matt put in for sperator role.
17:23:27 <mck> Did anyone not get a chance to review that?
17:23:31 <richardschwerdtfeger> http://rawgit.com/w3c/aria/action2069-separator/aria/aria.html#separator
17:23:44 <mck> I didn't see it discussed in future minutes while I was gone.
17:24:46 <mck> s/I didn't see it discussed in future minutes while I was gone./I didn't see it discussed in minutes while I was gone./
17:25:20 <mck> Joanie: wy is it exapdnable.
17:26:02 <mck> JC: it respresents when it is completely colapsed.
17:26:32 <mck> Joanie: on my platofrm, it is a value from 0 to 100
17:26:41 <mck> jc: 0 is closed and 100 is open?
17:28:17 <mck> MK: We wrote the text so it can be either a fixed or vairable separator.
17:28:40 <mck> Joanie: I am not liking it; not enough to object though>
17:32:17 <mck> jc:In sfari, we currently use presence of aria-expanded to disginguish between widget and static separator.
17:32:48 <mck> Joanie: I have no problem making distiction based on focusability.
17:32:52 <mck> JC: OK
17:33:05 <mck> CS: we have a sperate control type for movable splitters.
17:33:10 <mck> jc: bbrowser can do that.
17:33:32 <richardschwerdtfeger> q?
17:34:28 <mck> Joanie: I am not jazzed about aria-expanded.
17:34:42 <mck> on my platofmrs the mapping will say not to expose expanded.
17:34:49 <mck> rs: that is fine.
17:35:31 <mck> Janina: expanded is not the best descriptor for what is happening?
17:35:40 <mck> Joanie: yes, and it will add noise.
17:36:13 <mck> Joanie: it is something that opesn and closes, it is something that moves.
17:36:28 <mck> JN: yes, it is something that can open and closed.
17:36:30 <JaEunJemmaKu> apg doc reference https://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/#windowsplitter
17:37:41 <mck> MK: We could change it in aria 2
17:37:57 <mck> JN: We had expanded in aria 1.0
17:38:08 <richardschwerdtfeger> https://www.w3.org/TR/wai-aria/roles#separator
17:38:20 <mck> Joanie: My bad for not being aware ... that dpresses me.
17:38:33 <mck> rs: we can re-examine in 2.0
17:38:54 <mck> Joanie: do I need to move 2069 branch into master?
17:39:00 <mck> rs: yes.
17:39:35 <mck> rs: do we want an aria 2.0 spearator/spitter issue?
17:39:50 <mck> rs: I don't see verymany  of these out there.
17:39:58 <mck> jc: they are everywhere, but not accessible.
17:40:28 <mck> JN: today we use a button isntead of a separator.
17:40:37 <mck> rs: seems like we should have an issue then?
17:41:06 <mck> Joseph: we would need new elements in the AX APIs.
17:41:25 <mck> Joanie: I am for a new roel in aria 2.0.
17:41:32 <clown> s/need new elements/need new role/
17:41:43 <clown> s/need new role/need new roles/
17:41:59 <mck> TOPIC: action 2082
17:42:05 <mck> action-2082?
17:42:05 <trackbot> action-2082 -- Michael Cooper to Investigate having regular links to apg for each aria feature -- due 2016-09-16 -- OPEN
17:42:05 <trackbot> http://www.w3.org/WAI/ARIA/track/actions/2082
17:42:55 <mck> rs: Matt do you have objections moving this out?
17:43:09 <mck> MK: I don't know what is required here. I do not object.
17:43:42 <mck> MC: It was to have a link for every role. We are not ready yet. It could be an editorial issue and done later in process.
17:44:15 <mck> I prefer to see if we can do it in 1.1.
17:44:25 <mck> mK: I would like it in 1.1 if we can do it.
17:44:36 <mck> rs: we will checkpoint on it in september.
17:44:58 <mck> TOPIC: password role
17:45:07 <MichaelC> q+ to ask about implementation expectations
17:45:17 <mck> rs: some people want to move to 2.0. I don't think anything would change if we did push it out.
17:45:26 <mck> I think we have everything we need at this point.
17:45:33 <mck> We could amrk it at risk.
17:46:04 <jcraig> q+
17:46:09 <JF> Q+ to question exit criteria (2 implementations of AT doesn't cut it)
17:46:16 <mck> I think it is very important, espeically in IOS.
17:46:29 <richardschwerdtfeger> q?
17:46:32 <Stefan> -q
17:46:33 <MichaelC> ack m
17:46:34 <mck> ack me
17:46:35 <MichaelC> ack b
17:46:35 <Zakim> MichaelC, you wanted to ask about implementation expectations
17:46:43 <mck> q?
17:47:33 <mck> mc: There are still differing expectations regarding level of implementation required for it to be accepted.
17:47:44 <jcraig> ack me
17:48:20 <mck> jc: Biggest concern for me is there are specific security changes that occur when you use input type password.
17:48:33 <mck> Authors can not fake those behaviors.
17:49:22 <mck> There could be other ways of achieving the goals of preventing screen readers of echoing pw text.
17:49:50 <MichaelC> q+ to say we should focus on risks created by the password role, not on ones that are general to custom passwords
17:50:28 <mck> The proposed solution is to call the field a passwrod field, and this misleading to users b/c they may think they are typing in a secure field that really is not reasonably secure.
17:50:29 <MichaelC> q+ to ask if custom passwords w/o password role will increase or decrease user confusion
17:50:35 <MichielBijl> q+ to say an aria-masked attribute would convey that text is obfuscated, but not imply it's a secure field
17:50:55 <jamesn> q+
17:51:15 <mck> An example concern with this is type ahead suggestions.
17:51:19 <richardschwerdtfeger> q?
17:51:29 <mck> I am going to recommend not including the pw role.
17:51:29 <richardschwerdtfeger> ack JF
17:51:29 <Zakim> JF, you wanted to question exit criteria (2 implementations of AT doesn't cut it)
17:51:49 <mck> jf: A week ago I was on the same page as James.
17:52:20 <cyns> cyns has joined #aria
17:52:27 <mck> I put in a JSFiddle where I can script revealing password input.
17:53:08 <mck> This doesn't matter b/c there is no real security  in the type password.
17:53:57 <mck> jc: If js access is the onlyu concern, I would agree. but the functionality  I am talking about as risky is built into the browser.
17:54:17 <mck> jf: I pushed back really hard on this.
17:54:37 <mck> and if we get to agreement to push it out, I am on board.
17:55:03 <mck> I have a warning added for authors telling them that this role does not add security.
17:55:30 <mck> In the end, since all pw support is brittle, then the pw role does not do any damage.
17:55:35 <MichielBijl> q+ to ask if there are _any_ real world uses for this.
17:56:08 <MichaelC> ack me
17:56:08 <Zakim> MichaelC, you wanted to say we should focus on risks created by the password role, not on ones that are general to custom passwords and to ask if custom passwords w/o password role
17:56:12 <Zakim> ... will increase or decrease user confusion
17:56:19 <mck> And, we are going to have mapping that distinguishes a custom role  and a native pw input.
17:56:57 <Stefan> +q
17:57:05 <mck> mc: James, are you saying users could be more confused by the presence of the role than the abscence of the role?
17:57:43 <mck> jc: We already convey a diff between custom pw field and a standard pw field. custom pw field behaves as a text field.
17:58:17 <mck> VoiceOver treats a secure input differently.
17:58:42 <richardschwerdtfeger> q+
17:59:34 <mck> jf: My understanding is that an aria pw that does mask text, then the sr user will know that it is masked.
17:59:55 <mck> And, I am questioning the security of a secure inptu field.
18:00:41 <mck> jc: browsers save input for many fields, but not secure  input fields.
18:00:53 <richardschwerdtfeger> q+
18:00:56 <mck> jn: we can force that behaviro with autocomplete off.
18:01:13 <jamesn> s/force/get/
18:01:17 <richardschwerdtfeger> ack MichielBijl
18:01:17 <Zakim> MichielBijl, you wanted to say an aria-masked attribute would convey that text is obfuscated, but not imply it's a secure field and to ask if there are _any_ real world uses for
18:01:20 <Zakim> ... this.
18:01:38 <mck> MB: I think this is being pushed too hard and there are too many concerns.
18:01:55 <mck> We have asked for real world use cases. I have not yet seen one example of it yet.
18:02:26 <mck> I am really curious where this is happening.
18:02:55 <mck> JN: I prefer aria-masked  as a solution rather than role=password.
18:03:06 <mck> whether ti is too late for that in 1.1, i don't know.
18:03:25 <JF> +1 to aria-masked as well - and we can revisit actual "custom password" inputs in the 2.0 time-frame
18:03:45 <richardschwerdtfeger> q?
18:03:45 <mck> jc: it i usually done with a checkbox that toggles the type of the input between password and text
18:03:51 <richardschwerdtfeger> ack jamesn
18:04:14 <jcraig> +1 to aria-masked or another attribute to prevent speech, rather than a password role
18:04:47 <mck> Stefan: Is there a reason that browsers could not change behavior based on the aria role password.
18:04:50 <JF> +1 Stefan, but this is counter to the ARIA principle of no browser impact...
18:04:55 <richardschwerdtfeger> q?
18:05:00 <MichaelC> ack s
18:07:02 <JF> me/ I realize we are running over, but I'd like to Q+
18:08:00 <mck> rs: Other option is to have a special mapping that tells the user it is a custom pw rield.
18:08:06 <JF> Q+
18:08:24 <MichaelC> q+ to ask next steps
18:08:27 <MichaelC> ack r
18:08:48 <mck> If you just have a label of pw, then screen readers will echo text, even if it is visually masked.
18:08:50 <MichaelC> q+ to say some of the concerns are now coming more clear
18:08:55 <MichaelC> ack j
18:08:59 <MichielBijl> 1+ to say aria-masked could prevent echo if AT support
18:09:05 <MichielBijl> q+*
18:09:17 <MichielBijl> q+ to say aria-masked could prevent echo if AT support
18:09:27 <MichaelC> q- *
18:09:34 <mck> jf: Given we have long standing principle that aria does not change browser behavior, can we ask for a single exception to that?
18:10:05 <richardschwerdtfeger> q?
18:10:11 <mck> And, expand the type to any editable region rather than just an input.
18:10:15 <mck> q?
18:10:48 <mck> jc: if that is the approach you want to take, than it should happen in TPC with the html working group.
18:11:07 <mck> And, I would be on the opposing side. If you want a pw, us pw inpjut type.
18:11:25 <mck> jf: I have heard of use case with svg that could justify it.
18:11:35 <MichaelC> q+ to see we can´t enforce ¨only use native password¨ - but echo that I don´t know how widespread custom passwords are
18:11:40 <mck> I don't see why it has to be the input element.
18:12:08 <mck> jc: if you want to code that up today, don't use input type text. Just use a div that doesn't have a text value.
18:12:27 <mck> Nothing would get spoken and there would not be any security implications.
18:12:47 <mck> maybe you use role=textbox.
18:13:03 <MichaelC> ack me
18:13:03 <Zakim> MichaelC, you wanted to ask next steps and to say some of the concerns are now coming more clear and to see we can´t enforce ¨only use native password¨ - but echo that I don´t
18:13:05 <mck> That is more secure than using native text field.
18:13:06 <Zakim> ... know how widespread custom passwords are
18:13:55 <mck> mc: I am not sure we can enforce that. I have not seen theveidence this is a wide spread problem we must address now.
18:14:19 <jcraig> s/doesn't have a text value./doesn't have a text value. Just capture the key events on the div and check the charCode./
18:14:20 <mck> I feel some of the risks we have been talking about have been addressed.
18:14:28 <mck> I want to think about next steps.
18:14:32 <clown> clown has left #aria
18:14:35 <mck> I have been supporting wide review.
18:14:37 <clown> clown has joined #aria
18:14:45 <mck> rs: 2 things:
18:15:01 <mck> 1. James N, Oracle has seen instances.
18:15:32 <JF> What james said: https://github.com/w3c/aria/issues/166#issuecomment-172969506
18:15:41 <mck> JN: NO, my developers said that they do not do it but they have heard the reason is that some people do not want pws stored in pw managers.
18:16:04 <mck> cs: I have seen blog posts about how to do it so people can customize the behavior of the pw field.
18:16:19 <mck> but I have not found any example of sites that are doing it. so maybe not that urgent.
18:16:25 <jcraig> q+ to say, since the proponents this is "theoretical" or "not wide spread" then why is this being considered for a point 1 (ARIA 1.1) release (stay on scoping target, red leader)
18:16:30 <mck> jn: More like to find it on a small site.
18:16:58 <mck> mc: I am hearing hear-say evidence of need, but not acual need.
18:17:06 <mck> rs: I agree with that.
18:17:08 <MichielBijl> ack me
18:17:08 <Zakim> MichielBijl, you wanted to say aria-masked could prevent echo if AT support
18:17:09 <mck> q?
18:17:43 <mck> rs: Can I aske people to show examples of where this is happening.
18:18:01 <mck> If none exist, then maybe that is reason to justify pushing out to 2.0.
18:18:14 <MichielBijl> q+ to say: Twitter, Facebook, Google, Microsoft (live.com), IBM ID, Amazon, Apple, IMDb, even Slack all use type=password.
18:19:23 <MichaelC> ack m
18:19:23 <Zakim> MichielBijl, you wanted to say: Twitter, Facebook, Google, Microsoft (live.com), IBM ID, Amazon, Apple, IMDb, even Slack all use type=password.
18:19:42 <mck> mb: Just want to say none of the major sites I looked at use custom pw fields.
18:20:06 <mck> rs: good, thanks, maybe this is not urgent then.
18:20:19 <mck> Group has done good work on this issue.
18:20:33 <mck> I would like us to move to the last call draft next week.
18:20:35 <jcraig> good segue leading into my q+
18:20:36 <jcraig> ack me
18:20:36 <Zakim> jcraig, you wanted to say, since the proponents this is "theoretical" or "not wide spread" then why is this being considered for a point 1 (ARIA 1.1) release (stay on scoping
18:20:39 <Zakim> ... target, red leader)
18:20:52 <MichielBijl> rs: could move to 2.0 if we can't find any cases
18:20:54 <MichaelC> q+ to say APA and RQTF want to investigate password alternatives, probably will seek discussion with WebAppSec at TPAC
18:21:27 <mck> jc: I agree that this is likely edge case and that is sufficient justification for pushing out to 2.0.
18:21:50 <MichaelC> ack me
18:21:50 <Zakim> MichaelC, you wanted to say APA and RQTF want to investigate password alternatives, probably will seek discussion with WebAppSec at TPAC
18:22:10 <mck> I think that applies to more than just the pw roel and the leadership should be brutal about cutting stuff from 1.1 if group is concerned about scope of 1.1.
18:22:43 <richardschwerdtfeger> yes
18:22:48 <richardschwerdtfeger> defer to next week
18:22:48 <mck> mc: We have a week for someone to convince of need of pw role or it gets deferred.
18:22:53 <richardschwerdtfeger> np
18:23:02 <mck> and lc draft will be next week.
18:23:27 <mck> cs: can testing be at top of agenda next wek?
18:23:33 <mck> rs: yes.
18:23:43 <mck> rrsagent, make minutes
18:23:43 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/23-aria-minutes.html mck
18:55:28 <clown> clown has joined #aria
19:02:20 <jcraig> jcraig has joined #aria
20:03:22 <jcraig> jcraig has joined #aria
20:44:26 <Zakim> Zakim has left #aria
22:06:15 <jcraig> jcraig has joined #aria
22:26:57 <jcraig> jcraig has joined #aria
22:40:41 <jcraig> jcraig has joined #aria
22:45:10 <jcraig> jcraig has joined #aria
22:50:30 <jcraig> jcraig has joined #aria
23:00:56 <chaals> chaals has joined #aria
23:05:22 <jcraig> jcraig has joined #aria
23:18:35 <jcraig> jcraig has joined #aria
23:19:18 <jcraig> jcraig has joined #aria
23:32:19 <jcraig> jcraig has joined #aria
23:52:19 <MichaelC_> MichaelC_ has joined #aria