See also: IRC log
<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
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.
<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...
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
<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"><sup>$</sup>9<sup>99</sup><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.[End of scribe.perl diagnostic output]