IRC log of aria on 2016-03-31

Timestamps are in UTC.

16:24:20 [RRSAgent]: RRSAgent has joined #aria
16:24:20 [RRSAgent]: logging to http://www.w3.org/2016/03/31-aria-irc
16:24:22 [trackbot]: RRSAgent, make logs world
16:24:22 [Zakim]: Zakim has joined #aria
16:24:24 [trackbot]: Zakim, this will be
16:24:24 [Zakim]: I don't understand 'this will be', trackbot
16:24:25 [trackbot]: Meeting: Accessible Rich Internet Applications Working Group Teleconference
16:24:25 [trackbot]: Date: 31 March 2016
16:24:28 [Rich]: chair: Rich
16:24:35 [Rich]: RRSAgent, make log public
16:26:49 [MichielBijl]: present+ Michiel_Bijl
16:28:16 [mck]: mck has joined #aria
16:28:18 [joanie]: present+ Joanmarie_Diggs
16:28:56 [Rich]: https://lists.w3.org/Archives/Public/public-aria/2016Mar/0218.html
16:29:04 [fesch]: fesch has joined #aria
16:29:12 [Rich]: present+ Rich_Schwerdtfeger
16:30:13 [fesch]: present+ fesch
16:31:45 [janina]: present+ Janina
16:32:44 [mck]: present+ matt_king
16:34:24 [cyns]: cyns has joined #aria
16:36:27 [Rich]: https://lists.w3.org/Archives/Public/public-aria/2016Mar/0218.html
16:36:54 [fesch]: scribe: fesch
16:37:07 [fesch]: Topic: CSUN roundtable discussion
16:37:13 [jongund]: jongund has joined #aria
16:37:17 [jemma]: jemma has joined #aria
16:37:18 [fesch]: s/discussion//
16:38:01 [fesch]: js: refreshable Braille display for $500 announced at CSUN! Bluetooth...
16:38:01 [jemma]: can someone copy webx meeting url?
16:38:08 [clown]: clown has joined #aria
16:38:36 [fesch]: s/roundtable/round the table/
16:38:59 [fesch]: js: quality of dots are great...
16:39:18 [clown]: present+ Joseph_Scheuhammer
16:39:23 [jongund]: what is the URL fro webex?
16:40:50 [jongund]: what is the webex room number?
16:40:54 [jamesn]: jamesn has joined #aria
16:41:03 [jemma]: yeah. it asks Enter the meeting number to join.
16:41:05 [jamesn]: rrsagent, make minutes
16:41:05 [RRSAgent]: I have made the request to generate http://www.w3.org/2016/03/31-aria-minutes.html jamesn
16:41:14 [fesch]: Topic: CFC for Password Role
16:41:26 [jongund]: or host room id
16:41:46 [fesch]: rs: folks are making custom widgets that take passwords
16:42:00 [jongund]: can't seem to join webex
16:42:12 [fesch]: mk: AT are capable of echoing keys, not all users choose to echo keys
16:42:45 [fesch]: mk: most screen readers may have key echo on by default - new users may not know how to turn it off
16:43:04 [jemma]: present + JaEunJemmaKu
16:43:43 [fesch]: rs: if echoing characters, with a input / password some AT say * instead of echoing keys... but text may be visible and they won't be aware
16:43:46 [joanie]: q+ To make slight clarification about "require"
16:43:57 [clown]: q+ to ask how to get the rendered characters.
16:44:02 [fesch]: rs: Joanie Diggs has a solution... describes....
16:44:38 [fesch]: rs: talking with AT vendors... one vendor doesn't have a problem with a MUST being added to the spec
16:44:40 [jamesn]: q+
16:44:47 [MichaelC]: q+ to ask about AT MUST, with precedent and what happens if not all covered
16:44:49 [cyns]: q=
16:44:53 [cyns]: q+
16:45:09 [fesch]: mc: can't be sure that password is hidden on the screen
16:45:30 [Rich]: q?
16:45:37 [Rich]: ack joanie
16:45:37 [Zakim]: joanie, you wanted to make slight clarification about "require"
16:45:39 [fesch]: s /mc/mb/
16:46:41 [MichaelC]: q+ to ask do we have consensus of the issue that authors will create non-password passwords?
16:46:46 [fesch]: jd: even if we don't create a password role, there are already things that can toggle whether keys are displayed or not, screen readers need to ...
16:46:47 [janina]: q+ To note that you need to be able to have some kind of echo in mobile
16:47:03 [MichaelC]: q+ to say seems to me most important that users know it´s a password; they can take local security steps if they feel the need
16:47:20 [mck]: q?
16:47:21 [mck]: q+
16:47:28 [Rich]: ack clown
16:47:28 [Zakim]: clown, you wanted to ask how to get the rendered characters.
16:47:45 [fesch]: jd: we should go to each AT vendor and see what they do, if they are only showing stars then we need to convince them what is wrong
16:48:09 [Rich]: q?
16:48:10 [fesch]: jd: an AT gets it from the accessible text API
16:48:35 [fesch]: jd: when we get, we always get the rendered text
16:48:53 [fesch]: js: Can you point to a password, in the wild?
16:49:01 [fesch]: rs: came from Cyns...
16:49:18 [joanie]: s/when we get/for all elements, when ATs get the text/
16:49:47 [fesch]: cyns: came from James Nurthen... my security people say adding a password role does not increase risk because of physical presence
16:50:07 [mck]: q?
16:50:21 [fesch]: cyns: only possibility is an over the shoulder attack which requires physical presence
16:50:23 [bgaraventa1979]: bgaraventa1979 has joined #aria
16:50:29 [Rich]: ack jamesn
16:50:50 [bgaraventa1979]: bgaraventa1979 has joined #aria
16:51:14 [bgaraventa1979]: present+ Bryan_Garaventa
16:51:44 [fesch]: jn: I haven't seen one, but asked my security team - they said that folks want to avoid password managers and the way to work around that - they do not use a password field, because they want to suppress autocomplete on password fields
16:52:08 [Rich]: q?
16:52:09 [fesch]: js: firefox doesn't support autocomplete in passwords,
16:52:24 [fesch]: jn: but you can't stop password managers
16:52:57 [clown]: s/support autocomplete in passwords/support autocomplete in input type=password/
16:53:02 [Rich]: q?
16:53:02 [MichaelC]: ack me
16:53:03 [Zakim]: MichaelC, you wanted to ask about AT MUST, with precedent and what happens if not all covered and to ask do we have consensus of the issue that authors will create non-password
16:53:03 [Zakim]: ... passwords? and to say seems to me most important that users know it´s a password; they can take local security steps if they feel the need
16:53:07 [Rich]: ack MichaelC
16:53:07 [fesch]: jn: think attacking screen reader users, is a red herring
16:53:42 [fesch]: mc: discussion predicates that people don't use a input password field
16:54:02 [fesch]: mc: if authors don't use something else, then it isn't needed
16:54:16 [cyns]: q?
16:54:38 [fesch]: mc: what about the MUST in the spec, one vendor agrees, but we need more input
16:55:12 [fesch]: mc: looking through all the options, the best thing is letting the user know it is a password, so even if there isn't tool support then they are more vunerable
16:55:29 [Rich]: q?
16:55:36 [fesch]: mc: an authoring practice - put password in you label could help as well
16:55:55 [fesch]: cs: I raised this, it seems like a hole in a spec
16:55:55 [MichielBijl]: q+
16:56:15 [fesch]: cs: in my experience developers will make anything...
16:56:41 [fesch]: cs: my security folks said adding password role would not increase a security risk
16:56:52 [Rich]: q?
16:56:56 [Rich]: ack cyns
16:57:23 [fesch]: js: wanted to make sure we consider mobile - where you have to hear the keys you are using
16:57:45 [Rich]: ack janina
16:57:45 [Zakim]: janina, you wanted to note that you need to be able to have some kind of echo in mobile
16:57:57 [Rich]: ack mck
16:58:02 [fesch]: js: if someone is standing over your shoulder, then you have to have a solution... I lowered the volume... to do that
16:58:23 [Rich]: q?
16:58:30 [fesch]: mk: I am wary of doing an AT MUST path, no problem with an AT SHOULD
16:58:54 [Rich]: q+
16:59:01 [cyns]: q+ to say I'd like to see AT MUST as a general thing, but as an intentional decision, not by backing into it
16:59:18 [joanie]: I am too (which is the summary of my earlier comment which Fred asked me to minute)
16:59:42 [fesch]: mk: also rare when an AT user is unaware that they are typing in a password, so the user can already take action (mute echo...) to protect themselves
17:00:12 [fesch]: mk: so we are designing for the AT not the user... that is the primary purpose... not anything for the end user
17:01:07 [fesch]: mk: if you do input type=password does the value have the password value in clear text? Would that impact the AT ability to obscure the text?
17:01:54 [fesch]: js: I made a similar statement about the value in the password field is plain text.
17:02:03 [Rich]: q?
17:02:04 [fesch]: jd: no
17:02:23 [fesch]: jd: the rendered text is what you get in the AT
17:02:49 [fesch]: mc: in the accessibility API you don't get the plain text
17:02:55 [Rich]: ack MichielBijl
17:03:01 [fesch]: s/mc/mb/
17:03:03 [mck]: ack me
17:03:21 [fesch]: mb: I don't think we really need the role
17:03:41 [fesch]: cs: that is the point, HTML has it and ARIA doesn't have it
17:04:04 [fesch]: rs: password is not in SVG...
17:04:41 [MichaelC]: ack R
17:04:44 [fesch]: rs: in ARIA 1.1 we are trying to align with HTML and SVG, and someone is making passwords right now
17:04:59 [Rich]: q?
17:05:05 [fesch]: rs: I don't mind a SHOULD rather than a MUST but we should talk with AT vendors...
17:05:07 [MichielBijl]: ack MichielBijl
17:05:15 [MichaelC]: q+ to wonder if security issues are indeed a special case we might consider globally
17:05:25 [MichaelC]: ack c
17:05:25 [Zakim]: cyns, you wanted to say I'd like to see AT MUST as a general thing, but as an intentional decision, not by backing into it
17:05:35 [fesch]: cs: I think AT MUST is a good thing, but we need to make sure it is attentional --- all specs should be a MUST
17:05:36 [joanie]: +1 To talk to the AT vendors, because it's a bug if they fail to do this in any password input (it has nothing to do with this role).
17:05:40 [fesch]: rs: OHHH
17:05:47 [Rich]: q?
17:05:51 [Rich]: ack MichaelC
17:05:51 [Zakim]: MichaelC, you wanted to wonder if security issues are indeed a special case we might consider globally
17:06:16 [mck]: q+
17:06:21 [fesch]: mc: I wonder if security issues are a reason to have an exception to our normal rules
17:06:45 [janina]: q+ To say this may be the AT must exception that proves the rule, but discuss with vendors before finalizing
17:06:54 [fesch]: mc: I don't know if there are other ARIA roles that impact security... they might be subject to with a MUST
17:07:24 [fesch]: rs: AT vendors did not want to be dictated to, they want to be able to innovate
17:07:58 [joanie]: q+ To say that mappings should automatically cause ATs to do whatever they do with other password inputs (like input type="password").
17:08:12 [fesch]: rs: had problems with MUST with first user agent guidelines.... I appreciate they want to innovate, more willing to do MUST for security
17:08:12 [sam]: sam has joined #aria
17:08:21 [Rich]: ack mck
17:08:33 [fesch]: cs: plenty of vendors would prefer not to have standards, doesn't make it right
17:08:36 [sam_]: sam_ has joined #aria
17:09:42 [janina]: q-
17:09:47 [fesch]: mk: I would argue that there is not necessarily a security issue if they don't do anything, there may be convenience thing ... other ways to mitigate risk - head phones...
17:09:59 [fesch]: mk: I don't think there is a clear risk
17:09:59 [Rich]: q?
17:10:02 [Rich]: ack joanie
17:10:02 [Zakim]: joanie, you wanted to say that mappings should automatically cause ATs to do whatever they do with other password inputs (like input type="password").
17:10:05 [mck]: ack me
17:10:47 [fesch]: jd: should have it do same thing it does for input type=password....
17:11:02 [cyns]: q+ to say that we don't expose the value of password input in UIA but do for text input
17:11:04 [fesch]: mk: good point, if they already do something, then they are good to go
17:11:24 [fesch]: rs: that is if they use input password
17:11:37 [Rich]: q?
17:11:44 [Rich]: ack cyns
17:11:44 [Zakim]: cyns, you wanted to say that we don't expose the value of password input in UIA but do for text input
17:11:48 [fesch]: mc: we are asking them to map the password role to whatever they do for input type password
17:12:09 [Rich]: q?
17:12:19 [fesch]: cs: for UIA, we don't expose text for input password for text we do....
17:12:25 [MichaelC]: q+ to draft a consensus expression
17:12:53 [fesch]: mk: I hear consensus on a AT SHOULD rather than a MUST
17:13:05 [clown]: q+ to suggest that authors MUST obscure the text for a custom password ?
17:13:21 [fesch]: mk: we understand the risks Leonie raised...
17:13:50 [mck]: +1
17:13:53 [janina]: +1
17:13:59 [Rich]: q?
17:14:03 [MichaelC]: ack me
17:14:03 [Zakim]: MichaelC, you wanted to draft a consensus expression
17:14:03 [fesch]: rs: do people have an object to Joanie to modifying her branch and putting it out for consensus?
17:14:17 [fesch]: mc: I agree with that and Matt summarized it ...
17:14:27 [Rich]: q?
17:14:57 [MichaelC]: q+ to respond on author must
17:15:32 [MichaelC]: ack c
17:15:32 [Zakim]: clown, you wanted to suggest that authors MUST obscure the text for a custom password ?
17:15:35 [fesch]: js: do we want to include that authors MUST obscure the text on a custom password field , unless there is a checkbox saying show in plain text
17:15:52 [fesch]: rs: I don't know if we can do that, can't test for that
17:16:01 [Rich]: q?
17:16:06 [fesch]: rs: could have a authors SHOULD....
17:16:41 [fesch]: mk: the thing we should do is have AT's echo what is visible on the screen...
17:16:48 [Rich]: https://rawgit.com/w3c/aria/password-role/aria/aria.html#password
17:17:08 [MichaelC]: q-
17:17:13 [fesch]: mk: it's fine as long as AT user is aware the password is/isn't obscurred
17:17:28 [Rich]: q?
17:17:34 [fesch]: rs: Joanie OK with the changes?
17:17:47 [fesch]: jd: should not allow on input type text
17:18:08 [fesch]: jd: how would someone obscure it?
17:18:18 [fesch]: js: you have a script ...
17:18:28 [Rich]: q?
17:18:59 [fesch]: mc: would be hard to have a requirement in ARIA spec, have to go into HTML spec...
17:19:20 [fesch]: rs: each element in HTML 5.1 can restrict roles...
17:19:24 [Rich]: q?
17:19:37 [fesch]: mc: that would have to be taken to the HTML group
17:20:06 [fesch]: jd: only changes are about AT relaying the visible text
17:20:29 [clown]: https://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-input-password
17:20:53 [fesch]: mc: part of the discussion is to have it map to the same way input type password works - has that been done?
17:20:56 [fesch]: js: yes
17:21:52 [fesch]: RESOLUTION: Password role brings value even if not fully supported, UAs should map same as they map input type=password, want AT SHOULD but not MUST to enhance
17:24:02 [fesch]: rs: want to address ARIA key shortcuts... but being able to predict and warn the author where it produces a new single key is enormous and a giant rat hole ...
17:24:32 [Rich]: q?
17:24:33 [fesch]: rs: authors need to test with different keyboards...
17:25:10 [fesch]: mk: if you come up with wording that satisfies what folks have been raising...
17:25:30 [fesch]: rs: right now keyset is not global.... it should be global
17:25:52 [fesch]: rs: trying to do it in a single attribute could be a mess
17:26:06 [fesch]: mk: drafted wording already...
17:26:29 [Rich]: q+
17:26:58 [fesch]: Topic: ARIA key shortcuts (already ongoing)
17:27:50 [fesch]: mk: if the key shortcut is for the submit buttons... but if it is a landmark region that can't be activated, then the user will realize that focus will just be moved there
17:28:00 [Rich]: q?
17:28:24 [fesch]: mk: AT doesn't know the difference between the two scenarios - change focus vs activate
17:28:42 [fesch]: mk: all shortcuts do is document what is happening
17:29:42 [cyns]: +1
17:29:51 [fesch]: mk: key shortcuts is only communicating information - not providing support (onclick) - only purpose to provide information - doesn't add in functionality
17:30:23 [ShaneM]: note that the Access element that Rich proposed years ago had a way of indicating whether the shortcut should change focus or change focus AND activate.
17:30:46 [fesch]: mk: when you go into software today, and you hear a keyboard shortcut - they only thing the AT does is make an announcement
17:31:11 [fesch]: mk: screen reader may have a hot key - it doesn't tell you what the keyboard shortcut does -
17:31:51 [cyns]: q+ to ask whether focus vs. activate might be role-specific? for example, buttons invoke and an edits focus?
17:31:56 [fesch]: rs: you have user interface conventions, on the web we don't have consistent conventions for keys...
17:32:36 [fesch]: mk: purpose only for providing information - no plans for the property to tell the AT what the response to the key is
17:32:48 [fesch]: rs: what if you want an activate and a focus?
17:32:58 [fesch]: mk: not possible with what is proposed
17:33:08 [fesch]: mk: would be odd and silly
17:33:12 [fesch]: rs: why?
17:33:28 [fesch]: rs: why isn't what Chaals proposed enough?
17:33:55 [fesch]: jn: those are proposed - this documents what we have done in JavaScript
17:34:17 [fesch]: rs: neither of you have convinced me...
17:35:00 [fesch]: mk: it isn't necessary or useful for the key shortcut to announce the availability of the key
17:35:10 [fesch]: rs: I want to know...
17:35:31 [Rich]: q?
17:35:45 [fesch]: mk: you can't tell authors to only use it where it activates it and not when gives it focus
17:35:59 [Rich]: ack Rich
17:36:15 [fesch]: mk: you would have to have two properties.... can get the equivalent to what we have on the desktop
17:36:26 [fesch]: cs: is that a problem on the desktop?
17:36:31 [Rich]: q?
17:36:47 [fesch]: mk: gives a checkbox example....
17:36:58 [Rich]: q?
17:37:11 [fesch]: cs: is your expectation based on the control?
17:37:28 [fesch]: cs: is that expected by the user?
17:37:45 [fesch]: mk: I think users have to learn by experience...
17:39:04 [fesch]: jg: providing folks about keyboard interaction is important and being able to do that through ARIA is useful, the rest should be in the HTML 5 spec
17:39:34 [fesch]: rs: will try to make it a global property and let everyone chew on it for a week...
17:40:14 [jamesn]: q+ to get on queue for the text role discussion
17:40:15 [Rich]: https://www.w3.org/WAI/ARIA/track/actions/2023
17:40:18 [fesch]: Topic: Text Role
17:40:25 [clown]: action-2023
17:40:25 [trackbot]: action-2023 -- Joseph Scheuhammer to Write a proposal about how to modify the definition of role text to limit its use. -- due 2016-02-23 -- OPEN
17:40:25 [trackbot]: http://www.w3.org/WAI/ARIA/track/actions/2023
17:41:30 [fesch]: mk: unclear about the need for the role - can improve the support for image role - main concern it hides images from authors - several screen reader users agree
17:42:01 [fesch]: mk: if a screen reader wanted to recognize special images embedded in text, they could do that
17:42:10 [fesch]: q+
17:42:23 [Rich]: ack cyns
17:42:23 [Zakim]: cyns, you wanted to ask whether focus vs. activate might be role-specific? for example, buttons invoke and an edits focus?
17:42:25 [fesch]: mk: don't want to remove that functionality
17:42:33 [cyns]: ack me
17:42:33 [Rich]: ack jamesn
17:42:34 [Zakim]: jamesn, you wanted to get on queue for the text role discussion
17:42:44 [fesch]: jn: I see the image thing where it shouldn't be used
17:43:33 [fesch]: jn: I have seen multiple ways of doing things... there are places where it should not be used... like the rest of ARIA could be used to make things better
17:44:32 [fesch]: jn: a button next to a bunch of text, there is a bunch of links.... we don't make the links focus able.... allowing something that someone can simplify it might be better
17:45:02 [fesch]: mk: wondering if using role=presentation and .... describes alternative....
17:45:27 [fesch]: jn: another example when people want to put a price... and folks want to read that as a single text string
17:45:50 [cyns]: q+ to ask if this is urgently needed and has to be in 1.1? It seems like risk outweighs benefit
17:46:40 [fesch]: ack me
17:47:26 [fesch]: fe: can make a path element that looks like text
17:47:29 [jamesn]: this is from the adobe web site
17:47:30 [jamesn]: <div class="price">$999/mo</div>
17:48:12 [fesch]: mk: maybe we should make it an attribute and limit it to certain elements
17:48:31 [fesch]: rs: there was pushback to limiting it to the img element
17:48:37 [clown]: ★★★☆☆︎
17:48:57 [Rich]: q?
17:49:22 [fesch]: cs: how urgently do we need it? can it wait for ARIA 2?
17:49:58 [clown]: issue-435
17:49:58 [trackbot]: issue-435 -- Consider role="text" to expose elements (and contents) as static text node -- closed
17:49:58 [trackbot]: http://www.w3.org/WAI/ARIA/track/issues/435
17:50:08 [fesch]: mk: the big thing is the use case for SVG.. is the accessible interface... is a different kind of use case
17:50:34 [fesch]: mk: that is a bigger issue
17:50:36 [clown]: Email from Steve F: https://lists.w3.org/Archives/Public/wai-xtech/2011Apr/0007.html
17:50:43 [mck]: +1
17:50:48 [fesch]: rs: are people willing to move it to ARIA 2.
17:51:01 [mck]: +1 for moving text role to aria 2
17:51:07 [fesch]: +1 moving to ARIA 2
17:51:10 [cyns]: +1
17:51:19 [joanie]: +1
17:51:32 [Rich]: +1
17:51:33 [fesch]: jn: if we do it, lets do it right
17:51:47 [janina]: +1 for ARIA2
17:53:29 [Rich]: Proposed Resolution: Move role=“text” to ARIA 2 as issues such as implementing textpatterns (API work) should accompany this including for the SVG host language
17:54:16 [fesch]: cyns: maybe add we cant do this well in 1.1
17:54:47 [Rich]: Proposed Resolution: Move role=“text” to ARIA 2 as the group does not believe it can address the issues well in the ARIA 1.1 time frame.
17:55:25 [fesch]: RESOLUTION: Move role=“text” to ARIA 2 as the group does not believe it can address the issues well in the ARIA 1.1 time frame.
17:56:10 [fesch]: rss, make minutes
17:56:17 [fesch]: rrs, make minutes
17:56:27 [Rich]: RRSAgent, make minutes
17:56:27 [RRSAgent]: I have made the request to generate http://www.w3.org/2016/03/31-aria-minutes.html Rich
17:57:11 [clown]: clown has joined #aria
18:15:47 [joanie]: RRSAgent, stop