<Rich> https://lists.w3.org/Archives/Public/public-aria/2016Mar/0218.html

<Rich> https://lists.w3.org/Archives/Public/public-aria/2016Mar/0218.html

<scribe> scribe: fesch

CSUN round the table

js: refreshable Braille display for $500 announced at CSUN! Bluetooth...

<jemma> can someone copy webx meeting url?

js: quality of dots are great...

<jongund> what is the URL fro webex?

<jongund> what is the webex room number?

<jemma> yeah. it asks Enter the meeting number to join.

CFC for Password Role

<jongund> or host room id

rs: folks are making custom widgets that take passwords

<jongund> can't seem to join webex

mk: AT are capable of echoing keys, not all users choose to echo keys
... most screen readers may have key echo on by default - new users may not know how to turn it off

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
... Joanie Diggs has a solution... describes....
... talking with AT vendors... one vendor doesn't have a problem with a MUST being added to the spec

mc: can't be sure that password is hidden on the screen

<Zakim> joanie, you wanted to make slight clarification about "require"

s /mc/mb/

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 ...

<Zakim> clown, you wanted to ask how to get the rendered characters.

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
... an AT gets it from the accessible text API
... for all elements, when ATs get the text, we always get the rendered text

js: Can you point to a password, in the wild?

rs: came from Cyns...

cyns: came from James Nurthen... my security people say adding a password role does not increase risk because of physical presence
... only possibility is an over the shoulder attack which requires physical presence

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

js: firefox doesn't support autocomplete in input type=password,

jn: but you can't stop password managers

<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

jn: think attacking screen reader users, is a red herring

mc: discussion predicates that people don't use a input password field
... if authors don't use something else, then it isn't needed
... what about the MUST in the spec, one vendor agrees, but we need more input
... 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
... an authoring practice - put password in you label could help as well

cs: I raised this, it seems like a hole in a spec
... in my experience developers will make anything...
... my security folks said adding password role would not increase a security risk

js: wanted to make sure we consider mobile - where you have to hear the keys you are using

<Zakim> janina, you wanted to note that you need to be able to have some kind of echo in mobile

js: if someone is standing over your shoulder, then you have to have a solution... I lowered the volume... to do that

mk: I am wary of doing an AT MUST path, no problem with an AT SHOULD

<joanie> I am too (which is the summary of my earlier comment which Fred asked me to minute)

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
... so we are designing for the AT not the user... that is the primary purpose... not anything for the end user
... 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?

js: I made a similar statement about the value in the password field is plain text.

jd: no
... the rendered text is what you get in the AT

mb: in the accessibility API you don't get the plain text
... I don't think we really need the role

cs: that is the point, HTML has it and ARIA doesn't have it

rs: password is not in SVG...
... in ARIA 1.1 we are trying to align with HTML and SVG, and someone is making passwords right now
... I don't mind a SHOULD rather than a MUST but we should talk with AT vendors...

<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

cs: I think AT MUST is a good thing, but we need to make sure it is attentional --- all specs should be a MUST

<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).

rs: OHHH

<Zakim> MichaelC, you wanted to wonder if security issues are indeed a special case we might consider globally

mc: I wonder if security issues are a reason to have an exception to our normal rules
... I don't know if there are other ARIA roles that impact security... they might be subject to with a MUST

rs: AT vendors did not want to be dictated to, they want to be able to innovate
... had problems with MUST with first user agent guidelines.... I appreciate they want to innovate, more willing to do MUST for security

cs: plenty of vendors would prefer not to have standards, doesn't make it right

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...
... I don't think there is a clear risk

<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").

jd: should have it do same thing it does for input type=password....

mk: good point, if they already do something, then they are good to go

rs: that is if they use input password

<Zakim> cyns, you wanted to say that we don't expose the value of password input in UIA but do for text input

mc: we are asking them to map the password role to whatever they do for input type password

cs: for UIA, we don't expose text for input password for text we do....

mk: I hear consensus on a AT SHOULD rather than a MUST
... we understand the risks Leonie raised...

<mck> +1

<janina> +1

<Zakim> MichaelC, you wanted to draft a consensus expression

rs: do people have an object to Joanie to modifying her branch and putting it out for consensus?

mc: I agree with that and Matt summarized it ...

<Zakim> clown, you wanted to suggest that authors MUST obscure the text for a custom password ?

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

rs: I don't know if we can do that, can't test for that
... could have a authors SHOULD....

mk: the thing we should do is have AT's echo what is visible on the screen...

<Rich> https://rawgit.com/w3c/aria/password-role/aria/aria.html#password

