See also: IRC log
<richardschwerdtfeger> chair: Rich
<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria/2016Jun/0156.html
<scribe> scribe: matt_king
action-2067?
<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
<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2067
<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0043.html
<richardschwerdtfeger> ttps://www.w3.org/WAI/ARIA/track/actions/2067
RS: I didn't see any objections
to the cfc.
... action 2067 reached consensus.
<richardschwerdtfeger> https://www.w3.org/WAI/ARIA/track/actions/2067
TOPIC_ password role restriction cfc
rs: didn't see objections to the
proposed note
... in the future, this role could change, but I am not
objecting to it at this time.
action-2080?
<trackbot> action-2080 -- Joanmarie Diggs to Draft aria spec text limiting the use of role password on editable objects -- due 2016-06-09 -- PENDINGREVIEW
<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2080
<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0029.html
Joseph: Yes, I commented but am fine with it.
<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0028.html
RS: we didn't reach consensus
lot of discussion on this one.
James N gave example with menus including menuitems that have menus as children.
JN: menuitemradio and menuitemcheckbox are a bit weird that way, but spec does allow it.
rs: not sure what we do with it at this point.
what is impact if we do not make children presentational?
BG: Right now every thing is exposed.
What I recommend for this particular issue is to remove those 4 attribs from the proposal (treeitem, menuitem, menuitemradio, menuitemcheckbox)
And do something separate with them.
RS: need an aria 1.1 compromise so we we can get 1.1 done.
We can make a separate issue for treeitem and menuitem, and we can address this with authroing practices.
Suggestion is to have children presentational on radio, checkbox, option, menuitemradio and menuitemcheckbox
BG: I am not sure about tree tiem, menuitem, and menuitemcheckbox
MK: We should not allow menuitemradio to have semantic children
JN: Table of owned elments for menuitemradio right now allows for mchild menus
<clown> https://rawgit.com/w3c/aria/master/aria/aria.html#menuitemradio
<richardschwerdtfeger> http://rawgit.com/w3c/aria/master/aria/aria.html#menuitemradio
<clown> https://rawgit.com/w3c/aria/master/aria/aria.html#menuitemcheckbox
Joanie: we had a cfc and it was approved so menuitemradio right now has children presentational true.
<joanie> confirmed
<joanie> action-2071
<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
<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2071
Joanie: I completed action 2071 that added children presentational to multiple roles.
rs: We need to partially
undo
... remove from menuitem and treeitem
Joanie: and remove from spinbutton. And there is a separate action to make spinbutton composite.
rs: I'd like to have one branch that deals with presentational children as we want it.
and then put that out for cfc.
Joanie: I agree about spin button can not have children presentational true.
RS: summarize proposal: remove children presentational true from menuitem, treeitem, and spinbutton.
<clown> +1
<joanie> +1
<richardschwerdtfeger> +1
<JaEunJemmaKu> +1
+1
RESOLUTION: Modify current master, partially reversing action 2071, to remove children presentation true from menuitem, treeitem, and spinbutton.
<joanie> action Joanie to create a branch removing children presentational from menuitem, treeitem, and spinbutton
<trackbot> Created ACTION-2087 - Create a branch removing children presentational from menuitem, treeitem, and spinbutton [on Joanmarie Diggs - due 2016-06-30].
action-2084?
<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
<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2084
<clown> action-2084
<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
<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2084
<jcraig> +1 to removing children presentational on spinbutton
MK: push action 2084 to aria 2.0
rs: Do we close issue 1006?
I think we can close the issue.
I will not bind action 2084 to issue 1006.
rs: Updating the issue and action.
rs: to me, it is a composite. any objections?
bg: We need to clarify the spec text for spinbutton to spec how properties are set.
<Stefan> +q
rs: we may have diff implementations on mobile.
MK: So far, none of our patterns in apg have mobile specific implementations.
bg: Our clients want the same implementation on both mobile and desktop.
MK: I don't think the spec should be ambiguous about where states and props should be applied for composite roles.
Stefan: spinbutton is a simple composite, but when you have kb implementation, you can leave focus in one position.
but in mobile, you do need the buttons to be accessible.
<Stefan> -q
Joanie: I agree there are touch related issues.
I think there is advantage to adding a little text to address bryan's concerns.
I will volunteer to do that.
I don't think it is limited to the apg nor is it touch specific.
rs: you want to change the spec?
Joanie: a sentence or 2.
<Zakim> joanie, you wanted to say I don't think this is touch-specific and to offer to draft some spec text
<bgaraventa1979> +q
<joanie> ACTION: Joanie to draft some language to clarify spin button children [recorded in http://www.w3.org/2016/06/23-aria-minutes.html#action01]
<trackbot> Created ACTION-2088 - Draft some language to clarify spin button children [on Joanmarie Diggs - due 2016-06-30].
MK: MK: I see this as a lack of mobile browser support for aria roles.
rs: divs and spanc in ios safari can not process kb events
bg: one of the features of spinbutton is aria-valuetext.
If you make it composite and set focus on something else inside the control, it is not clear what will happen.
If you set focus inside the spinbutton, you are not interacting with the spinbutton, you are interacting with the element inside the spinbutton.
<Stefan> +q
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.
bg: so the spec needsx to say that.
<clown> action-2088?
<trackbot> action-2088 -- Joanmarie Diggs to Draft some language to clarify spin button children -- due 2016-06-30 -- OPEN
<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2088
<clown> action-2069
<trackbot> action-2069 -- Matthew King to Write proposal to resolve issue 1028 for the separator role -- due 2016-05-19 -- PENDINGREVIEW
<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2069
rs: I didn't have any issues with what Matt put in for sperator role.
Did anyone not get a chance to review that?
<richardschwerdtfeger> http://rawgit.com/w3c/aria/action2069-separator/aria/aria.html#separator
I didn't see it discussed in minutes while I was gone.
Joanie: wy is it exapdnable.
JC: it respresents when it is completely colapsed.
Joanie: on my platofrm, it is a value from 0 to 100
jc: 0 is closed and 100 is open?
MK: We wrote the text so it can be either a fixed or vairable separator.
Joanie: I am not liking it; not enough to object though>
jc: In sfari, we currently use presence of aria-expanded to disginguish between widget and static separator.
Joanie: I have no problem making distiction based on focusability.
JC: OK
CS: we have a sperate control type for movable splitters.
jc: bbrowser can do that.
Joanie: I am not jazzed about aria-expanded.
on my platofmrs the mapping will say not to expose expanded.
rs: that is fine.
Janina: expanded is not the best descriptor for what is happening?
Joanie: yes, and it will add
noise.
... it is something that opesn and closes, it is something that
moves.
JN: yes, it is something that can open and closed.
<JaEunJemmaKu> apg doc reference https://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/#windowsplitter
MK: We could change it in aria 2
JN: We had expanded in aria 1.0
<richardschwerdtfeger> https://www.w3.org/TR/wai-aria/roles#separator
Joanie: My bad for not being aware ... that dpresses me.
rs: we can re-examine in 2.0
Joanie: do I need to move 2069 branch into master?
rs: yes.
... do we want an aria 2.0 spearator/spitter issue?
... I don't see verymany of these out there.
jc: they are everywhere, but not accessible.
JN: today we use a button isntead of a separator.
rs: seems like we should have an issue then?
Joseph: we would need new roles in the AX APIs.
Joanie: I am for a new roel in aria 2.0.
action-2082?
<trackbot> action-2082 -- Michael Cooper to Investigate having regular links to apg for each aria feature -- due 2016-09-16 -- OPEN
<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2082
rs: Matt do you have objections moving this out?
MK: I don't know what is required here. I do not object.
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.
I prefer to see if we can do it in 1.1.
mK: I would like it in 1.1 if we can do it.
rs: we will checkpoint on it in september.
rs: some people want to move to 2.0. I don't think anything would change if we did push it out.
I think we have everything we need at this point.
We could amrk it at risk.
I think it is very important, espeically in IOS.
<Stefan> -q
<Zakim> MichaelC, you wanted to ask about implementation expectations
mc: There are still differing expectations regarding level of implementation required for it to be accepted.
jc: Biggest concern for me is there are specific security changes that occur when you use input type password.
Authors can not fake those behaviors.
There could be other ways of achieving the goals of preventing screen readers of echoing pw text.
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.
An example concern with this is type ahead suggestions.
I am going to recommend not including the pw role.
<Zakim> JF, you wanted to question exit criteria (2 implementations of AT doesn't cut it)
jf: A week ago I was on the same page as James.
I put in a JSFiddle where I can script revealing password input.
This doesn't matter b/c there is no real security in the type password.
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.
jf: I pushed back really hard on this.
and if we get to agreement to push it out, I am on board.
I have a warning added for authors telling them that this role does not add security.
In the end, since all pw support is brittle, then the pw role does not do any damage.
<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
And, we are going to have mapping that distinguishes a custom role and a native pw input.
<Stefan> +q
mc: James, are you saying users could be more confused by the presence of the role than the abscence of the role?
jc: We already convey a diff between custom pw field and a standard pw field. custom pw field behaves as a text field.
VoiceOver treats a secure input differently.
jf: My understanding is that an aria pw that does mask text, then the sr user will know that it is masked.
And, I am questioning the security of a secure inptu field.
jc: browsers save input for many fields, but not secure input fields.
jn: we can get that behaviro with autocomplete off.
<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
MB: I think this is being pushed too hard and there are too many concerns.
We have asked for real world use cases. I have not yet seen one example of it yet.
I am really curious where this is happening.
JN: I prefer aria-masked as a solution rather than role=password.
whether ti is too late for that in 1.1, i don't know.
<JF> +1 to aria-masked as well - and we can revisit actual "custom password" inputs in the 2.0 time-frame
jc: it i usually done with a checkbox that toggles the type of the input between password and text
<jcraig> +1 to aria-masked or another attribute to prevent speech, rather than a password role
Stefan: Is there a reason that browsers could not change behavior based on the aria role password.
<JF> +1 Stefan, but this is counter to the ARIA principle of no browser impact...
<JF> me/ I realize we are running over, but I'd like to Q+
rs: Other option is to have a special mapping that tells the user it is a custom pw rield.
If you just have a label of pw, then screen readers will echo text, even if it is visually masked.
<MichielBijl> 1+ to say aria-masked could prevent echo if AT support
jf: Given we have long standing principle that aria does not change browser behavior, can we ask for a single exception to that?
And, expand the type to any editable region rather than just an input.
jc: if that is the approach you want to take, than it should happen in TPC with the html working group.
And, I would be on the opposing side. If you want a pw, us pw inpjut type.
jf: I have heard of use case with svg that could justify it.
I don't see why it has to be the input element.
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. Just capture the key events on the div and check the charCode.
Nothing would get spoken and there would not be any security implications.
maybe you use role=textbox.
<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
That is more secure than using native text field.
mc: I am not sure we can enforce that. I have not seen theveidence this is a wide spread problem we must address now.
I feel some of the risks we have been talking about have been addressed.
I want to think about next steps.
I have been supporting wide review.
rs: 2 things:
1. James N, Oracle has seen instances.
<JF> What james said: https://github.com/w3c/aria/issues/166#issuecomment-172969506
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.
cs: I have seen blog posts about how to do it so people can customize the behavior of the pw field.
but I have not found any example of sites that are doing it. so maybe not that urgent.
jn: More like to find it on a small site.
mc: I am hearing hear-say evidence of need, but not acual need.
rs: I agree with that.
<Zakim> MichielBijl, you wanted to say aria-masked could prevent echo if AT support
rs: Can I aske people to show examples of where this is happening.
If none exist, then maybe that is reason to justify pushing out to 2.0.
<Zakim> MichielBijl, you wanted to say: Twitter, Facebook, Google, Microsoft (live.com), IBM ID, Amazon, Apple, IMDb, even Slack all use type=password.
mb: Just want to say none of the major sites I looked at use custom pw fields.
rs: good, thanks, maybe this is not urgent then.
Group has done good work on this issue.
I would like us to move to the last call draft next week.
<jcraig> good segue leading into my q+
<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
<MichielBijl> rs: could move to 2.0 if we can't find any cases
jc: I agree that this is likely edge case and that is sufficient justification for pushing out to 2.0.
<Zakim> MichaelC, you wanted to say APA and RQTF want to investigate password alternatives, probably will seek discussion with WebAppSec at TPAC
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.
<richardschwerdtfeger> yes
<richardschwerdtfeger> defer to next week
mc: We have a week for someone to convince of need of pw role or it gets deferred.
<richardschwerdtfeger> np
and lc draft will be next week.
cs: can testing be at top of agenda next wek?
rs: yes.
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/close what?// Succeeded: 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./ Succeeded: s/need new elements/need new role/ Succeeded: s/need new role/need new roles/ Succeeded: s/force/get/ Succeeded: 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./ No ScribeNick specified. Guessing ScribeNick: mck Found Scribe: matt_king Present: Joanmarie_Diggs Rich_Schwerdtfeger MichaelC Janina JaEunJemmaKu Michiel_Bijl matt_king fesch JF Bryan_Garaventa Joseph_Scheuhammer jongund Found Date: 23 Jun 2016 Guessing minutes URL: http://www.w3.org/2016/06/23-aria-minutes.html People with action items: joanie WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]