mk: it's fine as long as AT user is aware the password is/isn't obscurred

rs: Joanie OK with the changes?

jd: should not allow on input type text
... how would someone obscure it?

js: you have a script ...

mc: would be hard to have a requirement in ARIA spec, have to go into HTML spec...

rs: each element in HTML 5.1 can restrict roles...

mc: that would have to be taken to the HTML group

jd: only changes are about AT relaying the visible text

<clown> https://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-input-password

mc: part of the discussion is to have it map to the same way input type password works - has that been done?

js: yes

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

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 ...
... authors need to test with different keyboards...

mk: if you come up with wording that satisfies what folks have been raising...

rs: right now keyset is not global.... it should be global
... trying to do it in a single attribute could be a mess

mk: drafted wording already...

ARIA key shortcuts (already ongoing)

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
... AT doesn't know the difference between the two scenarios - change focus vs activate
... all shortcuts do is document what is happening

<cyns> +1

mk: key shortcuts is only communicating information - not providing support (onclick) - only purpose to provide information - doesn't add in functionality

<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.

mk: when you go into software today, and you hear a keyboard shortcut - they only thing the AT does is make an announcement
... screen reader may have a hot key - it doesn't tell you what the keyboard shortcut does -

rs: you have user interface conventions, on the web we don't have consistent conventions for keys...

mk: purpose only for providing information - no plans for the property to tell the AT what the response to the key is

rs: what if you want an activate and a focus?

mk: not possible with what is proposed
... would be odd and silly

rs: why?
... why isn't what Chaals proposed enough?

jn: those are proposed - this documents what we have done in JavaScript

rs: neither of you have convinced me...

mk: it isn't necessary or useful for the key shortcut to announce the availability of the key

rs: I want to know...

mk: you can't tell authors to only use it where it activates it and not when gives it focus
... you would have to have two properties.... can get the equivalent to what we have on the desktop

cs: is that a problem on the desktop?

mk: gives a checkbox example....

cs: is your expectation based on the control?
... is that expected by the user?

mk: I think users have to learn by experience...

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

rs: will try to make it a global property and let everyone chew on it for a week...

<Rich> https://www.w3.org/WAI/ARIA/track/actions/2023

Text Role

<clown> action-2023

<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

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2023

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
... if a screen reader wanted to recognize special images embedded in text, they could do that

<Zakim> cyns, you wanted to ask whether focus vs. activate might be role-specific? for example, buttons invoke and an edits focus?

mk: don't want to remove that functionality

<Zakim> jamesn, you wanted to get on queue for the text role discussion

jn: I see the image thing where it shouldn't be used
... 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
... 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

mk: wondering if using role=presentation and .... describes alternative....

jn: another example when people want to put a price... and folks want to read that as a single text string

fe: can make a path element that looks like text

<jamesn> this is from the adobe web site

<jamesn> <div class="price">^$9⁹⁹<small>/mo</small></div>

mk: maybe we should make it an attribute and limit it to certain elements

rs: there was pushback to limiting it to the img element

<clown> <p><span role="text img" aria-label="3 of 5 stars">★★★☆☆︎</span></p>

cs: how urgently do we need it? can it wait for ARIA 2?

<clown> issue-435

<trackbot> issue-435 -- Consider role="text" to expose elements (and contents) as static text node -- closed

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/435

mk: the big thing is the use case for SVG.. is the accessible interface... is a different kind of use case
... that is a bigger issue

<clown> Email from Steve F: https://lists.w3.org/Archives/Public/wai-xtech/2011Apr/0007.html

<mck> +1

rs: are people willing to move it to ARIA 2.

<mck> +1 for moving text role to aria 2

+1 moving to ARIA 2

<cyns> +1

<joanie> +1

<Rich> +1

jn: if we do it, lets do it right

<janina> +1 for ARIA2

<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

cyns: maybe add we cant do this well in 1.1

<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.

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.

rss, make minutes

rrs, make 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/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/discussion//
Succeeded: s/roundtable/round the table/
Succeeded: s/when we get/for all elements, when ATs get the text/
Succeeded: s/support autocomplete in passwords/support autocomplete in input type=password/
Succeeded: s/mc/mb/
Found Scribe: fesch
Inferring ScribeNick: fesch
Present: Michiel_Bijl Joanmarie_Diggs Rich_Schwerdtfeger fesch Janina matt_king Joseph_Scheuhammer JaEunJemmaKu Bryan_Garaventa
Found Date: 31 Mar 2016
Guessing minutes URL: http://www.w3.org/2016/03/31-aria-minutes.html
People with action items: 

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